[Webkit-unassigned] [Bug 100626] Support semantics annotation-xml elements

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=100626





--- Comment #14 from David Carlisle <davidc at nag.co.uk>  2012-10-30 03:32:41 PST ---

> --- Comment #13 from Jacques Distler <distler at golem.ph.utexas.edu> 
> 2012-10-29 18:31:49 PST --- (In reply to comment #12)
> 
>> The usage with no base expression and just annotations is really an
>> abuse of notation that was valid MathML2 because of loose schema
>> enforcement and works in gecko
> 
> Indeed, I seem to recall that the more "correct" usage, with a bogus
>  <csymbol> element as the first-child (and the <annotation-xml> 
> element as the second child) DIDN'T work. Omitting the bogus 
> <csymbol> worked fine in Gecko, so that's what I implemented.


Yes Gecko's implementation of just a simple css switch that
unconditionally renders the first child. I thought after posting that I
may have sounded a bit harsh on you which wasn't really fair (or
intended). I have the same problem with my own documents of juggling
between what is "standard" and what works. Choosing what works (and if
necessary getting the standard to change is not an unreasonable strategy.

> 
> On the other hand, not having a mechanism for fallback content, when
>  constructing such a compound document, is not a good idea either.

well you can still use semantics/annotation-xml to offer alternative
renderings to the mtext/svg so it's not that there is no mechanism it's
just that the markup cycles round a bit.

> 
> (Full disclosure; itex2MML's \begin{svg}...\end{svg} doesn't really 
> provide a convenient mechanism for including fallback content. But 
> more competently-designed authoring software certainly could.)
> 
> I could easily modify itex2MML to emit a bogus <csymbol> as the 
> first-child of <semantics>, with the actual SVG payload in the 
> second-child <annotation-xml>. ALL browsers would ignore the 
> <csymbol> element, and the SVG-capable ones would render the SVG.

I'd rather view html+svg+mathml as a combined coherent document format
for scientific documents and see svg directly included in mathml via mtext
rather than as a foreign annotation in annotation-xml. If you do want to
use a semantics/annotation encoding to also work in pure mathml systems
that don't do svg I think the most natural first child now to use would
be an mglyph referencing an image fallback for the svg.

> 
> (Well, OK, Firefox would have to be modified, but it seems that's in
>  the works, anyway.)
> 
>> It has the benefit of working in firefox but structurally, 
>> annotating nothing isn't really what is wanted here.
> 
> Well, I'll note that the Spec
> 
> http://www.w3.org/TR/MathML3/chapter3.html#presm.mtext
> 
> doesn't exactly go out of its way to indicate that <mtext> is the 
> preferred mechanism for building compound documents. In fact, unless
>  I misunderstand the schema
> 
> http://www.w3.org/TR/MathML3/appendixa.html#parsing_mtext
> 
> that usage is forbidden.
> 

The descriptin in chapter 3 and the schema in apendixa is for pure mathml
so doesn't allow element content in the token elements.
The use in a compound (x)html+mathml document is governed by
section 6.4 which says


> When designing a compound document format in which MathML is included
> in a larger document type, the designer may extend the content model
> of MathML to allow additional elements. For example, a common
> extension is to extend the MathML schema such that elements from
> non-MathML namespaces are allowed in token elements, but not in other
> elements. MathML processors that encounter unknown markup should
> behave as follows:

> ...

> Extending the schema in this way is easily achieved using the Relax 
> NG schema described in Appendix A Parsing MathML, it may be as
> simple as including the MathML schema whilst overriding the content
> model of mtext:
> 
> 
> default namespace m = "http://www.w3.org/1998/Math/MathML"
> 
> include "mathml3.rnc" { mtext = element mtext {mtext.attributes, 
> (token.content|anyElement)*} }

This is what the xhtml+mathml schema and (perhaps more importantly) the
hardwired rules in the HTML5 parser allow.

Currently the documentation of mathml+html(+svg) is regrettably rather
sparse. The MathML spec takes the view noted above that pure mathml is
just mathml and it is up to the host document type to define compound
formats. In this case the host document type is html5 but (apart from
the parser) the html(5) spec takes the view that everything that occurs
within <math> is deferred to the mathml spec. I've raised this as an
issue on html5 before without any great effect. I suspect we should
first get a good solution that works in webkit and gecko and then write
it up as a note or something so people have a better chance of finding it.

(I suspect we are wandering way off topic for a webkit bug: if the webkit folks rather we move this to www-math at w3.org, or anywhere else, please say)

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.