Re: Minutes: MathML Core meeting Sept 28, 2020

Hi Neil, all,

I tried quickly skimming the recording out of curiosity and was surprised
at the high levels of noise through what seems to be most of the call?
Unsure if this was also the case during the live conversation or just a bad
zoom recording. In case the noise was also present in the live call, I
would suggest that the Zoom host/admin should feel welcome to mute
participants with high background levels - or the recording is quite hard
to use afterwards.

Likely not much lost on my end, but thought I'd raise awareness that the
audio quality had issues.

Greetings,
Deyan

On Tue, Sep 29, 2020 at 1:57 PM Neil Soiffer <soiffer@alum.mit.edu> wrote:

> Attendees:
>
>    -
>
>    Neil Soiffer
>    -
>
>    Brian Kardell
>    -
>
>    Louis Maher
>
>
>    -
>
>    David Carlisle
>
>
>    -
>
>    Murray Sargent
>    -
>
>    Bruce Miller
>    -
>
>    Patrick Ion
>
>
>
>
> Agenda:
> https://github.com/mathml-refresh/mathml/issues/8#issuecomment-699753792
>
> The meeting was recorded:
> https://benetech.zoom.us/rec/share/A9Uq8szPKnT0WiLEtUsJrxNHFDkQ9Plcsd39F7GXJpxL-L5RqHOFZ7GN_FKI-iDc.cKuILMzuUfL6BGdm
> (Access Passcode: =TOy!855) The meeting starts ~5 min in
>
> Thanks to Patrick for doing the minutes.
> Charter Timelines
>
> https://mathml-refresh.github.io/charter-drafts/math-2020.html
>
>    -
>
>    Core Level 1
>
> NS: we need dates
>
> BK: maybe Q1 2022
>
> NS: for the whole thing maybe 2024
>
> BK: just say beginning normative work and WD expected
>
> NS: Q1 2022 for Test Suite and Impl Reports; is that all?
>
> BK: Yes from my POV; we have 2300 or so tests (perhaps less with those for
> features we backed out removed)
>
>
>
>    -
>
>    Core Level 2
>    -
>
>    Other Deliverables:
>    -
>
>       Test Suites
>       -
>
>       Implementation Reports
>       -
>
>       ???
>
>
> Resolving more issues:Applying visual effects #179
> <https://github.com/mathml-refresh/mathml/issues/179>
>
> NS: Rob not here, so no update.
> BK; there’s lots going on in October, in partic in Igalia
>
> automatic size adjustment: #225
> <https://github.com/mathml-refresh/mathml/issues/225> Updates?
>
> BK: No update
>
> U+002D HYPHEN-MINUS in mo operators: #146
> <https://github.com/mathml-refresh/mathml/issues/146> => write a polyfill?
> Updates?
>
> No update
>
> Include mo@accent attribute into MathML Core? #210
> <https://github.com/mathml-refresh/mathml/issues/210> Didn't reach any
> conclusions last time.
>
> NS: Brian and I had some discussion on implementation. Here’s a codepen:
> https://codepen.io/nms/pen/bGpQjmP
>
> NS: queston is how this affects spec; Fred wants accent on mo’s to be
> ignored; I claim irt breaks rendering of lots of legacy content.
>
> MS: rerun with accent=false makes it look quite different
>
> NS: That shouldn’t affect stretching
>
> MS: arrow got stretched but is higher and bolder
>
> NS: I’ll get example images paced into the issue for a better discussion
> to follow
>
> MS: [put in before] The MathML with accents Neil gave displays in
> OfficeMath as
>
> The MathML used here is
>
> </math>
>
> <p>With accent explicitly off</p>
>
> <math display="block">
>
>     <mover>
>
>         <mi>a</mi>
>
>         <mo>^</mo>
>
>     </mover>
>
>     <mo>+</mo>
>
>     <mover>
>
>         <mrow>
>
>             <mi>a</mi>
>
>             <mo>+</mo>
>
>             <mi>b</mi>
>
>         </mrow>
>
>         <mo>^</mo>
>
>     </mover>
>
>     <mo>+</mo>
>
>     <mover>
>
>         <mrow>
>
>             <mi>a</mi>
>
>             <mo>+</mo>
>
>             <mi>b</mi>
>
>         </mrow>
>
>         <mo>→</mo>
>
>     </mover>
>
> </math>
>
> MS: with accent=”false”, it looks different
>
> MS: with accent=”true”, looks the same as the first (with no accent
> attribute).
>
> MS: for the a\above(x->y), the accent attribute doesn’t change anything
> (first has accent=”true”, second accent=”false”). The OfficeMath accent
> object only handles a single accent character.
>
> Left: WebKit (linux/no mathjax) right: chrome+mathjax
>
> On Safari 14.0 on a Mac OS 10.14.6 (as the CodePen with mathJax commented
> out)
>
> Add scriptsizemultiplier to core #230
> <https://github.com/mathml-refresh/mathml/issues/230>/ #1
> <https://github.com/mathml-refresh/mathml/issues/1>
>
> NS: was in MathML3; then we decided to remove this and rely on the
> OpenMath table; however, this ignores visual problems and there it is
> useful to have this possibility; study has shown it is useful; so it is
> suggested to put it back
>
> MS: I think you can argue that this should be in a a11y setting;
>
> NS: subscripts may not be better reduced
>
> NS: I agree with MS that should be optional and settable by the user; but
> that means this attribute cannot go away for you can’t control it if it’s
> not there in Core.
>
> MS: if there’s an open path to deal with this it;s OK; in our environment
> there are lots of ways to cope; maybe CSS
>
> NS: if it’s not there then CSS can’t control it; that’s why we need the
> attribute back; people with low vision change the defaults for small font
> sizes; renderers can then see that there’s been an override; so
> scriptsizemultiplier =0.9 maybe would be invoked
>
> BK: I don’t have a comment on the a11y details; though everyone is for a11y
>
> MS: it’s a real long shot to get this in; a11y can be improved later
>
> BK: you can zoom your font any time
>
> MS: any time
>
> NS: that changes the whole screen; if it’s just the math with subscripts
> that is the problem then this multiplier allows …
>
> BK; we also don’t support line breaking which affects even more persons,
> surely
>
> NS: the objection to allowing this is that it’s one more piece of work to
> do
>
> MS: hyphen minus is more important
>
> NS: I guess I’m being asked to show examples of where there’s support and
> give images
>
> LM: people could use voice
>
> BK: or magnifiers
>
> NS: the people I’ve talked to don’t do that; 24pt is often used but this
> is about subscripts
>
> DC: even without a scale factor exposed can’t you, say, CSS style the 2nd
> child of msub to have 200%; it’s not a complete washout with
> scriptsizemultiplier not exposed;  nested subscripts are not all that
> common; one CSS rule would surely get 90% of the cases
>
> <<<
>
> PI: this is about User Style Sheets (USS) then perhaps
>
> BK: I think they may have gone out of style Chrome removed them in v 33
>
> NS: I should ask about it at an upcoming a11y; 2 people I know with vision
> problems did in fact use USS
>
> BK: ...
>
> MS: OfficeMath doesn’t do anything with scriptsizemultiplier. Maybe it
> should or have some way to implement this for accessibility
>
> NS: [ACTION]  I’ll check what low-vision people are using these days;
> maybe they don’t use Chrome, say.
>
> ----
>
>
> Mstyle mathvariant inheritance and mi #204
> <https://github.com/mathml-refresh/mathml/issues/204>/#1
> <https://github.com/mathml-refresh/mathml/issues/1> (comment by Neil to
> remove mathvariant on mstyle)
>
> NS: could be the last ‘needs resolution’ item
>
> NS: Fred’s forcing onto token elements is a bit of implementation
> complication
>
> NS: Discussion starts at
> https://github.com/mathml-refresh/mathml/issues/1#issuecomment-675725381
>
> MS: The following MathML turns off math italic
>
> <?xml version="1.0" standalone="no"?>
>
> <mml:math xmlns:mml="http://www.w3.org/1998/Math/MathML" display="block"
> mathvariant="normal">
>
>     <mml:mi>E</mml:mi>
>
>     <mml:mo>=</mml:mo>
>
>     <mml:mi>m</mml:mi>
>
>     <mml:msup>
>
>         <mml:mi>c</mml:mi>
>
>         <mml:mn>2</mml:mn>
>
>     </mml:msup>
>
> </mml:math>
>
>
> BM: I don’t see any compelling reason, but if it’s hard to implement
>
> NS: technically mathvariant doesn’t need to be there; but it allows the
> power to screw things up
>
> DC: there are useful cases; e.g. when you want to put sans-serif is being
> used, in TeX you out \mathff around things; but to convert to MathML is
> more difficult
>
> MS: I just put mathvariant=normal on the math tag and it turned all math
> italic off; that could be useful
>
> BK:
>
> BM: we shouldn’t confuse what we can do with what you should do
>
> <<<
>
> NS; consensus :’Keep mathvariant on mstyle’
>
> BK Fred on May 22 in issue 204 seems to have something about universal
> selectors ; now it’s unclear what is intended.
>
> NS: I hope the tests are testing what ‘faceless2’ (mike B..) wanted
>
> BK:
>
> WPT relevant tests are at:
> https://wpt.fyi/results/mathml/relations/css-styling?label=experimental&label=master&aligned
>
> [PI stops trying to minute]
>
>
>
>
> <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>
> <#m_-8225318170669911396_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>