[webkit-dev] HTML5 Parsing & MathML

[David Carlisle]

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