Re: [MathOnWeb] Peter K's comments on directions for 2018

Hi Ivan,

Let me change the thread title.

You wrote

> 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.

I can't really argue as you know much more about the history of the spec.
But I admit from today's point of view, it strikes me as very optimistic.

MathML is intentionally under-specified (as Neil pointed out in the last CG
call, as fit with the spirit of 90s HTML). From my time on the MathWG I had
the impression that WG members mostly thought this situation was desirable
or not their problem.

> 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 is not my impression.

The credo of the MathML community has always been "you don't write MathML
directly". Mostly this is used as a defense against plain text formats such
as TeX but depending on what people are trying to sell, is usually means
that you can convert your preferred format to MathML or that you can create
MathML it with their tools. This goes as far as AT such as MathPlayer or
speech-rule-engine which actually generates an essentially different format
that is then used for accessibility.

I think in reality, except for a very select group of specialists, nobody
"writes" MathML; just like very few people "write" SVG (relative to the
number of users who deploy SVG content).

So again, I'd say nothing changes if MathML is deprecated: instead of
converting content to MathML or creating MathML in editing interfaces,
people will convert to or create HTML, SVG etc.

> 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.

At the risk of repeating myself, there are many other tools that do similar
things to what MathJax does, some use MathML as a data model (most don't),
some go for the same TeX-style layout quality (most do not), some are
focused on problems such as editing or controlling visualizations, so they
have a completely different set of priorities.

> 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?

To me, this is the same question as asking anyone how they might get
anything slightly complex onto a webpage. There are many tools you can
choose from and authors already demonstrate that they don't have hard time
finding and choosing between them. So I admit I don't see what you think is
missing.

> 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.

Thanks for clarifying. I don't think a unified syntax is necessary or even
helpful. The growth of existing tools seems to indicate that it is better
not to have one but many.

Best,
Peter.

2018-01-15 13:45 GMT+01:00 Ivan Herman <ivan@w3.org>:

> Hi Peter,
>
> On 15 Jan 2018, at 12:46, Peter Krautzberger <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>:
>
>> Hi Peter,
>>
>> > On 12 Jan 2018, at 17:05, Peter Krautzberger <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/
>> mobile: +31-641044153
>> ORCID ID: http://orcid.org/0000-0003-0782-2704
>>
>>
>
>
> ----
> Ivan Herman, W3C
> Publishing@W3C Technical Lead
> Home: http://www.w3.org/People/Ivan/
> mobile: +31-641044153 <+31%206%2041044153>
> ORCID ID: http://orcid.org/0000-0003-0782-2704
>
>