Synchronization with WHATWG HTML5 spec

[fred-wang]

cc @bkardell @rwlbuis @emilio @bfgeek @annevk

HTML relationship is defined described here in the MathML Core spec: https://mathml-refresh.github.io/mathml-core/#html-and-svg

When parsing HTML documents user agents must treat any of the following MathML Core elements as belonging to the MathML namespace

Users agents must allow mixing HTML, SVG and MathML elements as allowed by sections HTML integration point, MathML integration point, tree construction dispatcher, MathML and SVG from [HTML].

MathML relationship is described here in HTML5: https://html.spec.whatwg.org/#mathml

The MathML math element falls into the embedded content, phrasing content, flow content, and palpable content categories for the purposes of the content models in this specification.
When the MathML annotation-xml element contains elements from the HTML namespace, such elements must all be flow content.
When the MathML token elements (mi, mo, mn, ms, and mtext) are descendants of HTML elements, they may contain phrasing content elements from the HTML namespace.

I'm not sure what should happen when a child is "invalid" i.e. the content model of an element is not expected by its parent. For MathML, I think for example WebKit does not create any layout node fro children of token elements that are not HTML contain phrasing content. Probably this constraint is only for validators and the rendering engine should just ignore it (Maybe create an anonymous wrapper if necessary)?

User agents must handle text other than inter-element whitespace found in MathML elements whose content models do not allow straight text by pretending for the purposes of MathML content models, layout, and rendering that the text is actually wrapped in a MathML mtext element. (Such text is not, however, conforming.)

<math>text</math> is visible in Gecko but WebKit and Igalia's Chromium don't create any text layout text node. I guess we again just want to allow such a text inside math (Maybe wrapped in an anonymous mtext node)? In any case, it seems something that has to be specified in MathML Core, not in HTML5, so we should ask the WHATWG to remove it.

User agents must act as if any MathML element whose contents does not match the element's content model was replaced, for the purposes of MathML layout and rendering, by a MathML merror element containing some appropriate error message.

@davidcarlisle mentioned it in https://github.com/mathml-refresh/mathml/issues/15#issuecomment-469405242 ; the conclusion from w3c/mathml-core#136 is that we don't want this constraint. So I guess we should ask the WHATWG to remove it.

To enable authors to use MathML tools that only accept MathML in its XML form, interactive HTML user agents are encouraged to provide a way to export any MathML fragment as an XML namespace-well-formed XML fragment.

I'm not sure what is expected from this paragraph? I think people interested in that should probably write WebExtensions to export / XML-serialize MathML content rather than having a vague suggestion in the HTML5 spec? (See similar discussion about the "mathml view source" in https://groups.google.com/forum/#!topic/mozilla.dev.tech.mathml/S0CdPUJuQnY)

The semantics of MathML elements are defined by MathML and other applicable specifications. [MATHML]

I think we should ask the WHATWG to refer to at least MathML Core.

Here is an example of the use of MathML in an HTML document:

nit: I think the form attribute is optional here and invisible operators should be written as &#XXXX; instead as that's otherwise confusing.

[annevk]

You will basically have to define somewhere what the layout model for MathML is and that will have to deal with all possible structures (not just those that are valid). Firefox's behavior of saying something to the extent of "invalid markup" should be a non-goal for this. Doing what SVG does (not rendering the subtree) seems reasonable.

[NSoiffer]

I'm still thinking about the harder issues, but for the simpler ones at the end:

1. I agree that at least for their example so that it is clear, they should write the invisible times as ⁢.

2. Re: "...export any MathML fragment as an XML namespace-well-formed XML fragment." For clarity, I think their example should have started
   <math xmlns='http://www.w3.org/1998/Math/MathML'>
   They could point to that as an example of a "an XML namespace-well-formed XML fragment." MathML, like SVG, does have a special status in the parsing of HTML documents and I don't see why support of that status shouldn't extend to exporting that fragment as it is still compatible with import as HTML.

[fred-wang]

2. Re: "...export any MathML fragment as an XML namespace-well-formed XML fragment." For clarity, I think their example should have started
   `   <math xmlns='http://www.w3.org/1998/Math/MathML'>`

I think the idea is to show an example of MathML in HTML5, which does not require xmlns.

   They could point to that as an example of a "an XML namespace-well-formed XML fragment." MathML, like SVG, does have a special status in the parsing of HTML documents and I don't see why support of that status shouldn't extend to exporting that fragment as it is still compatible with import as HTML.

Again, I still have no idea what is meant by the vague statement "a way to export any MathML fragment as an XML namespace-well-formed XML fragment". It there anything like that implemented in WebKit and Gecko? The DOM inspector does not seem to do that and view source was removed in https://bugzilla.mozilla.org/show_bug.cgi?id=1365626 ; I don't think HTML5/MathML Core should specify that, it's more a feature that can be implemented as a browser add-on in my opinion. cf the discussion with view source.

[annevk]

@fred-wang it's a tooling suggestion. Anyway, I've suggested removing that in whatwg/html#4962. Is that okay with you all?

[fred-wang]

@annevk Thanks Anne. Well I guess we haven't really discussed any of the item during a MathML CG meeting so although I'm personally in favor of removing this suggestion I think we should wait that we have consensus on this before merging the change.

[bkardell]

This seems reasonable to me. @davidcarlisle commented as much too on @annevk's link

[fred-wang]

mglyph and malignmark are mentioned in the HTML5 specifications:

https://html.spec.whatwg.org/multipage/parsing.html#tree-construction
https://html.spec.whatwg.org/multipage/parsing.html#mathml-text-integration-point

However, they have never been implemented in browsers and are currently not mentioned in https://mathml-refresh.github.io/mathml-core/#dfn-mathml-core-elements. See also #25 and #181

The ms element is also mentioned in several places but in #120 we decided to keep it in MathML Core and make it behave like an mn.

@MathML CG: Can we reach a final decision on #25? Should we then propose the WHATWG to remove the special cases or mglyph and malignmark? Alternatively, we can keep them in MathML Core but make them behave like an mrow.

[NSoiffer]

Discussed at Aug 17 meeting.
Consensus is to treat mglpyh/maligngroup/malignmark as unknown elements (#139 -- treat as mrows). No need to contact HTML WG/WhatWG.

[fred-wang]

AFAIK, the core spec never mentioned mglyph/maligngroup/malignmark and so they are currently treated as unknown. No change needed.

[NSoiffer]

Closing as there does not appear to be anything left to resolve