construct-stylesheets

> With adoptedStyleSheets they're objecting to making backwards incompatible changes Which would not be backwards incompatible if they hadn't shipped something that wasn't agreed on in the first place. Again, slowly: they literally shipped that to production despite loud and explicit objections from both Firefox and Safari. When asked to hide it back behind the flag, "but backwards incompatible change, the framework we're developing is already depending on it" And since you're quoting rniwa, here's the relevant quote https://github.com/WICG/construct-stylesheets/issues/45#issu...: --- start quote --- I feel like I’ve put so much time & energy into making this feature something sane & useful, and all you did was basically to dismiss many of my feedbacks and go with whatever you like and just ship it. And now you’re saying you can’t make ch

In both of your examples they're not saying they "cannot hide it behind a flag because people are already using it": * With adoptedStyleSheets they're objecting to making backwards incompatible changes, which is reasonable: everyone hates browsers breaking sites. But there are ways to do this safely, like changing the name of the property (as rniwa suggested https://github.com/WICG/construct-stylesheets/issues/45#issu...) and if that were the only issue I think they'd have done something like that. * With WebMIDI they're saying they want to do an announcement before making the change. (I do think it's nuts how long they're taking to fix this, and if you look on the blink-api-owners-discuss thread you linked you'll see I've been bugging them about it.)

Constructible Stylesheets was released despite objections from both Safari and Firefox when it had both badly designed API and an easily reproduced race condition. Literally "Note that .adoptedStyleSheets is used on about ~.8% of page loads in Chrome now. Backwards-incompatible changes are definitely an issue here." https://github.com/WICG/construct-stylesheets/issues/45#issu... --- WebMIDI allows enumeration of devices without asking the user for permission: https://twitter.com/denschub/status/1582730988118867968 (note this is a part of a whole bunch of hardware APIs that Chrome just shipped, no consensus needed) Well, what do you know https://groups.google.com/a/chromium.org/g/blink-api-owners-... "this is a case where we're going from no permission prompt to a permission prompt, I think a PSA and developer communication is a good idea.

I literally provided just some of the examples. Those are easily verifiable. Web Transport is shipped by default. What was the input from other browsers? Here's the timeline for HID: https://github.com/mozilla/standards-positions/issues/459#is... Constructible Stylesheets: the spec contained a trivially reproducible race condition, the API was badly specified. Google shipped against any objections and refused to bring it back under the flag. Full discussion here: https://github.com/WICG/construct-stylesheets/issues/45. Shipped in Chrome https://github.com/WICG/construct-stylesheets/issues/45#issu... (may be hidden on mobile) despite multiple unresolved issues. Two years later Chrome did add a better API that people originally requested, other issues potentially remain. You may believe in benevolent Google working hand in hand with others