Element interfaces across browsers

[domenic]

In https://www.w3.org/Bugs/Public/show_bug.cgi?id=27877 @bzbarsky brought up that element interfaces are not greatly defined in the current spec. In #1012 we are trying to nail them down better, but I am sticking to basically what the current spec says. There are a couple notable instances where browsers deviate from the more-precise version in #1012.

For clarity, #1012 includes:

1. If name is bgsound, blink, isindex, multicol, nextid, or spacer, return HTMLUnknownElement.
2. If name is acronym, basefont, big, center, listing, nobr, noembed, noframes, plaintext, rb, rtc, strike, tt, or xmp, return HTMLElement.
3. Otherwise, if this specification defines an interface appropriate for the element type corresponding to the local name name, return that interface.
4. If other applicable specifications define an appropriate interface for name, return the interface they define.
5. If name is a valid custom element name, return HTMLElement.
6. Return HTMLUnknownElement.

It is these first two steps I want to focus on.

With the help of https://jsbin.com/liticisino/edit?html,console, which goes through all elements listed as "obsolete" in the spec, and tests across Chrome, Firefox, and Edge, I have noted the following issues:

Element(s)	Spec	Chrome	Firefox	Edge	Safari
applet	HTMLAppletElement	HTMLUnknownElement	HTMLAppletElement	HTMLAppletElement	HTMLAppletElement
xmp, listing	HTMLElement	HTMLPreElement	HTMLElement	HTMLPreElement	HTMLPreElement
blink	HTMLUnknownElement	HTMLUnknownElement	HTMLUnknownElement	HTMLElement	HTMLUnknownElement
rb, rtc	HTMLElement	HTMLElement	HTMLElement	HTMLUnknownElement	HTMLElement
marquee	HTMLMarqueeElement	HTMLMarqueeElement	HTMLDivElement	HTMLMarqueeElement	HTMLMarqueeElement
basefont	HTMLElement	HTMLElement	HTMLElement	HTMLBaseFontElement	HTMLBaseFontElement

These all seem like browser bugs except applet (#454) and maaaybe xmp/listing. It would be good to fill in the Safari parts of the table though, and to see what implementers think. /cc @DigiTec who I know has been looking into this somewhat recently.

[bzbarsky]

I filled in the Safari bits, for Safari 9. Safari tech preview will apparently not run on my OS version, and WebKit nightly is hanging on startup for me....

[DigiTec]

@travisleithead to make sure we have appropriate tracking bugs. We now have an open bug tracker so it might be interesting to file one for each infraction there.

[domenic]

I think we need to decide what to do with xmp and listing. Does anyone have strong opinions? I think it would be mildly more annoying to specify HTMLPreElement than HTMLElement, but that's not a great reason.

[bzbarsky]

Does setting .width on <xmp> and <listing> actually do anything in the UAs that have them be an HTMLPreElement?

[domenic]

It sets the width content attribute. Which itself has no effect in any browser, it seems. https://jsbin.com/gosuga/edit?html,console,output

[tabatkins]

And <xmp> isn't pre-like in any significant way. In particular, it doesn't have the automatic strip-first-character-if-it's-a-newline behavior, and is not styled with whitespace:pre by default.

The only similarity is that, semantically, both are often used to mark up examples.

[zcorpan]

xmp and listing actually have the same default rendering as pre.

HTML also has this:

User agents must treat xmp elements in a manner equivalent to pre elements in terms of semantics and for purposes of rendering. (The parser has special behaviour for this element though.)

(And same for listing.) This is supposed to mean that ATs should act the same way for xmp as for pre, IIRC.

So I think xmp and listing are pre-like. Also note that pre itself doesn't do anything with the width content attribute. It doesn't affect rendering. I don't mind which way we go here, but I think it's not unreasonable to use HTMLPreElement for these.

[tabatkins]

xmp and listing actually have the same default rendering as pre.

What the heck, I swear I messed around with xmp a few years ago and it wasn't white-space: pre by default. >_<

[domenic]

Nobody seems to have strong opinions on this, so I am going to submit a pull request to change xmp and listing to use HTMLPreElement, following all engines except Gecko. Please speak up if you object; I'm happy to change course.

[bzbarsky]

OK. But plaintext is still HTMLElement, so https://github.com/w3c/web-platform-tests/blob/03f3a3f/html/dom/interfaces.html#L3282 is wrong, yes?

[domenic]

Yes; I believe @zcorpan is trying to address that in web-platform-tests/wpt#2883, but I am not confident I know how to read that test format.

[bzbarsky]

Ah, excellent. https://bugzilla.mozilla.org/show_bug.cgi?id=1266851 is tracking this change on the Gecko side.