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

Re Robin.

> Asking naïvely: is there any reason not to start fixing this right now?

Community interest. Also, all other challenges in terms of math AT.

>  • 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 have a solution but it does not fit into the margin of this book.

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

I think it's a bit early for that. It would also require quite a few
additional resources to pursue that path (at least from our perspective).

Peter.

On Tue, Aug 25, 2015 at 11:42 AM, Peter Krautzberger <
peter.krautzberger@mathjax.org> wrote:

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