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

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.


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

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

Let's continue in live conversation some time.
Best,
Peter.





2018-01-16 11:28 GMT+01:00 Ivan Herman <ivan@w3.org>:

> Hi Peter
>
> (skipping things where we agree:-)
>
> On 15 Jan 2018, at 20:59, Peter Krautzberger <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>:
>
>> Oops, sorry
>>
>> On 15 Jan 2018, at 16:05, Ivan Herman <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/
>> mobile: +31-641044153 <+31%206%2041044153>
>> 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
>>
>>
>
>
> ----
> 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
>
>