[math-on-web] CSS TF meeting minutes, 2018/05/07

Hi everyone,

Here are the minutes from the CSS task force meeting on May 7.

Best,
Peter.

# MathOnWeb CSS TF 2018-05-07

* Present: Peter, Arno
  * regrets: Dani.
* Arno: that SO example is interesting
  * much like CSS art (eg that portrait going around recently)
  * the question I've been wondering about: where do we draw the line
  * Peter: yeah, I've arguably become more and more radical on this
    * e.g., MathML templating vs HTML templating. Why not use a CSS-based
component?
    * "do you want to use the traditional approach"  always seems to come
down to "OpenType MATH tables or not"? (Which is a problematic technology)
* Arno: I mean something a bit different
  * e.g., where does CSS WG draw the line?
  * where do we draw the line?
  * do we just consider "you can do it" or "you can do it
well/convenient/nicely"?
    * what popular solution works, let's make it better.
* Peter: maybe we should ask CSS WG?
  * I fear their response will always be "just use houdini" (e.g., brace)
* Arno: Houdini is one route
  * but e.g. fences are popular enough, they appear often enough to count
beyond equation layout
  * ie. might fall above the line
  * there's a question of accessibility
    * e.g., a textbook publisher. can we expect them to write or re-use a
Houdini component?
* Peter: I think sooner or later it will be easy enough to write such
components
  * Arno: fair point. Fences, surds etc could become easy enough
* Arno: imagine there was border-glyph (top/left/bottom/right), maybe even
pieces
  * then browser vendors could decide how to implement that
    * e.g., opentype fonts, fallbacks
  * that would make it easier for authoring while not being too strenuous
* Peter: right. as we have more examples, when/how do we find out which
direction we can approach the CSSWG about
  * without implementor buy-in it's hard
* Arno: exactly my starting point
  * [Peter: sorry it took me so long...]
  * so far nothing proved impossible
  * but ease of authoring is
* Peter: I'm thinking the CSS WG might turn around and ask us which tools
are using our approach
  * so convincing these would be next
  * and is hard
* Arno: we could focus on bleeding edge
  * Peter: if we could get people together and primarily work on bleeding
edge, then that would help tooling as well
    * and solutions can convince CSS because our solutions inform their
solution
[off topic discussion about web components]
* Arno: when more people start to look for integrating content, then there
might be more incentive for a broader solution
* Peter: about that nice root trick
  * I like it
  * reminds me of a recent example I built for madruwb
    * hacky Lam drawing but better than what most tools will render
    * fun fact: there's no MATH Tables for this AFAICT
  * Arno: there's actually arabic stretchy unicode
https://unicode.org/charts/PDF/U1EE00.pdf
    * but not for lam?
    * Peter: Odd.
* Peter: I don't care about semantics much at this point
  * there's also the feature parity discussion in ARIA land, especially
from components pov
  * we should push for semantics for things we can't express
* recap
  * Arno: figure out where to we want to draw the line
  * Peter: maybe RfCs to the tool maker will help us here
    * ACTION: collecting and organizing the samples we have
  * Arno: we want to avoid the "1 way to do it, so CSS doesn't need to add
anything"
* Peter: just equation layout will never be enough of a use case for
standards
  * Arno: yes. We need more use cases and they exist
  * e.g., TeX authoring by hand is interesting. Making that easier might
find support withB the CSS WG.