the standards process doesn't really counterbalance that. Contrast it with TC39, which has much broader representation and — though it moves slower than many people would like — generally gets it right first time. I feel way more positive about the direction of JS than of the web
-
-
Replying to @Rich_Harris @gavindoughtie
You're right that the Standards process doesn't counterbalance this *on it's own*, but the Blink API OWNERs apply pressure to Blink launches to ensure we're doing our duty towards standards and (more importantly) developer feedback.
1 reply 0 retweets 1 like -
That is, within Chromium, the thing that keeps folks from shipping whatevs is that they have to come through the API OWNERs to get 3 LGTMs to ship. And we're de-facto conservative. But not so conservative that we're happy to idle forever.
1 reply 0 retweets 2 likes -
It's the API OWNERs that have pushed all these features to request
@w3ctag review (other browsers don't have this in their process, so it's a crapshoot if they ask for that wide review for features they lead on). And it's the OWNERS that frequently push teams towards OT.1 reply 0 retweets 1 like -
Replying to @slightlylate @Rich_Harris and
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.
1 reply 0 retweets 0 likes -
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
What this means, in practice, is that doing good feature development requires collaboration and iteration. And it means being able to effect change in important codebases. So we need to iterate in those codebases when doing feature development.
2 replies 1 retweet 0 likes -
currently reading those two posts, but to me this sounds like the tail wagging the dog
1 reply 0 retweets 1 like -
Imagine trading places with a browser engineer. A standards body stamps a clearly problematic design with their seal of approval. Neither you nor any of your engine builder peers think it's a good idea. Does it get implemented, particularly when doing so means taking a risk?
2 replies 0 retweets 0 likes
All good design work -- the stuff that gets to eventual interop and which folks don't hate -- is the result of a collaboration between platform developers and web developers. One party calling the shots never works, and putting standards before design iteration doesn't either.
-
-
I'm sure the browser engineers would hate it, just as companies often hate adhering to regulations and laws dreamt up by governments and lawmakers. The answer in both cases is for the rule-setters to take the advice given by industry seriously, without ceding power to it
1 reply 0 retweets 4 likes -
It doesn't seem we're talking about the same things.
1 reply 0 retweets 0 likes - 2 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.