Digital Publishing Interest Group Teleconference

<trackbot> Date: 14 September 2015

<inserted> scribenick: Karen

<scribe> Scribe: Karen

Ivan; We have a lot of regrets today, likely related to today being the Jewish New Year

scribe: Let's have first agenda item

<ivan> http://www.w3.org/2015/08/31-dpub-minutes.html

<NickRuffilo> I'm calling in shortly

scribe: minutes from last time

<NickRuffilo> then i can scribe if necessary

scribe: any problems accepting?
... Let's record that minutes are accepted

MathML

Ivan: Let's go next to topic of the day
... MathML
... the reason why we thought it would be worthwhile to have this discussion item
... because there has been a lot of discussion within MathML on where and how to go
... and consider some radical changes
... so Peter is going to explain this to us
... Peter, please take the floor

Speaker: Peter

Peter: one of reasons to have this on the agenda, is the discussion on the DigPub mailing list
... what came together at last MathML WG meeting is the rechartering of the MathML WG
... it is up for rechartering next year
... the group has been primarily in maintenance mode and has not created new specs
... it seems that W3C does not want to have WGs just do maintenance work
... so big discussion just kicked off on last call is what the future of the Math WG would be like
... if just maintenance, then it would be turned into a Community Group
... seems to be the new status for maintenance focused groups
... if that does not happen, then the Math WG needs some other kind of work item
... This had not yet led to a lot of discussion on Math WG side, but it has coincided with discussions on Digital Publishing group
... and the general direction for MathML
... and my general background working for MathJax, library that renders MathML on web browsers
... we are working on white paper about potential major revisions
... And our long-term goals
... One goal is to further mathematics on the web
... and have people publish MathML in browsers
... native MathML support in browsers has been a long-term goal
... so thinking about this problem, we have come to realization that we have not been successful in that
... we don't see how we can successfully trigger native browser development for MathML
... so thinking about how mathematics can be realized on the web if native support is not realistic goal
... One of things I brought up
... see if feasible to focus on work of DigPub and ARIA

<Ralph> Can I use MathML? report

Peter: possibly work on the ARIA side of things
... ARIA spec has a glaring hole when it comes to mathematics
... Seems to be some interest from ARIA folks
... Other side connects to Houdini work and would revolve around the problem of mathematical layout in browser engines
... to spec out the math layouts that are challenging in CSS
... this was discussed at last Math WG meeting
... There was not that much interest from Math WG itself
... but there is interest by myself personally and from MathJax
... we don't see how we can get MathML implemented
... Let me stop here and open the queue
... Does that make sense? Did I miss anything, Ivan?

Ivan: Maybe one more fact to add
... is of course a Working Group at W3C produces recommendations
... under the new charter this group has the possibility to do proof of concept technical work
... we have more possibilities to do things
... so some of work and possible directions could very well be done in this group and published by this group
... so we could help to move things forward; it's an extra liberty

Tim: So Peter, one of the other
... issues that comes up in discussions about MathML
... and wonder about its impact of support
... It is in competition in some circles with LaTeX
... is there a problem that the community is a little divided about what needs to be decided
... regarding use of mathematics on the web?

Peter: I would say that is not a real debate
... certainly the case that LaTeX and other input forms are still prevalent and successful
... it's rather verbose so you don't author by hand
... simple syntax
... WISIWG has not succeeded
... Math WG has overlap with largest group in form of David Carlisle
... there is no competition because LaTeX tools can understand and render MathML
... lots of tools do this
... more like saying mark-down and HTML are in competition; not a big issue
... there is one exception
... @ academies @
... precursor
... focused on LaTeX as a rendering model for the web
... in our view, since MathJax went another way, not a good strategy

<Ralph> KaTeX

Bill: ... just reinforcing Peter's point that MathML overwhelmingly preferred by publishing

Peter: deep down there are some deep technical discussions but don't want to get into those

Ralph: Thank you, Peter
... I work closely with Ivan; he encouraged me to attend this call today
... I am with you on frustrations for native browser support
... I'll paste the "can I use folk"

<Ralph> CanIUse MathML

Ralph: show that at least some browsers
... 2.5 who do support MathML natively
... there is some sense in the browser world that polyfills are not a bad way to go
... especially with a domain specific markup language
... and doing as a polyfill initially and building a corpus of published stuff on web is the way to encourage browsers to provide embedded support and not rely on polyfill
... can you say more about what is making MathJax less of a direction that publishers want to go
... Bill is saying MathML is preferred format for publishers
... and MathJax works; so what is impeding its use?

Peter: The first thing about the browser support; 'can I use this' is misleading
... the implementations are partial
... biggest problem is that WebKit is not anywhere near production ready
... Gecko is much better
... biggest issue with browser support is that browser vendors are not doing it

<AH_Miller> The fact that Antenna House supports MathML with our XSL-FO engine sells a lot of licenses for us.

Peter: code is almost exclusively written by volunteers
... WebKit went through several volunteers and failed to gain interest
... Apple invested in voice-over
... Google, Chrome speaks but does not render it
... With Gecko it is different
... clear that they don't currently have their own developers working on the code
... Mozilla will invest time to fix issues they create
... but they don't actively implement which is a huge issue
... have been some spurts along the way
... if we wait around, it would take five years to get to production levels
... Why is MathJax not good enough?
... We are mission driven, we want to see native driven
... and math is fundamental to communications; MathML fills that language gap
... still lots to do in MathML3
... practically speaking it's performance
... MathML is a very complex spec and math layout itself is complex
... expects a high level of typography that web does not yet have
... polyfill does not cut it yet
... in next release of MathJax we have a new output component that does not require rendering on the client
... pragmatic reasons where you don't have Java scrip under your control

<Ralph> [thanks for this data, Peter; it will be useful as we continue push on browser developers]

Peter: or suffer from network congestion on mobile devices
... not depending on JS is crucial

<clapierre> https://mathml-cloud.cloudapp.net

Charles: I wanted to touch on a couple things about what we are doing at Benetech
... MathML cloud to take either LaTeX or MathML to give an accessibility description
... we have some publishers using this in their pipeline
... using as alt text
... or description document
... Benetech is also working on a matrix
... a database, volunteer driven, as to what browsers, AT tech, MathJax
... depending on OS, to fill that out
... currently in alpha we are working on that
... and working with Readium folks who are working on MathML support in their products
... We are fully behind this and want to see it succeed
... success of MathML is key

Peter: point out that Readium includes MathJax
... problem is that reading system developers don't integrate it into their reader
... as Apple OS claims they have support but they don't...
... why include a tool like MathJax
... uses math on server

Paul: I had a question about the previous statements on using polyfills as a viable option from an accessibility POV

<inserted> [Peter notes that MathJax is not a polyfill in the modern sense]

Peter: older than that
... MathJax is not built in way to leverage partial implementations
... looking to future you could look at web components; shadow DOM
... we are disregarding
... simply because it does not buy us anything; does not solve the rendering issues
... Houdini has hope of simplifying the rendering
... and doing the main job
... that is something you can do
... but at same time
... you have actually a mark-up that should be possible to make HTML and SVG accessible on a level for MathML; that's what ARIA
... does
... would be prudent to have a tool set
... whatever direction math on web takes, it should supercede MathML

ivan: I see that Karen is leaving
... do you have to run now?

pkra: I can do one more

ivan: I was on the queue
... let's say you have a free hand in the sense of trying to modify MathML to work better with current environment
... and you had a free hand in MathJax
... what could be done to move the whole situation out of the current "dip"
... what actions would be useful?
... taking into account that the browsers don't care
... we can put possible answers on the agenda for a next meeting
... we have an idea of where we are, the question is where we can go
... this can be discussed at TPAC

pkra: I won't be at TPAC

ivan: thank you very much Peter!
... we did not plan for other agenda items
... are there any pressing items?

ivan: so let's get back to the topic next week, and we can gather questions
... meeting is adjourned. Thanks all!