There's a GitHub linked above with some feedback but little response. This is also shifting the goalpost, the *design* of the API doesn't appear to have been done in the open (again, GitHub with little comments), it was done in private meetings between FB and Google.
-
-
Replying to @matthewcp @yoavweiss and
There is no immaculate conception for web APIs. The explainer is a request for collaboration and you can shape the future of the API by engaging on GH or OT. What is objectionable about that?
2 replies 0 retweets 0 likes -
Replying to @slightlylate @matthewcp and
Lemmie try another way to describe what's going on here: Some customers (folks working on a heavily used framework) talked about a problem they had with receptive platform engineers. Together they sketched out a straw-person API...
1 reply 0 retweets 0 likes -
Replying to @slightlylate @matthewcp and
...then, they made the a doc to explain the problem and one possible solution and published it, asking for feedback is any constructive sort. Why? Because they could be wrong! It might not actually be the core problem (but rather, adjacent). It could also be the wrong design.
1 reply 0 retweets 0 likes -
Replying to @slightlylate @matthewcp and
Then, to try to understand of the design was good, they built a version based on what came out of that public debate...
1 reply 0 retweets 0 likes -
Replying to @slightlylate @matthewcp and
That process can only really tell you if the thing is *implementable*, not if it solves an important problem in a good way. And BTW, standards committees can't determine that either!...
1 reply 0 retweets 0 likes -
Replying to @slightlylate @matthewcp and
So, they are running an experiment to find out. And it's a *real experiment*. The thesis could be disproven! Has happened to a lot of OTs.
1 reply 0 retweets 1 like -
Replying to @slightlylate @matthewcp and
This is in contrast to the old way of doing things where consensus was valued more highly than evidence. Doing design outside committee, running trials, getting feedback, and iterating are *just good feature design*. And the result should be confidence in the design.
1 reply 0 retweets 0 likes -
Replying to @slightlylate @matthewcp and
...and that confidence should be backed with data. Data that
@yoavweiss and I and other Blink API OWNERS weigh when something is proposed to ship. It's a high bar!1 reply 0 retweets 1 like -
Replying to @slightlylate @matthewcp and
To clear it, the folks moving isInputPending forward will have to demonstrate that the feature has real value, not only that there was agreement in a conference room without any user (developer) feedback.
1 reply 0 retweets 0 likes
So if there's something bad or broken with the design, file issues! Speak up! The entire process has been radically reworked to ensure that feature developers *have* to take that feedback into account and that engaging has low barriers to entry.
-
-
Replying to @slightlylate @matthewcp and
I can't comment on this specific API, but I agree with most of Alex's comments here. I do think one thing that would be helpful is a way of tracking proposals & status in a centralized place. Which used to be the working group issue trackers, but maybe could be a WICG thing.
1 reply 0 retweets 2 likes -
Replying to @AmeliasBrain @slightlylate and
Right now, the WICG list of proposals is just the list of 100+ repos. No way to filter or know which have traction. Compare with the TC39 proposal stages, or
@Surma's https://ishoudinireadyyet.com/ I don't want to be an old grump saying the web is moving too fast. But it's chaotic.1 reply 0 retweets 3 likes - 8 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.