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

Re Doug.


> I think we could really benefit from taking a look at _why_ browser
vendors aren't implementing MathML, learning those lessons, and making a
new version of MathML that's easier to implement and maintain, easier to
author, easier to style, and is better integrated into HTML5.

+1 (but it's a rather tall order ;-) )

> I've voiced this opinion to Peter before. I don't think we differ much,

+1.


Re Rich

> What I have heard from some browser vendors is that there is just not
enough MathML content out there and it is difficult to justify the
performance hit.

Performance is definitely a problem even for browser implementations. But
it's hard to say if that's just for lack for interest from browser vendors.
For example, earlier this year we had an edge case where MathJax
outperformed native Firefox support (by a margin); this was quickly
resolved once we got the attention of Rob O'Callahan at Mozilla.

Re Rob.

> The FXTF (a joint task force of SVG and CSS) might be a good model here.

+1. One difference is that browser vendors were actually interested in
implementing SVG features; I don't see that for math layout. Still,
reactions from Houdini leave me mildly hopeful.

> The FXTF split out things like filters, transforms, animation into their
own modules. The effect is doubly beneficial: it is easier to focus on
implementing smaller features and the user base for a feature that works in
broader HTML+CSS contexts and use cases is much larger than that for just
SVG.

I'm not too sure about that. It was actually a very small math layout
feature that triggered the removal of MathML from Chrome. (The Chrome team
convinced itself that stretchy characters are somehow fundamentally
incompatible with CSS layout.)

Peter.

On Tue, Aug 25, 2015 at 11:07 AM, Robin Berjon <robin@w3.org> wrote:

> On 24/08/2015 23:43 , Doug Schepers wrote:
>
>> I think we could really benefit from taking a look at _why_ browser
>> vendors aren't implementing MathML
>>
>
> I won't claim that it's the final word from browser vendors, but this was
> discussed extensively at Balisage last year. MathML suffers from the
> combination of being a pretty large chunk with a relatively small community.
>
> learning those lessons, and making a new version of MathML that's
>> easier to implement and maintain, easier to author, easier to style,
>> and is better integrated into HTML5.
>>
>
> The FXTF (a joint task force of SVG and CSS) might be a good model here.
> SVG was also designed largely separately from HTML and CSS, and the FXTF
> has helped line things up so that the same tech could be used by both.
>
> A key point there was splitting things up. Implementing all of SVG at once
> is pretty daunting. The FXTF split out things like filters, transforms,
> animation into their own modules. The effect is doubly beneficial: it is
> easier to focus on implementing smaller features and the user base for a
> feature that works in broader HTML+CSS contexts and use cases is much
> larger than that for just SVG.
>
> --
> Robin Berjon - http://berjon.com/ - @robinberjon
>