Can we remove the HTMLTableDataCellElement/HTMLTableHeaderCellElement fiction?

[bzbarsky]

UAs just have HTMLTableCellElement.

[domenic]

I thought we did this as part of removing table sorting. Yes, we should fix this.

[annevk]

We discussed that as part of that, but decided not to since it would be more complicated than just removing table sorting. E.g., if we want to keep the current conformance requirements, we cannot really make this change, since td and th both have distinct obsolete members at the moment.

[bzbarsky]

Do browsers have those distinct obsolete members?

[domenic]

I think @annevk is saying that it will just take a bit of work to spec since we'll want to say something like "This attribute only has meaning for th elements" with regard to the abbr and scope IDL attributes. It shouldn't be very hard. I'll work on it now.

[bzbarsky]

Ah, I see. I guess Gecko reflects abbr and scope as strings (on both th and td) but does absolutely nothing else with them. Haven't checked other impls.

[bzbarsky]

Need to update WPT too.

[domenic]

Filed web-platform-tests/wpt#2908 to track that.

[cdumez]

FYI, we had implemented this in WebKit:
https://bugs.webkit.org/show_bug.cgi?id=148859

I think IE had this as well but I am not 100% sure.

Anyway, I am now rolling out the change via:
https://bugs.webkit.org/show_bug.cgi?id=159518

Next time, I'll wait for Firefox and Chrome to follow the spec before implementing :/

[domenic]

Oh my goodness, we're so sorry! We'll try to be better about testing in nightlies and giving everyone a heads-up in the future :(. This should not happen again.

[cdumez]

It is a good thing you guys updated the web-platform-tests so we noticed the change before actually shipping HTMLTableDataCellElement / HTMLTableHeaderCellElement.

[cdumez]

In the future, checking Safari Technology Preview [1], rather than shipping Safari would be nice. We have been making an effort aligning our implementation with the spec.

[1] https://developer.apple.com/safari/technology-preview/

[domenic]

Yep. I specifically ordered a Mac for testing Safari Tech Preview after opening a couple conformance bugs and learning they were fixed. It is sitting on my desk. That's part of why I'm more confident we won't let this kind of thing happen again.

It's also a lesson to us to make a greater effort to get sign-off from all implementers, even on changes that seem like they're just aligning with reality. It's already risky enough for implementers to go first in implementing something; we should not be making it more risky in this way. Being willing to go first should be celebrated, not punished.

[bzbarsky]

Unfortunately, Safari Technology Preview requires the most recent Mac OS version, which not everyone may have available. Amusingly, WebKit nightlies are less strict about that.

For the rest, I agree that people making changes first should not be punished, having been in that position myself. But I also think implementors should be very wary of making changes that move from "everyone is interoperable" to "now we follow the spec and are no longer doing the same thing as everyone else". In particular, there's a very good chance that a spec that is not matching something that every implementation does is just wrong.

[bzbarsky]

Oh, and I guess my point was that implementors should actually talk to each other about making such breaking changes. Chrome and Firefox both have public intent-to-implement/intent-to-ship processes that allow other implementors and spec editors to have an idea of what's going on and have a built-in "what do other UAs do?" sanity-check step. I wish other implementors would adopt something similar...

[cdumez]

FYI, WebKit nightlies still exist as well if your system does not support Safari Technology preview.

Also, the reason we made the change in WebKit was because I believe IE/Edge already had implemented it (At least this is what my changelog says). So not everyone was interoperable unless I incorrectly tested IE / Edge at the time.

[domenic]

I've just tested Edge, and it's true: they implemented this. We should have caught that as well.

Given that, with Edge + Safari TP on one side vs. Chrome and Firefox on the other, should we revert the removal? I think the separate classes is a better model...

[rniwa]

FYI, W3C version has these two classes separate: https://w3c.github.io/html/tabular-data.html#the-th-element

[domenic]

Yes, they haven't managed to copy over this change yet, although it's in their list

[rniwa]

I think we should revert the change and keep two classes separate given abbr and scope behave differently on td and th.

[domenic]

@rniwa how do they behave differently in WebKit? In Blink they behave the same (reflecting the content attribute).

I'm happy to revert, although I'd prefer to hear from @bzbarsky before doing so.

[cdumez]

In WebKit, th.scope only returns known values while td.scope does simple reflection.

[bzbarsky]

I don't have a strong opinion on this. I had been told that in IE these used the same interface, but if Edge is not matching IE here, I guess I don't feel too strongly about changing the behavior.

I should note that the behavior of scope/abbr in the spec still does not match the WebKit implementation described above, so the spec needed some sort of change here no matter what...

[cdumez]

@bzbarsky: Well, iirc the spec has scope / abbr on HTMLTableHeaderCellElement but not on HTMLTableDataCellElement. We merely had them on both in WebKit for backward compatibility.

[cdumez]

@bzbarsky: As far as I can tell, our implementation of th.scope / th.abbr matched the spec:

• The scope IDL attribute must reflect the content attribute of the same name, limited to only known values.
• The abbr IDL attribute must reflect the content attribute of the same name.

The only difference was that we had them on td as well for backward compatibility, unless I am missing something?

[bzbarsky]

@cdumez The point is, the spec needs to have them on whatever it is <td> ends up as, since all UAs do. Unless you have data that this is not needed for web compat?

[cdumez]

@bzbarsky: I see. I agree with you then. And no, I have have data saying they not needed on td for web-compatibility, which is why I kept them on td in WebKit.

[domenic]

This gets worse and worse. Edge has scope on TableCell (the base class) and TableHeaderCell (th) but not on TableDataCell (td). It has abbr on the base class but not on the two derived classes.

Test at http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=4306

So we have four mutually-incompatible models here:

• The current spec/Chrome/Firefox
• The old spec (scope and abbr only on th)
• Safari (scope and abbr only on th and td, not on TableCell)
• Edge (scope on TableCell and th, abbr on TableCell)

With this in mind two proposals make sense to me:

• Go with the only two browsers who agree: Chrome and Firefox
• Go with Safari's model, with scope and abbr on td being relegated to the appendix full of obsolete APIs

Given that every browser has scope and abbr on tds either directly or indirectly, I don't think we should try to go down the route of the old spec and remove them from there.

[cdumez]

I personally don't mind going with the Firefox / Chrome behavior at this point given that:

1. This is also Safari 9 behavior
2. The new WebKit behavior has not shipped in Safari yet.
3. I have a patch ready to land to restore the old behavior in WebKit which would mean Safari / Chrome and Firefox would all stay aligned.

[domenic]

OK. I think we should probably do that then, although this still stands out as a particularly bad oversight by us spec editors.

You aren't planning to implement XMLDocument.prototype.load, are you? :) #1478

[cdumez]

Ok, WebKit agrees with the spec again: http://trac.webkit.org/changeset/202937.

[zcorpan]

The old spec (scope and abbr only on th)

The old spec had abbr on td as well. (In the obsolete section.)

https://github.com/whatwg/html/pull/1125/files#diff-36cd38f49b9afa08222c0dc9ebfe35ebL113151