Re: Draft MathML specifications at Github

On 05/02/2019 09:01, David Carlisle wrote:
> 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

Hi David,

Just two notes to clarify my thought:

* Probably we are going to remove things from the MathML 4 spec too. Not
sure for <mfenced>,  but e.g.
https://www.w3.org/Math/draft-spec/chapter3.html#presm.deprecatt or
https://www.w3.org/Math/draft-spec/chapter2.html#id.2.2.2 are potential
candidates. So converters for backward compatibility won't be only for
the core spec. My suggestion would be to have separate documents / spec
to explain how to reduce to "MathML 4 core" and how to transition from
MathML 3 to MathML 4.

* Javascript polyfills can be slow, so I think it's good to have scripts
to convert to a reduced MathML *before* generating the page. Of course
Javascript can be used for that purpose too, but maybe popular languages
like Python or Perl could be considered too, depending on people's
interest. I was only mentioning XSLT because I thought that many
publishers use MathML in an XML context so that might be easier to
integrate XSLT stylsheets in their pipelines. In any case I agree that
English algorithm + Javascript implementation is probably enough.

-- 
Frédéric Wang