- From: Neil Soiffer <soiffer@alum.mit.edu>
- Date: Tue, 12 Nov 2019 15:40:30 -0800
- To: public-mathml4@w3.org
- Message-ID: <CAESRWkCPZSkvVZU2EyB5cqZ+ukHBgAtV5v46TY5A5mxw-4G+7A@mail.gmail.com>
MathML Core Meeting of Nov 11, 2019
Attendees:
-
Fred Wang
-
Neil Soiffer
-
David Carisle
-
Rob Buis
Regrets: Brian Kardell
Agenda:
https://github.com/mathml-refresh/mathml/issues/8#issuecomment-552338130
The meeting was recorded:
https://benetech.zoom.us/recording/play/bRdNIKVYjVcFVNG2GQz0eU1AacqmfCzOb71k4484vHoFC7xTPxujAQSD4MFJBXuW?continueMode=true
Quick updates
-
Chromium - first patches landed
FW: added some MathML DOM stuff and enabling the tests and other minor
things
FW: also added separate stuff, all preparation for getting layout in
RB: our upstream work can be followed here
<https://bugs.chromium.org/p/chromium/issues/detail?id=6606>
-
BlinkOn 11 - two MathML talks (Brian, Fred) will be livestreamed/recorded
-
https://meet.google.com/iae-rqbh-urv
-
Lightning Talks - Session 3 Nov 15, 16:10 - 16:55
<https://meet.google.com/utq-vkuj-xar>
-
FW: I have a 30 minute talk; BK has 30 slides in 3 minutes :-)
FW: Should be available on youtube later.
RB: Should be an opportunity for informal contacts with google and MS
people
FW: There is some discussion on accessibility.
NS: Not sure what needs to be done. I think MathML is already exported
to the accessibility tree
FW: At the minimum we need to get this exposed.
-
TAG Review process #438
FW: Not much new. F2F in December.
------------------------------
-
Stretchy operators
-
Proposal 1: "When calculating the inline size of
munder/mover/munderover, the unstretched size of horizontal stretchy
embellished operators is used." to avoid underestimation of min/max
stretchy horizontal operators ( #130
<https://github.com/mathml-refresh/mathml/issues/130> )
FW: need to come up preferred widths, don’t have vertical metrics for
stretchy chars.
FW: only one case where we underestimate, namely munderover.
NS: this won’t affect the tightness of surrounding text, right? It
only affects overflow or underflow of the containing lines.
FW: correct, only affects linebreaking. Potentially there is a trick
to write some JS to fix it up afterwards.
https://github.com/mathml-refresh/mathml/issues/153
NS: is there an analogy outside of math where you don’t know sizes
until layout?
FW: table. You don’t know the width ahead of time. There isn’t
anything where height affects width.
FW: For large operator, you know you need a large operator so you
know the width.
FW: the change might affect overflow locally but wouldn’t change the
preferred widths because the layout globally doesn’t change.
[looked at some fonts for overbrace for some examples of how much
things grow]
NS: Okay, I’m ok with the proposal as it doesn’t look like the
overflow was not much, at least for the font we looked at and
hopefully for
other well designed fonts.
NS: What about when minsize is specified?
FW: There are two issues, 153
<https://github.com/mathml-refresh/mathml/issues/153> and xxx(?)
related to this.
-
Proposal 2: Pass a 0 target size when calculating unstretched sizes,
to avoid issues with nested embellished operators ( #124 (comment)
<https://github.com/mathml-refresh/mathml/issues/124#issuecomment-546313283>
)
NS: I’m still trying to figure this out. Let’s postpone this.
-
Operator Dictionary:
-
Proposal 3: Move the official table (based on unicode.xml) into a
separate spec (maybe https://www.w3.org/TR/unicode-xml/ )
-
Proposal 4: Filter out unnecessary data from core e.g. #161
<https://github.com/mathml-refresh/mathml/issues/161>
-
Proposal 5: reorganize how it is presented to make it more optimal
-
DC: Additional: Improve consistency of some entries
DC: We first need to decide what properties are needed in core and
then extract that. Not really big enough for self-standing spec.
-
FW: We can put this off for now (but will need it when upstreaming).
-
ms #120 <https://github.com/mathml-refresh/mathml/issues/120> #126
<https://github.com/mathml-refresh/mathml/issues/126> (only implemented
in Gecko)
-
Proposal 6: remove from MathML Core (Brian) ← actually behave like mn
NS: in last meeting BK and NS had idea of requiring lquote/rquote to
be the same as that removes directionality issues. Use
before/after and the
problems with using that will dealt with independent of MathML
DC: I’d be in favor of dropping ms from core if we don’t allow the
quotes. Just polyfill in that case.
FW: like mfenced, it is bad because the quotes aren’t in the dom and
that causes issues. Copy/paste, maybe others.
NS: That’s a problem that is there in CSS whether we use it or not.
Others use it, so it needs to be dealt with independent of what
we do, so I
don’t see this as a problem. It will get resolved.
FW: still I not happy about that.
NS: I’m ok with dropping ms from core and polyfilling it. Is that a
problem for you, David?
DC: I’d prefer ms remain in core with attrs, but I don’t really care
because I could generate my stuff with mtext and include the quotes.
NS: but mtext has a different meaning
DC: I really don’t care. We use strings all over the place, but
clients wouldn’t know.
FW: can’t remove from core because it is in HTML due to special
handling for token elements.
DC: maybe we should keep it and tell people to either put the quotes
in the contents or add CSS to style it via before/after. I’m warming to
that even though I thought it was horrible earlier. It’s the
least invasive
option.
FW: that would be as a note
NS: It seems like the least bad of several bad alternatives. Maybe
done via a polyfill?
Resolved: tell people to either put the quotes in the contents or add
CSS to style it via before/after.
-
use of movablelimits ( #165
<https://github.com/mathml-refresh/mathml/issues/165> )
-
Proposal 7: move the scripts only when displaystyle is false on the
mover/munder/munderover elements (not necessarily the same as
base or core
operator).
Resolved: agree do it the way Gecko does it.
NS: I’ll write the test
FW: You should reuse the display style tests
<https://w3c-test.org/mathml/relations/css-styling/displaystyle-1.html>
and put in the same file.
-
Change definition of space-like maction and semantic ( #160
<https://github.com/mathml-refresh/mathml/issues/160> )
-
Proposal 8: Handle maction/semantics the same as other mrow-like
("whose in-flow children are space-like" instead of "whose first in-flow
child exists and is space-like")
Resolved: agree — this makes sense
-
Definition of "cramped" ( #134
<https://github.com/mathml-refresh/mathml/issues/134> )
-
Proposal 9: Remove item 6 (Neil)
Resolved: agree delete from the spec
-
Clarification for Operator maxsize/minsize: #109
<https://github.com/mathml-refresh/mathml/issues/109> #110
<https://github.com/mathml-refresh/mathml/issues/110>
-
Proposal 10: Keep current definition
FW: at the hackfest we looked up what CSS does min>max and felt we
should go with that — set maxsize = minsize
DC: I’m ok with that.
Resolved: agreed
FW: For stretching the min/max size stretching. We can either stretch
by scaling or stretch by adding a delta.
NS: Scaling could introducing rounding issues. I need to refresh my
memory
All: agree to postpone to next week.
-
Operator spacing in scripts (38
<https://github.com/mathml-refresh/mathml/issues/38>)
-
Proposal 11: Keep current definition? (Neil)
NS: let me create some examples
-
Other Issues:
-
FW: At the hackfest, people felt that “script” was too overused. We
use it in “scriptlevel”.
FW: proposal rename CSS properties math-script-level to math-level ;
math-style: normal/compressed ; but keep corresponding attribute names
-
Describe full side effects for math-level etc
-
Maybe explain “cramped” (does not exist yet). Needs to be brought
into the full spec also.
We will have a meeting next week.
Received on Tuesday, 12 November 2019 23:40:45 UTC