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

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

Received on Tuesday, 25 August 2015 18:04:36 UTC