- From: Ivan Herman <ivan@w3.org>
- Date: Tue, 16 Jan 2018 11:28:54 +0100
- To: Peter Krautzberger <peter@krautzource.com>
- Cc: mathonweb <public-mathonwebpages@w3.org>
- Message-Id: <B2F01799-65BE-42F5-A14D-47303BE4F940@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 ORCID ID: http://orcid.org/0000-0003-0782-2704 <http://orcid.org/0000-0003-0782-2704>
Received on Tuesday, 16 January 2018 10:29:08 UTC