Notes: MathML Core meeting 9/9/19

Note: next meeting on Thursday 12/9/19, 11am Pacific, 2pm Eastern, 8pm
Central European Time.

The meeting recording is at
https://benetech.zoom.us/recording/share/4xQEsJZ0gj-sZ_uzRPNDPjxOsag8Tcy5M1PYpZsqV-M


Attendees:

   -

   Neil Soiffer
   -

   Fred Wang
   -

   Rob Buis
   -

   David Carisle
   -

   Brian Kardell
   -

   Bruce Miller
   -

   Patrick Ion
   -

   Murray Sargent


Agenda:

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

DOM/IDL #83 <https://github.com/mathml-refresh/mathml/issues/83> #118
<https://github.com/mathml-refresh/mathml/issues/118> (update from Brian?)

BK: Some work is done in all of the browsers (HTMLOrForeignElement)

BK: Need to deal with tabindex

NS: What needs to specified?

BK: Need to say that tabindex is global to the document, not to just MathML

BK: Need to say in doc that has MathML, can put href on any element

BK: Need to say CSS focus pseudo-classes work in MathML like in HTML

BK: Not a lot of things to do, but it can be complicated. E.g., scrollable
areas that get focus.

NS: So just need to say MathML doesn’t need special cases.

BK: To me and you, it seems that simple but we need to be very explicit.
Activation behavior, keyboard behavior needs to be spelled.

BK: Fred -- how do we want to handle this in writing the spec?

FW: just do a PR and add to tabindex issue for that part since I’m sure
what should happen

FW: maybe part of global attrs

BK: bzbarsky said we should be explicit or say they are the same as HTML

BK: I think we can just point to HTML to avoid getting out of sync.

FW: we need more tests for DOM IDL

BK: No worry about renaming because we have implementer support for it.

FW: Dominic replied that we can send a PR to the HTML5 group.

BK: Just need to add HTMLOrForeignElement to spec, which is less important

BK: Turns out that Mozilla supports non HTML Custom Elements

BK: Looks like only XUL elements, but plumbing actually looks like is
supports anything.

FW: something to discuss at TPAC
percent width/height for foreignObject: #49 (comment)
<https://github.com/mathml-refresh/mathml/issues/49#issuecomment-529412104>

<mtext><span style="inline-block; width: 50%"></span></mtext>.

FW: I’d like % to resolve against 0

NS: what happens outside of MathML for span inside of another span

FW: needs to look at enclosing block

NS: Why not resolve against parent <math> or <mtable> which would be
enclosing block?

FW: Google felt it is more complicated

FW: Maybe in the future we could resolve against <math> or <mtable>.

FW: Haven’t agreed on supporting width/height on <math> or <mtable>.

BK: why can’t we support w/h on token elements?

FW: I had a proposal a while ago, but don’t remember all the details. There
are problems with overflow.

NS: So just generally a lot more complication?

FW: the issue is https://github.com/mathml-refresh/mathml/issues/45, which
we earlier resolved to ignore.

NS: Brian, did you have a use case?

BK: what about large numbers and getting them to linebreak?

FW: we’ve postponed linebreaking, so we’ve postponed that

NS: I agree -- lots of cases where we want linebreaking.

NS: What about span inside of mn

FW: Should just work

BK: I tried it and it didn’t work

NS: Sounds like a test is needed…

FW: Parent needs to pass width and height. In theory we can do it, but
someone needs to do that.

NS: Worry about it being different than the rest of web. How hard is it
really?

FW: Fred parent passes w/h to children, but doesn’t know w/h until children
have done layout.

NS: But this is a different w/h. It is the block w/h, no computation of the
children is needed. It is sort of the page width, not related to the
children’s w/h.

FW: Someone needs to do the work, so it is easy just to make it 0.

NS: But this makes MathML different than the rest of HTML.

NS: My feeling is that is linebreaking. We need to support it, but spec can
say currently not supported.

NS: Incompatibilities if we set it 0

FW: yes, there were some tests where different browsers do different things.

<some back and forth on how to say this in the spec>

BK: if we don’t say something, people will come to rely on current behavior.

FW: happens with Firefox’s linebreaking but Firefox’s linebreaking didn’t
follow the spec

FW: if you want it supported, then you need to write tests and implement it

FW: picking 0 is easiest

NS: I understand it is more work, but it seems wrong

FW: I agree it is wrong, but it is easy and we need to resolve this.

RB: We need to know more about how w/h work. Their not inheritable

BK: Not inheritable, but the space they render into is heritable.
#50 (comment)
<https://github.com/mathml-refresh/mathml/issues/50#issuecomment-529412323>

https://github.com/mathml-refresh/mathml/issues/45#issuecomment-511718819
display values and CSS properties: #31 (comment)
<https://github.com/mathml-refresh/mathml/issues/31#issuecomment-529409481>

BK: CSS group worried about these. They were worried that this would be
just the first of many, rather than just these three.

BK: No sure we can say they were strongly opposed.

FW: We can make these just internal.

FW: Could affect polyfills, but could otherwise do internally.

NS: I thought you had them set in the stylesheet

FW: Style sheet can make use of internal values.

NS: BK should talk to people at TPAC and get them more comfortable with the
idea of adding a few more properties.

#56 auto value for “display” property (comment)
<https://github.com/mathml-refresh/mathml/issues/56#issuecomment-529406477>

FW: need to add another display value “auto”

FW: could add more for every type of math notation

NS: I don’t see the CSS group allowing 20 new values.

FW: example -- suppose they want to use flex box to layout a fraction.
Adding a display:auto means that mfrac’s layout could be overridden.

FW: proposed to Google last week and they seemed happy with it

BK: maybe in the future we can add more display values

FW: but probably need to add a lot if we go that route

FW: and we’d probably have to expose linkethickness for fractions, etc.

BK: will see what TPAC people think of the proposal

BK: what happens with the current implementation if I override layout?

FW: It will ignore it in Chromium, at least in theory it should work, but
probably things will break


Ran out of time: next meeting on Thursday at the same time to resolve
remaining issues before BK goes to TPAC.