Re: [MathOnWeb] call for comments -- directions for 2018

Hi Peter,

> On 15 Jan 2018, at 12:46, Peter Krautzberger <peter@krautzource.com <mailto:peter@krautzource.com>> wrote:
> 
> Hi Ivan,
> 
> > 1. Let us say we deprecate MathML from HTML5. What exactly would you propose to replace it on a larger level?
> 
> No replacement is necessary.
> 
> Presentation MathML defines a set of tags alongside a (quite vague) specification for using them to realize traditional/print equation layout. These tags have no semantic value, just layout value (even if heuristics can guess partial meaning from layout+domain, cf., speech-rule-engine, MathPlayer).
> 
> It's not even hyperbole to say that since jsmath was released in 2004, it has been clear CSS can provide traditional equation layout at the highest quality. It may have been hacky (but what JS library wasn't in 2004) but in the mean time using CSS for equation layout has become steadily easier to do (as the increasing number of rendering tools demonstrate). In addition, SVG began providing a second option for laying out equational content. There's even a canvas-based solution.
> 
> It seems odd not to expect this development to continue to the point where experienced developers will be able to write an equation rendering tool for their projects; much like they could create a grid layout tool (even before CSS grids). I'd like to see that speed up but past experience shows CSS will get there one way or another.
> 
> For ContenMathML, it's a slightly different question. It is about semantics and we lack those; but it's not seen on the web outside of niches. While many people seem to want a way to express mathematical (and perhaps STEM) semantics that actually work on the web, Content MathML doesn't seem to be a good fit. So even here, I don't think "replacement" is needed; more like a clean slate that doesn't repeat its mistakes.
> 
> > Would it mean that one would have standardized syntaxes like Ascii or LaTex and… what is then the next step?
> 
> I don't see how authoring is relevant. One can build tools to create CSS/SVG/etc-based layout any which way one likes. What kind of internal data format is used is probably relatively disconnected from rendering. Obviously, MathML is going to stick around for this as it makes a lot of sense with an XMLy backend format. (But as I wrote I think something like CommonMark for ascii-like notations would be good.)
> 
> > Would we define some sort of an HTML extension through Web Components, for example?
> 
> I don't know any tool that does rendering this way but I suppose you could build a rendering tool that's based around web components. (Or perhaps you are thinking about a set of components as an authoring tool which I also haven't seen but could imagine.)
> 
> > I am obviously interested (mostly) on how to provide a standard environment where Math is easily accessible for a lambda web designer, which is what we all want…
> 
> I'm afraid I don't quite understand this part.

I am looking at this from the end user's point of view.

The approach taken by HTML5 back then was that:

- The math content is described in MathML and is added to HTML using the <math> element
- The browsers will "just do it", ie, the result is displayed properly in the text

That is all the user was supposed to know. If he/she was authoring HTML directly, then the idea was to use MathML elements. Of course, pre-processors or authoring tools were considered as possible bridges to use LaTeX or whatever else.

This model failed. At the minimum, this model has to be expanded by adding a reference to mathjax or something similar to make it work. MathJax was considered as a temporary solution with the hope that, eventually, browsers would take over and mahtjax would become obsolete. This never happened and we do not see any hope for that to happen. Alas.

What you propose is to essentially go back to the approach taken back then. I understand that and this may indeed be the right way to proceed. But I am still not clear what you propose to replace it with: if the <math> element is obsolete, what would an author have to do to get, at the end of the day, math on the page? What is the realistic path to get there? Hence my question of using web components for a replacement of the <math> element, the syntax(es) you propose to use within that element, the implementation strategies for getting that done, etc.

> 
> > 2. I am also not sure about your second point. Would it mean that you would want to expand on MathML's functionalities that are not related to Web usage?
> 
> Not me personally but I've met enough people who want to do this, yes. Again, it's about features that people need outside of the web but those features would make MathML duplicate even more functionality that's better done elsewhere in the web stack (e.g., going beyond the scope of an individual <math> tag, being more visual). If it wasn't included, MathML's elementary math notation would be another example.

I understand. Me _personally_ would like to solve the math on the Web problem first before doing anything in that direction…

Cheers

Ivan

> 
> Best regards,
> Peter.
> 
> 
> 2018-01-13 9:07 GMT+01:00 Ivan Herman <ivan@w3.org <mailto:ivan@w3.org>>:
> Hi Peter,
> 
> > On 12 Jan 2018, at 17:05, Peter Krautzberger <peter@krautzource.com <mailto:peter@krautzource.com>> wrote:
> >
> > Hi everyone,
> >
> > Let me try to kick things off by posting my own thoughts.
> >
> >
> <skip>
> > > 2. what directions do you want/hope/wish/expect to see take shape?
> >
> > On the scope of the group, I hope we find additional focus areas that can bring additional contributors. Two potential areas I see are the standardization of ascii-like equation input languages and richer semantics from computational tools.
> >
> > On the large scope, let me be seemingly negative here: I hope that 2018 will be the year that sees MathML being deprecated from HTML5.
> >
> > It will be 20 years in April since MathML 1 became a REC and it is no step closer to browser vendors giving a damn about it. I think the key reason nowadays is that MathML has simply become an outdated technology for the web: it may have been a good fit for the web of the 1990s but today it goes against that grain of the web.
> >
> > I think deprecating MathML from HTML 5 would be a positive step forward for two reasons.
> >
> > First, the empty promises of MathML hold the web back. As long as native MathML solutions remain an expectation,  it will continue to reduce leverage for more useful specs (i.e., parts for actually supported standards like CSS or ARIA). This means general web developers continue to miss out on good features because they don't have the support of those people hoping to see MathML - in particular of course those developers whose equation-related tools actually help the community -- MathJax, speech-rule-engine, mathlive, katex, mathquill, jqmath etc etc.
> >
> > Second, being part of HTML5 is holding MathML back. There are plenty of problems and limitations of the MathML spec specific to XML land where MathML still fits well into the technology stack. MathML should become better in the areas where it always succeeded rather than where it always failed, i.e., in XML documents and their workflows rather than the web.
> >
> 
> 
> Would it be possible to expand a little bit on these points? Because, I am afraid, I do not really understand…
> 
> 1. Let us say we deprecate MathML from HTML5. What exactly would you propose to replace it on a larger level? Would it mean that one would have standardized syntaxes like Ascii or LaTex and… what is then the next step? Would we define some sort of an HTML extension through Web Components, for example?
> 
> I am obviously interested (mostly) on how to provide a standard environment where Math is easily accessible for a lambda web designer, which is what we all want…
> 
> 2. I am also not sure about your second point. Would it mean that you would want to expand on MathML's functionalities that are not related to Web usage?
> 
> I am not agreeing or disagreeing with you, I just want to understand…
> 
> Thanks
> 
> Ivan
> 
> 
> 
> ----
> Ivan Herman, W3C
> Publishing@W3C Technical Lead
> Home: http://www.w3.org/People/Ivan/ <http://www.w3.org/People/Ivan/>
> mobile: +31-641044153 <tel:%2B31-641044153>
> ORCID ID: http://orcid.org/0000-0003-0782-2704 <http://orcid.org/0000-0003-0782-2704>
> 
> 


----
Ivan Herman, W3C
Publishing@W3C Technical Lead
Home: http://www.w3.org/People/Ivan/ <http://www.w3.org/People/Ivan/>
mobile: +31-641044153
ORCID ID: http://orcid.org/0000-0003-0782-2704 <http://orcid.org/0000-0003-0782-2704>