css-ui-3 ends up describing CSS UI 4

[gsnedders]

    {
      "url": "https://www.w3.org/TR/css-ui-3/",
      "seriesComposition": "full",
      "shortname": "css-ui-3",
      "series": {
        "shortname": "css-ui",
        "currentSpecification": "css-ui-4"
      },
      "seriesVersion": "3",
      "shortTitle": "CSS User Interface 3",
      "seriesNext": "css-ui-4",
      "release": {
        "url": "https://www.w3.org/TR/css-ui-3/",
        "filename": "Overview.html"
      },
      "nightly": {
        "url": "https://drafts.csswg.org/css-ui/",
        "repository": "https://github.com/w3c/csswg-drafts",
        "filename": "Overview.html"
      },
      "title": "CSS Basic User Interface Module Level 4",
      "source": "w3c",
      "versions": [
        "https://www.w3.org/TR/css-ui-3/",
        "https://drafts.csswg.org/css-ui/"
      ],
      "crawled": "https://drafts.csswg.org/css-ui/",
      "date": "18 September 2020",
...

This is undoubtedly down to css-ui-3 linking to an unversioned ED. Given it's a REC, it is perhaps slightly harder to change that to be versioned. I wonder if it's worth special-casing css-ui-3 for this?

Related to w3c/csswg-drafts#2941 and w3c/webref#11

[tidoust]

This is indeed due to css-ui-3 linking to an unversioned ED that now targets css-ui-4. I am not entirely clear about what the CSS WG resolved to do in the end. Is the end goal to have all /TR/ documents target versioned ED?

So far, the list of specs in browser-specs that Reffy uses typically tracks multiple levels of specs when the current one (as determined by the group) is not the latest one (see spec selection criteria. For instance, there is no entry for the first Pointer Lock recommendation, only one for Pointer Lock 2.0, which is still a Working Draft.

The fact that the CSS WG made the unversioned ED now target level 4 should mean that level 4 is now the current level and supersedes level 3. That suggests that there is no longer any need to track level 3. In other words, instead of special-casing css-ui-3, could we drop it from the list of crawled specs?

Regardless, I note that there are two levels at which the information could be updated:

1. In the spec itself. I believe that the CSS WG can ask to update the link to the ED in a REC without having to go through an extremely complex process (still more complex than a mere update though)
2. In W3C databases so that the W3C API returns the versioned ED, which would then get picked up by browser-specs and Reffy. That is something @deniak could probably do. That seems doable for one spec but a bit tedious and error prone if it has to be done for each and every CSS spec.

[gsnedders]

I am not entirely clear about what the CSS WG resolved to do in the end. Is the end goal to have all /TR/ documents target versioned ED?

Yes. And I /think/ (but am on the wrong computer and don't have a checkout of TR here) that this is the only REC with an unversioned link.

The fact that the CSS WG made the unversioned ED now target level 4 should mean that level 4 is now the current level and supersedes level 3. That suggests that there is no longer any need to track level 3. In other words, instead of special-casing css-ui-3, could we drop it from the list of crawled specs?

That seems sane! I wasn't quite clear enough on the spec selection criteria, especially for the "tr" view, but that seems sensible reading over it.

I wonder if it makes sense to have some way to audit the current != latest list?

[tidoust]

Yes. And I /think/ (but am on the wrong computer and don't have a checkout of TR here) that this is the only REC with an unversioned link.

FWIW, the CSS Fonts 3 and CSS User Timing 2 RECs also use unversioned links which target a more recent level.

Also, the CSS Containment 1 REC correctly links to a versioned ED, but the W3C API returns the unversioned ED for this one, which seems wrong. I'll have it fixed.

I wonder if it makes sense to have some way to audit the current != latest list?

I had a look and indeed found a few specs in that situation. I created a PR on browser-specs accordingly, see w3c/browser-specs#174.

The browser-specs index does not (yet?) track the TR status of a spec, so the audit cannot easily be automated for now, as we probably want to keep tracking the following specs that are still being worked upon (not published as a Rec yet), even though there exists a more recent level:

• CSS Compositing 1, currently a CR
• CSS Box 3, currently a WD
• CSS Cascade 3, currently a CR
• CSS Images 3, currently a CR
• CSS Values 3, currently a CR

[gsnedders]

It's interesting comparing this with what Shepherd believes is "current work" on https://drafts.csswg.org / https://drafts.fxtf.org:

• CSS Compositing 1, currently a CR

Current work is CSS Compositing 2 (Level 1 is effectively a branch heading towards REC at this point)

• CSS Box 3, currently a WD

Is… probably right? And matches the current work tag.

• CSS Cascade 3, currently a CR

Current work is L4, L3 is effectively a REC branch.

• CSS Images 3, currently a CR

Current work is L4, L3 is effectively a REC branch.

• CSS Values 3, currently a CR

Current work is L4, L3 is effectively a REC branch.

[tidoust]

Shepherd, browser-specs, and /TR/, should ideally all agree on which level is "current work". I fixed browser-specs for CSS Box 3, since it should have been flagged as "current". I also raised an issue to retrieve that info from the W3C API in the future, not to have to maintain it manually.

The rest of the list seems correct. That is precisely how I generated the list in the first place: specs that are not yet REC and that have a more recent level which is flagged as "current work".

[tidoust]

The W3C API now returns versioned ED for css-contain-1, and css-fonts-3 and css-ui-3. These updates shipped in v1.18.1 of browser-specs, integrated in Reffy through #421.

We're still figuring out whether and when to drop levels from browser-specs (see w3c/browser-specs#174), and how to detect potential hiccups. In the meantime, the reported issue no longer exists, and css-ui-3 properly describes css-ui-3 again. I'm closing this issue accordingly.

(That said, note that the issue still exists for user-timing-2 but there is no versioned ED that I'm aware of for that one...)