Minutes: MathML Core meeting: 15 June, 2020

MathML Core Meeting of June 15, 2020

Attendees:

   -

   David Carlisle
   -

   Neil Soiffer
   -

   Brian Kardell
   -

   Murray Sargent
   -

   Rob Buis
   -

   Bruce Miller
   -

   Louis Maher
   -

   Patrick Ion
   -

   Frédéric Wang



Agenda:

The meeting was recorded:

https://benetech.zoom.us/rec/share/4O9qDr2u5EFJAc_v1m2HQKcmHofveaa8gHNP-aAOyUbTYMfFgXU7gPdRhOhudDJk
Password: 3C!!wo4@


   - href (#125 <https://github.com/mathml-refresh/mathml/issues/125>)

[10 minute max discussion]
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.
From last week:
Resolution: BK to bring to TAG the vs limited number of hrefs
(compatibility issue).
Resolution: Discuss this further on Issue 125 and see if we can resolve
this (again :-) next week

BK:

   1.

   Filed
   https://github.com/w3ctag/design-reviews/issues/438#issuecomment-640917806
   2.

   Brief discussion with Alice Boxhall and reached out to Tess, we expect
   they will get to this in a breakout soon and get back to us
   3.

   I spoke to some web folks (just developers/standards folk, not MathML
   backgrounds) and they had the same series of questions: why have this on
   token elements. I told them backwards compatibility.

NS: I have been warming to the idea of a polyfill or a transform

DC: I can generate them, it's not a problem - almost every mi is a link, so
it will just add a lot of elements… thousands and thousands.  Maybe we
should just do it.

NS: Maybe we should wait for TAG feedback

BM: Basically the same as David. I guess the bigger concern to me is lack
of back compat and how that works for existing systems

DC: Yeah, if we don't get MathJax, for example, it will not work.

BM: Also no one has implemented it in the browsers.

FW: For FF and WebKit, the implementation would be very easy

NS: mrow around an mo acts like an mo so if you wrap a new element around
the mrow, that would not behave the same as if it were just an mrow. Same
for ma around an mtext (whitespace).

FW: This is just "mrow-like" - it has mrow layout.  This is why we
introduce this definition of mrow-like…. I'm not sure why you say it is
different.

NS: Because there is a space-like rules, won’t there be a problem if <ma>
isn’t spacelike?

FW: Space-like is a specialized mrow-like.  That's actually why we
introduced this common definition so that it just flows through and we
don't have to explain it all again so many times/ways.

BM: So there was hesitancy to just _use_ an mrow?

NS: well, there are concerns about shadow dom and stuff…  My proposal is we
wait for TAG to come back.

BM: I'm with David on getting implementations out there is worth a
sacrifice, it is a shame if we can't get it.  Maybe the solution is to
generate full and ignore and not care.

NS: I’ll check with David Cervone to see about his willingness to add <ma>
to MathJax.

BK: I agree we should wait for TAG.  What I was saying early on is that
links are complicated and it's unlikely that we will be able to get all of
that solved in this initial effort.  I'm not sure it makes sense to
speculatively put something in if we can't get implementations in time.  My
gut instinct is that you are going to either just let math render and not
care about the links, or you will use a transform/polyfill for backcompat.
If we want to create a 'proper' answer going forward, and aren't bound by
the past: Token elements can have links in them today, and we should do
<ma>.
CSS name bikeshedding

Proposals:

   -

   cramped: math-superscript-shift-style => math-shift #222
   <https://github.com/mathml-refresh/mathml/issues/222>
   -

   math-shift/math-style values: display/inline => normal/compact #170
   <https://github.com/mathml-refresh/mathml/issues/170>

FW: was trying to provide some simplification by suggesting a simpler name.

NS: I found ‘math-shift’ to be too generic a name.

DC: Comparison with inline/display -- they don’t really say what they do,
they just do things in different situations. “Cramped” does what it does
and is used by TeX and OpenType.

FW: Another option is to add another value to ‘display’ (add ‘cramped’ as a
value).

DC: There are actually four values in LuaTeX so you can explicitly get
cramped to happen in each of those styles, so you would need four values.

BK: If there is a strong argument for cramped, then it is fine with me - in
fact, I think there is a good argument to match the one that exists, but it
has to be described in the spec because you shouldn’t have to know TeX to
understand what it means.  Lots of CSS things that are technical and don’t
mean much without reading.

FW: There are the CSS property and the value. Fantasi doesn’t like value
names that end with “ed”. Not considered is consistent with CSS current
names. That is why normal/compact. Not sure about CSS names.

FW: They don’t like boolean properties. What happens when you add a new
value.

FW: need to send to CSS group and they may want to change the name

BK: I like ‘compact’

FW: math-style? Can we call its values as ‘normal’/‘compact’ instead of
display/inline?

FW ‘displaystyle’ is boolean, so want to get away from that.

DC: It's fine, but it seems weird.

BK: Can you articulate what it is that is weird so that I can be sure to
help explain this in CSSWG or maybe you see something we do not.

DC: I’ve used TeX for 30 years, so I find these weird. Ultimately, I don’t
care, but it will be confusing to people to do math layout because everyone
who does math layout won’t understand it.

FW: can send proposals to the CSS WG with some context about the names used
by people who do math rendering.

[some discussion about co-evolutions and how we can represent this
explanation in proposing to CSSWG]

NS: Are there any analogies with SVG and graphic layout using different
terms from CSS and how those were resolved?

[don’t know]

DC: Math is a bit different because SVG is a blob, but math is more like
text so needs to fit in more.

FW: Do we agree …

FW: One last thing about normal/compact. Are we ok with ‘normal’ being the
standard thing and ‘compact’ doing the other thing (more cramped/compact)

DC: It will work, we can live with it

FW: I guess I can modify the spec but not go too far, I'm not sure how to
present both in a way that is not confusing.

NS: I think that math-style is fine, the ‘math-shift’ seems terrible
because it is too generic for such a specific feature.

[discussion on text-transform in CSS and accessibility and what the spec
says and what happens in the real world]
More OpenType things:

   -

   rtlm / ssty
   https://mathml-refresh.github.io/mathml-core/#opentype-features
   Not sure we will implement this. put at risk and remove the ISSUE label?

Note: RTLM == Right-to-left mirrored forms. From spec: “This feature
applies mirrored forms appropriate for right-to-left text other than for
those characters that would be covered by the character-level mirroring
step performed by an OpenType layout engine.”

SSTY == Math script style alternates. From spec: This feature provides
glyph variants adjusted to be more suitable for use in subscripts and
superscripts. The script style forms should not be scaled or moved in the
font; scaling and moving them is done by the math handling client. Instead,
the 'ssty' feature should provide glyph forms that result in shapes that
look good as superscripts and subscripts when scaled and positioned by the
Math engine.

FW: consider prime (‘), in MathML uses msup, but OpenType has ssty that
says shift it some. Maybe rtlm and stty descriptions are at risk in the
spec.

MS: If you have a RTL run, you get automatic mirroring. RTLM is used when
the character such as integrals doesn’t have a mirror. They are orthogonal.

FW: All of the token elements that follow text will apply this.

MS: I am talking about a RTL math zone is used in some arabic countries - I
don't know if anyone implements it but the ..?

FW: The spec says how to lay out things from right to left and we have
implementations in webkit and Firefox and we are working on it in
chromium.  We have some very specific things like stretchy integrals - the
spec has to specify to pick the right glyph and to check the math table…
Basically, everything about it needs to be described. That’s not handled by
rtlm/OpenType. So what remains is only about the text

NS: At the font level, I understood MS was saying that RTLM in open type
would give me the mirror image of the character. Won’t it do that for the
parts of a glyph?

MS: only if ???

FW: Since we are implementing our own logic to stretch, character level
mirroring doesn't happen.  CSS supports character level mirroring, this is
about glyph level mirroring with RTLM.

MS: You have to do your mirroring before your stretching

FW: Right, so the issue is do we want to specify all of the details in the
spec now knowing that it probably doesn't work anywhere - and are we going
to write all of the tests and so on.

MS/NS: This is important but not for level 1.

FW: So do we clean up the spec or… how do we want to do this?

NS: How about starting a 'level 2' outline and dumping it in there? BK --
how is this done in other specs?

BK: Normally, it depends on how it is being dropped. E.g, CSS Colors is a
giant thing, sometimes you can hit a point where you just split it into two
specs with the real mature stuff or 'necessary first' stuff and then the
next. But before that, for lots of stuff - it can be tagged or in a wiki…
the next level selectors are always just in an outline form in the wiki..

NS: maybe just give it a “level 2” label and we can pull those out.

FW: for stty is it basically the same thing. I’ll remove that for level 1

DC: if you don’t have the stty thing for prime, what happens?

MS: We should substitute in U+2032

NS: Sounds like the ‘-’ and U+2212 issue

FW: generators should use the right character

MS: that’s really low level -- should be done by browser

FW: people shouldn’t use “-” and “‘“

NS: let’s table this to next week. This is a big issue.

Resolution: stty/rtlm move to level 2.

Meeting next week -- discuss character substitution and continue with the
OpenType issue.

<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Virus-free.
www.avg.com
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>