Oh, heh, that spec exception list change triggers a code owner review. I didn't thought about that before but it makes sense :)

I would disagree that https://w3c.github.io/setImmediate/ isn't a real spec, it's as good a spec as most in my reading.

It's not being maintained and this feature isn't going anywhere, but why shouldn't we link to the spec that defines it? It can be removed when the entry itself is eventually removed as irrelevant.

@foolip Can you raise your concerns in w3c/browser-specs#306? I'm trying w3c/browser-specs to be the place where the judgement calls are made. The project also defined criteria: https://github.com/w3c/browser-specs#spec-selection-criteria

@Elchi3 I've commented over there. I think it boils down to the audience of browser-specs so far being browser vendors, and the audience of BCD being web developers with a 2 year rule for irrelevance, which leads to this mismatch. Just allowing the links to live out their lives until the data is removed would be nice.

Thanks @foolip! Let's see if browser-specs maintainers share the same understanding.

I'm okay with leaving it in here until EOL (we can add a comment that it should be removed after 2022-01-15). My goal is that our exception list shouldn't be around really given the browser-specs spec selection criteria makes a lot of sense to me. Maybe you found an exception here, though. Oh well :)

I'm okay with leaving it in here until EOL (we can add a comment that it should be removed after 2022-01-15)

This sounds good enough to me. My bet is that we'll have just enough churn in the specs that we'll notice when the oldies need removed. We could also do some kind of check against the list of exceptions, to make sure they're actually used at least once.

Closing here then. Not old enough says the porter :)