Clarification on CSS Cascade

[marcoscaceres]

trafficstars

Hi @tabatkins ... we have an interesting issue. Terms like [=used value=] are defined in both "css-cascade-3" and "css-cascade-4", but under the short name "css-cascade".

When citing, ideally authors would have the option to just cite "css-cascade", meaning "the latest" or "highest level". However, ""css-cascade" is not aliased in Specref.... we are unsure if:

1. we should explicitly alias "css-cascade" to "css-cascade-4" in biblio.js?
2. in xref, just always assume that "css-cascade" means "css-cascade-4" (or the one with the highest level)

Right now, the we are overcoming this problem by using a localBiblio:

        localBiblio: {
          "css-cascade": {
            aliasOf: "css-cascade-4"
          }
        }

But that doesn't seem great. cc @sidvishnoi

[tobie]

This boils down to how each different WG does versioning, which unfortunately, W3C doesn't want to standardize.

[tobie]

Somewhat related to https://github.com/tobie/specref/issues/463

[marcoscaceres]

@tobie yeah, I figured that would be the case. I guess I was wondering at the same time how BikeShed deals with it and also how the CSS WG deals with it in general. @fantasai can probably also provide guidance as primary editor of the css-cascade spec.

[tobie]

FWIW: I think aliasing css-cascade to css-cascade-4 is perfectly acceptable.

[tabatkins]

Yeah, this is ultimately a W3C failing: we've tried to get them to give CSS a consistent treatment across all of our specs but have failed; instead we just have to remember to bug them about adding aliases whenever we publish something that doesn't have an alias yet.

Bikeshed ends up dealing with this via its biblio fallback; if a biblio label isn't in SpecRef, but it does match a shortname (versioned or not) in the anchor database, I go ahead and generate a biblio entry out of the anchor db's data.

Adding an override for that alias seems completely fine to me; it would be especially nice if you could do it for all the CSS specs that don't currently have an alias. ^_^ (There are, uh, just over a hundred CSS specs now.)

[marcoscaceres]

Adding an override for that alias seems completely fine to me; it would be especially nice if you could do it for all the CSS specs that don't currently have an alias.

Slapped together a script for it: https://github.com/tobie/specref/pull/564

@tabatkins, can you check if the output looks right? It is also capable of updating any outdated aliases to the highest level if a new level becomes available for a spec.

[frivoal]

Semi-off topic:

Yeah, this is ultimately a W3C failing: we've tried to get them to give CSS a consistent treatment across all of our specs but have failed;

This is in large part because not all WGs operate in the way the CSS-WG does, and the tooling is generic. If you have a suggestion of a Process change that would help clarify the relationship between various levels of a single spec, that would help the CSSWG without preventing other groups who want to work a little differently from doing so, and help motivate the systems team to build tooling to support that workflow, you have 2 CSSWG reps on the AB, so we could push for something.

[tabatkins]

We (fantasai, mainly, I think) have bugged them to do a single comprehensive update, and failed to get traction. This isn't something that needs a process change or a generic policy that applies cross-WG, just our single (large) set of specs getting an update in the systems so that they're all consistently handled, rather than the mishmash they are today.