structuring common attributes

[davidcarlisle]

MathML3 , in addition to attributes specified on each element had

• Global attributes https://www.w3.org/TR/MathML3/chapter2.html#fund.globatt
  id, xref, class, style, href and other
• Attributes on all Presentation https://www.w3.org/TR/MathML3/chapter3.html#presm.presatt
  mathcolor, mathbackgroud
• Attributes common to token elements https://www.w3.org/TR/MathML3/chapter3.html#presm.commatt
  mathvariant, mathsize, dir

It is perhaps worth noting given recent discussion of intent that class, style, href are similar presentation oriented attributes, introduced as global in MathML3 chapter 2, but given no specific mention in Chapter 4. While these could be used to control CSS acting directly on Content, in practice Content is rendered in most systems via translation to Presentation and so the effect of these attributes depends on the system-specific way they are copied to any generated presentation form.

This structure is still in the draft MathML4 description, notably Attributes common to Presentation, https://w3c.github.io/mathml/#presm_presatt Just lists mathcolor, mathbackgroud

However the draft schema builds up from MathML Core and is structured rather differently.

Core has a much longer list of global attributes,

https://w3c.github.io/mathml-core/#global-attributes

and almost all attributes are global (partly as <mstyle> is down-played in Core becoming essentially a synonym for <mrow>)

so attributes such as onclick are global in Core, as are traditional MathML attributes such as mathvariant

The Global Core Attributes are currently incorporated into the mathml4-presentation schema, and so also the mathml4 full schema, as attributes common to Presentation elements

This means that for example the following invalid MathML 3 example (as mathvariant was just allowed on token elements and mstyle)

<msup mathvariant="bold"><mn>1</mn><mi>x</mi></msup>

is valid MathML Core, and valid to the MathML4 Schema, but not described as valid in the text of the MathML 4 draft.

The same is true of

<msup onclick="something" tabindex=5"><mn>1</mn><mi>x</mi></msup>

and

<msup intent="whatever"><mn>1</mn><mi>x</mi></msup>

---

I am assuming that as far as possible we want MathML4 Full to be a superset of MathML Core so that we do want to make these attributes at least common to Presentation (as allowed by the current schema draft) but some might make sense being made global in Full as well.

Either way, even if they are just valid on Presentation, we probably need to say something about how far they are expected to have a effect on non-web-platform implementations. I'm assuming they can basically be ignored in that case. You can't really do much with an onevent javascript reference if reading MathML in to TeX or Word or Mathematica etc. An alternative would be to not add these attributes to full and structure Core as an "extended subset" of Full that adds these features as well as subsetting MathML Full. That has some benefits but means that MathML Core Fragments are not valid MathML which I think complicates the "story".

[davidcarlisle]

Note a third possibility, not currently used, between making Core global attributes valid on all presentation or all mathml, would be to just make them valid on the Core elements so not add them to non-Core Presentation such as <mfenced> and <mstack>

[davidcarlisle]

#363 addressed most of this adding core global attributes and intent+arg on all presentation elements (including non core ones)

https://w3c.github.io/mathml/#presm_presatt

Alhough we currently don't explicitly say what effect they have on eg mstack, perhaps will be enough for https://w3c.github.io/mathml/#presm_presatt_core to make a general comment how core-defined attributes should be interpreted. (I think in fact most of them will work as expected even without polyfill as the html ones will have an effect anyway even on unknown elements.)

[brucemiller]

I'm in favor of MathML 4 being a proper superset of Core.

[NSoiffer]

The June 9 meeting agreed that MathML should be a proper superset of Core.