On Wed, Nov 3, 2010 at 7:49 AM, David Carlisle <[email protected]> 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 _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
