Re: Fwd: [Moderator Action] RE: Active lobbying: Math

+1 to Bill's response in general. To add to that.

> What can be added to CSS that would clean up both the style and markup?

This is difficult to answer because the MathML spec implements a ton of
layout features and they are not necessarily organized in a CSS-compatible
way (or even CSS compatible). When I wrote "it's possible today", I did not
mean it is not one big ugly hack. It's not as bad as PDFjs output but maybe
not by far ;-) I would compare it to doing flexboxy things without flexbox
(or really: doing 10 flexboxy things wrapped inside each other without
having any of them available).

> What parts of that could actually be useful in other contexts?

Off the top of my head: Improved sub/superscripts and better glyph control
would be great for typography in general. Multiscripts are common in many
scientific notations, I was talking to Dave about possible connections
between munderover and Ruby, also, this wcig thread
<http://discourse.wicg.io/t/position-an-element-relatively-to-another-element-from-anywhere-in-the-dom/968>
connects,
MathML needs more advanced borders (for menclose and elementary math
notation, but I'm crazy and would even add stretchy characters here),
mtable is in parts more advanced than html table (in-table alignments etc).

Again, this is just shooting from the hip -- I think we would need a more
serious effort to really dissect this question.

Peter.


On Tue, Aug 25, 2015 at 8:04 PM, Bill Kasdorf <bkasdorf@apexcovantage.com>
wrote:

> Re Robin's:
> >• What can be added to CSS that would clean up both the style and markup?
> What parts of that could actually be useful in other contexts?
>
> I think this is absolutely key to making progress on this. What this means
> is thinking about the things that need to be done for math in a more
> abstract way (e.g., "this is not about the math, it's about this layout
> problem").
>
> I'm certainly not saying this would get us good, complete MathML
> implementation, but it might help get some progress.
>
> Off the top of my head, I can immediately see some general issues that
> could be abstracted (admittedly, these might be seen as just as seldom
> needed as math, but here goes). Plus apologies if we _already_ have these
> solutions; I am not intimately familiar with CSS. These are the kinds of
> things that I naively think already _must_ be handled by CSS and then am
> surprised to see there are problems.
>
> --Marking points at the phrase level at which other successive things
> (usually "the next line" but not always) that follow vertically must align
> horizontally. (The fuzzy nontechnical language is deliberate.) Being an
> English major, I immediately think of poetry; this is a huge issue in drama
> and poetry. But because those are just as arcane as math, I would point out
> that as a typographer this comes up all the time. I am quite sure that is
> already on Dave Cramer's list of to-be-worked-on use cases for CSS; and I
> would guess it's fundamental to bidi and vertical reading; I'm just
> pointing out that it is a basic feature of math that actually has lots of
> analogs outside of math. Most general: "if the line runs over, indent the
> remainder to align with this otherwise arbitrary point." Happens all the
> time. Quite sure this is not news to anybody.
>
> --Building up of big things from small components, especially vertically.
> Example from math: bracket that keeps growing until it is told to end. You
> want to wind up with one big thing but when you start you don't know how
> big the thing is. Related to but not the same as stretching. Because the
> solution in math is commonly assembling "segments" (usually three different
> kinds, a top one, middle ones, and an end one), we get into the next point:
>
> --And I'm sure I don't have to mention all the Unicode issues. You can't
> spit without hitting a Unicode issue in math. ;-) Also see fonts, and
> glyphs. Certainly a general issue that happens to be fundamental and
> pervasive in math. Many many many people in the world care about this
> issue. . . .
>
> Just some thoughts from a not-as-technical-as-the-rest-of-you guy. I just
> mainly want to point out that the idea of looking at what aspects of MathML
> have wider relevance might get us somewhere. Maybe even the realization
> that _we're already working on_ some of the things MathML needs.
>
> --Bill Kasdorf
>
>
>
> -----Original Message-----
> From: Robin Berjon [mailto:robin@w3.org]
> Sent: Tuesday, August 25, 2015 5:21 AM
> To: Peter Krautzberger; W3C Digital Publishing IG
> Subject: Re: Fwd: [Moderator Action] RE: Active lobbying: Math
>
> On 24/08/2015 21:47 , Peter Krautzberger wrote:
> > I think the main problem is that nobody really knows what it would
> > technically require to implement good math layout in browser engines
> > or what it would take to implement good MathML support.
>
> Nobody might be stretching it, but it's certainly a very small group.
>
> > * In my experience, both browser vendors, publisher, and third party
> > vendors have surprisingly little knowledge of
> >    * MathML as a markup language
> >    * math layout in general
> >    * MathML layout specifically
> >    * math layout using OWP tech
> >    * math accessibility using OWP tech
>
> Part of the problem there is that you don't just easily fall into MathML
> in an incremental manner, say by first trying to tweak the rendering of
> something perhaps even as trivial as <var>x</var> and then building up from
> there. The first step is relatively steep compared to many other parts of
> the platform.
>
> > * The ARIA spec has a massive hole where mathematics should be.
>
> Asking naïvely: is there any reason not to start fixing this right now?
>
> > * Neither browsers nor publishers are active in the MathWG (ok, maybe
> > 1 exception).
> >
> > * The MathML spec needs some work in an HTML5 context
> >    * MathML has been "out of sync" (for lack of a better term) with
> > HTML/CSS/SVG for a while
> >    * MathML duplicates HTML/CSS features (sometimes the features are
> > not compatible though never critically so imho)
> >    * MathML hides quite a few complex layout features behind math
> > syntax, complicating the implementation of both
> >    * ContentMathML has failed outside of CAS.
> >
> > Another key problem is: MathML is neither necessary nor sufficient for
> > math layout on the web. Nowadays, HTML/CSS implementations are good
> > enough for (high quality) math/MathML layout. I'm not speaking of
> > client-side JS-driven rendering but of (server-side) HTML+CSS
> > generation that looks the same on all recent browsers.
>
> That sounds like a great opportunity and a good starting point to rethink
> MathML.
>
> Starting from HTML+CSS code that's ugly and poorly accessible, but at
> least sports high-quality layout:
>
>    • What can be added to CSS that would clean up both the style and
> markup? What parts of that could actually be useful in other context?
>
>    • What can be done to make it properly accessible, ideally built-in
> rather than bolt-on?
>
>    • What could be added to HTML to make the markup simpler and more
> semantic, possibly by importing some elements from MathML more or less
> directly, without requiring them to be in a MathML context but without
> duplicating HTML functionality?
>
> I'm repeating both myself and others, but going about this with an
> Extensible Web Manifesto spirit would surely help.
>
> And I'm sure the WICG could be a great place to entertain
> (non-monolithic) new ideas and hash them out with support from browser
> vendors.
>
> > Personally, I don't think MathML will be implemented in browsers
> > (though I'd be extremely happy to be wrong here and will support any
> > effort in this group). I do think there are more realistic alternative
> > goals such as improving CSS implementations incrementally and
> > developing standards for exposing underlying data such as MathML to
> tools such as AT.
>
> +1
>
> --
> Robin Berjon - http://berjon.com/ - @robinberjon
>
>