[math-on-web] CG meeting minutes, 2018/02/15

Hi everyone,

The minutes are below.

The next meeting will be on March 1.  We should try to wrap-up the
conversation from the last meeting, we'll get an update from the CSS TF,
and we should discuss how to move the other TFs forward.

Best,
Peter.


# MathOn web CG meeting 2018/02/15

Present: Dani, Arno, Neil, Ivan, Krista, Peter

* Peter: re Ivan emails
  * people are sticking to MathML.  but browser never supported it.
    * Why would it be a loss now?
  * Ivan: not MathML per se but there's a problem
    * if we deprecate MathML, then what's the plan for fixing the problem
    * not even hard stuff. Just K-12 equations
  * Dani: I think today's HTML is very powerful. But we need to tell people
how to do it.
    * you can do things in HTML
    * I hope if we explain how to do this, then it will improve
  * Ivan: I could see that with HTML+CSS, HTML+SVG
    * but as somebody writing a page, I need to have a way to write the
content
      * you can't expect me to learn how to build complicated HTML+CSS to
get an integral
  * Arno: why wouldn't be a solution like mathlive, mathjax etc be
acceptable?
  * Ivan: I see two problem
    * MathJax is pretty slow today
    * adding a reference to a polyfill or whatever is ok as intermediary
      * but long term there should be a better way
    * again: SVG as example.
      * way back when, I needed to add the Adobe player to my page
    * I don't understand why browsers don't do it; it's all just hearsay
    * complex tools like matlab are sledgehammer
      * I want this to be as easy as writing HTML
      * Arno: but even slow is faster than not having it
    * Ivan: but I've seen eg. Analysis books and it is slow
      * so publishers go back to
* Arno: I think everyone understands the frustration that MathML is not
supported by browsers
  * but the problem of convincing browser vendors has not changed;
  * I doubt that they will suddenly see the light
  * on the other hand, convincing browser to improve HTML, CSS etc
    * and if those help rendering of equations
    * and smaller in scope
  * then we have a model of extending
  * and make renderers faster
* Ivan: I'd agree but would add something
  * I'd like to see some kind of analysis of why browsers rejected MathML
  * it's not enough to claim reasons
  * carving out a piece of useful MathML might be useful
  * but this requires understanding why browser rejected it
* Neil: I want to second what Arno said
  * e.g., MathJax v3 is much faster than v2
  * it would be nice if browsers considered a priority
  * it's not that the spec is wrong or blocking it, it's just not a priority
  * I don't think it's a particular issue with MathML
  * there are certainly things that are complicated and could be simplified
  * but I don't think the spec is the problem as such
* Ivan: but it remains a chicken-and-egg problem
  * e.g. publishers have given up
  * it's nice if the speed problem goes away
  * but do we require JS for equation rendering?
* Neil: it may be in the near future that CSS improves enough for
implementations to become trivial
* Dani: the complaints about MathJax could be summarized as "it needs JS"
  * if we avoid JS, then we have HTML, CSS, embedding fonts etc
  * that's enough to do anything
* Ivan: but who does it?
  * Dani: somebody has to do it; any tool
    * e.g. summation. It used to be hard; now we need one more child. Not
easy, but not bad either
    * that way we get to the point where it's possible but CSS needs to
help us improve it
* Ivan: that sounds fine if we can achieve it
  * but coming to Peter's comment to remove MathML from HTML
  * but if this works out, then what's the problem about MathML staying
inside?
  * Arno: e.g. Google said it's a complex implementation, security concerns
etc That makes it a drag. They were open to polyfilling
    * Neil: Google said publicly that they think MathJax is enough
  * Ivan: so if MathML became a web components thing, then it solves
* Arno: you're right that it's not very diferent from the author point of
view.
  * but from UA implementor, it's a whole sleuth of complexity they don't
have to do it
  * Ivan: I understand that and if that's reasonable to achieve, then that
works
  * Arno: and if you want to use TeX then use a library
* Ivan: if there's a plan to execute, then there's parallel tracks to work
through
  * CSS tricks and analyze how to improve them
  * CSS seems reasonable, HTML seems hard.
  * still, an analysis of MathML today and trying to extract something
that's easier to implement (don't know if that's possible)
    * but carving out that subset
* Arno: there's Fred Wang's note
  * it highlights what's hard to do, the things that don't fit the CSS, box
model etc
  * Ivan: that's interesting
* Ivan: another important question: is Content MathML used at all? is that
worth keeping that around?
  * Neil: some research groups and an assessment tool at Pearson
  * Ivan: so it sounds if MathML is ever re-opened, then that should
probably go
  * Dani: I would not drop it. As a separate spec, it's ok.
* Peter: I disagree with most of what has been said so far
  * MathML has fundamental problems that make it unfit for today's web
  * the platform is getting better by itself making equation rendering
tools easier to build (cf the increase of libraries)
  * speeding up that process is useful; everything
  * JS on the client is not necessary. Performance is not a problem.
* Ivan: I don't think deprecating will get us anywhere
  * publishers are suffering
  * Peter: but that's largely their own fault for not investing beyond
MathML
* Neil: @peter: do you think MathML is not serving them?
  * Peter: not as well as most people (including publishers) think.
* Ivan: but publisher are not technology developers
  * they can't build their tools
  * maybe MathML is pushing them in the "wait for browsers" direction
* Peter: I didn't mean that they develop something but that they need to
just look for the existing tools
  * Ivan: that sounds a bit unfair on them
* Dani: but something is progressing
* Neil: but what's holding browser back
* Arno: equation layout is difficult
  * bottom up equation layout -- CSS is top-down
  * MathML is one monolithic thing
    * with some interfaces that are not very natural
    * that creates complexity
  * since implementations are from external volunteers, probably nobody at
the browser vendors fully understand the situation
    * this leads to bugs and potential security issues
    * browsers don't want to have that kind of issue in their code base
* Ivan: Arno's comments sound reasonable
  * so maybe a simpler syntax
  * then web componets might be a feasible solution
* Peter: @IVan have you looked at the samples that have gone around the
list?
  * the latest ideas are not significantly worse than MathML
  * And MathML was never designed to be hand-written except by experts so
your criticism does not match
* Arno: MathML mixes a notation and layout model
  * if we drop it, we can separate
  * Peter: cf. table model, mstyle
* Ivan: but that was not my point about web-components
  * Peter: what would that syntax represent?
  * e.g., TeX and ascii mix both
* Arno: Fred's document is interesting on those clashes
* Ivan: if we remove it, then we can disregard that
* Dani: we shouldn't tell publishers not to use MathML in their workflow
  * but e.g. an epub there shouldn't be MathML there
  * finally there are issues about accessibility to be solved
* Arno: I think we're closer to understanding each other's position and the
directions
* Ivan: some kind of plan from this CG would be a very important thing