Re: Draft MathML specifications at Github

On 05/02/2019 07:05, Frédéric Wang wrote:
> Hi,
> 
> Thank you David. I'd like to mention two repositories I've pushed to 
> mathml-refresh:
> 
> - mfenced-polyfill: https://github.com/mathml-refresh/mfenced-polyfill

> (https://mathml-refresh.github.io/mfenced-polyfill/ does not work as 
> them minified version is not stored on GitHub, but you can check 
> https://people.igalia.com/fwang/mfenced-polyfill/)
>    This is a JS polyfill to implement <mfenced> using <mo> and <mrow> 
> (as defined in the spec). I think we could have similar scripts (e.g. 
> XSLT) or explicit textual description of the algorithm.
>    The idea would be to have similar backward compatibility scripts or 
> instructions for features we plan to remove from MathML or exclude from 
> the "MathML core".
> 
> - mathml-css-proposals: 
> https://github.com/mathml-refresh/mathml-css-proposals

> (https://mathml-refresh.github.io/mathml-css-proposals/)
>    These are first drafts for some CSS features for math to discuss and 
> then propose to the Math WG.
> 

Thanks Frédéric,

I have added a gh-pages index to all the current repositories and their 
gh-pages rendering at

https://mathml-refresh.github.io/


Would it be worth changing the index.html in the math polyfill to pick 
up the javascript from your site?

Happy to see the start of polyfills which I think are a good idea and 
fit with how I'd thought we'd align the specs

Despite the fact that XSLT is my go-to language for this sort of thing
a JavaScript implementation is more in the spirit of the times 
especially if we are targetting chrome.

When I re-implemented the Content MathML to Presentation MathML 
conversion giving rendering rules from XSLT to JavaScript then in
chrome it was shocking how slow the original XSLT version was and how 
much more usable the JavaScript re-implementation was (many times 
quicker overall and didn't block incremental document rendering)
The chrome XSLT implementation has not (to put it mildly) had the care 
and attention that its JavaScript has.

So for polyfills I think an english spec of the transformation backed up 
by JavaScript is what we should aim for, not XSLT.

I think that it would be good of we could layer

mathml core (or web profile or whatever)

then above that for all of presentation mathml either provide some 
javascript  polyfill or for those things where a polyfill is tricky or 
unreasonably slow/complicated deprecate the construct for web use (I 
suspect <malign> will fall in to this, but to be seen...)

Perhaps the JavaScript could be referenced from a non-normative appendix 
of the web-profile spec, so that document becomes a self standing 
specification of what a browser needs to implement

The full mathml4 spec could indicate the status of each construct, 
linking to the appropriate parts of the web profile spec.

David

Disclaimer

The Numerical Algorithms Group Ltd is a company registered in England and Wales with company number 1249803. The registered office is:
Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.

This e-mail has been scanned for all viruses and malware, and may have been automatically archived by Mimecast Ltd, an innovator in Software as a Service (SaaS) for business.