3 ms·
I'm guessing the problem this is trying to solve Originally we had prefixed APIs. webkitAudioContext for example. The idea was the prefix would be removed. Unf
by greggman 11y ago
I'm guessing the problem this is trying to solve
Originally we had prefixed APIs. webkitAudioContext for example. The idea was the prefix would be removed. Unfortunately the problem was thousands of websites would use the prefixed API. Now you can't remove the prefixed version without breaking many many sites. Worse, there's even arguably an incentive for other browser to add someone else's prefix because they want their browser to run all those same sites.
So, a couple of years ago the browser vendors all agreed, no more prefixes. They'll put all the new stuff behind flags that developers can opt into. The problem with that is no one uses them. The users aren't going to set the flag so no devs have any reason to try out the APIs. There's no re-world usage to see that the APIs work, to see what issues come up.
So, there's this one. Select a few special devs, let them use the features, enable those features for their domain only. Real users get to use the features with no work on their part. It solves the problem to some extent. The devs know the feature might not last. They're also signed up to get notification if the feature is going to change or be removed. And, I guess their motivation is to one up their competitors.
And that last part is the whole problem with this proposal. Unless any dev can sign up then only special "chosen" devs get the competitive advantage. That feels wrong for some reason. I don't have a better solution to suggest though.
edit:
-- ugh --
I suppose I should have clicked the link which said all of this
https://infrequently.org/2015/08/doing-science-on-the-web/ https://infrequently.org/2015/08/doing-science-on-the-web/