Impact and strategy for polyfills

[brucemiller]

In the various discussions on deprecating and simplifying the various features, elements and attributes of MathML, as well as whether or not a given feature should be present in MathML Core, one of the key factors in the decision is whether the feature in question can be recovered by use of a polyfill. I would like to start a discussion about how the group envisions polyfills being used.

For purpose of argument, let us assume that every feature in in the main spec but missing from Core would/could be implemented by a polyfill. We would need appropriate Feature Detection for each feature as well, which seems in some cases harder than the polyfill itself(?)

• Is including polyfills an author or browser responsibility?
• Would there be a standard set of feature/polyfill pairs?
• A master polyfill?
• A method to determine which polyfills are needed?
• General questions about performance trade-offs (both rendering and network).
  Presumably more questions will arise as we discuss :>

[NSoiffer]

Hopefully someone who has authored a large polyfill can join in. However, I'm sure the answer to one of your questions

Is including polyfills an author or browser responsibility?

I think the answer is that it is an author responsibility. If someone targets core, they almost certainly don't want to encumbered by a polyfill.

One place to look for potential answers is MathJax. Because it polyfills all of MathML, we can't learn from it as to how to divide a MathML core polyfill (if we want to divide it), but it does have configuration options about what input/output to accept/produce along with predefined common configurations. Maybe that is something relevant for this discussion.

I think another issue which we can't answer now is: "can we use shadow dom for the polyfill?" @bkardell has given this some thought and done some experimentation in a branch. I'm not sure what his current thinking/plans are. At the moment, there is a small set of elements which you can attach a shadow root to. Because of security concerns, we will never be able to put a shadow root on any element that accepts links, but if we go with a small set of elements that can be links, maybe we would be able to shadow mfenced and the elementary math elements. For other elements such as shadowing mfrac's bevelled or maybe trying to do a polyfill for linebreaking and mo (which I'm dubious is possible), I don't know. @bkardell: if you think that sometime in the future you'll have a proposal that allows shadowing some MathML elements, would that proposal allow for shadowing an element sometimes and sometimes not? Seems like that wouldn't be a problem because that's the case for the elements in HTML that can be shadowed. Not sure if you considered that for MathML though.

A fallback position if shadowing MathML elements is not allowed is to have the polyfill wrap the MathML in a div/span and put a shadow MathML tree in that. All the polyfills would modify that tree leaving the "light DOM" in tack other than the extra div/span above the MathML. I don't think that is what people imagined as an appropriate use of shadow DOM because none of the MathML children would point to their shadow. Maybe someone can shoot this idea down quickly with an example of why that would be bad...

[fred-wang]

* Is including polyfills an author or browser responsibility?

Sorry I haven't read everything as there is a lot of text here. But at the risk of making things even more complicate, I just wanted to pointed out that one there is a third option: The polyfill can be loaded in a user web extension. I guess a similar situation arises with math fonts (without them rendering is pretty bad, so it's even worse than e.g. no mfenced support): should they be pre-installed on the system? bundled in the browser? provided as web fonts by the author? or installed on the system / as a web extenion by the user?

[bkardell]

I think another issue which we can't answer now is: "can we use shadow dom for the polyfill?"

The answer here is currently no, but we hope to get it 'sometimes'...

@bkardell: if you think that sometime in the future you'll have a proposal that allows shadowing some MathML elements, would that proposal allow for shadowing an element sometimes and sometimes not?

Yes and that will match the rest of the platform. I realize that this is an imperfect goalpost but the aim is to match the platform and be able to benefit from advancements (and investments) there and move forward together, and that is currently the answer for the rest of the platform as well as I described in my blog post - moving all of this forward and figuring out HTML itself moves forward is a many year long effort that's had lots of thought. The most recent round of discussion was at whatwg/html#4696.

Is including polyfills an author or browser responsibility?

Definitely the author's but what that looks like can vary a lot. A very popular solution, for example, is polyfill.io which makes it as simple as "include a script tag to this url for polyfills". There are pages and pages and pages of things discussing this as a problem and lots of tradeoffs, but I don't think there is a perfect answer. DOM element 'polyfills' are weird especially - which is part of the nature of the problem here...

[NSoiffer]

From the 17/2/20 meeting, @davidcarlisle brought up the issue of polyfills and feature detection. On the assumption that MathML Core will evolve over time, it is a good idea to think about exposing features that are part of core so that polyfills will know whether they need to polyfill a feature or not. At the moment, it seems like there are two possibilities:

1. Create a toplevel object ("MathMLCore"?) and add the MathML Core element names as properties of it. The attributes supported by the elements would then be properties of the element. Not sure if we need to include CSS properties supported by the element, but that's an option.
2. Follow a model like CSS's @supports (somehow) that means JS is not needed for feature detection and a means of falling back (maybe to JS) is embedded in core.

Anyone have other alternatives for feature detection?

[fred-wang]

The WPT tests have feature detections to avoid false positive results when browsers don't support MathML https://github.com/web-platform-tests/wpt/blob/master/mathml/support/feature-detection.js

I'm not sure whether exposing new "feature detection" properties to claim support for legacy features will work well... This will fail to detect browser support for versions before these "feature detection" are implemented. And as usual we would need to convince browser implementers before introducing anything new. So I'm not sure we have any other choice than some JS code like what WPT tests do.

Some new features might be detected, (e.g. new CSS properties proposed or MathMLElement DOM) but I don't think that's relevant for polyfills that care about compatibility with non-web based approach.

[NSoiffer]

Action: move the polyfills to the W3C repo and transfer this issue there.

Note: do the same for the MathML schema.