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

Hi Ivan,

> You may be right on this, but that is not what I meant. I did say that
MathML was meant to be the standard on the "bottom", so to say, and there
would be tools mapping on that either from other syntaxes like LaTeX or
coming from interactive tools. Ie, I do not think we disagree on this.

Thanks for clarifying!

> If I followed your logic, there is no reason of having the HTML or SVG
elements either; having the DOM as a data model and a bunch of javascript
libraries handling that is enough. I have seen of course SVG based Web
sites where there is only one single SVG element used, namely <svg>, and
everything else is a giant javascript. Is this what you envisage for math
on the Web, too?

No, that's not what I mean. I intentionally never mentioned JavaScript up
until now. I think (as usual) the fact that most tools are JavaScript based
misleads people to think client-side rendering is necessary these days.
Instead, all JS-based equation layout tools support server-side conversion
and other server-side tools exist. While JS tools dominate for the historic
reason that browser implementations of CSS weren't that stable until a few
years ago (*cough* IE *cough*), at this point client-side rendering is just
a nice extra or for lazy users; that's just like client-side markdown
rendering is a thing some people do.

>  have difficulties to imagine that this approach would fly

Skipping because it's not what I meant.

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

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.

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

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

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.

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