Re: Implementation of semantics

Thank you for all your response. It seems that not everybody agree about 
the way semantics should be implemented and one additional confusing 
aspect is that the intentionally simplistic Gecko implementation is used 
in practice. So I guess Webkit and Gecko should try to do their best to 
implement a consistent behavior across browsers and perhaps the spec 
could be made more accurate.

Regarding my fourth question, I think it does not really make sense 
either to take the presentation MathML to determine whether it is an 
embellished operator, when this element is not visible. At least in 
Gecko, the embellished operator data passed to the parent also contain 
who should be stretched, so it's really relevant only if it is the 
operator is visible. So I think the correct behavior is to do as 
maction: the visible child is used to determine whether it is an 
embellished operator. Of couse, this only applied if the visible child 
is a presentation MathML. Also <maction> is space-like if the selected 
child is space-like and I guess that should be the same for <semantics>. 
Actually, I plan to share <maction> and <semantics> implementation in 
Gecko (both of them select one visible child after all) and so it would 
be best if the two behaviors were consistent.

BTW, I guess <annotation-xml> should be said to behave as <mrow>, so 
that the embellished op data and "space-like-ness" are passed to the 
parent when <annotation-xml> is the selected child of <semantics>.

On 30/10/2012 06:16, Neil Soiffer wrote:
> A little background first...
>
> semanatics/annotation was originally conceived as an open-ended 
> extension method for various purposes.  For products that had their 
> own internal representation, they could write that out inside of an 
> annotation and not lose that info when converting to MathML (assuming 
> all of the MathML was pasted back in).  One could also use it to tie 
> together presentation and content MathML.
>
> MathML 3 formalized some of those uses via the "cd" and "name" attrs.  
> I'm a bit dubious they are used much, so the primary thing to look at 
> (and only thing if they aren't present) is the encoding attr.  Those 
> are used but not really standardized other than the ones you mention 
> for MathML.
>
> I would guess that >99.9% of the uses of semantics have presentation 
> MathML as the first element *without* using an annotation.  The 
> annotation-xml element can be wrapped around the first element and it 
> can still be presentation MathML, but the presentation MathML could be 
> in some child other than the first child.
>
> For MathML inside of another environment, it is up to that environment 
> to define what is legal where.  HTML5 says you can put HTML inside of 
> mtext, so that is how you can add SVG to MathML *in an HTML 
> document*.  It won't likely work outside of an HTML5 environment 
> though.  I thought that annotation-xml was another legal place, but I 
> don't see it listed in [1].  It is however mentioned at [2]. I don't 
> know the normative nature of either of those documents.  Using 
> annotation-xml is a way to get SVG safely into MathML when you care 
> about other targets than HTML5.
>
>
> So on to your questions:
>
> 1.  If the implementation can handle something besides presentation 
> MathML, it probably should seriously consider using the alternative if 
> it is present.  After all, why go to the trouble of generating an 
> alternative if you don't think it is better/has more info?  So if SVG 
> is present and Firefox or Webkit can display SVG better than 
> presentation MathML, I'd suggest you use it.  The spec leaves this 
> decision up to the implementation, so the choice/decision is yours to 
> make.
>
> If there is no presentation MathML, then pick whichever format you 
> feel you can render.  I would tend to pick a richer format such as SVG 
> over plain text, but the spec says the choice is yours.
>
> 2.  Despite what the schema may say (another fix needed?), the first 
> child can be annotation/annotation-xml in addition to "raw" MathML. 
> That annotation can be presentation MathML, SVG, or XHTML.  You might 
> want to use the order to determine the top pick. I don't recall if we 
> discussed using ordering for a preference in the MathML WG.  If we 
> did, it didn't make it into the spec.
>
> 3.  I don't have anything to add to Paul and David's answers about 
> "official" encodings.
>
> 4.  I think you should take the Presentation MathML, whether you use 
> it for rendering or not, to determine whether this is an embellished 
> operator.  I think the wording in "3.2.5.7.3 Exception for embellished 
> operators" needs some cleanup as it doesn't make sense if the first 
> child is not presentation MathML. It was meant for msub and friends 
> and I think semantics was added to that text without thinking about it 
> completely.
>
>
> Neil Soiffer
> Senior Scientist
> Design Science, Inc.
> www.dessci.com <http://www.dessci.com>
> ~ Makers of MathType, MathFlow, MathPlayer, MathDaisy, Equation Editor ~
>
>
> [1] http://dev.w3.org/html5/html4-differences/
> [2] http://blog.whatwg.org/category/syntax/page/2
>
>
>
> On Mon, Oct 29, 2012 at 1:23 PM, Frédéric WANG <fred.wang@free.fr 
> <mailto:fred.wang@free.fr>> wrote:
>
>     Hi,
>
>     I have some questions about the correct implementation of
>     semantics, discussed on the Webkit bug tracker:
>
>     https://bugs.webkit.org/show_bug.cgi?id=100626
>
>     So the correct behavior is basically to use the first child as the
>     default rendering and find possible alternate renderings among the
>     annotation children. Some questions:
>
>     1) Does the following implementation make sense for a browser
>     without Content MathML support:
>
>     - Test if the first child is a presentation MathML element and if
>     so, display it.
>     - Otherwise, read the list of other children in that order and
>     display the first <annotation-xml> with a known encoding ; or a
>     plain text <annotation> if one is found.
>
>     2) I think the first child can only be presentation / content
>     MathML. But does that means that an <annotation> or an
>     <annotation-xml> (which are MathML elements) can be used as the
>     first child (to include SVG or HTML descendants for example)?
>
>     3) What are the official encoding values other than MIME
>     content-type? The REC mentions "Content-MathML",
>     "Presentation-MathML" for backward compatibility. The W3C note
>     http://www.w3.org/Math/Documents/Notes/graphics.xml#svg-in-mathml-guidelines
>     also contains the "SVG1.1" value, but is it official?
>
>     4) The spec says that <semantics> is an embellished operator if
>     the first child is one. But should we actually consider the
>     visible child  (as we do for maction)?
>
>     -- 
>     Frédéric Wang
>     maths-informatique-jeux.com/blog/frederic
>     <http://maths-informatique-jeux.com/blog/frederic>
>
>
>


-- 
Frédéric Wang
maths-informatique-jeux.com/blog/frederic