Re: Minutes MathML Core meeting 1, July

Slight correction, maybe even to what I said. Google's proposals (still
early) is that the core of HTML is 'mostly done' and that 'most things'
would be added this way.  There are things that add 'new magic' to the
platform and those would have to be part of the core of HTML, but those are
very rare.  <template> for example is not really a thing that you can do
this way, that's new magic in HTML itself.  Those are also pretty pricey in
the long term though and complex, so, rare.



On Tue, Jul 2, 2019 at 2:57 PM Neil Soiffer <soiffer@alum.mit.edu> wrote:

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


-- 
Brian Kardell :: @briankardell :: bkardell.com