Properly define DOM/IDL relationships

[bkardell]

Currently MathML doesn't define DOM/IDL things consistently with other spec areas of the platform, as such this leaves things under defined and MathML seems to be the one place that you can write markup and wind up with an Element (see
https://codepen.io/bkardell/pen/EMJqYz which reports Element as the constructor for me in FF, Chrome and Safari)

The downside of this is that it also winds up working considerably differently in important ways, making it harder to test, polyfill well, extend, or even just generally reason about. Effectively, it is currently 'outside the norm' of the platform currently.

To correct this and fit with the rest of the platform, we need to create some things. I've discussed briefly with some others and basically, the idea would be define a MathMLElement interface akin to SVGElement and then in HTML itself another like HTMLOrSVGElement which will probably have an unfortunately long name like HTMLOrSVGOrMathElement, but, first thing first - we should start with beginning to specify a MathMLElement and opening linked issues in HTML/CSSOM linking to those which give us access to things like .style, custom properties and so on and begin those conversations.

[davidcarlisle]

Yes, MathML2 did specify a DOM

https://www.w3.org/TR/2001/REC-MathML2-20010221/appendixd.html

But the feedback we had at the time was that it wasn't really being used anywhere and maintaining it in sync with changes planned for mathml3 was tricky so it was dropped from MathML3.

But I mention it as (perhaps) parts of that can be salvaged to help specify DOM/IDL declarations for mathml core. (Or perhaps it's not helpful and starting with a clean slate might be better?)

[bkardell]

Interesting, thanks for the pointer @davidcarlisle. That is kind of ... complex and also pretty different. It seems to me like starting with a clean slate and comparatively small interface that just puts it squarely in the same kind of general platform state would be better (SVGs is not huge, for example), but I am new here so I will lean on others for some advice/thoughts if you think otherwise.

[davidcarlisle]

@bkardell I thought you might say that:-)

No objection here, I just thought that there should be a link to that for the record. It is of course mostly large because it includes content mathml elements which you would not want in mathml core anyway, but also it's not surprising if the style of that interface description (mostly done around 1999) doesn't match the current specification style

[fred-wang]

I agree with Brian. The DOM/IDL we had in MathML 2 was really for MathML-specific stuff which was arguably not really useful and more work/code for implementers. I remember [1] from Mozilla.

However, the idea here would be to have a generic MathMLElement interface for MathML elements that derives from some common HTML/SVG/StyleElement/whatever interfaces so that we can share with them the features users are familiar with. Hence this aligns with our goal to make MathML more aligned with the rest of the web platform. For example @emilio recently reported an issue with Gecko/Marionette that makes one WPT test failing just because MathML element don't have the "style" property [2].

[1] https://groups.google.com/d/msg/mozilla.dev.tech.mathml/_T597837K08/e_NI5-j55aYJ
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1530110#c0

[annevk]

I'd suggest starting out with an empty MathMLElement that extends Element. And then change HTMLOrSVGElement to HTMLOrSVGOrMathMLElement or some such. And then shepherd everyone to use that mixin for features shared by all elements across these three languages that ought to have been one.

[bkardell]

talking to @bfgeek and we were wondering if maybe because of the unique place this sits it would actually be fine and path of least resistance to just make it HTMLElement?

[annevk]

I don't think so, that would complicate custom elements quite a bit and likely violates assumptions that HTMLElement implies a particular namespace (which it has done thus far).

[fred-wang]

I don't think so, that would complicate custom elements quite a bit and likely violates assumptions that HTMLElement implies a particular namespace (which it has done thus far).

I was talking to @bkardell yesterday, and raised exactly the same concerns as anne. Also from the implementation point of view, it could be weird/tricky to have MathMLElement C++ classes that don't derive from HTMLElement C++ classes but MathMLElement IDL interfaces that derives from HTMLElement IDL interfaces. So basically things could be less clean with that approach.

On the other hand, I see that making MathML elements derive from HTMLElement is enough if we don't care about MathML-specific DOM stuff (this would need to be discussed with the MathML CG of course), could be less spec changes and less implementation work. This is just a guess, I haven't actually tried to check the details.

[davidcarlisle]

@fred-wang wrote

On the other hand, I see that making MathML elements derive from HTMLElement is enough if we don't care about MathML-specific DOM stuff (this would need to be discussed with the MathML CG of course)

I can't speak for the group but speaking personally I've always been favour of mathml (and svg) in html being as much like html as possible, especially in relation to javascript/dom access. Whether that is by the mathml elements being declared as HTMLElement or declared as MathMLElement which derives from HTMLElement or whether it is just by defining MathMLElement so that it has effectively many of the same properties as HTMLElement is something I think those of you closer to the implementations should decide whichever fits best with the architecture, and then the math [WC]G should specify whatever you need...

[bkardell]

Alright, I honestly expected as much tbh but it seemed like worth asking when @bfgeek brought it up because it seems like a fair observation that it is probably mostly sort of a book keeping marker in practice in this particularly unique case.

So... realistically @annevk I think that HTMLOrSVGOrMathElement is going to be pretty much exactly what HTMLOrSVGElement is today probably, right? The two should really have the same intersection as far as I can imagine.

[annevk]

Ideally we rename the latter.

[fred-wang]

@bkardell @annevk: @rwlbuis investigated a bit the status in chromium and apparently HTMLOrSVGElement is only implemented in Gecko. So maybe it would make sense to directly rename it HTMLOrSVGOrMathMLElement and implement it everywhere.

Rob has a WIP patch here: https://chromium-review.googlesource.com/c/chromium/src/+/1655789

[fred-wang]

I wonder if we should just call it HTMLOrForeignElement to re-use the terminology of the HTML spec, make it a bit more shorter.

[fred-wang]

@bkardell I wrote a first draft for discussion: https://mathml-refresh.github.io/mathml-core/#dom-mathmlelement

[fred-wang]

@NSoiffer I fixed the typo, copying https://html.spec.whatwg.org/multipage/dom.html#elements-in-the-dom

@rwlbuis where did you find the quotation from the SVG spec regarding reflected attributes?

[dbaron]

It seems reasonable to me to have at least many of the things that are on all HTMLElements apply to SVG and MathML elements as well (probably really to all elements that are used for markup rather than data... which I almost think should just be Element). Thought from a Mozilla implementation perspective @bzbarsky could probably comment more authoritatively than I can.

[bzbarsky]

In implementation terms, pushing things up to Element is almost simpler than having copies of them live on multiple Element subclasses. But either one is not too bad to implement, really.

[slightlyoff]

@bkardell brought this thread to my attention, and while I don't have much to add on the naming question, would like to note my general support for the meta project of breaking up the various behaviors of elements (both abstract and concrete) into mixins that developers can mix into their own custom elements to get the built-in behaviors "for free". The details of how we do this matter a lot, but having the MathML and SVG integrations lead the way can help us plan a path for how to do this for the gnarliest cases (e.g. the magic bound up in HTMLInputElement).

[bkardell]

The current spec IDL says

[Exposed=Window]
interface MathMLElement : Element { };
MathMLElement includes GlobalEventHandlers;
MathMLElement includes DocumentAndElementEventHandlers;
MathMLElement includes HTMLOrSVGElement; // Rename to HTMLOrForeignElement?
MathMLElement includes ElementCSSInlineStyle;

@bzbarsky and @dbaron are you saying the stuff that is defined in HTMLOrSVGElement today would perhaps just move up to Element? More than just that stuff? Less than that? It seems only about a year ago that we did work to move some things into this mixin in whatwg/html#3543 ... I'm happy to create some WPT that test the effects, but I'm unsure what is the specific thing to point to to say why or what PR would ultimately be less confusing or problematic.

@slightlyoff I basically like the idea of mixing in stuff, but in this issue - I don't think we care specifically how these elements get 'unweirded' as much as that no element in HTML should be 'lesser' in basic ways like this. It is currently 'less' than HTMLUnknownElement, which feels wrong. I'm unsure the pros and cons of Element vs the mixin here, I assume there were good reasons for the latter though.

[fred-wang]

HTMLOrForeignElement has now been added to chromium and WebKit.

It is in Mozilla too.

[fred-wang]

Feedback after trying to implement this from Gecko:

• We need to explicitly list the DOM attributes: Add more global attributes from HTML mathml#118
• More spec details & tests is needed for tabIndex (especially with MathML links) tabIndex attribute mathml#131
• There is a mistake in the clipboard test: MathML clipboard events: Set the [event]Happened variables on the win… web-platform-tests/wpt#18917
• We need more tests for on[event] attributes: Check that the event listener is properly updated when they are attached/removed/modified or when the element node is cloned.

[fred-wang]

Regarding custom elements in non-HTML namespaces ( WICG/webcomponents#634 ), it is interesting to note that Gecko already has some support for custom elements in the XUL namespace.

[ExE-Boss]

Actually, Gecko has full support for custom XUL elements.

[fred-wang]

I've done the remaining work to add content attribute, indicate that they are reflected by the IDL ones and also rename HTMLOrSVGElement to HTMLOrForeignElement:

c2d770c

We also already have several tests for that, but we can still add more.

@bkardell I believe the remaining work is to move this to the HTML and CSSOM spec, I added some annotations so that we don't forget: https://mathml-refresh.github.io/mathml-core/#dom-and-javascript

[fred-wang]

@bkardell: Well, another thing we could do (not sure if we really want that, but maybe there is a consistency/completeness argument here) is to add IDL attributes to reflect the remaining MathML global attributes:

dir
displaystyle
href
mathbackground
mathcolor
mathsize
mathvariant
scriptlevel

https://mathml-refresh.github.io/mathml-core/#global-attributes

[NSoiffer]

Discussed at Aug 17 meeting:
NS: What’s going on with this. Is it resolved wrt to MathML?
BK: The problem is we are referring to something that doesn’t exist (it's called HTMLOrSVGElement in HTML spec).
Consensus: remove ‘needs resolution’. Make sure ‘needs spec change’ is still there.
Note: Brian will go back through 21, 94 and 152 (and look for others) to make sure that decisions about links are not included and they are marked as Level 2

[fred-wang]

@bkardell IIRC, Domenic was still asking missing DOM tests on the WHATWG PR. Does removing href and related link stuff from core level 1 address this concern about tests?

(BTW I think href WPT tests will need to be renamed to "tentative" tests)

[davidcarlisle]

Interoperable version (MathMLElement) is deployed in all major browsers, name not so important.
other issues may be opened in new issues for level 2