Ignoring @seldo's intemperate, self-owning ad-homenim, let's consider what it might mean...there are many versions! A few:
1.) *literally do exactly this*
2.) add building blocks
3.) start from syntaxhttps://twitter.com/seldo/status/1135150260425318400 …
-
Show this thread
-
Replying to @slightlylate @seldo
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.
2 replies 0 retweets 30 likes -
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.
-
-
Replying to @slightlylate @littledan and
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.)
1 reply 0 retweets 1 like -
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 - 1 more reply
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.