Simplification of the <semantics> element

[fred-wang]

The typical usage of the semantics element is as followed:

<semantics>
  [ANNOTATED PRESENTATION MATHML CHILD]
  <annotation encoding="application/x-tex">...</annotation>
  <annotation-xml encoding="MathML-Content">...</annotation-xml>
  ... MORE ANNOTATIONS ...
</semantics>

WebKit and Gecko will render the first child.

Currently, Chromium (without MathML support) will always hide that child but display all the annotations (which is ok when there is only one text annotation):
https://chromium.googlesource.com/chromium/src/+/HEAD/third_party/blink/renderer/core/css/mathml.css#40

A non-common case is when the first child is actually content MathML:
https://mathml-refresh.github.io/mathml/chapter5.html#mixing.alternate.representations
WebKit and Gecko will then actually try to render either a text annotation or a MathML/SVG/HTML annoation-xml:
https://mathml-refresh.github.io/mathml-core/#sematicsandpresentation
(Chromium will wrongly display all the children)

Another (non-valid) use case is when the semantics only has one annotation-xml child:

  <semantics>
    <annotation-xml encloding="SVG1.1">...</annotation-xml>
  </semantics>

which @distler has used to embed SVG inside MathML.
WebKit, Gecko and Chromium will properly handle that case too.

[fred-wang]

I'm not sure what will be the outcome of #47, but browser developers are not really fond of content MathML. My suggestion for MathML Core is thus to assume that the first child is presentation markup and then hide the annotations. Hence the proposal will be the same as what we decided for maction (#26):

• Treat maction as an mrow for layout purpose.
• Make the default display values of all but the first child display: none (it can be overridden by users via standard CSS).

This is Gecko's legacy implementation which is compatible with (and motivated) the non-valid SVG case above. Users could also override the behavior if they want to render annotations instead of presentation MathML.

[NSoiffer]

That seems reasonable to me. Core is all about making rendering in browsers simpler. A polyfill can always rearrange the children of semantics to make this work... assuming that there is some presentation that can be moved to be the first child. Potentially, the polyfill could hook into a content-to-presentation translator to generate presentation MathML. A wrinkle on such a translator is that needs to generate core MathML.

…

On Sun, Jun 9, 2019 at 10:06 PM Frédéric Wang ***@***.***> wrote: I'm not sure what will be the outcome of #47 <#47>, but browser developers are not really fond of content MathML. My suggestion for MathML Core is thus to assume that the first child is presentation markup and then hide the annotations. Hence the proposal will be the same as what we decided for maction (#26 <#26>): - Treat maction as an mrow for layout purpose. - Make the default display values of all but the first child display: none (it can be overridden by users via standard CSS). This is Gecko's legacy implementation which is compatible with (and motivated) the non-valid SVG case above. Users could also override the behavior if they want to render annotations instead of presentation MathML. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#100>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AALZM3ANYGQLOQCYA5QVY2LPZXOODANCNFSM4HWQNMGQ> .

[fred-wang]

We agreed during yesterday's meeting to follow #100 (comment)
I've rewritten the section accordingly: https://mathml-refresh.github.io/mathml-core/#semantics-and-presentation

[fred-wang]

https://lists.w3.org/Archives/Public/public-mathml4/2019Jun/0013.html

ADOPTED: render 1st child for Core default

ACTION ITEM: ADD issue for the Full spec as to what to do; this touches on
#101 on integration; and how the polyfill is affected

[Jamesernator]

but browser developers are not really fond of content MathML

They should be using it for screen readers, but otherwise I don't see what browsers should do with content MathML.

Content MathML is explicitly defined as not being tied to presentation and may not have a particular rendering (it's even the first sentence of the spec) so I don't think it makes sense for browsers attempt to render it.

For example something as simple as multiplication could be represented by a × b or a ⋅ b or even just ab depending on notational preference.

I personally think it's better to leave it to userland to generate (or hand author) a specific rendering as it's more likely the author will have a clearer preference for their specific use case on how it should be rendered.

As an example when representing the formula E = mc², using INVISIBLE TIMES (U+2062) for multiplication is more likely in that shorthand. However when showing full names then INVISIBLE TIMES wouldn't be used and instead one of the other representations would be used e.g. Energy = mass × accelaration².

[fred-wang]

Tested by
https://w3c-test.org/mathml/presentation-markup/mrow/legacy-mrow-like-elements-001.html
https://w3c-test.org/mathml/presentation-markup/mrow/legacy-mrow-like-elements-002.html

so closing.

[NSoiffer]

Needs a polyfill, so reopening.