What can W3C do quickly so that users can more easily distinguish spec proposals, early incubations, widely deployed features, and formal standards?

[michaelchampion]

As jensimmons states in the minutes:

Developers assume that when things land in a browser it went through a process where all the vendors agreed. Developers don't realize the actual dynamics of what's going on.This causes a lot of confusion, and we could make it a lot clearer.

What specifically can spec authors and W3C do to clear up this confusion on the part of users reading specs at W3C?

• Not display the W3C logo on specs until they have some real-world traction?
• Add harder-to-ignore graphics, metadata, etc. to warn users about early-incubation specs?
• Add in-line automatically-generated support tables (as WHATWG does) to illustrate the real-world status to readers?
• ???

[hober]

In WICG/admin#102 I made this suggestion:

This is a follow-on from #64 inspired by WICG/netinfo#82.

Sometimes, WICG specs define features that (a) have only been implemented by one engine, and (b) are unlikely to be implemented in any other engines.

@marcoscaceres wrote, in WICG/netinfo#82:

I think this incubation might have run its course as it hasn't successfully gained the cross browser support we had hoped for in the last 7 years.

I think cases like this should be clearly marked, ideally with a big red modal like WHATWG Review Drafts, stating that the spec documents the implementation of a feature that is implemented by only one engine, that it's unlikely to be implemented elsewhere, and that developers should refrain from using the features defined in it.

[cwilso]

I'd point to my response in that issue, though:

I'd be okay with putting vendor signals in the templating somewhere - but I would not limit it just to the current three engine vendors, and stating "this is unlikely to be implemented elsewhere" is not a rational statement to make. I do think we should somehow connect the signals from, say, Apple and Mozilla so they are surfaced on the incubations; but I patently disagree "developers should refrain from using features in this incubation" is a fair statement to make (do you intend to put such a big red modal in every incubation and feature proposal elsewhere as well, until universal implementation has been adopted?)

IOW, I do agree we should be clearly communicating the status of incubations in terms of community support, and of clearly communicating implementation shipping status, and progress (or indeed, lack thereof) on the standards track. The value judgement of "should not be used" is not one that I think a very small set of engine implementers should get to control, though.

[cwilso]

Again, to temper my comment above - I don't think we're clearly communicating ENOUGH yet.

[astearns]

@cwilso since you have disagreed with several proposals about what to communicate in several threads I have found, could I ask you to come up with a proposal of your own?

[cwilso]

@astearns I want to be clear that I wholeheartedly support efforts to clearly identify the actual status of specifications and incubations:

• are they in incubation phase (vs consensus-standards-track)
• who is working on them, and how actively
• what customers/web developers are interested in this
• how much interest is there across various browsers and engines in shipping this feature, and
• where is this implemented? (Obviously, for late-stage incubations.)

What I do NOT agree with is letting one or two parties in the world decide to dead-end features. "This is unlikely to be implemented 'elsewhere'" is speaking for the entire world, which is not, in my opinion, a fair or rational statement for one vendor (or even two) to get to make. Clearly communicating status of proposals so web developers know exactly what they are getting into, yes. Making it obvious how "baked" a spec is (on the spectrum from single-vendor proposal that is not yet implemented anyway, to fully-interoperable-shipping-in-"all"-browsers), absolutely. Letting any single vendor (or small group of vendors) control the Web platform with a veto vote, no.
Aside from that, I really don't think that I'm disagreeing with things that should be communicated; in general, the more metadata the better. I'm happy to discuss more and refine, though.

[astearns]

How would you like to clearly identify “how much interest is there across various browsers and engines in shipping this feature” when only one vendor has expressed interest?

[cwilso]

Well, for an obvious answer, I would refer to Chromium's browser signals in Intent mails. They are currently focused mostly on engines, but I think that should be extended to browsers. (Since I would point out that Brave and Chrome frequently have different takes on features; and even Microsoft Edge and Chrome should get to separately express their views.). As for the specifics of how that's expressed, I'm ambivalent. (Table at the top of the spec? I'm not picky.)

I don't have any problem with that being clearly expressed. I only have a problem with claiming that because Apple and Mozilla don't like a feature, it should be essentially vetoed from future consideration.

[astearns]

I think I disagree, somewhat. I do not see it as a dead-end or as vetoed. But I don’t really consider something that documents a single-vendor implementation where we have no idea where and when a second implementation might follow as a spec in active incubation. I think there is value in being honest about this (sometimes very stable) state.

If it’s clear that we’re stalled on getting another implementation, I think there are two benefits that could help eventual standardization:

• developers who like the feature could put more pressure on other vendors
• spec editors would have more pressure to make changes to accommodate other vendors

(It looks like the second might be happening after over a year of inactivity in netinfo? Could that have happened sooner if there was a standard procedure for marking stalled incubations?)

[cwilso]

"active incubation" can quite easily happen with only one engine interested. Incubation is an exploration. "Active interoperable standardization", of course, cannot.

I suspect that the netinfo instance would not have happened sooner if it was somehow better marked; but I want to be clear, I don't oppose a marker that says "this has pretty much gone as far as it can with a single vendor, and we'd like to ask for further attention from other vendors". I don't think the developers who like the feature are super-pumped to be responsible to individually go drum up support from each engine vendor separately, but ... sure? (I'll own up to having a biased view from my WebMIDI experience. :) )

I am supportive of marking these things as "graduated from incubation, and in stasis." (I will of course be clear that Chromium will continue to ship such features, after trying to drum up support; because it is the only pressure mechanism we have to even get other engines to look at features.)

[astearns]

I suspect that the netinfo instance would not have happened sooner if it was somehow better marked

All I know is that nothing was happening in that repo until I started asking about how to mark it inactive.

I would also support a 'graduated from incubation, currently in stasis' state. Could you and your other chairs work on how this would best be done in practice?