[webkit-dev] HTML5 Parsing & MathML

[Alex Milowski]

On Wed, Nov 3, 2010 at 7:49 AM, David Carlisle <d.p.carlisle at gmail.com> wrote:
>
>> 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.
>

Sure. ...didn't win that one!  :)

We have these token categories:

   * identifier (mi)
   * number (mn)
   * operator (mo)
   * text (mtext)
   * space (mspace)
   * string (ms)

What if our use of some chunk of HTML doesn't fit in the
categorization of the above?  I would have been nice to have an
ability to annotate "foreign markup" as some kind of layout element
implemented in, say, HTML, and then potentially use embedded
additional MathML for inner constructs.  That way, things like
accessibility would know that the foreign markup isn't a terminal
structure of the Mathematics and might know (e.g. via ARIA) the role
of the layout.

...so, that's what I meant.   Just an idea ...

>> 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.

Right.  That's not different from what we'd expect.  In section 3.2.1, it says:

"Token elements (other than mspace) should be rendered as their
content, if any, (i.e. in the visual case, as a closely-spaced
horizontal row of standard glyphs for the characters or images for the
mglyphs in their content)."

Introduce a few SVG and HTML elements and then you have to make the
assumptions about the children that are being rendered according to
the normal rules (plus mglyph) so that this works:

<mi> xyzzy <div> .... </div> </mi>

Without any CSS, that 'div' will be a block whose rendering will cause
a new block to be stacked within the inline.  That's a consequence of
my choice of using inline blocks and allowing the rendering of the
'div' to default to the current internal style within WebKit.  I think
that's the right choice but there might be other interpretations.  For
example, one could say that divs inside MathML have a display property
of inline-block by default.

That choice isn't covered by either MathML3 nor HTML5.  I'm not sure
it should be.

>> 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"

Well, that's a consequence of building the rendering tree.  Right now
we don't have a special rendering object for token elements other than
for 'mo'.  In the case of operators, this becomes complicated due to
operator stretching.  It may work out to be straightforward but those
feel like famous last words.  That's all I meant.

>
> 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?
>

No much and hopefully it stays that way.

At this point I'm not raising any issue except that I know that our
'mo' implementation is currently broken in this regard.

-- 
--Alex Milowski
"The excellence of grammar as a guide is proportional to the paucity of the
inflexions, i.e. to the degree of analysis effected by the language
considered."

Bertrand Russell in a footnote of Principles of Mathematics