Alex,
> Uncle! This will take some work to get working correctly with the > implementation in WebKit. Sorry about that. > Right now, in XHTML documents with MathML, > we get non-token XHTML for free. Within MathML token elements, this > won't necessarily be the case. For example, the 'mo' element renderer > as currently implemented won't preserve child rendering objects. > We'll need to detect these situations and decide what to do. Hmm, the mathml3 spec particularly recommends mtext as the extension point although I think it made sense to specify all the token elements for the parser, to switch to html rendering as it's much easier for validation or convention to restrict the document type than to extend the parser later. > It would have been nice if MathML 3 had a "foreign token" element or > indication via attribute typing so that we'd know that there is some > kind of non-MathML content children that should be rendering according > to the host language. But elsewhere you argue that such an element isn't needed and you should just be able to drop in other namespaced elements anywhere. in fact MathML3-in-(x)html does specify such an element, namely content of mo mi mtext are specified as being html. > We'll now have to have some kind of de-facto > default set of rules that say that mixed content within a MathML is > identified and handled slightly differently (especially if it contains > things like SVG). differently to what? Sorry I'm not sure I understand what you mean here, can't you just always view the content of mtext as inline html: it basically has the same content model as the content of an html span. SVG is allowed there just because it's allowed in any inline html. Clearly if you are looking up the content of mo in an operator dictionary that will only succeed if the mo only contains character data, but even if the mo does contain character data the dictionary lookup will fail in general if you have a finite dictionary and an arbitrary string as the content of the mo, so having it fail on mixed content isn't (in the abstract) any different, although I accept that an implementation may have different concerns. > That is, we'll need to detect things like: > <math><mo> random text <svg> ... </svg> more random text</mo></math> as above i don't see why you need to "detect" such things any more than you need to "detect" <span> random text <svg> ... </svg> more random text</span> In fact your original proposal was that <math><span>.....<svg>.... should just work, and so what is to stop mtext being treated exactly like span? David _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
