Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Clarify MathML integration points #101

Closed
fred-wang opened this issue Jun 10, 2019 · 10 comments
Closed

Clarify MathML integration points #101

fred-wang opened this issue Jun 10, 2019 · 10 comments
Labels
MathML Core Issues affecting the MathML Core specification need specification update Issues requiring specification changes

Comments

@fred-wang
Copy link

The MathML Core spec defines the following integration points:
https://mathml-refresh.github.io/mathml-core/#othertech

In particular, it relies on the validator schema:
https://github.com/validator/validator/blob/master/schema/.drivers/html5-svg-mathml.rnc#L9
https://github.com/validator/validator/blob/master/schema/.drivers/html5-svg-mathml.rnc#L11
https://github.com/validator/validator/blob/master/schema/.drivers/html5-svg-mathml.rnc#L18
https://github.com/validator/validator/blob/master/schema/.drivers/html5-svg-mathml.rnc#L29

By default MathML4's RelaxNG schema does not allow foreign content in token elements. However, there are suggestions to allow it in Chapter 6:
https://mathml-refresh.github.io/mathml/chapter6.html#world-int-combine-other

Finally, the WHATWG HTML5 spec describes integration points for mi, mo, mn, ms, and mtext, annotation-xml and foreignObject:
https://html.spec.whatwg.org/#mathml
https://html.spec.whatwg.org/#svg-0

MathML WPT Tests:
https://github.com/web-platform-tests/wpt/tree/master/mathml/relations/html5-tree
@fred-wang fred-wang added MathML Core Issues affecting the MathML Core specification need implementation update need polyfill Issues requiring implementation changes need resolution Issues needing resolution at MathML Refresh CG meeting need specification update Issues requiring specification changes need tests Issues related to writing WPT tests labels Jun 10, 2019
@fred-wang
Copy link
Author

cc @annevk @sideshowbarker @bkardell @rwlbuis

I'd like to better align all these definitions (at least Core and WHATWG) and not refer to the validator schema. Some things to consider:

  1. <math> is allowed in <foreignObject> per the HTML5 spec because it's flow content (probably the validator schema should do common.elem.flow |= math).
  2. <svg> is allowed in <annotation-xml> per the HTML5 spec because it's flow content (probably the validator schema should do common.elem.flow |= svg). I believe we can remove the restriction on the encoding attribute (see also Simplification of the <semantics> element #100).
  3. The validator allows <html> in <annotation-xml> but I'm not sure that's true per the HTML5 spec. The MathML full spec contains such an example https://mathml-refresh.github.io/mathml/chapter5.html contains such an example. Do we really want that? If so, can the restriction on the encoding attribute be removed (see issue Simplification of the <semantics> element #100)?
  4. Should we allow foreign content in <mtext> only or in any token element? Should we instead have some generic foreignObject-like MathML element?

@NSoiffer NSoiffer mentioned this issue Jun 10, 2019
Closed
@fred-wang
Copy link
Author

I've improved a bit the description of HTML parsing:
https://mathml-refresh.github.io/mathml-core/#web-platform-integration

My proposal is the following:

It seems the only controversial change is whether to allow phrasing content in mi, mo, mn, ms too. Some arguments:

  • That would allow to get rid of the mglyph element Remove/Deprecate mglyph element #25, since you can then e.g. use an "img" tag inside the token element instead.
  • More generally, it's good to be able to tag a foreign element with a special type, e.g. <mn><input id="number" type="number" value="42"></input></mn> is more correct for MathML authors than using mtext. Or you can use <mo><select>my list of operators</select></mo> with custom lspace/rspace attributes which is not possible with mtext etc
  • This is already in the HTML5 spec, so it seems a bug in the checker :-)
  • This is relaxing the restriction, so shouldn't break backward compatibility.
  • This might require some special handling in the MathML browser implementation, but it does not seem harder than the mtext case.

Also this is perhaps a separate discussion, but we might want to allow foreign content in mrow that accept phrasing content (or introduce a foreignObject-like MathML element). Rationale:

  • This would allow to embed HTML custom element anywhere in the MathML formulas (not only in token elements).
  • This would address the use case of people using <annotation-xml> to embed foreign content (see the non-valid case discussed in Simplification of the <semantics> element #100).

@fred-wang
Copy link
Author

@sideshowbarker I think this is a bit a separate discussion, but yes it would make sense to have the HTML checker verify validations against the stricter MathML Core spec (perhaps as a default option). As I understand, Apple's concern is about the fact that a stricter MathML could break backward compatibility, so we are implementing these restrictions under a "MathML Core" flag. But in general there should be no problem with improving or extending MathML support. Note that in this case, my proposal is actually to make things more relaxed (see #101 (comment)).

@annevk annevk mentioned this issue Jun 12, 2019
Closed
@davidcarlisle
Copy link
Collaborator

It seems the only controversial change is whether to allow phrasing content in mi, mo, mn, ms too.

Personally I'd be in favour of this.

The original description of nesting in mathml suggested html be allowed in all token elements but (as far as I recall the conversations) when the actual merge got specified in whatwg/html5 there was a feeling to be cautious at first and restrict the integration points so just allow mtext (or at least only declare that case as valid input) but if there are no real implementation hurdles here then treating all token elements in the same way (and declaring them valid author input) if they have html would be better.

@NSoiffer
Copy link
Contributor

Just want to be clear about the proposal...

Is the proposal to all foreign content at the character level or token level. That is, is this legal:
<mn> 23 <input> ... </input> 4 </mn>

If not, then this isn't a direct replacement for mglyph since that acts as a character. On the other hand, if we say any foreign content must be the entire contents of mn, mtext, etc., then that likely simplifies implementations.

Personally, I like the idea of a new foreign object element, but I think that ship has sailed.

@fred-wang
Copy link
Author

Is the proposal to all foreign content at the character level or token level. That is, is this legal:
<mn> 23 <input> ... </input> 4 </mn>

Yes AFAIK that's currently legal per the HTML spec, so the proposal is to accept it in core too (rather than following the validator)

fred-wang added a commit to w3c/mathml-core that referenced this issue Jun 17, 2019
@fred-wang
Update description about integration points (refer to HTML) and menti…
b668a1e 
…on the particular MathML cases in a note.

w3c/mathml#101
w3c/mathml#102
@fred-wang
Copy link
Author

We agree to follow what HTML allows during today's meeting.
Section updated: https://mathml-refresh.github.io/mathml-core/#html-and-svg

@fred-wang fred-wang removed need implementation update need resolution Issues needing resolution at MathML Refresh CG meeting labels Jun 17, 2019
@fred-wang fred-wang reopened this Jun 18, 2019
@fred-wang fred-wang mentioned this issue Jun 28, 2019
Open
@NSoiffer
Copy link
Contributor

This has the 'need-polyfill' label. What needs to be polyfilled?

@fred-wang
Copy link
Author

I think this can be removed.

@fred-wang fred-wang removed need polyfill Issues requiring implementation changes need tests Issues related to writing WPT tests labels May 19, 2020
@fred-wang
Copy link
Author

I'm also removing need tests as we already have some and most are in HTML actually. So we can close this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
MathML Core Issues affecting the MathML Core specification need specification update Issues requiring specification changes
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@fred-wang @davidcarlisle @NSoiffer