MathML core 17/6/19 meeting minutes

Much improved meeting minutes from last week thanks to Patrick Ion's
scribing. For full details or clarifications, the meeting was recorded:
https://benetech.zoom.us/recording/share/tyRKJXHzg2D15oSZg-1ginMUVDfoM9ZIUCL3cw-5xFOwIumekTziMw



=====  MathML Core Meeting of 20190617

Present:

   -

   RB: Rob Buis
   -

   DC: David Carlisle
   -

   SD: Sam Dooley
   -

   PI: Patrick Ion
   -

   BK: Brian Kardell
   -

   BM: Bruce Miller
   -

   MS: Murray Sargent
   -

   NS: Neil Soiffer
   -

   FW: Frédéric Wang

Scribe initially: PI  [... means something missed]

==============

Discussion on notes to follow when Brian joins

------------------------

ITEM: Agree on interpretation of MathML 4 values for named constant in
linethickness (#4) and mathsize (#7) -- Murray, Dani

NS: just need to pick numbers

linethickness for fractions: 067, 1.0, 1.67

MS: nested fraction has standard width; longer length sometimes increases
thickness for nesting

FW: thickness is already controlled

NS: I'd be more subtle than 2 as a multiplier; try MathJax values

NO Objections - ADOPTED  067, 1.0, 1.67

---

mathsize #7

FW: proposed large, small, medium, xsmall and xlarge

ADOPTED Mapping to CSS’s values for x-small (¾), medium (1), and x-large
(3/2)

====

NOTES and how to take them:

NS: Community notes didn't work well; IRC was suggested; or something on
Google Docs

People then can go back and fix up.

BK: generally we had ….; last time suggested this

NS: IRC can only correct last line

BK: <lost connection>

DC: if Zakim is still usable one could edit by script as we used to;

NS: I suggest Google Docs; maybe wiki pages on Github

BK: ...

NS: I've been putting the minutes into the mailing list; few people are
subscribed to issues

BK: works well with Markdown well; we [elsewhere] generally export each
meeting into an MD file and we add a folder per meeting

NS: do you also send email pointing to it?

BK: yes

DC: to be honest we don't need to over-engineer; each issue has its own
tracking; if an issue is closed I'm unlikely to go back to the minutes to
see discussion.

NS: Use Google docs and check later

ADOPTED --- someone will be the main scribe and use a shared Google doc
that others can fix up

======

ITEM: Keep in Core as mrow-like? #100 (semantics)

NS: First element is presentation MathML; ignore rest;

FW: this can readily be overridden; FF does implement a case …

NS: there was the matter of  SVG and possible XML within it .

FW: notation as first

NS: this then is a way of getting foreign content in as 1st element of
<semantics>

SD: we are treating semantics as a presentation element that allows
providing info as to what’s being rendered

NS: straddling presentation and content; affects the potential polyfill:
look for presentation and move to 1st element; or look for SVG and move to
front; what would  polyfill do?

FW: changing the display property is what’s happening;

NS: it wouldn’t physically change the code

FW: DOM tree is unchanged though layout tree is; if child 1 is presentation
mathml it is rendered, otherwise look for SVG

DC: polyfill just needs to pick something; we don’t have to specify which
child; there’s author choice

FW: only render presentation mathml by default; author could insist on
rendering another child;

NS: author should specify CSS so as to be clear which child to render

Rendering a foreign element such as HTML or SVG does have a consequence for
the full spec

DC: SVG was put in (by Jacques Distler) as annotation 1st child so as to
get foreign stuff in; that had to be done this way so as to make it valid;
suggest for Core that semantics renders its first child.

ADOPTED: render 1st child for Core default

ACTION ITEM: ADD issue for the Full spec as to what to do; this touches on
#101 on integration; and how the polyfill is affected

---------

ITEM: MathML integration points #101 (proposal: #101 (comment)), #102

NS: this above is a potential integration point; I thought MathML3 limited
this to <mtext> only; the discussion seems to be otherwise

FW: HTML allows in all token elements; in MathML3 it doesn’t specify, I
think

DC: that was an intentional vagueness; we didn’t have another system; Ian
Hickson allowed all over so that was later limited; I think it’s useful to
allow HTML in all leaf elements; rather than just <mtext>

NS: can they then include MathML again?

DC: if you say that’s a problem then you just switch to <mtext>. And go
back again; we have no nesting prohibition; any inline element allows
<mtext> and thus MathML as well.

FW: we have the problem for <mtext> anyway so it isn’t adding a new one; we
do have the question over resetting the scriptlevel as you start new
MathML; I do this for all cases already; adding mtext in a superscript then
having mathML within that leads to the question of what size it should be?

DC: the outer text is a certain size, e.g., 5pt,; you don’t want to
continue that size

FW: It still works to set the font size

NS: fractions might be a little more cramped; you’d lose that

FW: if block has ...

PI: anyone putting math in mtext in a superscript should be responsible for
adjustments

BK: ...

FW: ...

NS: it requires people to do more work rather than having the machinery
sort it all out

MS: Office Math doesn’t allow nested math, unlike TeX

NS: ...

MS: embedding Word Docs in Word Docs works on the desktop but not elsewhere

NS: PROPOSAL: allow foreign objects in all leaves and inside semantics or
annotation-xml

FW: this is in harmony with HTML

DC: agreed, as Fred said; we tightened to mtext in MathML3; we’re loosening
that

FW: In WebKit we forbad nesting on the layout side; but it’s OK on the
parsing side

NS: mglyph acts as a character so that it can also be used with other
characters

FW: the number of children is not restricted in token elements

DC: it’s explicitly the HTML inline content----not block content

SD: but don’t put an HTML table

DC: an inline table is ok; but not a heading

FW: there is something said about the <html> element,

BM: LaTeXML tracks math mode so it doesn’t have a problem; people using tks
can use objects involving SVG and math nested; I give a warning message;
tracking script size is then my own problem in the implementation

ADOPTED: all token elements are allowed assuming this is part of the parser
in HTML5

DC  saying integration points are as in HTML spec would close #102 as well

ADOPTED; do that

=====

ITEM: DOM/IDL relationship #83 -- introduce a MathMLElement? shadow DOM
(brian)?

NS: this is not my expertise

BK: we now have mostly usable element that can be styled;....

NS: changing the name to include MathML?

BK: the IDL specifies what can be displayed to the user from the DOM; it
used to be that everything was just an element; there were no dot-style
properties; certain JavaScript things can’t be done; dataset wasn’t
available; we gained ca. 120 new iterable properties, I think, from what we
did - so that's kind of huge

NS: did you have a stand-alone math elt or what?

BK: there are interfaces and mix-ins that go both directions; I don’t
recollect exactly what Rob did; mix-in, I think; a new thing that wasn’t
implemented in Chrome

FW: there are ..

RB: I added a derived mathml element that can have interaction with global
event handlers; shared some stuff with the HTML/SVG interface; …; pretty
minimal so far, but we can add stuff

FW: only implemented in FireFox

NS; is this a change you can make or is it a big thing?

BK: it is a change to the spec and only we implement it at present;  Chrome
didn’t even have the mix-ins and we could pull that in; shadow DOM is
another consideration now under discussion; but it doesn’t have an impact
on the Web IDL at present; currently there’s only one class exposed, namely
mathml; everything went from an element to a mathml-element; we could add
subclasses

FW: we started with the minimum

NS: could an element like <maction>, say, pick up new handlers?

FW: I don’t know if we want to add too many more actions

BK: this is mostly relevant to possibly allowing every mathml-element to
have a shadow root; it would be easier if we had something to work with
than just talk; but this is brand new;

SD: the access to a special mathml-element type from scripting would be a
huge step forward

BK: access to a shadow DOM could make MathJax or any kind of polyfills
(including the ones we keep talking about here) much simpler for users,
since the DOM does not get shuffled about beneath you

-----

ITEM: Remove mfrac@bevelled? #29
<https://github.com/mathml-refresh/mathml/issues/29>

DC: Unicode fraction works in Firefox and Chrome but not in Edge

NS: people use it to save vertical space; I’m trying to get stats on usage
from Pearson

DC: I wonder if what CSS wants to do for a sloping line isn’t going to
cause more complication than it’s worth

FW: there’s a stretchy glyph for slash; people could use that in an <mrow>

NS: out of time, this matter of beveled fractions is clearly for later

======== From Chat, various snippets from RB

From rwlbuis to Everyone: (02:53 PM)

actual commit:
https://github.com/Igalia/chromium-dev/commit/e0b51fdb6528054df4e55002e1ac5fcaa045e730

From rwlbuis to Everyone: (02:53 PM)

interface

MathMLElement : Element {        [SameObject, PerWorldBindings] readonly
attribute DOMStringMap dataset;        //

CSS Object Model (CSSOM)      //
https://drafts.csswg.org/cssom/#the-elementcssinlinestyle-interface

[SameObject, PutForwards=cssText] readonly attribute CSSStyleDeclaration
style;    };

MathMLElement includes GlobalEventHandlers;

MathMLElement includes DocumentAndElementEventHandlers;

From rwlbuis to Everyone: (02:54 PM)

something like above is in the spec

Spec link for DOM/IDL:

     https://mathml-refresh.github.io/mathml-core/#dom-and-javascript