Add [Historical] extended attribute

[saschanaz]

Closes #910

This intentionally applies it to member constructs rather than interfaces to keep it simple.

---

Preview | Diff

[annevk]

Somewhat confusingly we also use the term historical in web-platform-tests to test for non-support of obsolete features. (And HTML uses obsolete to mean obsolete for web developers, but not fur user agents.)

Suffice to say it's all a bit of a mess, but I'd like us to agree on a way forward. Are we going to use historical for discouraged features that stick around? (And name new non-support tests differently?)

[annevk]

a historical reason

[annevk]

Generally we keep web lowercase as per https://whatwg.org/style-guide (unless it's part of a title or some such) though it seems IDL is somewhat inconsistent on this.

[saschanaz]

Yes, quite a lot Web are in this spec, probably time to fix them.

[annevk]

I actually don't think it's worth the effort of removing these APIs. They are not harmful and removing them might break the end user experience on sites, causing frustration for most parties involved.

[saschanaz]

I added this as I thought Gecko already had use counters for them but it seems not. I'm okay without this.

[domenic]

I remain -1 on this. Comments are the appropriate way to add information which does not impact bindings generation.

[saschanaz]

Comments are the appropriate way to add information

If only humans are reading them, yes. If any machines want to detect such things then I think a machine-readable way is more preferable. Call it MDN, TypeScript-DOM-lib-generator, or whatever.

[domenic]

I think those machines are better off using a different source of data, so Web IDL can stay focused as a language designed for web browser and spec bindings generators.

[saschanaz]

Maybe yes if people were not already mixing it into IDL as comments, unlike HTML events. My opinion is, why a different source when IDL already includes the info?

Looking at real world IDLs I can see some major use cases for comments inside IDL (locally searched // inside here):

1. Sectioning (e.g. Logging/Counting/etc. in Console)
2. Marking as historical
3. Showing default value for attributes (e.g. in HTML Canvas) - Maybe also something to discuss, but not totally sure
4. Others (proses)

Which shows it's not a rare convention.

[domenic]

My opinion is, why a different source when IDL already includes the info?

I understand that's your opinion. Mine is the opposite. The ad-hoc, per-editor usage of commenting out things that that particular editor feels are historical, should not be enshrined into IDL. It's just a comment from the editor to the reader explaining something interesting, like "why are there three attributes that do the same thing". It's not a reliable source of data for historical-ness.

Instead, different sources should use their own judgment to collate their own lists of historical things.

[saschanaz]

It's just a comment from the editor to the reader explaining something interesting, like "why are there three attributes that do the same thing". It's not a reliable source of data for historical-ness.

Probably because there is no real web-platform-wide definition of being historical. Maybe a chance to define it here if that's the case, as it might help removing some potentially confusing comments. (I don't have any specific examples, could you provide one?)

[domenic]

I don't think settling on a platform-wide definition of historical is possible. Different people will consider different things historical. For example, I would consider appendChild() historical; append() is much better. Going and marking everything that I consider as historical as such, and then debating that with other stakeholders, is not a good use of anyone's time. It's not what specs are for.

Instead, if MDN wants to mark things as historical, it can do so independently, using the MDN decision makers' judgment.

[saschanaz]

The definition can start with an intersection of what people thinks to prevent needless debates. I don't think it has to cover everything, if it can cover HTML/DOM cases that already marked as obsolete/historical, that should already be a good start.

If we can never get a consensus then I think we shouldn't have an "obsolete" section in HTML, because well, does everyone in every browser vendor really thinks they are obsolete? (If the answer is yes then we have a consensus.)

[domenic]

At this point it feels like we are going in circles, so I'll stop repeating myself. I think I've made it clear though, that bringing this level of "social information" into a bindings-generator language is not appropriate, in my view.

[saschanaz]

Are we going to use historical for discouraged features that stick around? (And name new non-support tests differently?)

Or maybe just [Discouraged].

[saschanaz]

My use case is covered by BCD so I have no interest anymore.