Re: Sharing MathML data for Firefox

I personally hate polyfills: They are slow, often require many megabytes of libraries to be downloaded and require JavaScript to be enabled. 

Kind regards,
   Gunter.


Am 24. August 2019 01:02:16 MESZ schrieb "Hammond, William F" <whammond@albany.edu>:
>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

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.