Sometimes we get things wrong! But as often as not these days, we just can't get feedback from other vendors in a timely way. It's a direct consequence of them starving their platform teams of staff.
-
-
But the big question here is this: why are *browser vendors* in charge of web standards, as opposed to a faction within a larger group of stakeholders (a la TC39, though ideally without the same financial commitments) that can advise on implementation pitfalls?
1 reply 1 retweet 3 likes -
I wrote a blog post series on some of this: https://infrequently.org/2018/06/effective-standards-work-part-1-the-lay-of-the-land/ … https://infrequently.org/2018/06/effective-standards-work-part-2-threading-the-needle/ … TL;DR: feature development and standardisation are separate-but-related processes, and the folks who ship the bits take the risks.
2 replies 1 retweet 2 likes -
Replying to @slightlylate @Rich_Harris and
Your blog posts and the threads have the role of standards organizations upside down. SDOs and their working groups should REVIEW proposed design changes, by the widest possible review committee. Ship first process disenfranchises. Review takes time and attention.
1 reply 0 retweets 2 likes -
Replying to @masinter @Rich_Harris and
You presume I have a single step gearing in mind, rather than frantic iteration (including wide review). That's an error not contained in the text.
1 reply 0 retweets 1 like -
Replying to @slightlylate @masinter and
This misconception is falsified by my role in putting
@w3ctag review in the center of the Blink launch process. You can persuasively argue many faults of my character, but suggesting disbelief in the value of wide review is among them is unlikely to come up aces.1 reply 0 retweets 0 likes -
Replying to @slightlylate @Rich_Harris and
no character fault was implied, stick to the ideas. It's great that you have some review early in the Blink launch process, but
@w3ctag is of necessity not always representative of the affected community....2 replies 0 retweets 0 likes -
Replying to @masinter @slightlylate and
What is the launch process for a new feature from someone else, when do you provide feedback to other vendors on their proposals?
1 reply 0 retweets 1 like -
Replying to @masinter @Rich_Harris and
"From someone else" == "for features proposed/implemented first in other engines"? Or do you mean "from contributors other than Google within the Chromium project"?
1 reply 0 retweets 0 likes -
Replying to @slightlylate @masinter and
If the question is the first, we try to engage when asked about proposals in important areas. Relatively few of these from other vendors are done via a similar incubation processes (which is a point of contention), so we'll usually get a whiff of them at WG's...which is a problem
2 replies 0 retweets 1 like
In those cases, we'd hope other engine projects would send their proposals to similar review (e.g., via the TAG). But they don't
A part of the disconnect is that we're more interested in developer feedback and sentiment than formal WG approval. WG's aren't fitness functions.
-
-
Replying to @slightlylate @masinter and
Some WG's exhibit a really weird survivorship bias: they were themselves formed from successful features that were initially designed and launched *outside* the formal process, but now expect everyone to do all new work in an environment they didn't start in...which is


1 reply 0 retweets 0 likes -
Replying to @slightlylate @masinter and
On feedback from other's proposals, Mozilla's positions repo is an interesting way of handling this sort of review flow. We have thought about something similar. Frustrating that Chromium is so far ahead on features that we tend to be the ones pushing most new work = (
1 reply 0 retweets 0 likes - 5 more replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
& Web Standards TL; Blink API OWNER
Named PWAs w/
DMs open. Tweets my own; press@google.com for official comms.