-
Notifications
You must be signed in to change notification settings - Fork 15
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.
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
Clarify the language around deprecated features of MathML #279
Comments
It's a little difficult to say for sure that we can treat all of these equally.... The trouble with MathML Core is that is it trying to address several factors around the age and size of MathML and align it with the rest of the platform: How it fits with DOM and CSS and events and so on. Part of this is drawing a somewhat arbitrary box around what we can tackle in v1, trying to define a minimum viable inter-operational subset that we can hope to achieve. Some things are left to decide in a possible v2. Others are, I think, fairly straightforward - they are listed as presentational hints already... That's just how they are implemented and explained - they are not recommended for use if you are only writing for the web, but tbh I'm not sure if they should be added to a a section like https://html.spec.whatwg.org/#non-conforming-features, because MathML is used outside of the browser too and there it might actually be necessary... |
If Core focuses on the web platform only, I tend to think it would be fair to have a note about these elements that are not recommended if you only care about web. Something like:
|
The Math WG discussed this at the meeting today. One thing that kept coming up is that there are really two related specs, but MDN doesn't seem to have a way to dealing with that: "deprecated" and "experimental" don't fully make sense in this situation. As an example, CSS support is not fully implemented in Firefox and Safari. Additionally, it is not clear how CSS will interact with the math layout rules which has its own "math inline" and "math block" rules. Because of these two things, many people felt that maybe some additional text is needed for many of the items to clarify the core/full difference and explain the limitations. |
As per the the 30 Jan Math WG meeting, this is a workspace for people to add their thoughts about how each item should be classified. Two options are "deprecated" and "experimental". The meeting consensus was that there may need to be other options. NSoiffer's general comment: the core spec mentions several features in MathML full that are "presentational hints". These include "mathcolor" and mspace's "width" attribute. These can be handled via UA style sheets. I think (as I indicate below), many of these incompatibilities can be resolved in this manner. In addition to reducing incompatibilities, doing this means people don't have to invent their own methods for implementing these features. MDN currently lists "mathcolor" as deprecated which I don't feel is appropriate. mathml.elements.mactionNS: In core and is useful to keep even though JS can be put on any element. I think there is a strong analogy "button" which can be emulated with JS. DG: deprecate, the web platform has enough affordances for interactivity. The element semantics do not have a clear value-add in 2025. (Possibly even mathml.elements.maction.actiontypeNS: deprecate mathml.elements.maction.actiontype.toggleNS: deprecate mathml.elements.maction.selectionNS: deprecate mathml.elements.mfencedNS: deprecate. Although this is in full, there is a good work around (mrow) that can be used, so mathml.elements.mfrac.denomalignNS: should be a presentational hint. mathml.elements.mfrac.linethickness.named_spacesNS: deprecated mathml.elements.mfrac.linethickness.nonzero_unitless_valuesNS: deprecated mathml.elements.mfrac.linethickness.thin_medium_thickNS: deprecate mathml.elements.mfrac.numalignNS: should be a presentational hint. mathml.elements.mmultiscripts.subscriptshiftNS: should be a presentational hint. mathml.elements.mmultiscripts.superscriptshiftNS: should be a presentational hint. mathml.elements.mo.named_spacesNS: deprecated mathml.elements.mo.nonzero_unitless_valuesNS: deprecate mathml.elements.mpadded.named_spacesNS: deprecated mathml.elements.mpadded.nonzero_unitless_valuesNS: deprecated mathml.elements.mpadded.pseudo_unitsNS: deprecated mathml.elements.mpadded.scale_factorNS: deprecated mathml.elements.mspace.named_spacesNS: deprecated mathml.elements.mstyle.backgroundNS: deprecated mathml.elements.mstyle.colorNS: deprecated mathml.elements.mstyle.fontsizeNS: deprecated mathml.elements.mstyle.fontstyleNS: deprecated mathml.elements.mstyle.fontweightNS: deprecated mathml.elements.msub.subscriptshiftNS: should be a presentational hint. mathml.elements.msubsup.subscriptshiftNS: should be a presentational hint. mathml.elements.msubsup.superscriptshiftNS: should be a presentational hint. mathml.elements.msup.superscriptshiftNS: should be a presentational hint. mathml.elements.mtable.width.named_spacesNS: deprecated mathml.elements.semantics.advanced_visible_child_selectionNS: deprecated mathml.global_attributes.mathbackgroundNS: should be a presentational hint. mathml.global_attributes.mathcolorNS: should be a presentational hint. This was explicitly introduced to MathML as people felt that a red 'x' could be a different variable than a black 'x' just as a bold 'x' is different than a regular 'x'. Hence, the use of an attribute as opposed to CSS which is purely presentational and not semantic. I realize it is a bit ironic that I suggest that this be called a "presentational hint", but that's really about how it could/should be implemented. mathml.global_attributes.mathsizeNS: deprecated mathml.global_attributes.mathsize.named_spacesNS: deprecated mathml.global_attributes.mathsize.nonzero_unitless_valuesNS: deprecated mathml.global_attributes.mathsize.small_normal_bigNS: deprecate |
A few MathML features are marked as deprecated on MDN, but looking at the spec tells me a different story, and I wonder if MDN is incorrect, or if the spec language should be changed on these features.
Let's take the example of the
mathbackground
global attribute:The MDN article says:
The spec has a note about the attribute:
Reading this makes me think that using the attribute is an author choice. The spec doens't specifically discourage using it, and certainly doesn't deprecate it as MDN says.
As a comparison point, here's what the UI Events spec has to say about
MutationEvent
:This language is a lot more definitive and leaves no room for interpretation.
Should the MathML Core spec be more definitive about the elements, attributes, and attributes values it discourages? Or is MDN's language a bit too strong in this case? Or am I misreading these documents?
For context, this came up in web-platform-dx/web-features#2513, which is where the WebDX CG is trying to create a web-features entry for the remaining MathML features that are not part of the main MathML feature.
These remaining MathML features are all marked as deprecated by BCD (the data source that MDN uses for compat tables). Here is the list of these features, listed as BCD "keys":
The text was updated successfully, but these errors were encountered: