MathML Core meeting minutes for 20/5/19

Thanks to David C for the meeting notes (again)!
The recording can be found at
https://benetech.zoom.us/recording/share/gjQYbRp1YgOJE-2kXPwVscwINI8BLagn5JSJZyiyJ_-wIumekTziMw


## Topics for 20/5/19 Meeting

* Check the consensus from previous meeting: numbers #23, mstyle #88 #89 ;
mfenced #2 ()


Neil: I replied on #88/#89 on mstyle (wait for polyfill)

Neil: on #23 resolution was to match css.
(Neil to check previous minutes)
(Neil found last reference in minutes:
https://lists.w3.org/Archives/Public/public-mathml4/2019May/0006.html. In
it we postponed a resolution pending a complete search of the the
spec/schema to see if scriptsizemultiplier and mpadded's attrs are the only
non-length non-integer values used. If so, then agreement on using CSS
parsing for values with the exception of mpadded attrs which we will get to
later [#81].)

Fred: If we agree now to add mstyle attributes. we can start
implementations.
Fred: #88 agreed on plan to allow attributes, #89 delay.

Neil: mfenced is used but redundant
Patrick: redundant for rendering but not possible uses.
Neil: is mfenced a problem for browser implementation?
Fred: reviewers may reject it as it duplicates features and firefox and
webkit implementations of mfenced have issues.

Neil: Brian mentioned before this could be polyfilled via shadow dom but
general issue that custom elements can't be used for known elements...
which includes MathML elements.
Neil: we could discuss this with html wg
Fred: Brian has started some discussions with other implementers.

Moritz: also not a fan of mfenced as it introduces duplication and so
complexity.
Agreed: drop from core.
Murray: Office apps use mfenced but will need work anyway so not a major
issue.


* Explicit values for linethickness and mathsize names in MathML Full (#4
#7)? -- similar to what we decided for namedspace values.
  - linethickness: map to 50%; 100%, 200%
  - mathsize: map to 0.75em, 1em, 1.5em

Fred: we agreed to remove them but need explicit values for polyfills.
named spaces agreed but line thickness not fully specified.
Action: Neil to report on MathPlayer values.
Action: Full spec should specify values for the names to allow to mapping
to core.


* Reset CSS rules on the math too (UA stylesheet): #34 #35 #36

Fred: If you put css properties on html then this is inherited by the
MathML elements and has strange effects and interaction not currently
defined,so implementations now reset to default at start of math.

Fred: effects show side effects of implemention.
Fred: longer term may want to define this more fully.
Neil: worried that if we define something later, will it still make sense
to reset.
Neil: need to think if these should ever affect math.

Fred: People should check #34 #35 #36 (especially direction) and discuss in
a later meeting.
Fred: LateX2ML uses some CSS.
Bruce: generally intent was that when latexml switches to math that font
styling was not inherited to the math.

Neil: should we enumerate all css properties and specify if they should be
reset, ignored, or used by math elements.
Fred: should concentrate on properties that have caused issues in webkit
and firefox plus the ones raised by google (existing issues raised)
Neil: Put this on agenda for next time.
Fred: by reset here as defined by css keyword (resets to initial values)

Fred: direction might include up/down. Mongolian example
https://bugzilla.mozilla.org/show_bug.cgi?id=1077525


* Keep in Core as mrow-like?
https://github.com/mathml-refresh/mathml/issues/26#issuecomment-472831261
https://github.com/mathml-refresh/mathml/issues/70#issuecomment-472851862,
https://github.com/mathml-refresh/mathml/issues/65#issuecomment-472850668

* fallback values for math constants: #69

Neil: will check the mathplayer
Fred: checked with google most values are Ok, can be got from tables, but
axis height and line height is hard as you have to measure one glyph,
google concerned about efficiency but may be Ok as a fallback.
Fred: css already has allows some default properties by measuring glyphs.


-----

Next meeting June 3rd. Next Monday is a holiday in the US.

Received on Monday, 20 May 2019 23:41:55 UTC