[meta] How should we indicate which features in a pre-CR draft are “stable enough” to reference?

[astearns]

A question about the stability of the interactivity property https://drafts.csswg.org/css-ui-4/#inertness came up when we discussed an HTML PR yesterday whatwg/html#10956. It’s not entirely clear to me that the WHATWG process requires this, but it seems desirable to avoid linking to CSS features from non-CSS specs until the feature has reached some level of stability.

If the module is in CR, that seems obviously ready to be referenced. But we also have relatively stable features inside modules that are not yet in CR. How should we express the stability of individual features when some external party wants to link to them?

After discussing and taking a resolution declaring a feature is “fairly stable” like we sometimes do with a feature that is ready to ship, we could:

1. Add something to the draft noting the enhanced status
2. List those individual features in the “fairly stable” section of our snapshot
3. Something else?

I don’t expect we should do this for every stable-ish feature, but only when someone asks whether a pre-CR feature is stable enough to reference.

Thoughts?

[svgeesus]

I believe we are already doing 2. but not continuously, rather as a sort of annual round-up. I believe it should be done continuously.

I think that 1. would also be useful to note, as it is in-place so easier to find.

[astearns]

I believe we are already doing 2. but not continuously, rather as a sort of annual round-up. I believe it should be done continuously.

I think we are doing 2 for entire module levels that are fairly stable but have not yet transitioned to CR. I am not aware of any feature subsections that we have added to snapshot sections. I agree that we should be publishing snapshot updates whenever we resolve to make changes.

[SebastianZ]

I think we are doing 2 for entire module levels that are fairly stable but have not yet transitioned to CR. I am not aware of any feature subsections that we have added to snapshot sections.

We do have a section called "Safe to Release pre-CR Exceptions" for that.
And in #10687 we're collecting features that should be included in the upcoming snapshot.

So I agree with @svgeesus, we should continue doing this but also add a note in the drafts themselves.

Sebastian

[astearns]

Thanks! I was only looking through section 2 and had not gone through the whole table of contents.

[astearns]

So my next question is whether our “safe to release” state is what WHATWG needs to land whatwg/html#10956

@domenic appears to be saying it’s not required. @annevk appears to be saying it is (or at least some signal of stability is needed)

I’m not sure interactivity is ready to be marked "safe to release” anyway, as the TAG is currently working on their review, and I see from the intent thread that it’s been shipped with promises to “invest in additional changes as necessary”

[tabatkins]

I’m not sure interactivity is ready to be marked "safe to release” anyway, as the TAG is currently working on their w3ctag/design-reviews#1055 (comment), and I see from the intent thread that it’s been shipped with promises to “invest in additional changes as necessary”

This is the exact sort of chicken-and-egg I'd like to avoid, by not invoking even more cross-WG bureaucracy. Different WGs and standards bodies can have different goalposts for various steps, and linking them implicitly unions all the goalposts, making it harder to finish things without anyone being "responsible" for the slowdown.

The WHATWG's standard for when something is safe to merge has for some time been "multi-implementor interest". That's a fairly easy bar to clear; you just need a public signal saying "yes".

The CSSWG's bar for putting something in the "safe to release" section of the snapshot has never been firmed up (due to lack of any real need), but responses like this from Alan (which I don't think are unreasonable!) show that this bar is definitely different to the WHATWG's "multi-implementor interest", and generally higher. We, the CSSWG, should not be approving the WHATWG hooking themselves to us like this unless the WHATWG indicates that they do indeed, affirmatively, want to increase the standards they apply to things being mergeable. To the best of my knowledge, they don't want that, so this looks to me like people just trying to squint and find equivalent-looking things without really considering the ways in which they're not equivalent.

All the implementors in the WHATWG have coworkers in the CSSWG. They can ask them for stability. We don't need to give them a stamp of stability, either slowing down the WHATWG working mode or relaxing the CSSWG's desired requirements.

[annevk]

Here's two things I want to avoid:

1. WHATWG process being used to circumvent the process of some other group.
2. A WHATWG standard depending on something that then gets revised in some significant way without that being deemed a problem by those maintaining the upstream dependency because they did not consider it to be stable.

(WHATWG also has more requirements than just multi-implementer interest.)

[astearns]

I agree with Tab’s comment re: cross-WG bureaucracy.

I think it’s OK for other groups to link to pre-CR CSSWG drafts, as long as they are OK taking on the risk that things may change and require updates. I also think it’s OK for other groups to ask whether something is actually farther along than the draft status might indicate. In this case I think our answer would likely be “no, not yet.”