3 ms·

Constructible Stylesheets was released despite objections from both Safari and Firefox when it had both badly designed API and an easily reproduced race conditi

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#issuecomment-577781329 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 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-discuss/c/RWw9-bGrewU 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. Other chromium-based browsers may want to know as well, via these channels." Thankfully, there will be a change. At some point. === These are two I know of, that's why I said "sometimes". As Chrome releases 400 new APIs each year, it's impossible to track them all.

jefftk 4y ago
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#issuecomment-577832197 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.)
- illiarian 4y ago
  > 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#issuecomment-577839892 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 changes because you shipped it? I’m sorry but that’s just not how standards work. --- end quote --- > With WebMIDI they're saying they want to do an announcement before making the change. Indeed. Once again: because they shipped an API that neither Safari nor Mozilla supported. Now that this issue has surfaced (no thanks to Chrome), they can't just roll it back or fix it because people already rely on this behaviour, which they implicitly acknowledge.

jefftk 4y ago

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#issuecomment-577832197 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.)

illiarian 4y ago
> 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#issuecomment-577839892 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 changes because you shipped it? I’m sorry but that’s just not how standards work. --- end quote --- > With WebMIDI they're saying they want to do an announcement before making the change. Indeed. Once again: because they shipped an API that neither Safari nor Mozilla supported. Now that this issue has surfaced (no thanks to Chrome), they can't just roll it back or fix it because people already rely on this behaviour, which they implicitly acknowledge.