Minutes MathML Core meeting 1, July

Next meeting is 8 July, same time.

Charles is on vacation, so no recording link this time.
Here are the minutes, with thanks to Patrick Ion for volunteering:


MathML Core Meeting (July 1, 2019)

Attendees:

   -

   BK: Brian Kardell
   -

   FW: Frédéric Wang
   -

   NS: Neil Soifer (Chair)
   -

   DF: David Farmer
   -

   PI: Patrick Ion
   -

   BM: Bruce Miller
   -

   SD: Sam Dooley
   -

   DC: David Carlisle
   -

   RB: Rob Buis
   -

   MS: Murray Sargent



Topic: DOM/IDL relationship #83
<https://github.com/mathml-refresh/mathml/issues/83> -- introduce a
MathMLElement? shadow dom <-- update from Brian and Rob. This is related to
remove mglyph? #25 <https://github.com/mathml-refresh/mathml/issues/25>


RB: I was implementing this a few weeks ago; Brian has experimented with
it; We now allow a shadow DOM in MathML in our chromium builds ….

Mfenced can be seen expanding into the shadow DOM without messing up other
things

NS: Is this breaking rules about using shadow DOM for existing elements or
just an experiment?

BK; Others are trying this sort of thing or at least in conversation about
it; it’s not exceptionally radical since Google is involved in such a thing.

NS: Should we be commenting?

BK: I’ll comment.

NS: I think this is a great idea; do any others think it is a bad idea; how
about reluctance to push this forward as an approach to making polyfills?

DC: seems really good to me …

PI:What are the disadvantages?

NS: Someone might introduce a polyfill that screws up Core by
reimplementing something in core….

BK: That’s why there are restrictions in HTML; showing that we have a
working an experiment apparently supporting opening up may be helpful;
there will be conflicts, but they can be overcome.

Google’s proposal is that HTML Core is done and immutable; the import idea
is the only way to introduce anything new. The idea here is that all
additional MathML would be done via ‘import’; you’d ship extensions with
the browser, but it would be necessary to ‘require’ anything not basic.

NS: Anyone object to BK’s reporting that the MathML WG feels this is a
worthy thing to pursue?

BK: If there are any other polyfills we have to do, I’d be happy to help.

DC: The old Content MathML Javascript stuff could be converted to this way
of doing things.

NS: A bigger job than I want to do personally right now; but later on… What
about mglpyh?

BK: I don’t know

PI: mglyph needs to be a pseudo-character. I’m trying to find out from CSS
how to do this.  There have been proposals, such as SING from Adobe. I
can’t find out what got adopted for gaiji that are used in the CJKV context.

FW: PI seems to want to go back to ‘old-style’ mglyph not adopt the new
from MML3.

NS: The important thing is that you can specify the height and width and
vertical alignment;

FW: You lose with <img> the other font properties, like color, …

DC: I don’t think there’s a point in making mglyph part of core; in MML3 it
is essentially just an image and all else was jettisoned; use is for some
weird character you haven’t got in fonts yet.

NS: It’s an image with the ability to do some alignment; the only issue is
the valign.

FW: All we said is that we give some interpretation of vertical align.

MS: The problem of vertical alignment is already there for images.

FW: mglyph in MML3 is really bad.  Just use custom fonts and that will do.

BK: If you want to do more than an image will then make a font

DC: mglyph’s point was to put an image in; just a name change for image in
a situation independent of HTML say; valign can be tricky.

FW: We still haven’t defined how vertical align or absolute position is
done.

NS: Just align and relative to the baseline.

FW: A baseline in math perhaps, as baseline is not defined in CSS.

NS: Isn’t this really equivalent to voffset in mpadded?

FW: ONE glyph and you can use mpadded to change the offset.

NS: It’s the same as voffset but without that thing’s fancy pseudo-units.

FW: mglyph can be used in token elements; and that would make the
definition more complex; We don’t have to come; PI’s use case didn’t use
the current version.

DC: I’d drop in Core …

NS: Much more usage of elem math than mglyphs

DC: Agree to drop from Core

NS: Get a working polyfill using shadow DOM; but it’s for Full only.

NS: The MathML wg is in favor of this.

BK: Anyone wanting to work with polyfill’s contact me and we’ll make some
time.


BJ: Rob’s work brings in ca. 150 properties and methods that elements did
not have before; all elements are about the same now; we probably need a
few more eyeballs examining this.  If

We can get this now it will be leap forward.

FW: We have several serious new elements; …

BK: tab index that will allow active math elt; accepting focus and blur et
al.;

NS: section 2.1.3 DOM and Javascript there’s a typo; ‘must expose to
script’ needs fixing

FW: yes, …

BK: yes, remove ‘and’, say,

BK/FW: This will be fixed



FW: One consequence is that there are added a whole lot of new properties;
for the implementers this is not an extra problem; I think RB just
introduced …..

RB:There’s a focus method and a blur method already; they just get adopted

DC: We use a lot from the Firefox (FF) implementation whether or not yet
standard;   … some markup is made valid by new arrivals in the JS markup

BK: It’s the global event handlers from HTML.

DC: Should the schema represent it? I must;  the markup side of this as
opposed to the JS side.

FW: Just a matter of editing

RB: SVG does the same thing perhaps.

FW: Only FF has MathML SVG perhaps; Brain, you will handle this discussion
in HTML5

BK: Do we want a mathml-unknown element to be different from a mathml
element

FW: All this group needs to do is decide to go ahead and trust Brian to go
forward

DC/NS/..: a great idea

BM: don’t get too excited; it could be a bit much to expect all browsers
implement this feature given how much other work they need to do.; I’m all
for MathML elements being first-class citizens of the web page.

NS: all that support for event-handlers and so on is essentially for free;
so it is not a worry then

FW: So all elements are HTML unknowns until MathMl is implemented in
Chromium

BK: Big difference is whether or not you can ask shadow-DOM to be supported
or not;   I had the impression the SDOM was not so bad to add

RB: Not so difficult; there are versions 1 and 2 at least but it went OK.

FW: Hopefully the layout tree generated with SDOM is the same. Does mfenced
have its own layout node or just include the subtree from the SDOM?

BK: Is there a test?

FW: Yes, we should be able to do such a thing.

-----


Topic: Discussion about scriptlevel and min font size <-- update from Rob.

RB: I fixed the math scriptlevel problem; then I noted that one can keep
decreasing the font size indefinitely; this has to be related to min font
size; at least FF cuts off at some point; Chromium seems not to do this.

By the way note (as in Chat)

“For every event type that the user agent supports, SVG supports that as an
event attribute, following the same requirements as for event handler
content attributes [HTML]. The event attributes are available on all SVG
elements.”

FW: CSS seems to have dropped the minfontsize property; FF and Chromium
this have different interpretations; that of Chromium is not compatible
with MathML

NS: So we have to rewrite what we said about using CSS’s min font size?

FW: The CSS fontspec doesn’t give  min size so that’s the problem; it’s
their problem.

RB: So you can create the same problem in CSS?

FW: How a browser handles continued diminution is up to it them; FF has a
min size; Chromium is different in how it handles fonts.

NS: If CCS doesn’t support we have possible cross-browser problems in
getting the same rendering.

FW: CSS expect to rely on new CSS functions (later) that would allow
specification of font size

NS: We have say 2 years to move to a recommendation; we need something
about this before then to get to spec.

FW: minsize is not as important as getting the rest of the spec done

Topic: Math constants, etc

NS; We didn’t get that much done but it settled important points; my work
on math constants slipped through the cracks in the last two weeks; I have
suggested default values in process but I will have the description by next
meeting; the values will be derived from common global values

FW If they don’t use math fonts people can’t be expecting high-quality

NS Perhaps not pixel-perfect but people want a lot; I wrote to Dani for his
values for mathType (but he’s no longer with WIRIS so may not have them);
we need other WIRIS persons

FW: WIRIS hasn’t sent anyone new yet.

NS: I have to talk to them about MathPlayer updates, so I’ll ask for
persons for the WG then.


<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>