Minutes: MathML Core Meeting of June 8, 2020

Attendees:

   -

   David Carisle
   -

   Neil Soiffer
   -

   Brian Kardell
   -

   Murray Sargent
   -

   Rob Buis
   -

   Bruce Miller
   -

   Louis Maher
   -

   Patrick Ion



Agenda:
https://github.com/mathml-refresh/mathml/issues/8#issuecomment-637641350

The meeting was recorded:
https://benetech.zoom.us/rec/share/3ct3ForeyUlLH7P_zF7Wfvc4IYjnaaa81HUY8vEEz0coOv2ZEXyJdB2XD76KVp_f
Password: 8L.4=9P&

Interpretation of new display: math/inline-math and compatibility with
block/inline ( #214 <https://github.com/mathml-refresh/mathml/issues/214>)

FW: These are mapped using UA rules.

BK: Will something break. Will people have set it in CSS and nothing
happened. Now it will do something. Can’t break things.

DC: there is no native cross browser compatibility for MathML, no spec, so
can’t really be breaking anything.

BK: we should at least see if it is being used

NS: how?

BK: I think that only through instrumentation in the browser itself because
you would need to run the style/cascade to know what it was applying to or
if it was relevant… We have a decent case that it doesn’t matter because
there was no interop.

DC current firefox behaviour:

FW: all children (such as fracs) are mapped to display:math. How should we
interpret it as display:in-math. Currently we just map to ‘math’.

BK: the only way to get metrics to add something to Firefox to collect
metrics, but no one will want to do it. I would propose that we just are
careful to express what should happen on all of these and make the case
that it doesn't matter lacking current interop

Resolved: we discussed and felt that this shouldn’t be a problem because
there is existing incompatibility now.

href

Implemented in WebKit/Gecko and we have a patch for Chromium. However,
there are many security questions as well as other issues related to
tabindex or shadow DOM. So we are likely not going to upstream the patch
for now.
=> Proposal: Put it "at risk"
=> Brian's notes: I think we need this, it seems to make sense to keep for
v1 even if it might take some time to achieve parity on this though and can
be 'mostly' polyfilled (like actually polyfilled I think) for practical
purposes. It definitely would appear to stand in the way of moving some
things in v2 forward to me, so just logically it feels like it belongs here.

From last meeting: BK needs to resolve the default tabindex issue with
Apple folks. The shadow DOM can’t have elements with href, so something to
keep in mind especially wrt mrow.

BK: Apple person is one leave. Need to see if someone else can explain it.

BK: BM and FW think mrow should allow shadow DOM on mrow.

DC: Saying that MathML can’t have linking is a big step backwards as MathML
should be part of the web.

BK: It’s not a matter of “never”. It’s what we do now. You could do a
polyfill with an onclick handler

NS: Generally accessibility is hard and you should use native semantics;
people mess up accessibility when done by hand

BK: <a> would solve this

NS: for consistency should we use <ma> or make use of <maction>

DC: <maction> is ugly because children are required for the link

BM: what elements can have a link

BK: can’t be all elements. Maybe the current solution is because we were
exhausted from this.

FW: maybe only maction should be only one to allow shadow DOM because it
was supposed to be extended.

FW: if we have a separate <ma>, …

BK: <ma> would be easier to get in

DC: so we would have to wrap <ma> around any element?

BK: yes.

BM: isn’t there a compatibility issue? Existing markup won’t work

NS: there would be a polyfill

DC: anything not in core has this problem

BM: this is a big change for what I generate

BK: the security concerns are real for the browser community, so it is a
bigger ask. Definitely can’t have shadow DOM on a linkable element.

PI: there are 23 link types. Do we need to support all the link types?

BK: it needs to be like other links

PI: so we need to read the WHATWG’s spec and be careful if we want to change

NS: the simple thing is to do the same as what the spec says

DC: I suspect that being told every other meeting that this is risky to ask
for, maybe we have to bow to what Igalia is willing to do/can get done.
It’s a breaking change, so it is real.

BK: options are we pursue nothing, we pursue what we said, or we can pursue
<ma>.

BM: is there a level 1 / 2 issue

BK: yes, we could do that. The more we do, the more we paint ourselves into
a corner.

BM: I’d be okay with it being only supported in Firefox

NS: but then everyone would use a polyfill

BM: I think people will choose to use the browser with better support

BK: <summary> is an example of supported in some browsers but not others;
data says everyone uses a polyfill.

Resolution: BK to bring to TAG the <ma> vs limited number of hrefs
(compatibility issue).

Resolution: Discuss this further on Issue 125
<https://github.com/mathml-refresh/mathml/issues/125> and see if we can
resolve this (again :-) next week


mtable/mtr/mtd attr support (#114
<https://github.com/mathml-refresh/mathml/issues/114>, #220
<https://github.com/mathml-refresh/mathml/issues/220>)

NS: none of the attrs are supported. Can only do basic matrices and
determinants

FW: google is redoing table, so we can’t upsteam anything until they
implement something.

NS: no tables at all in core??? That doesn’t seem acceptable.

FW: I agree. But we should wait and see what they come up with

DC: seems like we need to put off attr support