Re: Sharing MathML data for Firefox

Frédéric Wang writes:

I'm not going to give more details here, discussion is already taking place in the proper channels.

I apologize for my ignorance, but I do not know which discussions you are here characterizing as the proper channels.  Could you clarify?

Another question: In regard to the case of removing native support for <mfenced>, has thought been given to supplying standard XSLT  for expanding it.  I think you had mentioned JavaScript. The question of relative speed aside, Javascript operates on a document's object module (DOM), whereas XSLT can generate a new document serialization that might be sensible for strategic caching.  Also I think that XSLT is a better fit for the task than Javascript.

Thanks.

              -- Bill


________________________________
From: Frédéric Wang <fwang@igalia.com>
Sent: Thursday, August 22, 2019 2:32 PM
To: Hammond, William F <whammond@albany.edu>; public-mathml4@w3.org <public-mathml4@w3.org>
Cc: www-math@w3.org <www-math@w3.org>; Mozilla Math Developers <dev-tech-mathml@lists.mozilla.org>
Subject: Re: Sharing MathML data for Firefox

On 22/08/2019 20:01, Hammond, William F wrote:
I assume this is about MathML elements such as "mfenced" that previously you have expressed a wish to drop.  I continue to advise you not to take any such step.

From spec authors' point of view: the MathML CG already decided to remove mfenced and other features from MathML Core. They will stay in MathML full but won't have web platform tests for them and the expectation is that they are implemented via JS polyfill.

From implementers' point of view: the plan is to try and unship these features. However, this will be done carefully by measuring & analyzing data and adding runtime flag.

That said, I have questions:

Will your probe pick up instances where MathJax ("CommonHTML") rendering of MathML is used?

Will your probe pick up instances served as "application/xhtml+xml"?  I mention this case because some web searching algorithms seem often to have bypassed it.

The probe will only measure MathML content that is actually rendered by Firefox. Being in the DOM is not enough, for example by default Wikipedia has MathML content with "display: none" so it is excluded from the data. The fact of being handled by the HTML5 or XHTML parser does not matter here. One can use https://addons.mozilla.org/en-US/firefox/addon/native-mathml or similar to force native MathML rendering.

To play devil's advocate, if MathML or some of its features are actually not rendered in browsers then it makes sense for browser vendors to actually remove them. So measuring MathML content that is actually rendered by browsers is the correct measurement from that point of view.

There are discussions in the MathML CG to collect more data besides native implementation but unfortunately we didn't get a lot of feedback on this so far.

Note: I'm not going to give more details here, discussion is already taking place in the proper channels.

Thanks,

--
Frédéric Wang