Minutes: MathML Core meeting Sept 28, 2020

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>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Received on Tuesday, 29 September 2020 17:57:23 UTC