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

Hi Peter,

> On 16 Jan 2018, at 16:08, Peter Krautzberger <peter@krautzource.com <mailto:peter@krautzource.com>> wrote:
> 
> Hi Ivan,
> 
> I feel like we're talking about different things and I don't think know how to overcome this miscommunication. One last try though.
> 
> > Well, that is where we may disagree. You say 'might be nice', and I say it is a necessity.
> 
> I agree that we disagree. But I have more reasons that will be side-tracking even further.
> 
> > Let me turn the question around: what is your view (because I do not really understand) on how authors should author their mathematical formulae? What should a publisher use in their workflow, what should an educational publisher use? Do you mean that each of them should use a different tool and there is no need for anything standard?
> 
> This sounds as if people didn't have anything to work with. Everyone has a solution that works for them. Some better, some worse.
> 
> At the same time it's also not like there's a mess of hundreds of ways of doing this. There are a handful of formats used for storing equation layout information (with TeX, MathML, Word probably representing an exremelty vast majority) combinend with a handful of ways of rendering such content on the web.
> 
> Most publishers are still only capturing print-style equation layout; TeX and MathML are prefectly fine for that.
> Those who do things beyond print usually have more complex, web-centric scenarios; the equation layout becomes fragmented in a more complex web application structure, e.g., interactive teaching or assessment tools. If those groups feel the need for standardization, they should speak up.
> 

I think here is the core of our differences. I believe it is necessary to have a standard (or maybe 1-2 standards if necessary) to provide a standard syntax for mathematics on the Web; you seem to be comfortable having just tools around with renderers around without any standards. I do not really care whether it is MathML or LaTeX or something else, but it has to be

- usable for the various communities
- it is unambiguously implementable within or on top of browsers

I am not saying it must be part of HTML5 as it is today, that is a different issue.

(I work for a standards body, remember? :-)

> 
> > And I am not sure that is a good thing. That is exactly my point.
> 
> I agree but it's what MathML wanted to do and I think it's what endears it to the XML community.
> 
> >  I could say: "Literary content/knowledge is not determined by layout even if the textual layout does express it." Nevertheless, there was/is a need to produce a very precise definition on how HTML elements are laid out by the browser engines: publishers, for example, rely on this.
> > I do not think there is such a big difference in this respect between math and, say, HTML.
> 
> This completely confuses me.

Let us forget about this then. I answered to one of your side issue.

> 
> >  I am not sure I agree. A mathematical layout is, in this context, part of a larger layout which is the page in a book (offline or online). If the result of the equation's layout is unpredictable, because the underlying layout engines follow very different strategies, we may have a problem. Unless the specification on how the layout should/must happen is more strictly determined.
> 
> I was talking about different but equally robust ways of doing design on the web. So I think we're agreeing?

Not sure. Equally robust is fine. But, regardless of whether the implementation is based on CSS, SVG, or anything else, they should also produce the same layout as identically as possible. Just like the same HTML page should look, essentially, the same on a FF and Chrome browsers with only very small differences.

> 
> Let's continue in live conversation some time.

Sure

Ivan

> Best,
> Peter.
> 
> 
> 
> 
> 
> 2018-01-16 11:28 GMT+01:00 Ivan Herman <ivan@w3.org <mailto:ivan@w3.org>>:
> Hi Peter
> 
> (skipping things where we agree:-)
> 
>> On 15 Jan 2018, at 20:59, Peter Krautzberger <peter@krautzource.com <mailto:peter@krautzource.com>> wrote:
>> 
> <skip>
>> 
>> >  I believe there is a need for some declarative (or mostly declarative) syntax for mathematics.
>> 
>> Are you mixing equation layout with mathematics or are you really thinking about Content MathML? If you have used it, what was your experience?
>> 
> 
> No, I do not mean content markup. That part of MathML seems to be, alas!, dead I guess.
> 
>> Anyway, yes, it might be nice if it existed (I say might because I'm generally not a huge fan of print-focused equation layout on the web). In my experience, we'd really have to talk about human authoring if we wanted to solve this.
>> 
> 
> Well, that is where we may disagree. You say 'might be nice', and I say it is a necessity.
> 
> Let me turn the question around: what is your view (because I do not really understand) on how authors should author their mathematical formulae? What should a publisher use in their workflow, what should an educational publisher use? Do you mean that each of them should use a different tool and there is no need for anything standard? (This is where this issue _is_ close to the HTML level, ie, to the fact that the existence of an HTML element set is important.)
> 
> (I suspect that authors/content providers would vote with their feet. Whether it is MathML or LaTeX or something else may be open, but the community needs a stability in this respec… ie, a standard would or does emerge…)
> 
>> > Furthermore: there is an issue of interoperability. The HTML community has put in an enormous energy to define, in a real detail, on what really happens for each HTML element, and how they are presented on the screen. What they achieved is a significant interoperability among browsers as for layout and other things.
>> 
>> Yes. And MathML intentionally wants to leave it up to the renderer: Section 3.1.1 "MathML presentation elements only suggest (i.e. do not require) specific ways of rendering".
> 
> And I am not sure that is a good thing. That is exactly my point.
> 
>> 
>> > Isn't there a need to do something similar for math? Some sort of a specification that says "this and this feature is implemented through this and this CSS/SVG/HTML element"?
>> 
>> Again, I think this is mixing layout with semantics. Mathematical knowledge is not determined by layout even if equation layout is. Presentation MathML does not encode mathematical knowledge, it encodes equation layout information; those are two very different things.
> 
> I could say: "Literary content/knowledge is not determined by layout even if the textual layout does express it." Nevertheless, there was/is a need to produce a very precise definition on how HTML elements are laid out by the browser engines: publishers, for example, rely on this.
> 
> I do not think there is such a big difference in this respect between math and, say, HTML.
> 
>> 
>> CSS and SVG are very good at capturing layout information and they are as robust as it gets for today's web. Obviously, they make no claims on semantics.
>> 
>> > Otherwise we incur the danger of different tools mapping math on completely different feature sets, leading to a possible mess...
>> 
>> Again, it's not about math but equation layout. I don't think the "mess" of doing things one way with CSS, another way with SVG is a problem; it's something you see every day on the web; sites like codepen are full of examples; it's creative and inspiring, both for authors, specs, and implementations.
> 
> I am not sure I agree. A mathematical layout is, in this context, part of a larger layout which is the page in a book (offline or online). If the result of the equation's layout is unpredictable, because the underlying layout engines follow very different strategies, we may have a problem. Unless the specification on how the layout should/must happen is more strictly determined.
> 
> 
> Cheers
> 
> Ivan
> 
> 
>> 
>> Best,
>> Peter.
>> 
>> 
>> 
>> 2018-01-15 16:15 GMT+01:00 Ivan Herman <ivan@w3.org <mailto:ivan@w3.org>>:
>> Oops, sorry
>> 
>>> On 15 Jan 2018, at 16:05, Ivan Herman <ivan@w3.org <mailto:ivan@w3.org>> wrote:
>>> 
>>> I am bound to the current MathML syntax.
>> 
>> I should have written: "I am not bound" :-)
>> 
>> ivan
>> 
>> 
>>> I could even to have several syntaxes aimed at different communities. But you seem to say that there is no need for such standard whatsoever. This may be a source of our disagreement… (unless I completely misunderstand what you say).
>>> 
>>> Furthermore: there is an issue of interoperability. The HTML community has put in an enormous energy to define, in a real detail, on what really happens for each HTML element, and how they are presented on the screen. What they achieved is a significant interoperability among browsers as for layout and other things. Isn't there a need to do something similar for math? Some sort of a specification that says "this and this feature is implemented through this and this CSS/SVG/HTML element"? Otherwise we incur the danger of different tools mapping math on completely different feature sets, leading to a possible mess...
>>> 
>>> 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:+31%206%2041044153>
>>> 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 <tel:+31%206%2041044153>
>> 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 <tel:+31%206%2041044153>
> 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>

Received on Tuesday, 16 January 2018 17:54:44 UTC