They said the same thing about jQuery, where there was arguably a stronger case to be made. People who shout "Build X into the browser" usually miss how poorly designed popular systems are. Which is the right tradeoff for libraries and the wrong tradeoff for the permanent web.
-
-
Replying to @wycats @slightlylate
Laurie Voss Retweeted Laurie Voss
Firstly, please stop arguing with a joke:https://twitter.com/seldo/status/1135212478810509312?s=21 …
Laurie Voss added,
1 reply 0 retweets 1 like -
Secondly, we absolutely did it with jQuery when we made Document.querySelector().
1 reply 0 retweets 6 likes -
Replying to @seldo @slightlylate
I'd say that document.querySelector was a careful and very minimal incorporation of a piece of jQuery. The browser never did incorporate arguably the most popular aspect of jQuery: ubiquitous chaining.
1 reply 0 retweets 3 likes -
It's also a case study in close-but-not-quite: qSA was lazy in the sense that it reused the engine matching system for a selector, which is document-wide...but that's not what any library did. So we all still had to wrap it. The return type was also a dud.
2 replies 0 retweets 4 likes -
...which is why -- in the modern era -- we study what libraries *actually do* and preflight many new features with Origin Trials to collect feedback before path dependency sets in: https://developers.chrome.com/origintrials/#/trials/active …
1 reply 0 retweets 2 likes -
Replying to @slightlylate @seldo
I'm not convinced preflight would have caught the qSA mistake. What's the incentive to spend enginering resources preflighting qS and qSA?
1 reply 0 retweets 1 like -
I literally told browser engineers pre-shipping that qSA was wrong in at least the selector dimension. As for incentives, browsers *hate* being wrong. Deprecating APIs takes huge amounts of effort; same for community opprobrium for a choice you can't get a mulligan on.
2 replies 0 retweets 2 likes -
Hmm, given that you did tell them and they didn't listen, sounds like the issue wasn't lack of available data but that it wasn't taken properly into account. How should we fix that class of problems? More data reinforcing that others would face the same issues?
2 replies 0 retweets 2 likes -
My hope is that some of what we've done in the Blink process forces feature developers to honestly collect and reckon with that sort of feedback; e.g. with incubation and Origin Trials. Not all vendors use these processes. I expect our batting average would go up if they did.
1 reply 0 retweets 2 likes
The current moment where Blink is first to implement most things is an historical aberration. In a moment where, e.g., Apple decides Safari is strategic, we'd be back to the old ways (see also: force touch events, notch CSS, Apple Pay for web, etc.)
-
-
Replying to @slightlylate @littledan and
I want a world where more vendors are competing on different ideas about how to solve important developer problems in ways that don't lead to burn-in or groupthink dominating the design phase.
1 reply 0 retweets 2 likes -
Selectors are an unfortunate example because - the API was straight forward - the userspace examples were unified - the mistake was obvious and pointed out to them by people they respected I don't think that combination of factors happens a lot these days.
0 replies 0 retweets 2 likes
End of conversation
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.