-
Notifications
You must be signed in to change notification settings - Fork 99
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
How to handle the remaining MathML BCD keys #2513
Comments
This is very similar to #2485, where we documented the deprecated SVG keys. Currently, SVG is a "junk drawer", so we opted to make a single junk drawer of discouraged SVG features. My thought is to make a single discouraged MathML junk drawer to match what we did there, and to not have more discouraged MathML features than non-discouraged MathML features. |
I agree with, @jamesnw. We can reserve the option to split up the features in the future. But until we can demonstrate there's an audience for those features (in contemporary or historic MathML), I think we shouldn't split them up. If I were making the MathML discouraged feature, I'd probably do a similar thing as SVG: name: MathML 3 (discouraged)
description: MathML 3.0 specifies several components that were excluded from MathML core, such as the `<maction>` and `<mfenced> elements. |
Thanks for the input. I'll take a stab at creating a discouraged feature for these elements and attributes. |
Following this thread because WPT currently uses the |
Short update on this (mostly paraphrasing @bkardell, thanks for your help Brian): MathML Core isn't a new version of the spec in that it doesn't add new elements. It only describes a subset of existing MathML elements that should work in the browser and integrate nicely into the rest of the platform (i.e, fit with DOM and CSS and events and so on). By doing so, MathML Core is trying to address several factors around the age and size of MathML as a whole (which evolved at the same time as html and css were). Another aspect to keep in mind is that MathML isn't only used on the web, and that other platforms implement more than MathML Core. So, while MathML doesn't specifically deprecate anything from other MathML specs, in prose, it effectively does so by limiting itself to a subset of the elements that apply to the web only and work great with it. It gets more complex though, because Core is drawing a somewhat arbitrary box around what can be tackled in the current version of the spec. Core is trying to define a minimum viable inter-operational subset that can be achieved. So, some elements are left outside of the scope, not forever, but just because they don't currently fit in the list of things that the group can work on now. So there's a chance for a future Core v2 that has more elements. |
Based on the above comment, one next step would be to categorize the list in the description of this issue into:
@bkardell, would you be able to help me with the above? |
Talked with Brian, the mathml 4 group has a meeting today to discuss this issue: w3c/mathml-core#279. It's possible that a warning like the one mentioned in that issue gets added (as a non-conforming section) to the spec, for certain things at least. We could then point to this for our discouraged feature. |
We already have a MathML feature on the repo: https://github.com/web-platform-dx/web-features/blob/main/features/mathml.yml which contains quite a lot of BCD keys.
Looking at the list of remaining unmapped BCD keys, I see there are quite a few still. These are marked as deprecated on BCD.
How do we want to handle them on this repo?
maction - Entire element is deprecated
mfenced - Entire element is deprecated
mfrac:
mmultiscripts
mo
mpadded
mspace
mstyle - Entire element is deprecated?
msub
msubsup
msup
mtable
semantics
Global attributes - Deprecated attributes and attribute values
The text was updated successfully, but these errors were encountered: