Re: Sharing MathML data for Firefox

I explained in the other email the rationale. The idea is not to write
polyfills for the full MathML spec but to start focusing on a core
subset that is aligned with the rest of the browser technologies / code
base so that it can be implemented, tested and maintained easily in all
browsers and in an interoperable way.

For example the CG decided to remove support for MathML length "1234.px"
which is not compatible with CSS and suggest to use "1234px" instead.
Since changing the syntax can potentially break legacy website / tools,
we still need to provide some kind of polyfill to perform this
replacement until people migrate to the newest version. This can be done
with a few lines of Javascript and can be executed after
DOMContentLoaded is fired, before any layout happens. It's true that
Javascript need to be enabled though, but I guess you will encounter
more trouble with JS disabled before realizing the issue with a legacy
MathML content using "1234.px" ;-)

PS: I'm really not going to reply anymore to this thread. Please
continue discussion in the MathML CG if you are interested.

On 24/08/2019 06:16, Gunter Königsmann wrote:
> 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. 


-- 
Frédéric Wang