Minutes: MathML Core meeting Sept 30, 2019

Thanks to Brian for helping with the notes.

MathML Core Meeting of Sept 23, 2019

The meeting was recorded:
https://benetech.zoom.us/recording/share/tAsZLldeDp-N7DL-AP41iui5ibCSb5yqhphEfpVR2OWwIumekTziMw

Attendees:

   -

   Neil Soiffer
   -

   Fred Wang
   -

   Patrick Ion
   -

   Bruce Miller
   -

   Murray Sargent
   -

   Brian Kardell

Agenda:

https://github.com/mathml-refresh/mathml/issues/6#issuecomment-535561177


Operator Dictionary updates #6
<https://github.com/mathml-refresh/mathml/issues/6> #6 (comment)
<https://github.com/mathml-refresh/mathml/issues/6#issuecomment-532673415>
#87 <https://github.com/mathml-refresh/mathml/issues/87> (Neil, David) #142
<https://github.com/mathml-refresh/mathml/issues/142> #143
<https://github.com/mathml-refresh/mathml/issues/143>

Waiting for update from David accents in the op dict

Waiting to hear back about Arabic

Rob implemented multi char operators

No progress on fixing priorities (precedences) used in full, not core, so
not urgent for testing

MathML 4 full needs to update spec to point to core about op dict, but also
indicate non-normative in full.


DOM/IDL #83 <https://github.com/mathml-refresh/mathml/issues/83> #138
<https://github.com/mathml-refresh/mathml/issues/138> #139
<https://github.com/mathml-refresh/mathml/issues/139> #140
<https://github.com/mathml-refresh/mathml/issues/140> (Brian) - closed: #131
<https://github.com/mathml-refresh/mathml/issues/131> #118
<https://github.com/mathml-refresh/mathml/issues/118>

Did some updates on tabindex and global handlers in the spec.

Fred submitted a patch for FireFox for all the DOM tests.

Brian wrote a blog post on handling unknown elements a while back based on
some google ideas. Unfortunately some of the google ideas didn’t go
anywhere (how to move HTML forward from idea to polyfill to using a builtin
module that would ship on demand in the browser).

There is a complication related to using ShadowDOM and unknown elements, so
that still needs to be resolved. Perhaps we can create a list of known
elements and anything else in the MathML namespace (which is somewhat
special in HTML) would work.

A problem is if we add support for element down the road, the polyfill will
stop working and there could problems

FW: do we really want to use shadow-roots.

BK: there is frequently value in adding shadow-roots. Useful because it
doesn’t modify the tree, which would mess up any CSS

FW: shadow dom can be on any custom element?

BK: yes. The path forward is tricky if we decided to add something like
mfenced into core, then there could be a problem. The JS would throw an
error trying to create a shadow root. It might be a problem.

NS: so maybe we need to add a note or add to the spec how this would go so
implementers write code to catch the error and not have it be a problem.

BK: this isn’t critical, is it

FW: no, but we need to present it to google, etc., so we need to think
about it. It’s good to have a plan for extending MathML

BK: I’ll work on it and what should be in the allow list.


Unknown elements #139 <https://github.com/mathml-refresh/mathml/issues/139>
and test for the removed mfenced element #2
<https://github.com/mathml-refresh/mathml/issues/2>

(continuation of above discussion)

FW: What to write test on unknown elements like mfenced, but not sure how
test for that.

BK: I thought we already made the decision that they would be treated as
mrow -- Are they treated as mrow in the implementation?

NS: I thought we had decided that too - that unknown things would be
treated as mrow because we can't not display it.

FW: Ok, I guess I know how to write the test

NS: That is how we decided to handle merror too I think?

FW: Yes, an mrow plus some CSS UA-styles.

BK:  Do we need a resolution on this?

NS: If it was not already resolved, let's resolve it now. Ok?

<no objections>



Unknown menclose #144 <https://github.com/mathml-refresh/mathml/issues/144>
and test for the removed radical notation #3
<https://github.com/mathml-refresh/mathml/issues/3>

FW: We had already decided radical notion would be removed. But I was
writing a test and I realized we didn't specify what would happen here if
it was an invalid value. Do we treat it as the default or…?  I don't really
think I have a strong preference, but we need to write something down and
probably send a patch for Firefox.

(discussion about whether order matters, or whether duplicate values are
actually an error or still functional like id ref lists in aria or class=""
in html)

FW: currently using this def:
https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#space-separated-tokens

FW: I will try to define the attribute without disallowing duplicate values
and ignore unknown values. We will keep longdiv as the default, as bad as
it is as a default. No strong reason to break backwards compatibility.

FW: basically keep as in MathML 3


Remove mlabeledtr #72 <https://github.com/mathml-refresh/mathml/issues/72>
, mfrac@bevelled? #29 <https://github.com/mathml-refresh/mathml/issues/29>,
subscriptshift/superscriptshift attributes of msubsup/msup/msub #27
(comment)
<https://github.com/mathml-refresh/mathml/issues/27#issuecomment-472848739>
-> Fred willing to write .tentative.html to check that they are not
supported, so that we have tests for tentative runtime flags in
Firefox/WebKit.

mlabeledtr occurs on 0.0007319348193744977% of desktop pages and 0 mobile
from the July 2019 crawl of the HTTPArchive - roughly 4.4 million desktop
homepages and 5.3 million mobile (note: you don't expect lots of math use
on home pages in this set to begin with but this is diminishingly small
even in this set - it's roughly 0.04% of pages that do use <math>)


Remove mglyph #25 <https://github.com/mathml-refresh/mathml/issues/25> (not
implemented in any browser)

but seems supported by MathJax.

Occurs on 0% of pages in both mobile and desktop datasets from HTTPArchive.