Drop superseded CSS Recommendations

[tidoust]

Several CSS specifications, being developed by the CSS WG, supersede a previous level published as a W3C Recommendation, meaning that the series shortname no longer targets the Recommendation, but rather targets the new level. That suggests that the previous level no longer needs to be tracked in browser-specs (at least, that is the rule we follow for IDL specs).

This update removes the following CSS Recommendations from the index as a result:

• CSS Color 3
• CSS Containment 1
• CSS Fonts 3
• CSS Basic UI 3
• CSS Writing Modes 3
• CSS Mediaqueries 3
• CSS Selectors 3
• CSS User Timing 2

See original discussion in:
w3c/reffy#417

I guess the overall question that this PR raises is around the definition of "superseded". One could perhaps argue that previous levels need to be retained, e.g. because they could still, in theory, be updated.

[dontcallmedom]

How confident are we that the "superseding" behavior clearly matches a CSS WG decision (vs an error, or a single editor decision, or …)? The rules for the canonical TR URL is that it should point to “the most mature Recommendation of a given technology or the most agreeing-on version” at the discretion of the group - I wonder if there is a papertrail that documents these decisions one way or another.

What are the implications of dropping the Recs from a webref perspective?

You mention CSS User Timing 2, but this isn't a CSS spec, nor does https://www.w3.org/TR/user-timing/ points to User Timing 3 - am I missing something?

I note that https://www.w3.org/TR/css-mediaqueries/ doesn't point to MQ4 (while https://www.w3.org/TR/mediaqueries/ does) - probably another bug to report.

[tidoust]

How confident are we that the "superseding" behavior clearly matches a CSS WG decision (vs an error, or a single editor decision, or …)? The rules for the canonical TR URL is that it should point to “the most mature Recommendation of a given technology or the most agreeing-on version” at the discretion of the group - I wonder if there is a papertrail that documents these decisions one way or another.

From a W3C publication perspective, that should be tracked within publication requests. I do not know how systematic we are on this for leveled specs, though. I'll let @deniak comment.

From a browser-specs perspective, I don't know that we should care about the papertrail. We can fix things one way or the other. It seems more important to be consistent with /TR/. We could perhaps add some checks to alert us when /TR/ disagrees with Shepherd.

What are the implications of dropping the Recs from a webref perspective?

It shouldn't change anything for CSS and IDL extracts. It would drop dfns extracts for these specs though and that is potentially more problematic. For instance, if a spec that is about to be published as PR or REC needs to reference CSS Fonts, it will likely have to reference CSS Fonts 3, which is the current REC, and not CSS Fonts 4, which is just a WD. That suggests that we may actually want to take an opposite approach and always list the latest REC when there is one on top of the current draft (e.g. that would mean that we would add Pointer Lock on top of Pointer Lock 2.0).

You mention CSS User Timing 2, but this isn't a CSS spec, nor does https://www.w3.org/TR/user-timing/ points to User Timing 3 - am I missing something?

That's a double mistake on my side :)
I removed that file from the list of dropped specs in this PR and filed #177 to flag User Timing 2 as the current specification in browser-specs.

I note that https://www.w3.org/TR/css-mediaqueries/ doesn't point to MQ4 (while https://www.w3.org/TR/mediaqueries/ does) - probably another bug to report.

Indeed.

[dontcallmedom]

From a browser-specs perspective, I don't know that we should care about the papertrail. We can fix things one way or the other.

It seems to me that part of the value in browser-spec is collecting data that reflects the consensus of the platform builders - in many cases, we have implicitly assumed the underlying processes embody that consensus. My sense is that it's not as clear that this is the case for the "superseding"/"canonical" discussion, so it's probably worth our attention :)

That suggests that we may actually want to take an opposite approach and always list the latest REC when there is one on top of the current draft

This starts to feel like another layer over our ed / tr distinction; I don't have a clear picture yet of what we should do, but I think we need to understand the versioning model we want for what use cases before coming to the right solution.