Consider renaming HTMLOrSVGElement to HTMLOrForeignElement
#4702
Comments
ExE-Boss
changed the title
HTMLOrSVGElement to HTMLOrForeignElement
annevk
added
addition/proposal
|
. I'm very happy to send a pull request changing one word, but which word seems to be the question... I think that several of us agree that HTMLOrForeignElement seems ok, as does simply WebElement. The latter was independently offered by several people and a very unscientific and small Twitter poll seems to indicate that it's more intuitive as a name too.. I kind of prefer the former I think, but.. Thoughts? Opinions? Concerns? |
|
What's the problem with being specific (and adding |
|
I'd like to step back and make sure we have multi-browser buy in for mixing this in to MathML elements before renaming anything. |
|
@annevk In theory, nothing at all. In practice, i suppose just that it really forces the question of who may use the mixin without it being weird. Our chromium build and the spec are currently using an interface which implies it isn't useable by MathML, in theory or practice - but it seems fine in both. @domenic yeah, that would be good because this is mostly just de-weirding DOM... although as I said just above, there seems to me a slight difference between simply choosing a name that leaves open the possibility (before people go and plug it in too - I think as of a week or two ago, only 1 browser had used this mixin), and actually accepting a particular proposal with said interface. idk, maybe that is not as practically important a distinction as I imagine - I'll ask around. |
|
There's no observable (testable) difference created by the name, so I think it's fine for the MathML spec to reference an awkward name while it's still in an not-multi-implementer-interest state. |
|
Regarding multi-vendor interest, is it really not the case? Regardless of priorities (MathML is not a priority in Firefox as far as I can tell, and seems like the state in WebKit is similar too), it does have multiple implementations and interest from the other engine that doesn't have it, right? Anyhow whatever the name is I think this makes sense: not having .style in mathml stuff, for example, is a silly problem, specially since mathml does support the style attribute. It is something I've had to work around when writing tests. |
|
I don't know the implementer interest (ideally of the form "we would like to add this soon", per the working mode), or implementation status, for adding the elements of this mixin to MathMLElement. Any on-record statements, or links to passing web platform tests, would be great. |
Implement the interface mixin between HTML/SVG/etc as specified here: https://html.spec.whatwg.org/multipage/dom.html#htmlorsvgelement Note that the intention is to rename above HTMLOrSVGElement to HTMLOrForeignElement: whatwg/html#4702 This also removes NoncedElement. Matches WebKit and Firefox. Bug: 835571 Change-Id: I98c7fcf4c081bdee1a861138e03155a77ca37161 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1655789 Commit-Queue: Rob Buis <[email protected]> Reviewed-by: Frédéric Wang <[email protected]> Reviewed-by: Fredrik Söderquist <[email protected]> Cr-Commit-Position: refs/heads/master@{#691580}
|
HTMLOrForeignElement has now been added to chromium and WebKit. |
|
Was it just a renaming (no normative changes to the spec needed), or did Chromium and WebKit actually change anything that tests can detect? |
|
Right now, it’s just the rename but the plan is to add the support for FWIW, as I noted elsewhere renaming it to |
|
Yep, once there's actual multi-implementer movement on normative changes that the rename would support, we should definitely do the rename. |
|
Well, both WebKit and Chromium have now implemented this, and Firefox will be implementing this in bug 1577660. |
|
I'll reemphasize the "normative change" part of my comment. |
HTMLOrForeignElement has been added to Gecko too. |
|
Note that https://trac.webkit.org/changeset/249572 added the support for tabIndex & global event handlers to WebKit and it constitutes normative behavioral changes. |
Right, it also adds support for style IDL attribute via ElementCSSInlineStyle, which Emilio mentioned in #4702 (comment) as something we want for Mozilla's test automation ( https://bugzilla.mozilla.org/show_bug.cgi?id=1530110 ). As Brian mentioned, there is also https://bugzilla.mozilla.org/show_bug.cgi?id=1571487 in Mozilla which is pending https://github.com/mathml-refresh/mathml/issues/83#issuecomment-529135238 before being sent for review & announced on mozilla's mailing list. But yes, there is already "multi-implementer movement on normative changes that the rename would support". |
|
Great. At this point then a pull request that implements those normative changes to the spec should go through the normal WHATWG process (which the pull request template can help you with). |
|
@fred-wang @domenic - what would it take to move this forward? It's currently blocking adding the mathml IDL to wpt, and it would be nice to resolve that. |
|
@stephenmcgruer Well, there’s #5248, but that currently has merge conflicts. |
|
What's missing here is tests: #5248 (comment) |
|
Is renaming an Because I’m pretty sure that WebIDL doesn’t make |
|
Please read the linked discussion. |
See https://github.com/mathml-refresh/mathml/issues/83#issuecomment-501643288 for details.
The text was updated successfully, but these errors were encountered: