Skip to content

structuring common attributes #361

@davidcarlisle

Description

@davidcarlisle

MathML3 , in addition to attributes specified on each element had

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".

Metadata

Metadata

Labels

MathML 4Issues affecting the MathML 4 specificationneed specification updateIssues requiring specification changes

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions