Make single-engine WICG specs even less official looking #102
Comments
|
The big red model in WHATWG Review drafts is because almost no one should be looking at such a specification (they should be looking at the current LS - RDs are by definition for lawyercats only). By contrast, WICG incubations that have only been implemented by one "engine" are still... incubations. It would be hard to argue that such incubations are innately inappropriate for developers to look at, given that early incubations are usually single-engine, and getting developers to channel that demand to engines is frequently critical in order to get engines to ramp up efforts to implement such things (including, of course, the impetus to move to a final standards body). 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?) |
|
I understood the proposal here to be limited to being about specific cases like the one one cited in issue description: an “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”. For those kind of cases only, I agree something along the lines of “big red modal like WHATWG Review Drafts” doesn’t seem inappropriate — and instead seems useful to web developers as far as more clearly signaling to them about the fact the spec, despite being around for quite a while, hasn’t gotten implementor interest needed to put it on a trajectory to become part of the platform. On the other hand I also agree that such a “big red modal like WHATWG Review Drafts” thing shouldn’t be applied prematurely to specs that haven’t had some chance yet to prove themselves — and I mean not as far as implementor interest, but also web-developer interest. To be more specific: Consider a case like the original I realize the comparison to those earlier days of the |
Yes, Mike's right; I intended this suggestion only for dormant/maintenance-mode incubations with only one implementation and on-the-record opposition from other implementers.
Yes, this is exactly what I had in mind.
Yes, agreed. |
|
I'd honestly prefer we time box specs instead... like, if they go dormant for 1-2 years, and there is clear indication that "it's not going to happen", we close them out. Having a sense of urgency around them help make more meaningful compromises towards reaching consensus on a "minimum viable spec" that at least has cross-engine support. I also understand that that might not be realistic. People have different priorities and working on different things at different times. It's not unrealistic for some browser engineers to not look at things from ~3 years after incubation starts... maybe we should then set it to 5 years max? |
“close them out” is ambiguous. But I think at least a lot of cases, one thing it shouldn’t mean is that we completely delete the repo and un-publish the spec. I say that because even in cases where a spec goes dormant, it’s often already been documented in MDN — with links from MDN into anchors to particular definitions/sections in the spec. Given that, it seems like “close them out” should basically involve at least doing what’s proposed in the description for this issue — so that we don’t break the links and so that we give web developers an unambiguous indication of the implementation status of the spec. |
Sorry: I mean, archive them. As we've been doing with some. See the "archived" tab at the bottom of this spreadsheet:
sigh... but yeah.
Agree. |
|
I think going forward it makes sense to have a timeout like @marcoscaceres suggests. If we adopt one, I think it would be worth the effort to go through the existing WICG repos to apply this to things that have already timed out, too. |
|
I'm not sure why a timeout would make sense. The original issue that sparked this discussion - over in WICG/netinfo#82 - shows pretty clearly that even what might be considered "stagnant" incubations may actually regain momentum, because the whole gating factor that leads one vendor or another to be opposed to implementing may actually change when it comes up for discussion, and those vendors have bandwidth to discuss and explore. To be clear: I am opposed to any arbitrary time-boxing of incubations - particularly in the world where it is difficult if not impossible to get bandwidth from other vendors, even to make statements on features with clear developer demand. (Yep, Web MIDI would be a good example here.) Labeling implementation support for incubations is understandable; clearer signals on incubations where implementers can lay out their reasoning is great. Archiving or closing out incubations is not; there are IP questions opened by doing so. I am strongly opposed to any auto-archiving based on time, as it shuts off any discussion or conversation in the incubation - and prevents, in fact, any vendor from participating in a discussion that might change their mind. The only reason to archive should be 1) the feature has moved to a different place - e.g. been adopted by the WHATWG into HTML - and discussion should move there, or 2) all parties - but most particularly those who shepherded the incubation to begin with, agree that it has failed. |
Like this? As @cwilso is saying, the fact that an incubation started X months/years ago is not a good signal about its future viability. Similarly, the fact that some vendors oppose a proposal in its current form doesn't mean that a compromise can't be achieved. This is even more true for features that have clear use cases and wide developer demand. Shutting down that conversation seems extremely wrong. |
Please note that no one is suggesting auto-archiving. What I was proposing, and what we've been doing for the last year+, is politely asking those involved if the incubation is still viable or if some alternative solution was found - more often than not, an alternative emerged and all those involve agree that archiving is the way to go (or they ask for more time to try to keep things moving along). Netinfo is a bit of an outlier here, because some folks really want it (in some shape or form) - and other folks acknowledge there is a need for something like it - but don't particularly agree with the direction. What's kinda unfortunate with Netinfo is that it looks like a fairly formed spec, and an implementation to match - but without the agreement that the spec should have that shape. That's somewhat exceptional, because other incubations hopefully get shaped through collaboration and rough consensus. To me, it seems like the best solution would be to scale back an incubation to just the parts people agree on. Any super controversial parts of the spec should be removed, and, in the worst case MDN should get updated to reflect the experimental nature of any proposal. In the extreme case, we start slapping red warnings everywhere - but I'm hopeful we can avoid doing that. |
Archiving abandoned work (which everyone agree is abandoned) is fine from my perspective. This is not what this issue is about though.
What you described sounds a lot like collaboration on the proposal with the purpose of it graduating into a WG. That would be highly welcome. It's also something that cannot happen with archived proposals. aside: I'm assuming you're talking about the specific case of a mature incubation which lacks multi-implementer support (as early-stage incubations should be encouraged to explore the problem space, rather than seek consensus).
I'm failing to see how red warnings would be helpful for something other than discouraging WICG work. |
Well, the thing people at Mozilla get upset about is web developers thinking that WICG incubations are "standards" (why we moved to add the "Unofficial" watermark to the top of CG specs - though if that was effective is something still up for debate). Developers come and express their dismay that we don't support some random WICG API linked to from MDN that's shipped in one browser - even though that API doesn't have broad consensus or hasn't been vetted beyond a single browser vendor. I imagine that's also what's bothering @hober and the WebKit folks - and red boxes are a cheap solution to address that issue. Now, again, without saying we should do the red boxes: I think that's what ultimately leads to a red box situation - so for us that are not shipping, we can point to a spec and say "see, this is not a thing yet... one day, maybe... but not yet". |
That sounds like you're getting a clear signal from developers that those "random" APIs are solving a real problem they encounter in their day-to-day work. I doubt debating W3C process with those developers would help them solve those problems. Maybe instead, when such signals are received, that should encourage collaboration on those APIs to make sure they are something y'all can implement and ship once the implementation work is prioritized? |
Heh, valid :) Priorities tho.
"We do what we can with what little we have". |
|
Regarding MDN concerns ancillary to this, a somewhat-related guideline was very recently added to the contributor docs for the associated browser-compat-data project:
|
Another thing that could be done here is to tweak the info on MDN to be more clear that the API is still experimental / being incubated. For example, the Keyboard Lock API on MDN has a yellow bar at the top indicating that it's Experimental. But that's easy to forget as you scroll down and start reading the page. When you scroll down to the "Specifications" section, the spec link to the WICG spec looks just as official as any other spec link on MDN. If you put one of those experimental Flask icons next to the spec (or flashing red tags, or whatever), it might help as a reminder. |
|
Paging @jpmedley. |
I added one there for now, just to show what it would look like. But note that there’s already also such a “this is experimental” flask icon in the Browser Compatibility table just below that Specifications table. I would think web developers are likely to be paying more attention to that Browser Compatibility table than the Specifications table, so maybe adding the icon to the Specifications table too is overkill. Anyway, https://github.com/mdn/sprints/issues and https://discourse.mozilla.org/c/mdn/236 are good places to discuss any ideas about how to make MDN articles give further signals about experimental features. |
|
@yoavweiss and I had a call about this. We feel making changes per the WHATWG is a bit too extreme for incubations – as the purpose of the incubations is to foster discussion and collaboration, not to scare people away. We acknowledge there are issues with people outside the standards community being confused that these are not "real standards". We've made some efforts towards clarifying that... like making sure the "unofficial" watermark is across the header of a document (Mozilla folks wanted it through the whole document, but it made the documents too unreadable from an a11y perspective). Now, there are special cases where an API ends up shipping in a single engine - and we should maybe work out some way of denoting that. MDN is doing this already for us, but maybe we could add something to specs to indicate that fact. However, we would be reliant on spec authors to annotate, or otherwise mark up, specs to show this. We are open to suggestions for how to incrementally improve things. |
|
SGTM. |
Actually, these bars are being removed from MDN because they very badly lack needed subtly. (It also relates to a plan to move MDN content creation to GitHub. I'm leaving out details about that.) For example a spec like service worker, which is implemented in all major browsers, is largely the same in those browser, and changes very little, contains an experimental browser, while something like the Payments API, which is a candidate recommendation, and is still highly volatile contains no such warning.
I couldn't agree more. The distinctions you're all drawing in this discussion are murky at best to those outside the standards problems. I've had a front row seat to the standards process for six years, attended three TPACs, and had the process explained to me by Chris Wilson. I make no claims whatsoever about my knowledge of it. What do you think the average web developer makes of the distinction between various types of specs? MDN's primary purpose is for developers who just need to build something that works on as much of the platform as possible. |
|
This has come up again in w3c/web-share#150 - where Web Share L2 is an incubation. |
|
Hmm, interesting. Where is Web Share L2 being incubated? I'm having a hard time distinguishing between "L1" and "L2" specs. In general, this is a particularly interesting problem - e.g. for specs that are forks of current TR specs (e.g. https://github.com/WICG/media-source), how should we clearly delineate those? |
|
mdn/browser-compat-data#6059 came up today and has ended up making me think more about the MDN and BCD side related to this discussion. I posted comments there — which are long and basically a monologue at this point (though I’m sure others will weigh in) — but the summary is, it’s related to https://developer.mozilla.org/en-US/docs/Web/API/Window/onbeforeinstallprompt and w3c/manifest#836, which is a case of a feature that:
The last bullet point above makes it not directly relevant to the specific issue discussed here — but for the MDN and BCD side, it’s related in that we need to decide what to convey to web developers about its status. Specifically, do we want to go so far as to have the MDN article say that the feature is “no longer recommended” and that “developers should avoid this functionality”? Or is it sufficient to instead just convey to developers that the feature is non-standard and experimental? I don’t expect any further discussion about that specific case to take place here — you’re free to comment on it at mdn/browser-compat-data#6059 and I may raise a related meta-issue at https://github.com/mdn/sprints or https://discourse.mozilla.org/c/mdn/236— but it seemed worth mentioning here in order to point out a specific example where, along with the issue about how specs should be conveying feature status, we have a related need for MDN. |
|
@travisleithead, yes, we (WebAppsWG) have been a little bit slow about moving it over to the WICG. Mozilla and Apple folks were hoping to avoid that by trying to convince the editor to just drop the level, and let things sit in pull requests per the WebApps working mode/charter (w3c/web-share#107 (comment)). However, some Editors like having WICG specs instead of PRs... which gets us back into this not so great situation. |
|
Here is a concrete proposal: we make it clear to all engineering leads/teams at all companies that: where a technology is in scope of a working group charter, we (the standards community) prefer pull requests rather than things getting pushed into the WICG. That would:
That would also delineate more clearly what is in scope of the WICG and what isn't: if it doesn't fit in a working group, then the WICG will take it! But if it's a feature that a working group rejected, it shouldn't end up at the WICG. Similarly, if a single engine implemented it, but it got rejected by a Working Group, that's not a good reason to bring it to the WICG... it can be incubated as a pull request, or wiki page, or even a new repo, in a working group instead. |
|
Both personally and on behalf of Google, I oppose that proposal. The whole point of incubation is to enable multiple experiments, and to try out unorthodox things. That's one of the strong points in favor of doing such experiments outside working groups (and why we have an Immersive Web Community Group as well as an Immersive Web Working Group, e.g.). I think letting a Working Group "lick all the cookies" is not a good idea, particularly when that scope is, frankly, intentionally huge like the Web Apps WG. That's not to say that the community in such a group should be ignored; they absolutely should be invited if not involved (again, cf the Immersive Web groups, where the overlap is very high). I've been a consistent advocate that incubations should go where their community is; however, if the WG isn't interested, it clearly isn't there. Certainly, in some specs where the features being incubated are intimately involved in an already-extant WG spec, PRs are the right way to go (e.g. many smaller features that go into DOM or HTML), but PRs are already kind of a challenging mechanism for developing proposals for anything but small feature additions. For medium to large features, they should probably start as a standalone explainer. But if a WG covering that feature's scope has explicitly rejected a feature, it seems they've explicitly stated they DON'T want to participate in incubating it further, so I'm not sure why you'd say to do it there. Moving it out elsewhere seems warranted. Nothing (as per previous comment) can prevent the "faux spec" problem, other than commitments to clearly label status of proposals, incubations, and support from browsers and engines. MDN, in my opinion, absolutely should be leading with the "spec status of this feature" as a banner - not the current "experimental", but something that delineates clearly the baked-ness of, say, most of ServiceWorker or WebXR vs. onbeforeinstallprompt. |
The value of incubation is not in question here. We are all in violent agreement on the value of incubation, and we've had great success with the WICG over the last 5 years.
My experience is that both Chairs and Team are pretty strict about not spinning up random work.
Agree.
There is a difference between incubating and outright rejecting a feature... that's a hard pill to swallow sometimes, but that's basically what this really comes down to: not all ideas will make it into "The Platform", irrespective of how much we want them to succeed or how many years they sit in incubation - or even if it's shipped in a single engine and developers are relying on it at the expense of privacy and/or security. There are good reasons to toss something over to the WICG to chew on... but, tossing something to us that's not going to happen is patronizing to both the engineers involved and the WICG. It's why we end up with memes like:
Again, that's totally different from two implementers saying, "we are never going to implement X" (e.g., parts of NetInfo) VS "yeah, that's seems super interesting, let's work together and see what we come up with!" (e.g., feature policy). There has to be a point of acceptance that some things will die on the vine. WICG shouldn't be a place where we keep dead specs and/or outright rejected features on life support as a face saving measure. That is deceptive to the community and lessens the value and credibility of the WICG - we are better than that, I hope.
How MDN does things is a separate concern. I've no doubt they will do an exceptional job in communicating the status of things, as they've always done. I ask that we put MDN aside and focus on the WICG and WICG specs. What I'm saying is: If incubations didn't succeed, but a single vendor wants to continue with it despite it being rejected by other implementers, then they should be taken back to the said vendor's repo (and marked as a proprietary extension, given the browser vendor's logo, etc. so there is no confusion about it being a proprietary thing). If at some later point, other vendors see the error of their ways and realize feature X was actually a brilliant idea, they can go asking to bring back a feature for incubation. |
|
@cwilso wrote:
@marcoscaceres replied (emphasis mine):
@cwilso wrote:
@marcoscaceres replied (again, emphasis mine):
I could not agree more with @marcoscaceres on these points. |
|
There are multiple different threads here.
|
|
Replying to Marcos' comment, a few points in no particular order:
Overall, I’m concerned that siloing proposals into vendor-specific orgs would prevent other vendors from commenting on them and shape them. It seems like an extreme measure, that would lead to overall less collaboration. Going back to a question I asked earlier up-thread: what problem are you trying to solve with this proposal? |
|
This is getting very long.... and starting to get circular. Let's tl;dr on @yoavweiss core question:
*"rejected" by the W3C process - because it was marked "at risk". More rambling responses below... but maybe we should switch to a higher bandwidth medium to discuss this as there are too many questions/points for me to address. I put Let's find some middle ground and propose some workable solutions. I made a proposal - it wasn't amazing, but maybe it's a start?
@cwilso wrote:
Sorry, I was not very clear so my point didn't come across: Adding necessary things, like an IDL attribute, a method, or even spinning off a spec to meet a use case, is not uncommon in a WG: That's normal operating procedure in standards development for any working group, and well within a working groups charter. What I was objecting to was: spinning up a WICG incubation for adding an IDL method, attribute, or enum value to an existing spec because those extensions have shipped in a single engine before the working group had a chance to discuss them, or because they were rejected by the WG.
Yes, again, that's never been in question. For example, the Shape Detection API, Web Share, Feature Policy, Badging, and many other are all fine examples of good incubations.
That's not what I'm saying... I'm saying that if a feature got tried, tested, and no one wanted to implement it, then bringing it to the WICG is a lost cause (e.g., Take Web Share API "L2" as a more concrete example: it's proposing a couple of new IDL enums and a method, so it shouldn't need to go through the WICG - multiple implementers already said they are interested in exploring the use cases of "L2", though they don't necessarily agree with the approach, but are supportive of finding the right API shape. However, because the Share "L2" shipped in Chrome before we could reach consensus on the shape of the API, we now have a bad situation where there is "faux spec" pretending that this is the way it is: the "faux spec" is just documenting Chrome's behavior. That's not great. Solution: propose those things in a pull request instead. It's exactly the same story with NetInfo: it contains a bunch of stuff no one wants, but a couple of use cases that compelling ("what's the effective download speed?" and "is the connection metered?") - but the API shape in the spec is just documenting stuff in Chrome - thus not reflective of any sort of consensus. It could just be gutted out and we could have the incubation discussions in either an explainer, in issues, or whatever... and eventually get to something that looks like a spec through collaboration. So, to @yoavweiss point, about grounds for further collaboration: Solution: gut the spec. Start again. Let's work through the use cases and propose a new API shape via a set of pull requests, as a community. The WHATWG put a stop to the bad behavior I described above by not allowing anything into HTML without agreement from two vendors - something I'm also enforcing in Web Payments and Web Apps WG. The reality is that the rule is going to make Google's life difficult: because it means working really really hard to convince other engines to support those things... but that seems fair, given that it's a shared platform. But for all things Google, please ship whatever you like... but please clearly delineate what's Google Proprietary stuff and where it's actual "web platform" things: where multiple browser engines are actually planning to ship. And that brings us full circle to the WICG: When the community tries to incubate things, but it turns out that only one vendor is excited about a feature, then at some point it's time to concede that an incubation has failed (irrespective of it having shipped in Chrome - that's not Mozilla or Apple's problem... except when Google goes and sells incubations to developers like they are "web platform" things).
It's not Apple and Mozilla that shut it down: It's the W3C Process that we all agreed to operate under. WebMIDI won't ever get to REC because WebMIDI is never going to get two interoperable implementations. That's the process we all agreed to operate under, and yes, it sucks that stuff fails sometimes. Remember, you are talking to someone who wasted a PhD and 7 years on W3C Widgets, so believe you me I know how much it sucks when people are using your stuff and yet it fails to become a thing. But that's the standards game: win some, lose some, move onto the next one. @yoavweiss asked:
Eventually we'd like to bring them over, so long as we get support from multiple implementers. Web Share was a good example... working hard to try get interest on the others.
There is no "forbidden". It's a case by case basis... look at Badging API: at the last TPAC, a bunch of smart folks got together around a whiteboard and totally changed the API shape based on some really productive discussions. The point is that we have a pretty good idea how we want things to work, how we bring things into the WG in a fair way, and we know when things are "not quite right".
We have plenty of examples of that in the WICG (e.g., the event options). So yes - they would. But they could incubate it outside, then bring it in. That's what happened already. Further, if it was a single vendor trying to do what you describe, you can bet that it would be PR. There are not hard fast rules here - so asking "gotcha" questions is not going to help. It's more of a clear case of where some specs are clearly doing the wrong thing.
It's not... the W3C Process clearly states that things that don't have multiple implementations will get marked "at risk", and booted from the spec if they don't get interoperable implementations. I don't make the rules, I just enforce them (as Chair). |
|
@yoavweiss and I spoke again to see if we could find a more palatable proposal... here is another go at this as a straw person:
|
|
Thanks for writing it up!
Those bits seem great. The only part where I may push back on is the "before" part. I don't think this should be a pre-requisite for incubation, but something that should happen either before or during the lifetime of the incubation.
That can work for smallish things that we're pretty certain are a good idea, but leaves less room to abandon the incubation idea and move on to a better solution to the problem. So I'm not opposed to the principle, but think that in practice, it'd probably be better to let most things incubate for a while.
I think this is mixing up 2 separate notions: WG support and community/industry support. At the same time, I'd object to requiring WG approval in order to incubate things. That seems like a step backwards. Here's the flow that I had in mind when we discussed this:
That way, the WGs act on an advisory role for the proposals that are likely to fall in their lap, which seems like something everyone would benefit from. This is more or less the process we follow in the WebPerfWG regarding related incubations, and I think it was pretty successful. WDYT? |
|
I should have explicitly noted - Yoav and I are in agreement here. I like this recast. I'm concerned by the statement "If a working group is like... "meh..." and there is no real public support for said feature beyond a single company, then we don't create a repo (until such time where there is support)." Mostly, I want to ask - do you see this today? I've been quite cautious not to migrate repos into the WICG unless there is an expression of support from more than one entity. Secondly, though, I want to underscore again- a lack of interest from a working group is just a lack of interest from them; anything someone could go create another CG to incubate, it seems like we should welcome in WICG. |
|
For incubations that have a clear "upstream" working group/workstream (and for which there isn't already a more focused CG for that proposal to be incubated in--e.g., an immersive web-related proposal, I like this proposal a lot. The "check in" regularity helps WG avoid surprises (e.g., "hey CSS WG, here's a fully-baked proposal that came out of WICG that you've had no feedback on and makes lots of assumptions that aren't going to work... please adopt it!) and the advisor (as noted) can assist to help it be successful (like a struggling grad student). I would even support documenting the advisor relationship in our report template. I'll note that this change doesn't address the "single-engine WICG specs" concern cited earlier, except perhaps that it tries to foster increased collaboration with an actual upstream community that will help shape the feature into something more plausibly supportable by more than just a single-engine vendor. Then by the time the incubation is considered "mature" it will have had feedback on what is likely to get wide implementation and what needs to change. I'm reasonably confident the chairs will be able to find the upstream advisor WG for most incubations--but there will likely be some unique proposals that won't have a clear home, or will be too underdeveloped to know yet where they should go. This is OK, but could leave the incubation without good support--which in turn might lead to it becoming stale, and then we will still need to grapple with what to do about it. Hopefully this will be a small minority of proposals.
|
There's that, but we also talked about having clear signals of support in the specs as a way to address those concerns.
I agree that this will be a minority. One option in such cases is to have "multiple advisors". Have the proponents present to multiple candidate WGs and see what folks say.
The way that I pictured this is with the advisor relationship being voluntary. So if the proponents and the advising WG don't see eye to eye, that seems like something we should try and help fix, rather than penalize. |
|
@cwilso and I chatted about this on today's call. The @WICG/Chairs will endeavor to reach out to working groups early in the incubation process to try to get more engagement from browser vendors and the rest of the standards community in new proposals. We are also making an effort to identify which working groups could potentially adopt a WICG spec, in the hope to get those specs included in any charter renewals. As to the OP proposal, we still don't feel that putting up a WHATWG-style modal banner would be appropriate. We've already made sure the headers of CG Drafts are watermarked as "Unofficial". Closing this out. Thanks everyone for the great discussion! |
|
Which incubations could go into which groups can be seen in the WICG tracking spreadsheet. |
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 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.
The text was updated successfully, but these errors were encountered: