The
*Planet MathML* aggregates posts from various blogs that
concern MathML. Although it is hosted by W3C, the content of the
individual entries represent only the opinion of their respective
authors and **does not reflect the position of
W3C.**

- Re: Clipboard API: remove dangerous formats from mandatory data types • August 27, 2015
- RE: Fwd: [Moderator Action] RE: Active lobbying: Math • August 25, 2015
- Re: [Moderator Action] RE: Active lobbying: Math • August 25, 2015
- Re: Fwd: [Moderator Action] RE: Active lobbying: Math • August 25, 2015
- Re: Fwd: [Moderator Action] RE: Active lobbying: Math • August 25, 2015
- Re: Fwd: [Moderator Action] RE: Active lobbying: Math • August 25, 2015
- Re: Fwd: [Moderator Action] RE: Active lobbying: Math • August 25, 2015
- Fwd: [Moderator Action] [Moderator Action] RE: Active lobbying: Math • August 25, 2015
- Fwd: [Moderator Action] [Moderator Action] RE: Active lobbying: Math • August 25, 2015
- Fwd: [Moderator Action] [Moderator Action] RE: Active lobbying: Math • August 25, 2015
- Fwd: [Moderator Action] [Moderator Action] RE: Active lobbying: Math • August 25, 2015
- Re: Fwd: [Moderator Action] RE: Active lobbying: Math • August 24, 2015
- Re: Fwd: [Moderator Action] RE: Active lobbying: Math • August 24, 2015
- Re: Fwd: [Moderator Action] RE: Active lobbying: Math • August 24, 2015
- RE: Fwd: [Moderator Action] RE: Active lobbying: Math • August 24, 2015
- Re: [Moderator Action] Active lobbying: Math • August 24, 2015
- Meeting minutes 2015-08-24 • August 24, 2015
- Re: Fwd: [Moderator Action] RE: Active lobbying: Math • August 24, 2015
- Fwd: [Moderator Action] Active lobbying: Math • August 24, 2015
- Fwd: [Moderator Action] RE: Active lobbying: Math • August 22, 2015
**[List of feeds]**

On Mon, Aug 17, 2015 at 2:54 PM, Paul Libbrecht <paul@hoplahup.net> wrote: > Hallvord, > > do you not want to split the writable types list in safe and non-safe ones > and let browsers how they deal with unsafe ones? > No, absolutely not. If we leave such things up to the browser we end up with implementations that do wildly different things and web developers suffering new levels of incompatibility pain. > Here's an idea: > > html, xml, and picture formats should be in the unsafe ones. > If we can help it, HTML should not be unsafe. It's the web's primary format, and if we class it as unsafe we basically prohibit scripts from being able to export formatted text to the clipboard. I do however know it takes a bit of a leap of faith to believe that it's safe enough, given that HTML parsing was a bit of a dark art for many years. Today we can at least hope a lot of software that consumes HTML has been updated to use HTML5 algorithms. > I guess json too (but both XML and JSON are too generic to my taste). > Why should JSON be unsafe? Parsing JSON should be pretty easy, so hopefully most parsers would be safe. > For the unsafe formats, the warning could say that the UA-implementors > should only support the flavour if they have a method to make this content > safe so that local applications (which do not expect untrusted content) > receive content they can trust when pasting. Methods to make the content > safe include the following: transcoding a picture, inlining all external > entities for html, xml, mathml, or rtf). > On Windows I believe images are transcoded to and from DIB - device independent bitmap format anyway. Is there any equivalent graphics interchange format on other platforms? Does mandating such transcoding help guarantee against payloads that might trigger vulnerabilities in target software? I expect it adds a significant hurdle against exploits, but I'd like input from Daniel Cheng and perhaps from people who have worked on image decoders.. -Hallvord

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

Robin, ARIA 1.0 was done to address the accessibility of Rich Internet Application. Although we are working on a 1.1 to address gaps for that type of content in 1.0, we now have an extension process. We have expanded to create modules for book digital publishing semantics and also graphics. So, if you look at the creation off multiple semantic taxonomies we have only scratched the surface. Math is an obvious essential next step for ARIA. Unfortunately, our charter is being held in limbo right now by some AC members. This is also holding up ARIA extensions for web components. I hope it gets resolved soon. The extension process was put in place so that work on new modules could start without making the ARIA working group main body a bottle neck to innovation in new taxonomies like Math. If we are to do an ARIA module for Math it would require a joint task force between the new ARIA working group and I think the Math WG with additional invited experts of course. We would need MathJax people to participate or even lead the effort. Other than having the new charter approved and committed people I don't see why this work could not start. I would argue that the accessibility of digital math is one of the most important things we should be doing at W3C. It just has not gotten the due attention. An ARIA module would facilitate multimodal access to Math which has proven to grow math comprehension for all users by roughly 10 percent. Rich Sent from my iPad > On Aug 25, 2015, at 4:22 AM, Robin Berjon <robin@w3.org> wrote: > > 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 >

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

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 >

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

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

> Begin forwarded message: > > From: Paul Topping <pault@dessci.com> > Subject: [Moderator Action] RE: Fwd: [Moderator Action] RE: Active lobbying: Math > Date: 25 Aug 2015 01:04:42 CEST > To: Richard Schwerdtfeger <schwer@us.ibm.com>, Doug Schepers <schepers@w3.org> > Cc: Peter Krautzberger <peter.krautzberger@mathjax.org>, "W3C Digital Publishing IG" <public-digipub-ig@w3.org> > X-W3C-Hub-Spam-Status: No, score=-8.6 > > With MathJax there is a huge amount of MathML content out there. Of course, this is all relative but I would challenge anyone to say that MathML is not important. Besides, there is the obvious chicken-and-egg situation here. How can a browser maker say that MathML is not used when people can’t put MathML in their pages because browsers don’t implement MathML? There are a lot of tools that produce MathML. Most people just don’t know it. Around 90% of all math submitted to scientific journals is in Microsoft Word format and uses either its built-in equation format or my company’s MathType equations. Both of these formats are readily convertible to MathML. The rest of the equations are LaTeX and there are lots of LaTeX-to-MathML convertors out their. I could go on but I can’t buy the “no MathML demand or content” argument. > > I don’t see the performance issue either. MathML rendering performance is only an issue for pages containing MathML. Performance was never an issue in MathPlayer in IE. We did rendering tests where we displayed 30 simultaneous windows full of equations in just a couple of seconds. It was orders of magnitude faster than a human could open windows and read them. I am sure the Firefox implementation was just as fast. MathPlayer is a lot slower due to JavaScript but even more due to the hoops it has to jump through because it is not a native implementation that is part of the browser. > > Paul Topping > > From: Richard Schwerdtfeger [mailto:schwer@us.ibm.com <mailto:schwer@us.ibm.com>] > Sent: Monday, August 24, 2015 3:40 PM > To: Doug Schepers <schepers@w3.org <mailto:schepers@w3.org>> > Cc: Peter Krautzberger <peter.krautzberger@mathjax.org <mailto:peter.krautzberger@mathjax.org>>; W3C Digital Publishing IG <public-digipub-ig@w3.org <mailto:public-digipub-ig@w3.org>> > Subject: Re: Fwd: [Moderator Action] RE: Active lobbying: Math > > 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. I believe this is due to a lack of easy to use authoring tools for Math that could be made available to educators. That is starting to change. > > I sit on a Technical Advisory Board for Namo Interactive. Their Namo Author EPUB authoring tool has some phenomenal templates for math (this is not a plug) that are easy to use by educators that help promote MATHML in their EPUB authoring tool. There is also the chicken and egg problem that because we did not have a lot of MathML generated on the web that the browser support has been dropping off. Readium is building math support into their EPUB readers which will help fill some of those gaps. This will result in greater use of digital math in education. I think the adoption of EPUB is going to grow greater adoption of MathML. > > Rich > > Rich Schwerdtfeger > > Doug Schepers ---08/24/2015 04:43:56 PM---Hi, folks– MathML was developed a long time ago, in isolation from HTML and CSS. > > From: Doug Schepers <schepers@w3.org <mailto:schepers@w3.org>> > To: Peter Krautzberger <peter.krautzberger@mathjax.org <mailto:peter.krautzberger@mathjax.org>>, W3C Digital Publishing IG <public-digipub-ig@w3.org <mailto:public-digipub-ig@w3.org>> > Date: 08/24/2015 04:43 PM > Subject: Re: Fwd: [Moderator Action] RE: Active lobbying: Math > > > > > Hi, folks– > > MathML was developed a long time ago, in isolation from HTML and CSS. > > 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. > > I've voiced this opinion to Peter before. I don't think we differ much, > and I think the years of experience the MathJax team and others have in > implementing MathML in modern browsers could yield a lot more benefit > than trying to push browser vendors to implement MathML as it is today. > > Regards– > –Doug > > On 8/24/15 3:47 PM, Peter Krautzberger wrote: > > Hi, > > > > This is a bit longer. Sorry about that. > > > > 1. Ivan suggested I should sum up what I've been involved in. > > > > * In 2013, when Chrome dropped WebKit's MathML code, we coordinated with > > our MathJax sponsors to reach out to Google management (non-publicly) to > > encourage the Chrome team to reconsider. > > * in 2013/14, MathJax looked into working on Gecko and WebKit directly; > > we could not find funding and we could not get WebKit companies to even > > have a discussion about long-term code ownership (let alone architecture > > or any other guidance). I'm aware of several efforts to find funding > > since then. > > * in 2015, the MathWG reached out to browser vendors to start a > > discussion of the overall situation; we put this on hold for lack of > > availability from the browser end > > > > 2. Regarding the discussion so far > > > > * re Paul Belfanti: "publishing at volume". > > > > I think from a browser vendors perspective, there will never be enough > > volume. > > > > * re Bill Kasdorf > > +1 to all points. But also: publisher investments in MathML have been > > mostly internal. Not many have invested in polyfills, web development > > tools, web standards development, or browser development. Similarly for > > third party vendors. > > > > * re Paul Topping. > > > > > I used all my votes for MathML but I am sure it didn't get many votes > > compared to other features. > > > > Actually, some features have fewer votes than MathML and get moved > > towards implementation. > > > > > After MathJax, the problem is largely solved, at least from their > > perspective. > > > > This does not match my experience. Frequently, web developers are using > > MathJax's shortcomings as an excuse to dismiss MathML. > > > > * re Deborah Kaplan > > > > > I want to stress that the push for native MathML is not out of any > > desire to get rid of MathJax. > > > > That's ok ;-) the MathJax project was designed to eliminate itself by > > encouraging browser support. But we'd also be happy to enable what comes > > after MathML 3. > > > > > It is out of the need for publishers to be able to distribute native > > math that can be read by screen readers without users having to do > > anything special. > > > > This strikes me as orthogonal to native MathML rendering. Both exposing > > MathML to a11y interfaces and finding MathML-enabled AT are quite > > different (but equally messy) problems. > > > > Simply reading out MathML via MathML-enabled AT is theoretically easy; > > try the example at https://github.com/mathjax/MathJax-docs/issues/111 <https://github.com/mathjax/MathJax-docs/issues/111>. > > > > The much bigger problem is AT for visual users, e.g., sync-highlighting > > and exploration (see comment on ARIA below). > > > > > Rather, the greater concern is non-browser-based reading systems, > > frequently used for textbooks, which have legal requirements for > > accessibility. > > > > How do you see browser implementations for MathML help here? > > > > * re Liam > > > > re (1) you make it sound easy ;-) > > > > re (3) is actually a huge, messy, overlooked issue; see my use cases on > > font metrics APIs for Houdini. > > > > re (4) I don't really think this is a big issue these days (although > > third party vendors are a different issue). TeX conversion has many > > options, Microsoft's own equation editor and Windows handwriting > > recognition can produce MathML, MyScript has great apps. Although > > high-quality MathML Editors are virtually non-existent (esp. if your > > focus is publishing on the web) -- that probably means something? > > > > re (5) the examples are not quite right, I think, (long division etc is > > actually pretty easy in MathML 3 markup). But otherwise, yes. > > > > re (a) math content becomes quickly tabular and there's not a lot room > > for reflow in tables. But here's something fun > > https://github.com/mathjax/MathJax-RespEq <https://github.com/mathjax/MathJax-RespEq> > > > > re (c) the state of MathML accessibility is pretty messy, on both the > > content, browser, OS, and AT end. > > > > > > 3. Let me add a couple of entirely personal points. > > > > 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. > > > > * Browser vendors have never worked on MathML. > > * MathML in Gecko and WebKit has been almost exclusively implemented > > by unpaid volunteers > > * Only Mozilla devs has actually supported its volunteer; they are > > the only knowledgeable browser devs regarding MathML. > > > > * 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 > > > > * third party vendors have a bit more knowledge of the first two but I > > sometimes see an incentive to keep things complicated (read: expensive). > > > > * The ARIA spec has a massive hole where mathematics should be. > > > > * 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. (MathJax will introduce such > > a technology in our next release. It's not pretty markup code and it's > > not perfect but it works.) > > > > 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. > > > > Again, sorry about the length. > > Peter. > > > > On Mon, Aug 24, 2015 at 7:29 PM, Deborah Kaplan > > <dkaplan@safaribooksonline.com <mailto:dkaplan@safaribooksonline.com> <mailto:dkaplan@safaribooksonline.com <mailto:dkaplan@safaribooksonline.com>>> > > wrote: > > > > On Mon, 24 Aug 2015, Paul Topping wrote: > > > > Convincing them to implement EPUB would be a worthwhile cause. > > > > > > Yes, absolutely. > > > > Isn't the bigger problem convincing students and teachers to > > adopt etextbooks? > > > > I'm sure many of you here know the actual data, and anecdotes are > > not data. But I do know that when I was a graduate student two years > > ago, I had two choices: print, or the official electronic textbook > > through our vendor, which was an epub which could only be read > > through the vendor's reading system. > > > > At that institution, in any case, the students and the teachers > > aren't making the decisions. If you buy a textbook, you get the > > electronic version as is delivered, which is usually EPUB. > > > > But again, I'm sure many people on this list have the actual data. > > > > (There was non-terrible accessibility on the reading system (since > > it is an educational platform with compliance requirements), so it > > was minimally usable without a mouse. But the textbooks were > > unedited OCR, so I wouldn't have wanted to use them with a screen > > reader. > > > > That's a content problem, though. Unedited OCR isn't going to end up > > with MathML markup no matter what the reader supports.) > > > > Deborah > > > > > ---- Ivan Herman, W3C Digital Publishing Activity Lead Home: http://www.w3.org/People/Ivan/ mobile: +31-641044153 ORCID ID: http://orcid.org/0000-0003-0782-2704

> Begin forwarded message: > > From: Paul Topping <pault@dessci.com> > Subject: [Moderator Action] RE: Fwd: [Moderator Action] RE: Active lobbying: Math > Date: 25 Aug 2015 24:17:09 CEST > To: Doug Schepers <schepers@w3.org>, Peter Krautzberger <peter.krautzberger@mathjax.org>, W3C Digital Publishing IG <public-digipub-ig@w3.org> > X-W3C-Hub-Spam-Status: No, score=-8.8 > > Although I have my own issues with MathML's design, it was not that hard to implement in Internet Explorer with our MathPlayer plugin. Microsoft did add perhaps 3 APIs that helped it along but, other than that, MathPlayer was able to do a pretty good job of rendering MathML both graphically and as speech. Although MathPlayer acted as a plug-in to IE, it was implemented using native C++ COM objects, just like IE itself, and, therefore, was an integrated part of the browser. > > I have never heard anyone representing a browser maker complain that MathML was hard to implement. They all said that they didn't perceive any demand. Of course, we know enough about MathML to say that it is not trivial to implement but I see nothing that makes me think that is the source of the problem. Furthermore, those things that make MathML implementation non-trivial are really unavoidable. Off the top of my head, there are two areas: > > - Font and character metrics. Browsers don't provide enough APIs to do this. In MathPlayer we were able to do this with native Windows APIs so this was not really a problem. > > - Layout negotiation. In the simplest situation, equation rendering code needs to get information from the layout engine about the body text font, size, and color and the column width, calculate the vertical space required for the equation, and then be told by the browser to render in the space it provides. > > These problems are really not that hard to solve and would be present in equation rendering regardless of the design of MathML. > > Paul > >> -----Original Message----- >> From: Doug Schepers [mailto:schepers@w3.org] >> Sent: Monday, August 24, 2015 2:43 PM >> To: Peter Krautzberger <peter.krautzberger@mathjax.org>; W3C Digital >> Publishing IG <public-digipub-ig@w3.org> >> Subject: Re: Fwd: [Moderator Action] RE: Active lobbying: Math >> >> Hi, folks– >> >> MathML was developed a long time ago, in isolation from HTML and CSS. >> >> 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. >> >> I've voiced this opinion to Peter before. I don't think we differ much, >> and I think the years of experience the MathJax team and others have in >> implementing MathML in modern browsers could yield a lot more benefit >> than trying to push browser vendors to implement MathML as it is today. >> >> Regards– >> –Doug >> >> On 8/24/15 3:47 PM, Peter Krautzberger wrote: >>> Hi, >>> >>> This is a bit longer. Sorry about that. >>> >>> 1. Ivan suggested I should sum up what I've been involved in. >>> >>> * In 2013, when Chrome dropped WebKit's MathML code, we coordinated >> with >>> our MathJax sponsors to reach out to Google management (non-publicly) >> to >>> encourage the Chrome team to reconsider. >>> * in 2013/14, MathJax looked into working on Gecko and WebKit directly; >>> we could not find funding and we could not get WebKit companies to even >>> have a discussion about long-term code ownership (let alone architecture >>> or any other guidance). I'm aware of several efforts to find funding >>> since then. >>> * in 2015, the MathWG reached out to browser vendors to start a >>> discussion of the overall situation; we put this on hold for lack of >>> availability from the browser end >>> >>> 2. Regarding the discussion so far >>> >>> * re Paul Belfanti: "publishing at volume". >>> >>> I think from a browser vendors perspective, there will never be enough >>> volume. >>> >>> * re Bill Kasdorf >>> +1 to all points. But also: publisher investments in MathML have been >>> mostly internal. Not many have invested in polyfills, web development >>> tools, web standards development, or browser development. Similarly for >>> third party vendors. >>> >>> * re Paul Topping. >>> >>>> I used all my votes for MathML but I am sure it didn't get many votes >>> compared to other features. >>> >>> Actually, some features have fewer votes than MathML and get moved >>> towards implementation. >>> >>>> After MathJax, the problem is largely solved, at least from their >>> perspective. >>> >>> This does not match my experience. Frequently, web developers are using >>> MathJax's shortcomings as an excuse to dismiss MathML. >>> >>> * re Deborah Kaplan >>> >>>> I want to stress that the push for native MathML is not out of any >>> desire to get rid of MathJax. >>> >>> That's ok ;-) the MathJax project was designed to eliminate itself by >>> encouraging browser support. But we'd also be happy to enable what >> comes >>> after MathML 3. >>> >>>> It is out of the need for publishers to be able to distribute native >>> math that can be read by screen readers without users having to do >>> anything special. >>> >>> This strikes me as orthogonal to native MathML rendering. Both exposing >>> MathML to a11y interfaces and finding MathML-enabled AT are quite >>> different (but equally messy) problems. >>> >>> Simply reading out MathML via MathML-enabled AT is theoretically easy; >>> try the example at https://github.com/mathjax/MathJax-docs/issues/111. >>> >>> The much bigger problem is AT for visual users, e.g., sync-highlighting >>> and exploration (see comment on ARIA below). >>> >>>> Rather, the greater concern is non-browser-based reading systems, >>> frequently used for textbooks, which have legal requirements for >>> accessibility. >>> >>> How do you see browser implementations for MathML help here? >>> >>> * re Liam >>> >>> re (1) you make it sound easy ;-) >>> >>> re (3) is actually a huge, messy, overlooked issue; see my use cases on >>> font metrics APIs for Houdini. >>> >>> re (4) I don't really think this is a big issue these days (although >>> third party vendors are a different issue). TeX conversion has many >>> options, Microsoft's own equation editor and Windows handwriting >>> recognition can produce MathML, MyScript has great apps. Although >>> high-quality MathML Editors are virtually non-existent (esp. if your >>> focus is publishing on the web) -- that probably means something? >>> >>> re (5) the examples are not quite right, I think, (long division etc is >>> actually pretty easy in MathML 3 markup). But otherwise, yes. >>> >>> re (a) math content becomes quickly tabular and there's not a lot room >>> for reflow in tables. But here's something fun >>> https://github.com/mathjax/MathJax-RespEq >>> >>> re (c) the state of MathML accessibility is pretty messy, on both the >>> content, browser, OS, and AT end. >>> >>> >>> 3. Let me add a couple of entirely personal points. >>> >>> 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. >>> >>> * Browser vendors have never worked on MathML. >>> * MathML in Gecko and WebKit has been almost exclusively >> implemented >>> by unpaid volunteers >>> * Only Mozilla devs has actually supported its volunteer; they are >>> the only knowledgeable browser devs regarding MathML. >>> >>> * 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 >>> >>> * third party vendors have a bit more knowledge of the first two but I >>> sometimes see an incentive to keep things complicated (read: expensive). >>> >>> * The ARIA spec has a massive hole where mathematics should be. >>> >>> * 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. (MathJax will introduce such >>> a technology in our next release. It's not pretty markup code and it's >>> not perfect but it works.) >>> >>> 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. >>> >>> Again, sorry about the length. >>> Peter. >>> >>> On Mon, Aug 24, 2015 at 7:29 PM, Deborah Kaplan >>> <dkaplan@safaribooksonline.com >> <mailto:dkaplan@safaribooksonline.com>> >>> wrote: >>> >>> On Mon, 24 Aug 2015, Paul Topping wrote: >>> >>> Convincing them to implement EPUB would be a worthwhile cause. >>> >>> >>> Yes, absolutely. >>> >>> Isn't the bigger problem convincing students and teachers to >>> adopt etextbooks? >>> >>> I'm sure many of you here know the actual data, and anecdotes are >>> not data. But I do know that when I was a graduate student two years >>> ago, I had two choices: print, or the official electronic textbook >>> through our vendor, which was an epub which could only be read >>> through the vendor's reading system. >>> >>> At that institution, in any case, the students and the teachers >>> aren't making the decisions. If you buy a textbook, you get the >>> electronic version as is delivered, which is usually EPUB. >>> >>> But again, I'm sure many people on this list have the actual data. >>> >>> (There was non-terrible accessibility on the reading system (since >>> it is an educational platform with compliance requirements), so it >>> was minimally usable without a mouse. But the textbooks were >>> unedited OCR, so I wouldn't have wanted to use them with a screen >>> reader. >>> >>> That's a content problem, though. Unedited OCR isn't going to end up >>> with MathML markup no matter what the reader supports.) >>> >>> Deborah >>> >>> > ---- Ivan Herman, W3C Digital Publishing Activity Lead Home: http://www.w3.org/People/Ivan/ mobile: +31-641044153 ORCID ID: http://orcid.org/0000-0003-0782-2704

> Begin forwarded message: > > From: Paul Topping <pault@dessci.com> > Subject: [Moderator Action] RE: Fwd: [Moderator Action] RE: Active lobbying: Math > Date: 24 Aug 2015 22:12:36 CEST > To: Peter Krautzberger <peter.krautzberger@mathjax.org>, "W3C Digital Publishing IG" <public-digipub-ig@w3.org> > X-W3C-Hub-Spam-Status: No, score=-6.3 > > Peter, > > I totally agree with the lack of MathML knowledge on the part of browser vendors and, perhaps, beyond. Perhaps there’s some math phobia at play here. > > I also agree that the state of math accessibility is messy. Lots of stuff out there to convert MathML to speech strings (plug: my company’s MathPlayer does a good job) but what is lacking are the consistent delivery mechanisms. It is hard for end users to put all the pieces together. In fact, it is hard for software developers to put the pieces together. The number of people who care about math accessibility, AND have the intimate technical knowledge to even know what’s missing, is small. It is hard for them to get the attention of the people who set the technical agenda and allocate resources for screen readers, browsers, AT s/w, standards, etc. They all have bigger fish to fry, as they say. > > When you say “web developers are using MathJax's shortcomings as an excuse to dismiss MathML”, what shortcomings were you referring to? Judging from the mailing list traffic, my own take is that, except perhaps for performance, the shortcomings are really just due to the difficulty of integrating MathJax into web pages. This is not so much due to shortcomings that MathJax can address but the general lack of modularity and structure in the modern web platform. This is at least something that the HTML5 movers and shakers are aware of and are addressing. Though they have a long way to go, there is a lot of energy behind it and it has a high priority. That said, I do worry that they are not addressing precisely the issues that MathJax needs addressed. Perhaps an agenda item would be to make these needs explicit. Rather than demand that browser makers implement MathML, ask that they address a set of integration problems that would make MathJax easier to work with and have better performance. For example, MathJax has to perform a bunch of tricks to make typographic measurements and these are generally a performance bottlekneck. Perhaps these could be supplied by some new browser API. > Paul > > From: Peter Krautzberger [mailto:peter.krautzberger@mathjax.org <mailto:peter.krautzberger@mathjax.org>] > Sent: Monday, August 24, 2015 12:48 PM > To: W3C Digital Publishing IG <public-digipub-ig@w3.org <mailto:public-digipub-ig@w3.org>> > Subject: Re: Fwd: [Moderator Action] RE: Active lobbying: Math > > Hi, > > This is a bit longer. Sorry about that. > > 1. Ivan suggested I should sum up what I've been involved in. > > * In 2013, when Chrome dropped WebKit's MathML code, we coordinated with our MathJax sponsors to reach out to Google management (non-publicly) to encourage the Chrome team to reconsider. > * in 2013/14, MathJax looked into working on Gecko and WebKit directly; we could not find funding and we could not get WebKit companies to even have a discussion about long-term code ownership (let alone architecture or any other guidance). I'm aware of several efforts to find funding since then. > * in 2015, the MathWG reached out to browser vendors to start a discussion of the overall situation; we put this on hold for lack of availability from the browser end > > 2. Regarding the discussion so far > > * re Paul Belfanti: "publishing at volume". > > I think from a browser vendors perspective, there will never be enough volume. > > * re Bill Kasdorf > +1 to all points. But also: publisher investments in MathML have been mostly internal. Not many have invested in polyfills, web development tools, web standards development, or browser development. Similarly for third party vendors. > > * re Paul Topping. > > > I used all my votes for MathML but I am sure it didn't get many votes compared to other features. > > Actually, some features have fewer votes than MathML and get moved towards implementation. > > > After MathJax, the problem is largely solved, at least from their perspective. > > This does not match my experience. Frequently, web developers are using MathJax's shortcomings as an excuse to dismiss MathML. > > * re Deborah Kaplan > > > I want to stress that the push for native MathML is not out of any desire to get rid of MathJax. > > That's ok ;-) the MathJax project was designed to eliminate itself by encouraging browser support. But we'd also be happy to enable what comes after MathML 3. > > > It is out of the need for publishers to be able to distribute native math that can be read by screen readers without users having to do anything special. > > This strikes me as orthogonal to native MathML rendering. Both exposing MathML to a11y interfaces and finding MathML-enabled AT are quite different (but equally messy) problems. > > Simply reading out MathML via MathML-enabled AT is theoretically easy; try the example at https://github.com/mathjax/MathJax-docs/issues/111 <https://github.com/mathjax/MathJax-docs/issues/111>. > > The much bigger problem is AT for visual users, e.g., sync-highlighting and exploration (see comment on ARIA below). > > > Rather, the greater concern is non-browser-based reading systems, frequently used for textbooks, which have legal requirements for accessibility. > > How do you see browser implementations for MathML help here? > > * re Liam > > re (1) you make it sound easy ;-) > > re (3) is actually a huge, messy, overlooked issue; see my use cases on font metrics APIs for Houdini. > > re (4) I don't really think this is a big issue these days (although third party vendors are a different issue). TeX conversion has many options, Microsoft's own equation editor and Windows handwriting recognition can produce MathML, MyScript has great apps. Although high-quality MathML Editors are virtually non-existent (esp. if your focus is publishing on the web) -- that probably means something? > > re (5) the examples are not quite right, I think, (long division etc is actually pretty easy in MathML 3 markup). But otherwise, yes. > > re (a) math content becomes quickly tabular and there's not a lot room for reflow in tables. But here's something fun https://github.com/mathjax/MathJax-RespEq <https://github.com/mathjax/MathJax-RespEq> > re (c) the state of MathML accessibility is pretty messy, on both the content, browser, OS, and AT end. > > > 3. Let me add a couple of entirely personal points. > > 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. > > * Browser vendors have never worked on MathML. > * MathML in Gecko and WebKit has been almost exclusively implemented by unpaid volunteers > * Only Mozilla devs has actually supported its volunteer; they are the only knowledgeable browser devs regarding MathML. > > * 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 > > * third party vendors have a bit more knowledge of the first two but I sometimes see an incentive to keep things complicated (read: expensive). > > * The ARIA spec has a massive hole where mathematics should be. > > * 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. (MathJax will introduce such a technology in our next release. It's not pretty markup code and it's not perfect but it works.) > > 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. > > Again, sorry about the length. > Peter. > > On Mon, Aug 24, 2015 at 7:29 PM, Deborah Kaplan <dkaplan@safaribooksonline.com <mailto:dkaplan@safaribooksonline.com>> wrote: > On Mon, 24 Aug 2015, Paul Topping wrote: > > Convincing them to implement EPUB would be a worthwhile cause. > > Yes, absolutely. > > Isn't the bigger problem convincing students and teachers to adopt etextbooks? > I'm sure many of you here know the actual data, and anecdotes are not data. But I do know that when I was a graduate student two years ago, I had two choices: print, or the official electronic textbook through our vendor, which was an epub which could only be read through the vendor's reading system. > > At that institution, in any case, the students and the teachers aren't making the decisions. If you buy a textbook, you get the electronic version as is delivered, which is usually EPUB. > > But again, I'm sure many people on this list have the actual data. > > (There was non-terrible accessibility on the reading system (since it is an educational platform with compliance requirements), so it was minimally usable without a mouse. But the textbooks were unedited OCR, so I wouldn't have wanted to use them with a screen reader. > > That's a content problem, though. Unedited OCR isn't going to end up with MathML markup no matter what the reader supports.) > > Deborah > ---- Ivan Herman, W3C Digital Publishing Activity Lead Home: http://www.w3.org/People/Ivan/ mobile: +31-641044153 ORCID ID: http://orcid.org/0000-0003-0782-2704

> Begin forwarded message: > > From: Paul Topping <pault@dessci.com> > Subject: [Moderator Action] RE: Fwd: [Moderator Action] RE: Active lobbying: Math > Date: 24 Aug 2015 20:11:32 CEST > To: Deborah Kaplan <dkaplan@safaribooksonline.com> > Cc: Ivan Herman <ivan@w3.org>, W3C Digital Publishing IG <public-digipub-ig@w3.org> > X-W3C-Hub-Spam-Status: No, score=-6.3 > > Actually, the Infty Reader Group (www.inftyreader.com) has software that does OCR into MathML. > >> -----Original Message----- >> From: Deborah Kaplan [mailto:dkaplan@safaribooksonline.com] >> Sent: Monday, August 24, 2015 10:29 AM >> To: Paul Topping <pault@dessci.com> >> Cc: Ivan Herman <ivan@w3.org>; W3C Digital Publishing IG <public-digipub- >> ig@w3.org> >> Subject: RE: Fwd: [Moderator Action] RE: Active lobbying: Math >> >> On Mon, 24 Aug 2015, Paul Topping wrote: >> >>> Convincing them to implement EPUB would be a worthwhile cause. >> >> Yes, absolutely. >> >>> Isn't the bigger problem convincing students and teachers to adopt >> etextbooks? >> I'm sure many of you here know the actual data, and anecdotes are not data. >> But I do know that when I was a graduate student two years ago, I had two >> choices: print, or the official electronic textbook through our vendor, which >> was an epub which could only be read through the vendor's reading system. >> >> At that institution, in any case, the students and the teachers aren't making >> the decisions. If you buy a textbook, you get the electronic version as is >> delivered, which is usually EPUB. >> >> But again, I'm sure many people on this list have the actual data. >> >> (There was non-terrible accessibility on the reading system (since it is an >> educational platform with compliance requirements), so it was minimally >> usable without a mouse. But the textbooks were unedited OCR, so I >> wouldn't have wanted to use them with a screen reader. >> >> That's a content problem, though. Unedited OCR isn't going to end up with >> MathML markup no matter what the reader supports.) >> >> Deborah > ---- Ivan Herman, W3C Digital Publishing Activity Lead Home: http://www.w3.org/People/Ivan/ mobile: +31-641044153 ORCID ID: http://orcid.org/0000-0003-0782-2704

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. I believe this is due to a lack of easy to use authoring tools for Math that could be made available to educators. That is starting to change. I sit on a Technical Advisory Board for Namo Interactive. Their Namo Author EPUB authoring tool has some phenomenal templates for math (this is not a plug) that are easy to use by educators that help promote MATHML in their EPUB authoring tool. There is also the chicken and egg problem that because we did not have a lot of MathML generated on the web that the browser support has been dropping off. Readium is building math support into their EPUB readers which will help fill some of those gaps. This will result in greater use of digital math in education. I think the adoption of EPUB is going to grow greater adoption of MathML. Rich Rich Schwerdtfeger From: Doug Schepers <schepers@w3.org> To: Peter Krautzberger <peter.krautzberger@mathjax.org>, W3C Digital Publishing IG <public-digipub-ig@w3.org> Date: 08/24/2015 04:43 PM Subject: Re: Fwd: [Moderator Action] RE: Active lobbying: Math Hi, folks– MathML was developed a long time ago, in isolation from HTML and CSS. 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. I've voiced this opinion to Peter before. I don't think we differ much, and I think the years of experience the MathJax team and others have in implementing MathML in modern browsers could yield a lot more benefit than trying to push browser vendors to implement MathML as it is today. Regards– –Doug On 8/24/15 3:47 PM, Peter Krautzberger wrote: > Hi, > > This is a bit longer. Sorry about that. > > 1. Ivan suggested I should sum up what I've been involved in. > > * In 2013, when Chrome dropped WebKit's MathML code, we coordinated with > our MathJax sponsors to reach out to Google management (non-publicly) to > encourage the Chrome team to reconsider. > * in 2013/14, MathJax looked into working on Gecko and WebKit directly; > we could not find funding and we could not get WebKit companies to even > have a discussion about long-term code ownership (let alone architecture > or any other guidance). I'm aware of several efforts to find funding > since then. > * in 2015, the MathWG reached out to browser vendors to start a > discussion of the overall situation; we put this on hold for lack of > availability from the browser end > > 2. Regarding the discussion so far > > * re Paul Belfanti: "publishing at volume". > > I think from a browser vendors perspective, there will never be enough > volume. > > * re Bill Kasdorf > +1 to all points. But also: publisher investments in MathML have been > mostly internal. Not many have invested in polyfills, web development > tools, web standards development, or browser development. Similarly for > third party vendors. > > * re Paul Topping. > > > I used all my votes for MathML but I am sure it didn't get many votes > compared to other features. > > Actually, some features have fewer votes than MathML and get moved > towards implementation. > > > After MathJax, the problem is largely solved, at least from their > perspective. > > This does not match my experience. Frequently, web developers are using > MathJax's shortcomings as an excuse to dismiss MathML. > > * re Deborah Kaplan > > > I want to stress that the push for native MathML is not out of any > desire to get rid of MathJax. > > That's ok ;-) the MathJax project was designed to eliminate itself by > encouraging browser support. But we'd also be happy to enable what comes > after MathML 3. > > > It is out of the need for publishers to be able to distribute native > math that can be read by screen readers without users having to do > anything special. > > This strikes me as orthogonal to native MathML rendering. Both exposing > MathML to a11y interfaces and finding MathML-enabled AT are quite > different (but equally messy) problems. > > Simply reading out MathML via MathML-enabled AT is theoretically easy; > try the example at https://github.com/mathjax/MathJax-docs/issues/111. > > The much bigger problem is AT for visual users, e.g., sync-highlighting > and exploration (see comment on ARIA below). > > > Rather, the greater concern is non-browser-based reading systems, > frequently used for textbooks, which have legal requirements for > accessibility. > > How do you see browser implementations for MathML help here? > > * re Liam > > re (1) you make it sound easy ;-) > > re (3) is actually a huge, messy, overlooked issue; see my use cases on > font metrics APIs for Houdini. > > re (4) I don't really think this is a big issue these days (although > third party vendors are a different issue). TeX conversion has many > options, Microsoft's own equation editor and Windows handwriting > recognition can produce MathML, MyScript has great apps. Although > high-quality MathML Editors are virtually non-existent (esp. if your > focus is publishing on the web) -- that probably means something? > > re (5) the examples are not quite right, I think, (long division etc is > actually pretty easy in MathML 3 markup). But otherwise, yes. > > re (a) math content becomes quickly tabular and there's not a lot room > for reflow in tables. But here's something fun > https://github.com/mathjax/MathJax-RespEq > > re (c) the state of MathML accessibility is pretty messy, on both the > content, browser, OS, and AT end. > > > 3. Let me add a couple of entirely personal points. > > 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. > > * Browser vendors have never worked on MathML. > * MathML in Gecko and WebKit has been almost exclusively implemented > by unpaid volunteers > * Only Mozilla devs has actually supported its volunteer; they are > the only knowledgeable browser devs regarding MathML. > > * 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 > > * third party vendors have a bit more knowledge of the first two but I > sometimes see an incentive to keep things complicated (read: expensive). > > * The ARIA spec has a massive hole where mathematics should be. > > * 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. (MathJax will introduce such > a technology in our next release. It's not pretty markup code and it's > not perfect but it works.) > > 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. > > Again, sorry about the length. > Peter. > > On Mon, Aug 24, 2015 at 7:29 PM, Deborah Kaplan > <dkaplan@safaribooksonline.com <mailto:dkaplan@safaribooksonline.com>> > wrote: > > On Mon, 24 Aug 2015, Paul Topping wrote: > > Convincing them to implement EPUB would be a worthwhile cause. > > > Yes, absolutely. > > Isn't the bigger problem convincing students and teachers to > adopt etextbooks? > > I'm sure many of you here know the actual data, and anecdotes are > not data. But I do know that when I was a graduate student two years > ago, I had two choices: print, or the official electronic textbook > through our vendor, which was an epub which could only be read > through the vendor's reading system. > > At that institution, in any case, the students and the teachers > aren't making the decisions. If you buy a textbook, you get the > electronic version as is delivered, which is usually EPUB. > > But again, I'm sure many people on this list have the actual data. > > (There was non-terrible accessibility on the reading system (since > it is an educational platform with compliance requirements), so it > was minimally usable without a mouse. But the textbooks were > unedited OCR, so I wouldn't have wanted to use them with a screen > reader. > > That's a content problem, though. Unedited OCR isn't going to end up > with MathML markup no matter what the reader supports.) > > Deborah > >

Hi, folks– MathML was developed a long time ago, in isolation from HTML and CSS. 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. I've voiced this opinion to Peter before. I don't think we differ much, and I think the years of experience the MathJax team and others have in implementing MathML in modern browsers could yield a lot more benefit than trying to push browser vendors to implement MathML as it is today. Regards– –Doug On 8/24/15 3:47 PM, Peter Krautzberger wrote: > Hi, > > This is a bit longer. Sorry about that. > > 1. Ivan suggested I should sum up what I've been involved in. > > * In 2013, when Chrome dropped WebKit's MathML code, we coordinated with > our MathJax sponsors to reach out to Google management (non-publicly) to > encourage the Chrome team to reconsider. > * in 2013/14, MathJax looked into working on Gecko and WebKit directly; > we could not find funding and we could not get WebKit companies to even > have a discussion about long-term code ownership (let alone architecture > or any other guidance). I'm aware of several efforts to find funding > since then. > * in 2015, the MathWG reached out to browser vendors to start a > discussion of the overall situation; we put this on hold for lack of > availability from the browser end > > 2. Regarding the discussion so far > > * re Paul Belfanti: "publishing at volume". > > I think from a browser vendors perspective, there will never be enough > volume. > > * re Bill Kasdorf > +1 to all points. But also: publisher investments in MathML have been > mostly internal. Not many have invested in polyfills, web development > tools, web standards development, or browser development. Similarly for > third party vendors. > > * re Paul Topping. > > > I used all my votes for MathML but I am sure it didn't get many votes > compared to other features. > > Actually, some features have fewer votes than MathML and get moved > towards implementation. > > > After MathJax, the problem is largely solved, at least from their > perspective. > > This does not match my experience. Frequently, web developers are using > MathJax's shortcomings as an excuse to dismiss MathML. > > * re Deborah Kaplan > > > I want to stress that the push for native MathML is not out of any > desire to get rid of MathJax. > > That's ok ;-) the MathJax project was designed to eliminate itself by > encouraging browser support. But we'd also be happy to enable what comes > after MathML 3. > > > It is out of the need for publishers to be able to distribute native > math that can be read by screen readers without users having to do > anything special. > > This strikes me as orthogonal to native MathML rendering. Both exposing > MathML to a11y interfaces and finding MathML-enabled AT are quite > different (but equally messy) problems. > > Simply reading out MathML via MathML-enabled AT is theoretically easy; > try the example at https://github.com/mathjax/MathJax-docs/issues/111. > > The much bigger problem is AT for visual users, e.g., sync-highlighting > and exploration (see comment on ARIA below). > > > Rather, the greater concern is non-browser-based reading systems, > frequently used for textbooks, which have legal requirements for > accessibility. > > How do you see browser implementations for MathML help here? > > * re Liam > > re (1) you make it sound easy ;-) > > re (3) is actually a huge, messy, overlooked issue; see my use cases on > font metrics APIs for Houdini. > > re (4) I don't really think this is a big issue these days (although > third party vendors are a different issue). TeX conversion has many > options, Microsoft's own equation editor and Windows handwriting > recognition can produce MathML, MyScript has great apps. Although > high-quality MathML Editors are virtually non-existent (esp. if your > focus is publishing on the web) -- that probably means something? > > re (5) the examples are not quite right, I think, (long division etc is > actually pretty easy in MathML 3 markup). But otherwise, yes. > > re (a) math content becomes quickly tabular and there's not a lot room > for reflow in tables. But here's something fun > https://github.com/mathjax/MathJax-RespEq > > re (c) the state of MathML accessibility is pretty messy, on both the > content, browser, OS, and AT end. > > > 3. Let me add a couple of entirely personal points. > > 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. > > * Browser vendors have never worked on MathML. > * MathML in Gecko and WebKit has been almost exclusively implemented > by unpaid volunteers > * Only Mozilla devs has actually supported its volunteer; they are > the only knowledgeable browser devs regarding MathML. > > * 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 > > * third party vendors have a bit more knowledge of the first two but I > sometimes see an incentive to keep things complicated (read: expensive). > > * The ARIA spec has a massive hole where mathematics should be. > > * 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. (MathJax will introduce such > a technology in our next release. It's not pretty markup code and it's > not perfect but it works.) > > 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. > > Again, sorry about the length. > Peter. > > On Mon, Aug 24, 2015 at 7:29 PM, Deborah Kaplan > <dkaplan@safaribooksonline.com <mailto:dkaplan@safaribooksonline.com>> > wrote: > > On Mon, 24 Aug 2015, Paul Topping wrote: > > Convincing them to implement EPUB would be a worthwhile cause. > > > Yes, absolutely. > > Isn't the bigger problem convincing students and teachers to > adopt etextbooks? > > I'm sure many of you here know the actual data, and anecdotes are > not data. But I do know that when I was a graduate student two years > ago, I had two choices: print, or the official electronic textbook > through our vendor, which was an epub which could only be read > through the vendor's reading system. > > At that institution, in any case, the students and the teachers > aren't making the decisions. If you buy a textbook, you get the > electronic version as is delivered, which is usually EPUB. > > But again, I'm sure many people on this list have the actual data. > > (There was non-terrible accessibility on the reading system (since > it is an educational platform with compliance requirements), so it > was minimally usable without a mouse. But the textbooks were > unedited OCR, so I wouldn't have wanted to use them with a screen > reader. > > That's a content problem, though. Unedited OCR isn't going to end up > with MathML markup no matter what the reader supports.) > > Deborah > >

Hi, This is a bit longer. Sorry about that. 1. Ivan suggested I should sum up what I've been involved in. * In 2013, when Chrome dropped WebKit's MathML code, we coordinated with our MathJax sponsors to reach out to Google management (non-publicly) to encourage the Chrome team to reconsider. * in 2013/14, MathJax looked into working on Gecko and WebKit directly; we could not find funding and we could not get WebKit companies to even have a discussion about long-term code ownership (let alone architecture or any other guidance). I'm aware of several efforts to find funding since then. * in 2015, the MathWG reached out to browser vendors to start a discussion of the overall situation; we put this on hold for lack of availability from the browser end 2. Regarding the discussion so far * re Paul Belfanti: "publishing at volume". I think from a browser vendors perspective, there will never be enough volume. * re Bill Kasdorf +1 to all points. But also: publisher investments in MathML have been mostly internal. Not many have invested in polyfills, web development tools, web standards development, or browser development. Similarly for third party vendors. * re Paul Topping. > I used all my votes for MathML but I am sure it didn't get many votes compared to other features. Actually, some features have fewer votes than MathML and get moved towards implementation. > After MathJax, the problem is largely solved, at least from their perspective. This does not match my experience. Frequently, web developers are using MathJax's shortcomings as an excuse to dismiss MathML. * re Deborah Kaplan > I want to stress that the push for native MathML is not out of any desire to get rid of MathJax. That's ok ;-) the MathJax project was designed to eliminate itself by encouraging browser support. But we'd also be happy to enable what comes after MathML 3. > It is out of the need for publishers to be able to distribute native math that can be read by screen readers without users having to do anything special. This strikes me as orthogonal to native MathML rendering. Both exposing MathML to a11y interfaces and finding MathML-enabled AT are quite different (but equally messy) problems. Simply reading out MathML via MathML-enabled AT is theoretically easy; try the example at https://github.com/mathjax/MathJax-docs/issues/111. The much bigger problem is AT for visual users, e.g., sync-highlighting and exploration (see comment on ARIA below). > Rather, the greater concern is non-browser-based reading systems, frequently used for textbooks, which have legal requirements for accessibility. How do you see browser implementations for MathML help here? * re Liam re (1) you make it sound easy ;-) re (3) is actually a huge, messy, overlooked issue; see my use cases on font metrics APIs for Houdini. re (4) I don't really think this is a big issue these days (although third party vendors are a different issue). TeX conversion has many options, Microsoft's own equation editor and Windows handwriting recognition can produce MathML, MyScript has great apps. Although high-quality MathML Editors are virtually non-existent (esp. if your focus is publishing on the web) -- that probably means something? re (5) the examples are not quite right, I think, (long division etc is actually pretty easy in MathML 3 markup). But otherwise, yes. re (a) math content becomes quickly tabular and there's not a lot room for reflow in tables. But here's something fun https://github.com/mathjax/MathJax-RespEq re (c) the state of MathML accessibility is pretty messy, on both the content, browser, OS, and AT end. 3. Let me add a couple of entirely personal points. 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. * Browser vendors have never worked on MathML. * MathML in Gecko and WebKit has been almost exclusively implemented by unpaid volunteers * Only Mozilla devs has actually supported its volunteer; they are the only knowledgeable browser devs regarding MathML. * 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 * third party vendors have a bit more knowledge of the first two but I sometimes see an incentive to keep things complicated (read: expensive). * The ARIA spec has a massive hole where mathematics should be. * 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. (MathJax will introduce such a technology in our next release. It's not pretty markup code and it's not perfect but it works.) 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. Again, sorry about the length. Peter. On Mon, Aug 24, 2015 at 7:29 PM, Deborah Kaplan < dkaplan@safaribooksonline.com> wrote: > On Mon, 24 Aug 2015, Paul Topping wrote: > > Convincing them to implement EPUB would be a worthwhile cause. >> > > Yes, absolutely. > > Isn't the bigger problem convincing students and teachers to adopt >> etextbooks? >> > I'm sure many of you here know the actual data, and anecdotes are not > data. But I do know that when I was a graduate student two years ago, I had > two choices: print, or the official electronic textbook through our vendor, > which was an epub which could only be read through the vendor's reading > system. > > At that institution, in any case, the students and the teachers aren't > making the decisions. If you buy a textbook, you get the electronic version > as is delivered, which is usually EPUB. > > But again, I'm sure many people on this list have the actual data. > > (There was non-terrible accessibility on the reading system (since it is > an educational platform with compliance requirements), so it was minimally > usable without a mouse. But the textbooks were unedited OCR, so I wouldn't > have wanted to use them with a screen reader. > > That's a content problem, though. Unedited OCR isn't going to end up with > MathML markup no matter what the reader supports.) > > Deborah > >

On Mon, 24 Aug 2015, Paul Topping wrote: > Convincing them to implement EPUB would be a worthwhile cause. Yes, absolutely. > Isn't the bigger problem convincing students and teachers to adopt etextbooks? I'm sure many of you here know the actual data, and anecdotes are not data. But I do know that when I was a graduate student two years ago, I had two choices: print, or the official electronic textbook through our vendor, which was an epub which could only be read through the vendor's reading system. At that institution, in any case, the students and the teachers aren't making the decisions. If you buy a textbook, you get the electronic version as is delivered, which is usually EPUB. But again, I'm sure many people on this list have the actual data. (There was non-terrible accessibility on the reading system (since it is an educational platform with compliance requirements), so it was minimally usable without a mouse. But the textbooks were unedited OCR, so I wouldn't have wanted to use them with a screen reader. That's a content problem, though. Unedited OCR isn't going to end up with MathML markup no matter what the reader supports.) Deborah

Regarding Paul's point about stakeholder-issued public statement in support of MathML: - BISG's Accessible Publishing Working Group is addressing the use of MathML as a "top tip" in the Quick Start Guide to Accessibility (currently in progress); we may also include MathML as a discussion topic at an Accessibility Summit in the spring- more on that will be finalized near the beginning of 2016. - George Kerscher's Baseline Requirements document will serve as a useful tool for gaining industry consensus in support of accessibility best practices, including MathML. I believe George and others at DAISY are currently planning for where this document and initiative will live. Thanks, Julie On Fri, Aug 21, 2015 at 10:52 AM, Ivan Herman <ivan@w3.org> wrote: > I think that, from an accessibility point of view, content MathML would be > preferable indeed. However, at this point, I think that the publishers > would be thrilled to have at least presentation MathML in the browsers:-) > > Ivan > > > > > On 21 Aug 2015, at 16:48 , Olaf Drümmer <olaf@druemmer.com> wrote: > > > > Just to be clear: are we talking about just presentation MathML or also > (or even preferably) content MathML? > > > > Olaf > > > > On 21 Aug 2015, at 16:24, "Belfanti, Paul" <paul.belfanti@pearson.com> > wrote: > > > >> I think one important step would be for a broad range of stakeholders > to issue joint public statements in support of MathML and EDUPUB and signal > their intent to publish content in these standards at volume. This will > create both business certainty and opportunity for those who can properly > play/display this content and create competitive dynamic to support rich, > accessible content. > >> > >> Paul > >> -- > >> Paul Belfanti > >> Director, Content Architecture > >> Core Platforms & Enterprise Architecture > >> office: +1 201-236-7746 > >> mobile: +1 201-783-4884 > >> > >> > >> On Fri, Aug 21, 2015 at 9:46 AM, Deborah Kaplan < > dkaplan@safaribooksonline.com> wrote: > >> On Fri, 21 Aug 2015, Ivan Herman wrote: > >> > >> Yes, if we can actively lobby, with the weight of the publishing market > behind us, to have browser vendors implement a particular feature, that > would be a win. For everybody. And that should indeed be the topic of our > discussions, too. > >> > >> (see changed subject line) > >> > >> I am hijacking this thread because of this comment by Ivan. This is > great to hear that you feel this way, Ivan. And in that case, given that it > is a truth universally acknowledged in this IG that native browser and > reading system support for MathML would be a big win for the publishing > sector, how would we go about designing and presenting that case, and then > going on to actively lobby for the vendors to implement it? > >> > >> Deborah > >> > >> > > > > > ---- > Ivan Herman, W3C > Digital Publishing Activity Lead > Home: http://www.w3.org/People/Ivan/ > mobile: +31-641044153 > ORCID ID: http://orcid.org/0000-0003-0782-2704 > > > > > -- *Julie Morris* Project Manager: Standards & Best Practices Book Industry Study Group | BISG.org <http://www.bisg.org/> Tel: 646-336-7141 Ext 14 Email: julie@bisg.org

Meeting minutes are here: http://www.w3.org/2015/08/24-dpub-minutes.html Text version are below for your convenience Ivan ---- Ivan Herman, W3C Digital Publishing Activity Lead Home: http://www.w3.org/People/Ivan/ mobile: +31-641044153 ORCID ID: http://orcid.org/0000-0003-0782-2704 [1]W3C [1] http://www.w3.org/ Digital Publishing Interest Group Teleconference 24 Aug 2015 [2]Agenda [2] https://lists.w3.org/Archives/Public/public-digipub-ig/2015Aug/0077.html See also: [3]IRC log [3] http://www.w3.org/2015/08/24-dpub-irc Attendees Present Markus Gylling, Tzviya Siegman, Ivan Herman, Julie Morris, Brady Duga, Leonard Rosenthol, Karen Myers, Deborah Kaplan, Nick Ruffilo, Peter Krautzberger, Heather Flanagan, Tim Cole, Bill Kasdorf, Charles LaPierre, Ben De Meester, Paul Belfanti Regrets Chair Tzviya Scribe TimCole Contents * [4]Topics 1. [5]Minutes 2. [6]Update on Accessibility 3. [7]Document about publishing requirements for packaging 4. [8]TPAC Preparation * [9]Summary of Action Items __________________________________________________________ <trackbot> Date: 24 August 2015 <tzviya> agenda: [10]https://lists.w3.org/Archives/Public/public-digipub-ig/2015 Aug/0121.html [10] https://lists.w3.org/Archives/Public/public-digipub-ig/2015Aug/0121.html <ivan> scribenick: TimCole <ivan> Chair: Tzviya <tzviya> [11]http://www.w3.org/2015/08/17-dpub-minutes.html [11] http://www.w3.org/2015/08/17-dpub-minutes.html Minutes <HeatherF> ship 'em! Minutes Approved. Update on Accessibility <clapierre> [12]http://w3c.github.io/dpub-accessibility/ [12] http://w3c.github.io/dpub-accessibility/ clapierre: progress on note ongoing, but a little slow ... a number of topics to fill in ... image descriptions task is taking some time (working with P&F / ARIA) ... need to get this into a spec that can be used ... looking at alternatives that may be better fit ... a lot of discussion on MathML lately ... this also has taken some focus away from producing the Note ... will be looking for reviews from this group. deborah: we sometimes think about digital publishing as a special case of Web publishing, but really DPub has some different needs when it comes to Accessibility ... really appreciate input from this group. lrosenth: good information in the draft note, but some of these issues have been addressed in an ISO std. (which one?) ... conceptually some of these items in PDF UA may be helpful deborah: we want to encourage 2 way communications with other groups <lrosenth> will do! clapierre: please add edits or issues to the current draft on github <tzviya> [13]http://www.w3.org/2015/08/extended-description-analysis [13] http://www.w3.org/2015/08/extended-description-analysis <clapierre> wil do tzviya: adding an additional link to P&F grid about DPub requirements; they've asked for a punch list of comments from DPub ... our requirements are already well reflected in this draft from P&F <HeatherF> Even positive comments are worthwhile tzviya: conversations about some our requests, e.g., details deborah: (in response to a question) the sub-group is on top of getting the note done, though help is always welcome. Document about publishing requirements for packaging <tzviya> [14]https://www.w3.org/dpub/IG/wiki/Requirements_for_Web_Public ation_and_Packaging [14] https://www.w3.org/dpub/IG/wiki/Requirements_for_Web_Publication_and_Packaging <lrosenth> +1 to move it forward <tzviya> +1 tzviya: there has been a lot of talking about the document, but we seem to have approached consensus as of end of last week <ivan> +1 <pkra> +1 <mgylling> +1 <HeatherF> +1 <NickRuffilo> +1 <clapierre> +1 tzviya: are we ready to push this forward (+1_ <bjdmeest> +1 <Karen> +1 <Julie_Morris> +1 <Bill_Kasdorf> +1 <pbelfanti> +1 ivan: before sending to public list, we may worth contacting Yves to see if this is the form of comments they want to receive ... we did this partly for ourselves, but also this will be of interest to Eve and others working on packaging standard ... so we should check with them to make sure format is of use. ... alternatively we could distill out something more specific to their needs ivan: tzviya or markus will send a note to see. tzviya: assuming we send this forward to Yves, do we leave it as a Wiki page or publish more formally? ivan: Don't know what they will prefer. For us Wiki page is okay, but they may want something more formal. ... we need to check to see if Yves is on vacation ... should be back by end of the week. TPAC preparation <tzviya> [15]https://www.w3.org/dpub/IG/wiki/Oct_2015_F2F_Logistics_and_ Details [15] https://www.w3.org/dpub/IG/wiki/Oct_2015_F2F_Logistics_and_Details tzviya: There are people in this group who have registered for TPAC, but have not registered for DPub session? Are they going to attend DPub and what would they want to talk about? ivan: in response to question, there will be WebEx for those who want to participate remotely. <tzviya> [16]https://www.w3.org/dpub/IG/wiki/Oct_2015_F2F_Logistics_and_ Details [16] https://www.w3.org/dpub/IG/wiki/Oct_2015_F2F_Logistics_and_Details ivan: there is a topic that came up on the mailing list - we may want to have a discussion of glossary of the terms we (DPub) uses ... this might be a good thing to have by no later than TPAC ... it's good to have a clear idea for ourselves and others about what we mean, especially in contrast to some of these terms as used on the Web ... will facilitate future work <HeatherF> +1 tzviya: a great idea ... case in point - the word 'semantics' ... let's start a wiki page now ivan: will do start this wiki page clapierre: just got confirmation that I will be going to TPAC ... would want to schedule some time to talk about Accessibility - do we need to coordinate with P&F and/or CSS ... have we heard about DPub charter renewal ivan: we had a good number of positive votes, vote being reviewed, should here in a week or two HeatherF: Any advice for first-time TPAC attendees? pbelfanti: has a request in to attend TPAC ... would like to talk about topics raised by Daniel Glazman tzviya: not everyone is aware of these topics? ... will review on a call before TPAC ... the logistics page provides an opportunity to suggest topics / task force discussions for TPAC <pkra> do we want to talk about that MathML thread? <pkra> ... <Bill_Kasdorf> +1 to looking at Liam's e-mail tzviya: if we do want to move forward with being a bit more activist, the MathML discussion suggested some possible ways forward. <HeatherF> thanks tzviya: adjourn early. <ivan> trackbot, end telcon Summary of Action Items [End of minutes] __________________________________________________________ Minutes formatted by David Booth's [17]scribe.perl version 1.140 ([18]CVS log) $Date: 2015/08/27 19:31:41 $ [17] http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/scribedoc.htm [18] http://dev.w3.org/cvsweb/2002/scribe/

From: Paul Topping <pault@dessci.com> > I should also add that full MathML support in browsers would not eliminate MathJax from many websites I want to stress that the push for native MathML is not out of any desire to get rid of MathJax. It is out of the need for publishers to be able to distribute native math that can be read by screen readers without users having to do anything special. And once again, I think at the moment, digital publishing's greater concern is not browsers (where at least MathJax is an option, and theoretically a work with MathML could contain links on how to install MathJax where necessary). Rather, the greater concern is non-browser-based reading systems, frequently used for textbooks, which have legal requirements for accessibility. I worry less about convincing the big brother manufactures that it's in their best interest to do native MathML. I worry more about convincing the textbook reading systems, where MathJax is often not an option. So often it takes an actual lawsuit before things change. I would like us to prove Bill correct; that this can be done by showing numbers to the people who make decisions based purely on numbers. It would be great if there didn't have to be an actual lawsuit first. Deborah

> Begin forwarded message: > > From: Julie Noblitt <julien@benetech.org> > Subject: [Moderator Action] Re: Active lobbying: Math > Date: 24 Aug 2015 14:10:21 CEST > To: Charles LaPierre <charlesl@benetech.org>, Bill Kasdorf <bkasdorf@apexcovantage.com> > Cc: "Belfanti, Paul" <paul.belfanti@pearson.com>, Deborah Kaplan <dkaplan@safaribooksonline.com>, Ivan Herman <ivan@w3.org>, "W3C Digital Publishing IG" <public-digipub-ig@w3.org>, Anh Bui <anhb@benetech.org> > X-W3C-Hub-Spam-Status: No, score=-8.9 > > Bill, so well said -- love that tagline! It has to make economic sense, and we have evidence that it can. We have been working with O'Reilly Media on their implementation of MathML Cloud, and their director of publishing technology told us that their Illustration team cleans up all author-supplied artwork during book production, with math equation image production being an extension of that work. After they integrated MathML Cloud into their workflow, that image generation was automated (along with generation of associated descriptions and MathML) -- it has resulted in a savings of 5-10 hours of work per book for math-heavy titles. > > --Julie > > ******** > Julie Noblitt > Community Manager, The DIAGRAM Center > Mon-Th: 650-352-1092 > http://diagramcenter.org/ <http://diagramcenter.org/> > Follow us on Twitter: @DIAGRAMC > > > From: Charles LaPierre > Sent: Friday, August 21, 2015 9:17 AM > To: Bill Kasdorf > Cc: Belfanti, Paul; Deborah Kaplan; Ivan Herman; W3C Digital Publishing IG; Anh Bui; Julie Noblitt > Subject: Re: Active lobbying: Math > > Well said Bill!! > > _______________________________ > > Charles LaPierre > charlesl@benetech.org <mailto:charlesl@benetech.org> > > > > >> On Aug 21, 2015, at 8:51 AM, Bill Kasdorf <bkasdorf@apexcovantage.com <mailto:bkasdorf@apexcovantage.com>> wrote: >> >> +1 >> >> Picking up on both Paul's comment—"signal their intent to publish content in these standards _at volume_"—and Ivan's—"after all we are all geeks and not suits"—clearly we need a SUITS FOR MATHML movement!!! ;-) >> >> Seriously, though. . . . It is so easy for the suits to say "yeah, of course the geeks want this, the geeks want everything. I've got a business to run." >> >> Suits need numbers. Preferably preceded by glyphs like $, €, £, ¥, etc. >> >> I'm not saying that will be easy to come up with. But here's an anecdote from my personal experience: >> >> --I have always been an advocate of MathML. But I'm an idealist and standards maven. >> >> --Ditto for accessibility. >> >> --Even so, when I was asked to lead the AAP EPUB 3 Implementation work a year or two ago, I have to admit I was surprised and puzzled to see MathML keep rising to the top of the priorities. "Really?" I thought. "How many publishers even publish math?" [Note that my reaction was more suit-like than geek-like. So now you know that the reason you more often see me in a suit than a t-shirt. In fact I can pretty much guarantee you've never seen me in a t-shirt.] >> >> --So in my work with that AAP initiative, I was talking to a key guy at the American Printing House for the Blind, who put some numbers, with one of those glyphs in front of them, in front of me. "Bill, when a student in a class needs a math book, it can take six months and $50,000 to get that book accessible for her. [A legal obligation, btw.] By which time the class is over. If the math in that book had been MathML it would have cost a small fraction of that and we could have gotten the book to her quickly. There are hundreds of books like that." >> >> --"Shit!!!" I thought. "Now I get it!" >> >> Of course now we are off in an even more remote corner of the world, from the suit's point of view: a book _with math_ for a tiny percent of the potential readers of that book. And the suits that are exposed to the legal liability are not the Publisher Suits, they're the University Suits. >> >> That's the challenge we have. I am not trying to be Debby Downer here; I'd like to be just the opposite. >> >> But for SUITS FOR MATHML to succeed, we need a way to say "this makes business sense, it's costing money and creating a dangerous legal liability to not have this problem solved, and I am going to [in Paul's words] make MathML available in volume [in the case of Publisher Suits; or] I am going to make a commitment of staff and resources to help solve this problem [in the case of University Suits] if I can see that this problem is being adequately addressed by the industry." >> >> We need to move beyond shame and conscience, unfortunately. That hasn't worked. So again, to +1 Paul and Ivan, we need to get commitments, and we need to get those commitments from the suits. >> >> --Bill Kasdorf >> >> >> From: Belfanti, Paul [mailto:paul.belfanti@pearson.com <mailto:paul.belfanti@pearson.com>] >> Sent: Friday, August 21, 2015 10:25 AM >> To: Deborah Kaplan >> Cc: Ivan Herman; W3C Digital Publishing IG >> Subject: Re: Active lobbying: Math >> >> I think one important step would be for a broad range of stakeholders to issue joint public statements in support of MathML and EDUPUB and signal their intent to publish content in these standards at volume. This will create both business certainty and opportunity for those who can properly play/display this content and create competitive dynamic to support rich, accessible content. >> >> Paul >> -- >> Paul Belfanti >> Director, Content Architecture >> Core Platforms & Enterprise Architecture >> office: +1 201-236-7746 >> mobile: +1 201-783-4884 >> >> >> On Fri, Aug 21, 2015 at 9:46 AM, Deborah Kaplan <dkaplan@safaribooksonline.com <mailto:dkaplan@safaribooksonline.com>> wrote: >> On Fri, 21 Aug 2015, Ivan Herman wrote: >> >> Yes, if we can actively lobby, with the weight of the publishing market behind us, to have browser vendors implement a particular feature, that would be a win. For everybody. And that should indeed be the topic of our discussions, too. >> >> (see changed subject line) >> >> I am hijacking this thread because of this comment by Ivan. This is great to hear that you feel this way, Ivan. And in that case, given that it is a truth universally acknowledged in this IG that native browser and reading system support for MathML would be a big win for the publishing sector, how would we go about designing and presenting that case, and then going on to actively lobby for the vendors to implement it? >> >> Deborah >> ---- Ivan Herman, W3C Digital Publishing Activity Lead Home: http://www.w3.org/People/Ivan/ mobile: +31-641044153 ORCID ID: http://orcid.org/0000-0003-0782-2704

--- Ivan Herman Tel:+31 641044153 http://www.ivan-herman.net (Written on mobile, sorry for brevity and misspellings...) Begin forwarded message: > From: Paul Topping <pault@dessci.com> > Date: 22 August 2015 20:03:45 CEST > To: Ivan Herman <ivan@w3.org> > Cc: W3C Digital Publishing IG <public-digipub-ig@w3.org> > Subject: [Moderator Action] RE: [Moderator Action] Active lobbying: Math > > I should also add that full MathML support in browsers would not eliminate MathJax from many websites because they rely on its ability to process LaTeX, though perhaps MathJax and other software could be used to do LaTeX-to-MathML conversion off-line leaving browsers to work with pure HTML5+MathML. Even then, MathJax provides additional functionality such as zoom and the ability to copy MathML to the clipboard, things that browser may not implement consistently or at all. > > Paul > >> -----Original Message----- >> From: Ivan Herman [mailto:ivan@w3.org] >> Sent: Saturday, August 22, 2015 12:15 AM >> To: Paul Topping >> Cc: W3C Digital Publishing IG >> Subject: Re: [Moderator Action] Active lobbying: Math >> >> >>> On 21 Aug 2015, at 20:13 , Paul Topping <pault@dessci.com> wrote: >>> >>> This is a topic I've thought a lot about so I will throw my two cents >> in. >>> >>> Whenever I've talked to browser folks about supporting MathML, which >> is not often, the consistent answer I get back is that they perceive >> very little call for it. My first reaction is to wonder who they ask or >> who they listen to. It seems unlikely that browser makers listen to >> end-users. In general, they do not request support for web standards. I >> suspect who they are listening to are web developers. There are a huge >> number of people involved in making websites and a large, but smaller, >> group involved in developing web standards and advocating for them. >>> >>> A good example of this is Microsoft's page where people get to vote >> for features they'd like to see in Internet Explorer and now Edge. I >> used all my votes for MathML but I am sure it didn't get many votes >> compared to other features. >>> >>> So, the problem as I see it is that very few web developers are >> asking for MathML support. Before MathJax, they all just used equation >> images. After MathJax, the problem is largely solved, at least from >> their perspective. Perhaps more importantly, the number of web >> developers who deal with math in their pages is a miniscule fraction. >>> >>> So who do we have to rally to get MathML implemented? I don't think >> talking to web developers will work. Instead, I would say we have to >> rally education. This is where the need for accessibility is strongest. >> Also, no software company wants to be seen as not supporting education >> and accessibility. The problem with this is that educators do not know >> about MathML for the most part. We would have to convince them to trust >> us on the technology question. On the other hand, there are some >> influential (I'm guessing) organizations that know about MathML: >> Educational Testing Service (ETS), to name one. >>> >>> If browser makers actually listened to us and implemented MathML >> natively in browsers, we might experience a new problem. There will >> undoubtedly be differences in the quality of their implementation. Even >> if quality isn't a problem, separate implementations will undoubtedly >> make different rendering choices. The MathML spec allows this. MathJax, >> on the other hand, provides consistent cross-browser MathML rendering. >> We must be careful what we wish for. >> >> That is, actually, an interesting issue. Speaking as a (former) >> mathematician, I know that mathematicians may be extremely picky on the >> way their equation look. Ie, I do not know how much variation they >> would tolerate and, for that matter, how precise the presentation >> markup of MathML defines the outlook (SVG is very precise, almost at >> pixel level, for example). >> >> Ivan >> >>> >>> Paul Topping >>> Design Science, Inc. >>> www.dessci.com >> >> >> ---- >> Ivan Herman, W3C >> Digital Publishing Activity Lead >> Home: http://www.w3.org/People/Ivan/ >> mobile: +31-641044153 >> ORCID ID: http://orcid.org/0000-0003-0782-2704 > >

Planet MathML features:

- Ask.com News Search for "mathml"
- Blog de Frédéric - Tag - mathml
- David Carlisle
- Design Science News
- FMath
- MathJax
- Murray Sargent: Math in Office
- Planetary Developer Forum: {9} Planetary News
- SF.net - ASCIIMathML
- SF.net - DocBook to LaTeX Publishing
- SF.net - MathCast Equation Editor
- SF.net - MathStudio
- SF.net - Open Math Edit
- SF.net - PyMathML
- SF.net - SVGMath
- SF.net - UniWakka
- SF.net - jsMath
- SF.net - jscl-meditor
- SF.net - pMML2SVG
- W3C Blog
- W3C Math Working Group
- W3C News
- Web Platform Blog
- mathml - Google Blog Search
- public-digipub-ig@w3.org Mail Archives
- public-html-a11y@w3.org Mail Archives
- public-html@w3.org Mail Archives
- public-webapps@w3.org Mail Archives
- www-math@w3.org Mail Archives
- www-style@w3.org Mail Archives

If you own a blog with a focus on MathML, and want to be added or removed from this aggregator, please get in touch with Bert Bos at bert@w3.org.