Document.domain SETTER is deprecated

[hamishwillee]

The Document.domain setter is deprecated, as indicated in MDN docs and the specs:

There is no way to mark just the setter deprecated, and I don't know how I might add a note to clarify this. So I have marked the whole item as deprecated. This PR is therefore obviously "for discussion."

This came out of #10224

[foolip]

I'm skeptical about deprecating in BCD if this might lead to tooling warning against using this API, even if it's only read and not set. I'm not actually aware of any JS lint tooling that uses BCD, but it's something that could be built.

Maybe noting this in MDN is sufficient?

[hamishwillee]

It would be "better" if it can be somehow recorded in BCD because it should be the canonical source of true on compatibility issues. Where I'd like to see it is as a note on deprecation or even at the "support" level.

If that is not something that you want to support then I'd agree having it just on MDN is probably better than stating the "whole" use of the API is deprecated.

Really I just created this so the BCD team can tell me the right way to handle this :-)

[foolip]

I will leave it to @ddbeck to give a more authoritative opinion :)

When the scope of an API has been reduced in the standard I think it's not super useful to point out the previously bigger shape of the API, because it's impossible to write code that works in current browsers which doesn't work in older browsers. A part of the API that doesn't exist anymore, and if it were a separate entry would be removed from BCD as irrelevant.

The other way around is more important to capture, where there are ways of using the API that won't work in slightly older browsers which are still in use.

[ddbeck]

I must be a glass-half-full person because if half of something is deprecated…

OK, two major things here. First, the theoretical bit. BCD should be the canonical place to record relevant compatibility data, that is true. But the extent to which we record status information is in service to understanding the compatibility data we have. If a feature is supported in some browsers but not others, you kinda need the context provided by the statuses to understand what that means, whether a feature is emerging (or failing to), inert, or going away.

As a practical matter, we've got the problem of only half the behavior represented by the feature being deprecated. If we were serious about showing the deprecation status, we'd create getter and setter subfeatures and set their deprecation status accordingly. But I don't think we should do that, at least not yet. As far as I can tell, the only difference between support for the setter and getter is the deprecation status; no browser has actually started the process of withdrawing support for the setter. Which is to say, there's no actual compatibility story to tell here, just a spec author's aspiration.

Perhaps someday, the spec will be revised to make domain read-only and a browser will actually introduce some different behavior. When that day comes, we'll have a concrete divergence in behavior between browsers to talk about, at which point the deprecation status will be relevant again. It will be way more specific and actionable and much clearer about what we're supposed with the data at that point.

So I'm in favor of deferring this, at least. Does that make sense?

[foolip]

That makes perfect sense. I didn't do any digging and assumed the setter had actually been removed from all browsers, when the opposite is true :)

[hamishwillee]

Thanks guys, that all makes perfect sense.