Minutes: MathML Core meeting August 10, 2020

Attendees:

   -

   Neil Soiffer
   -

   Patrick Ion
   -

   David Carlisle
   -

   Brian Kardell
   -

   Murray Sargent
   -

   Bruce Miller
   -

   Rob Buis


Regrets: Louis Maher

Thanks to Brain Kardell for taking a good chunk of notes.



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

The meeting was recorded:
https://benetech.zoom.us/rec/share/x88uM72u739JZ7fv0xjBe4AIGbzceaa8gSQc_vQJmEkDQl7EFJlVKaFtBdhBeSGu
(Access Password: WVs!C40@)  [meeting starts about 10 minutes in]

Charter:

   -

   We created a very basic starting point (not even a 'first draft') of  MathML
   WG charter
   <https://docs.google.com/document/d/1W-oYUbOMueaqb3KFSWkjWVBwR6AzSEBizHwQhvSwfDc/edit>,
   please have a look, comment, contribute

NS: semantics meeting came up with three goals for MathML: presentation,
accessibility, and search. The latter may be not so well defined or agreed
upon. Note that computation is not currently listed as a goal.

There are 26 MathML Core issues with "needs resolution". Let's try to
resolve some of them:mpadded and resolution of percentage values #227
<https://github.com/mathml-refresh/mathml/issues/227>

NS: The issue as I understand it is that we have already disallowed …?

RB: It looks like our answer for the width is hacky and won't be accepted.

NS: It seems weird to allow it on the height and depth, but not width

RB: I agree

NS: I looked at usage stats
https://github.com/mathml-refresh/mathml/issues/55, but didn’t see %.  I'm
not sure, if it is not getting used, it seems it is not an issue

DC: Use other forms, not percentages.

BM: In principle I would have liked this, but since it never worked I
wasted too much time and chose something else.

DC: The relative ones are more natural, I think we could live without it. I
don't think it affects the visual semantics.

MS: Our math reader has all of the infrastructure, but doesn't do much with
this - it won't affect us.

NS: So add to full, polyfill, remove from core?  Objections to that?

Resolved: remove % completely from core. Leave in full and add them to the
polyfill.

automatic size adjustment: #225
<https://github.com/mathml-refresh/mathml/issues/225>

NS: Weed to wait for Fred for this one I think.
U+002D HYPHEN-MINUS in mo operators: #146
<https://github.com/mathml-refresh/mathml/issues/146> => write a polyfill?

NS: I think this is an issue we have to wait for Fred for - I think this is
a really simple thing in the implementation, I think it's really about how
many there are and how clean that is… Does it need to be in core?  I think
Fred would like to omit it, but we'll wait for Fred.
Include mo@accent attribute into MathML Core? #210
<https://github.com/mathml-refresh/mathml/issues/210>

NS: Again, I think we need Fred for this.
Add menclose to MathML core #216
<https://github.com/mathml-refresh/mathml/issues/216> (anything new?)

NS: Rob, I'm not sure - did you say that menclose is just not on the list
of things Igalia was planning to do?

RB: Right.

NS: So, is this a level 2 thing?
RB: We haven't made any plans for next year yet, but could be.

NS: What do other browsers think then, do we know?

BK: Status in other browsers?

NS: I think it was fairly fully, but not completely implemented in FF and
WebKit. I certainly use it for school stuff - crossing things out.  It's
not easy to do the cross outs. I think I did it with before/after and a
transform or something?  That's pretty hacky but maybe it is what you have
to do

BM: I didn't mean to imply that you could do it with CSS currently, but
rather that it seemed like a thing CSS would be interested in.

BK: Met with apple devs. Discussion of what it means to be in core. Should
be interoperable in all major browsers.

NS: Can some of this be done in CSS?

BK: I think we should punt to level 2.

Resolved: Move to level 2. Need to implement polyfill.

Consider integrating scriptlevel into font-size #174
<https://github.com/mathml-refresh/mathml/issues/174> (anything new from
fantasai?)

BK: We opened this metabug https://github.com/w3c/csswg-drafts/issues/5384

BK: includes new ask. Might create a new keyword for fontsize (math). Would
be a property. Just a guess.
mstyle mathvariant inheritance and mi #204
<https://github.com/mathml-refresh/mathml/issues/204>

BK: This has CSS implications. I have pushed them. Someone else finally
added it to the agenda but I wasn’t notified and missed the discussion.
Current status is Elika is going to submit new text for the spec here on
text-transforms and we can see if it can move forward.  This is, I think,
how they are actually implemented though, so vendors may want this to
remain an internal property and not exposed to users. Still unclear.
Describe how to layout DOM elements violating HTML5 model #187
<https://github.com/mathml-refresh/mathml/issues/187>

NS: this applies to both parsing and JS adding an element.

BK: This seems like they should be treated as unknown elements. I.e, treat
them as mrow (I think we changed this to 'container' or 'grouping' in
specs). Maybe someday

DC: in HTML parsing, some elements abort the math and others are unknown
elements.

DC: Overtime, we’ve moved to making everything mrows over merrors.

BK: Any tree you can create the spec should say what should happen.

DC: Any problems with someone inserting a form element with JS? Or a script
element?

BK: I think it just turns into an unknown element.

NS: this is related to #15. What did Apple say about that?

BK: It will take some time to work through these things. So we talked about
the meta issue of them getting involved in the discussions

BK: We talked a little about it and will follow up later this week given
they have some time to think about it.

BK: Rob, I think Ian Kilpatrick from Google prefers this approach, is that
your understanding too?

RB: I’m not sure. I think maybe.

BK: Let’s make sure to cc them - @rniwa, @bfgeek, @emilio

Consensus: Let's treat this as an unknown element and hence layout as an
mrow/grouping container. Let’s see what feedback we get before we put this
into the spec.

Remove/Deprecate mglyph element #25
<https://github.com/mathml-refresh/mathml/issues/25>

NS: seems like the issue has a resolution but the label is still there  --
don’t be part of core but leave in full because of non-web issues.

BK: there are some CSS issues BMrelated to this
https://github.com/w3c/csswg-drafts/issues/4116. This about having an image
that establishes a baseline. I suggest members weigh in.

BK: Why can’t this be trivially implemented with shadow DOM?

BK: Why can’t MathML full just add <img>? The web has all these security
issues and synchronicity, etc.

BM: I think it is harder than you say because the full spec then needs to
say all the things the web says about img. Why can’t browsers just treat
mglpyh as a subset of img.

BK: It's possible I am overthinking or confused or just misrepresenting
where I imagine the concerns will be - I don't think we are going to
resolve something here - let's continue some discussion async and come back
to this.