Consider renaming `HTMLOrSVGElement` to `HTMLOrForeignElement`

[ExE-Boss]

See https://github.com/mathml-refresh/mathml/issues/83#issuecomment-501643288 for details.

[bkardell]

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

[annevk]

What's the problem with being specific (and adding orMathML)?

[domenic]

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.

[bkardell]

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

[domenic]

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.

[emilio]

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.

[domenic]

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.