Rename HTMLOrSVGElement to reflect its wider use in MathML as well

[bkardell]

(updated tests)

Renames relatively recent HTMLOrSVGElement IDL mixin to HTMLOrForeignElement in order to reflect its wider use in MathML as well, which previously was just Element. This is referenced in the new interface defined in MathML-Core and aimed at resolving this historical oddity.

• At least two implementers are interested (and none opposed):

  • new MathMLElement which uses this mixin is shipping in Firefox already
  • new MathMLElement patches landed in webkit on 9/6/2019
  • supportive comments from blink owner in https://github.com/mathml-refresh/mathml/issues/83, upstreaming in https://bugs.chromium.org/p/chromium/issues/detail?id=6606#c89

• Tests are written and can be reviewed and commented upon at:

  • https://wpt.fyi/results/mathml/relations/html5-tree/html-or-foreign-element-interfaces.tentative.html?label=master&label=experimental
  • https://github.com/web-platform-tests/wpt/blob/master/mathml/relations/html5-tree/tabindex-002.html

• Implementation bugs are filed:

  • Chrome: https://bugs.chromium.org/p/chromium/issues/detail?id=835571
  • Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1571487
  • Safari: https://bugs.webkit.org/show_bug.cgi?id=200470

(See WHATWG Working Mode: Changes for more details.)

---

💥 Error: Wattsi server error 💥

PR Preview failed to build. (Last tried on Jan 15, 2021, 8:01 AM UTC).

More

PR Preview relies on a number of web services to run. There seems to be an issue with the following one:

🚨 Wattsi Server - Wattsi Server is the web service used to build the WHATWG HTML spec.

🔗 Related URL

Parsing MDN data...
Parsing...

If you don't have enough information above to solve the error by yourself (or to understand to which web service the error is related to, if any), please file an issue.

[domenic]

Thanks! I think the main issue here is the tests.

• https://wpt.fyi/interop/mathml/relations/html5-tree/clipboard-event-handlers.tentative.html?label=master&label=experimental
• https://wpt.fyi/results/mathml/relations/html5-tree/css-inline-style-interface.tentative.html?label=master&label=experimental
• https://wpt.fyi/results/mathml/relations/html5-tree/math-global-event-handlers.tentative.html?label=master&label=experimental

It's unclear what these have to do with the PR.

• https://wpt.fyi/results/mathml/relations/html5-tree/html-or-foreign-element-interfaces.tentative.html?label=experimental&label=master

This tests dataset, tabIndex, focus, and blur. It does not test autofocus or nonce.

These tests are also not exhaustive of the behaviors involved, but I don't think that's required, unless there exists exhaustive tests for SVG elements and those behaviors that we should try to be at least as good at. Still, at least a test for focus()'s options would be nice.

Also, is there any need to modify https://html.spec.whatwg.org/#dom-tabindex for any MathML elements, or do they all always give -1? Although testing every MathML element doesn't seem necessary, are there any "suspicious" MathML elements that people might naively consider "default focusable", which we should be sure to test are still -1? Compare to https://github.com/web-platform-tests/wpt/blob/master/html/interaction/focus/sequential-focus-navigation-and-the-tabindex-attribute/tabindex-getter.html

[domenic]

Please remove this addition

[fred-wang]

It's unclear what these have to do with the PR.

I guess these tests are for the more general case of adding a MathMLElement IDL (which includes the case of HTMLOrForeignElement).

• https://wpt.fyi/results/mathml/relations/html5-tree/html-or-foreign-element-interfaces.tentative.html?label=experimental&label=master

This tests dataset, tabIndex, focus, and blur. It does not test autofocus or nonce.

Yes, this is what I asked in #4893 (comment) ; @bkardell since you wrote these tests, do you know why autofocus and nonce were not tested?

Additionally, I mentioned these two tests for tabindex on the abandoned PR:
https://w3c-test.org/mathml/relations/html5-tree/tabindex-001.html
https://w3c-test.org/mathml/relations/html5-tree/tabindex-002.html

These tests are also not exhaustive of the behaviors involved, but I don't think that's required, unless there exists exhaustive tests for SVG elements and those behaviors that we should try to be at least as good at. Still, at least a test for focus()'s options would be nice.

I agree it would be nice to have more tests however, I believe that would be asking way too much for just a renaming to HTMLOrForeignElement. Even the important case of tabindex is not tested with SVG last time I checked.

Also, is there any need to modify https://html.spec.whatwg.org/#dom-tabindex for any MathML elements, or do they all always give -1? Although testing every MathML element doesn't seem necessary, are there any "suspicious" MathML elements that people might naively consider "default focusable", which we should be sure to test are still -1? Compare to https://github.com/web-platform-tests/wpt/blob/master/html/interaction/focus/sequential-focus-navigation-and-the-tabindex-attribute/tabindex-getter.html

MathML3 allows an href attribute on any MathML elements which makes them all possibly linkable. There is a discussion to simplify this in MathML Core: https://github.com/mathml-refresh/mathml/issues/125 ; tabindex-002.html only checks mrow@href.

[domenic]

I agree it would be nice to have more tests however, I believe that would be asking way too much for just a renaming to HTMLOrForeignElement.

I disagree. The point of an integration PR is to be sure any integration into the HTML Standard is up to the requirements of the HTML Standard. If the goal is to be a first-class peer of other HTML Standard types, then there needs to be the corresponding amount of work done.

It's true that before the modern WHATWG working mode, some PRs went un-tested. That's not a reason to abandon test discipline on future changes.

[fred-wang]

I disagree. The point of an integration PR is to be sure any integration into the HTML Standard is up to the requirements of the HTML Standard. If the goal is to be a first-class peer of other HTML Standard types, then there needs to be the corresponding amount of work done.

It's true that before the modern WHATWG working mode, some PRs went un-tested. That's not a reason to abandon test discipline on future changes.

@domenic I agree with what you are saying so I believed you overlooked the just a renaming to HTMLOrForeignElement part of my comment. Unless I'm missing something, the renaming alone does not cause any observable change in implementations so there is actually nothing testable and it does not make sense to require tests in the first place. And even forgetting about MathML, the renaming makes sense to do it by itself, since that matches the internal name used by browsers and makes the interface name less specific in case it has to be reused (e.g. Mozilla uses it for XULElement). Now if we send more PRs that actually have an observable change such as introducing MathMLelement with MathMLElement includes HTMLOrForeignElement or tweaking the section related to the default tabindex value, then obviously tests can and must be written for these. I hope that clarifies what I meant.

[domenic]

I did not overlook this. The renaming integration PR is an opportunity to improve the test coverage and hold the line, if we're going to welcome MathMLElement into the same family as HTMLOrSVGElement. If we're not willing to do that, then we should just live with the not-so-suitable name, as a reminder that MathMLElement is not up to the same standards.

[domenic]

Perhaps another way of looking at it is: it seems autofocus, nonce, and the options member of focus() were added to the MathMLElement spec without any tests. This may be acceptable working practice for the MathML working group, but it is not acceptable for the WHATWG. Thus, at the point where the specs intersect in a way that asks for changes to WHATWG standards, we need to ensure that those tests are present. Even if the way that the specs intersect is just in a request for renaming.

[domenic]

Additionally, I mentioned these two tests for tabindex on the abandoned PR:
https://w3c-test.org/mathml/relations/html5-tree/tabindex-001.html

This test seems to reveal that this PR is incomplete, and https://html.spec.whatwg.org/#dom-tabindex also needs modification to add something like "a MathML element with a href attribute", before we could merge this PR.

(Similar to the above comments, I realize that this PR is currently just a renaming, and that the MathML working group has mixed in HTMLOrSVGElement into MathMLElement without updating the appropriate section of the HTML Standard to state how tabIndex behaves on MathML elements. And similarly to the above, we need to do better, now that we are requesting changes to HTML.)

[fred-wang]

@domenic I'm uncomfortable with this approach as that makes the boundary of required tests quite arbitrary, as opposed to focusing on changes in what is actually specified in the WHATWG spec. Anyway, I'm not going to argue any further and with that explanation, I agree that this PR is not ready yet. Thanks for the useful feedback and please try to be a bit less negative in the way you communicate it.

[ExE-Boss]

Please don’t remove trailing new‑lines.

Suggested change

	</html>
	</html>

[bkardell]

This test seems to reveal that this PR is incomplete, and https://html.spec.whatwg.org/#dom-tabindex also needs modification to add something like "a MathML element with a href attribute", before we could merge this PR.

@domenic After some decision making and conversations - proposed spec updates for this added, will be updating tests to reflect here too, assuming this much looks right to you?

[domenic]

Awesome, yeah! Editorially the latest commit looks good to me; do the proposed semantics match existing implementations (or do we have multi-implementer interest in updating to match them)?

[bkardell]

do the proposed semantics match existing implementations (or do we have multi-implementer interest in updating to match them)?

@domenic They have differences - but I believe the answer is yes we have agreement to match: this decision was made in the CG in cooperation with @emilio and double checked back with @rniwa , we're working on chromium - I think that about covers us.

[rniwa]

do the proposed semantics match existing implementations (or do we have multi-implementer interest in updating to match them)?

@domenic They have differences - but I believe the answer is yes we have agreement to match: this decision was made in the CG in cooperation with @emilio and double checked back with @rniwa , we're working on chromium - I think that about covers us.

Generalizing HTMLOrSVGElement to MathML elements seem fine to me since it doesn't post any backwards compatibility concerns.

[rniwa]

@rniwa I was specifically referring to the choice of elements for which tabIndex returns -1.

All mathml elements return -1 for tabIndex unless it's a link (because it has href) in which case it would return tabIndex of 0 in WebKit so this PR is consistent with that behavior.

In general, I'm not too concerned about the focusing behavior within MathML than the rendering behavior since I haven't encountered a content where portions of MathML were interactive, had a hyperlink, etc...

[fred-wang]

All mathml elements return -1 for tabIndex unless it's a link (because it has href) in which case it would return tabIndex of 0 in WebKit so this PR is consistent with that behavior.

This is how it is implemented in Gecko and Chromium too. However, beware that @bkardell's proposal is to make tabIndex == 0 for all potentially linkable elements, not only those that are actually links. Apparently he said that's the case for in SVG and HTML too, but the CG people didn't want to introduce a separate element for MathML.

In general, I'm not too concerned about the focusing behavior within MathML than the rendering behavior since I haven't encountered a content where portions of MathML were interactive, had a hyperlink, etc...

People from the CG said they used links it widely, but not sure they actually had to rely on tabindex behavior, which was only implemented recently.

[rniwa]

All mathml elements return -1 for tabIndex unless it's a link (because it has href) in which case it would return tabIndex of 0 in WebKit so this PR is consistent with that behavior.

This is how it is implemented in Gecko and Chromium too. However, beware that @bkardell's proposal is to make tabIndex == 0 for all potentially linkable elements, not only those that are actually links. Apparently he said that's the case for in SVG and HTML too, but the CG people didn't want to introduce a separate element for MathML.

Oh, that's not good. What's the set of those elements?

[bkardell]

@rniwa

Oh, that's not good. What's the set of those elements?

From the small actual spec edit, based on @domenic's observations and questions above:

or is a MathML hyperlinking element (mi, mo, mn, ms, mtext, or mrow)

Apologies if this feels like I am saying something too basic or something, but I feel like it would be good to state what seem like the important bits here because there seems to have been some confusion in earlier discussions...

This spec edit is about setting what the default .tabIndex reports as, which isn't much of a good indicator of pretty much anything as far as I can tell, really and feels a little obscure: The default .tabIndex of a <p> or a <span> (most elements) is -1, that doesn't make them programatically focusable... it's only part of the equation. The default .tabIndex for linky elements like <a>, <area> or SVG's <a>, is 0 regardless of whether they have a href -- they are neither part of sequential focus or programatically focusable. This is, indeed, how it is in every browser, as illustrated by this hixie live-dom-viewer snippet. That's all we're really talking about here - they wouldn't suddenly become focusable without an [href].

We'd like, ultimately, for advances in the platform to lift all the boats, and this is substantially more difficult where we do something different.

[rniwa]

@rniwa

This spec edit is about setting what the default .tabIndex reports as, which isn't much of a good indicator of pretty much anything as far as I can tell, really and feels a little obscure: The default .tabIndex of a <p> or a <span> (most elements) is -1, that doesn't make them programatically focusable... it's only part of the equation. The default .tabIndex for linky elements like <a>, <area> or SVG's <a>, is 0 regardless of whether they have a href -- they are neither part of sequential focus or programatically focusable. This is, indeed, how it is in every browser, as illustrated by this hixie live-dom-viewer snippet. That's all we're really talking about here - they wouldn't suddenly become focusable without an [href].

It's very misleading to change the semantics of tabIndex in a PR titled "Rename HTMLOrSVGElement to reflect its wider use in MathML as well".

I don't think we should make such focus behavior semantics change in this PR. Please split it into a separate PR.

[ExE-Boss]

@bkardell
This needs rebasing, and you should also put “Fixes #4702” into the PR description.

---

See the relevant article on GitHub Help for details.

[foolip]

I'm keeping an eye on this PR because it's one of the things that need fixing to make the Web IDL of HTML + MathML consistent for https://github.com/w3c/webref, which is used for web-platform-tests and MDN.

@bkardell what still remains to resolve to get this PR merged? It looks like the discussion of focus behavior ended up with the conclusion that focus behavior changes should be done in another PR, so is there anything else still blocking?

[bkardell]

I'm keeping an eye on this PR because it's one of the things that need fixing to make the Web IDL of HTML + MathML consistent for https://github.com/w3c/webref, which is used for web-platform-tests and MDN.

@bkardell what still remains to resolve to get this PR merged? It looks like the discussion of focus behavior ended up with the conclusion that focus behavior changes should be done in another PR, so is there anything else still blocking?

It's really linking and relationship to tabIndex that's held it up. When figuring out what we needed to create here, @domenic had specifically asked about updating the default tabIndex parts, and that's a little dicey - we punted figuring that out in MathML-Core "level 1". MathML was one of the "any element can have an href" specs, like SVG - but this is full of problems for many reasons which have been discussed before, but also including perhaps more things now - like MathML's ability to potentially eventually integrate and move forward with ideas like custom elements or shadow DOM. It's a big topic, I guess, and we decided to wait for the formation of the (now formed) working group and other progress because the truth is "we're not 100% sure what we want to specify on that".

I would be happy to remove the .tabIndex related changes from this PR and we could create a new issue to specify them? If you have suggestions, I would very much welcome direction.