Re: Updated invitation with note: MathML Refresh Meeting

On 12/02/2019 11:17, David Carlisle wrote:
>
> I suggest that we drop at least the xhtml version (which was originally
> needed to display mathml) just having the html(5) version is also a
> possibility but my recommendation would be to keep the others as
> (a) the build is set up and having fewer changes is good and (b) I think
> it's good to have a normative version that works in all browsers today
> rather than just browsers that have the math support that we would
> wish for.
>
>
Yes, I think we can drop the xhtml version and keep HTML5 so that we are
closer to what browser vendors and the web community expect (there are
not big fans of XML as you are aware). I don't have opinion about the
other formats. I don't think we should use MathJax though. In addition
to all the known issues and extra pain it causes, it is a bit in
contradiction with the message of native browser rendering and it does
not align with the implementation details of the MathML Core spec. I
think we can rewrite things so that documents display correctly in all
browsers without any extra library (see below).

> mathml-web-profile
> ------------------
>
> I quite liked "mathml web profile", but I think this should be thought
> of as a self standing spec on which "full" mathml can build, rather than
> something normatively defined as a subset of full mathml. So I suspect
> that Frédéric is right and the name is wrong and something like "MathML
> Core" would be better.

The document was initially designed as an implementation note based on
MathML 3 (and it quotes section from MathML). Whatever the name chosen
at the end, I think it should be rewritten as a standalone document that
browser implementers, W3C TAG or others can review and use. I don't
believe this kind of audience would be happy with a big MathML spec so
we should avoid making the full version the default entry point. So I
agree with David that "a core spec on top of which full MathML can be
built" sounds a better presentation than "a profile to partially
implement the main MathML spec".

> We should consider whether it's "MathML4 core" or
> "MathML core") to have or not have version numbers still being a
> somewhat contentious issue in html(5) related specs..

I'm not familiar with that. Can you please explain what is this
discussion about versioning?

> We should decide whether the document should contain MathML in the main
> text or whether (like the MathML spec) it should avoid doing that, and
> if there are any small expressions use simple html <sub> markup, or
> (perhaps) statically convert to svg rendering while generating the
> document, or have the math as mathml but include mathjax or some other
> javascript fallback....

I believe the formulas that would be needed will really just be simple
arithmetic, so we can follow what we did for the MathML spec and use
simple HTML markup (again we won't need MathJax). For example, the
biggest formula was for math-script-level (and BTW is wrong), it can be
rewritten using English and introducing variables:

https://mathml-refresh.github.io/mathml-css-proposals/math-script-level-and-math-style-explainer.html#css-math-script-level-property

If we really need complex math formulas (which I doubt we do), we could
still use semantics + image annotation-xml or semantics + text
annotation to provide a fallback which is supported by Chromium.

> Currently the source for this document is essentially html as xml but
> then combined and normalised via the build script. The images are
> currently inlined as base64 encoded data but that's an artefact of the
> way the sources were pulled together, I assume we'll reconstitute the
> original image sources as needed to make editing possible again.

Yes, I think we can review the process to generate images. Again, it was
originally based on LaTeXML but we can find a more convenient way to
generate this kind layout schemas. If possible I'd like to keep vector
graphics rather than raster images. BTW, I think the English description
should also explain the layout without the need of the schema, if that's
not already the case.

-- 
Frédéric Wang