The most broken inconsistency across web browsers is printing, print preview, print-related CSS, etc. No print media related features made it onto this list :(
Personally, I like the concept, but not the execution. It only changes its size externally on DOMContentLoaded, and again on load. So, if the user e.g. expands a <details> element, that won't update the size of the iframe. If the width of the main window changes size, resulting in the iframe changing width, resulting in the content within becoming a different height, it won't update the size of the iframe.
In cases like this, the iframe has to manually call window.requestResize(). And… that just doesn't feel like a big step up from the hacks we do today.
> A feature like WebBiDi has nothing to do with the CSS engine team.
This example is almost true, but not entirely. For example the getBoxQuads API was something that testing tools wanted, which led to it being standardised [1]
More generally there can be surprising dependencies between features when it comes to implementation (e.g. both DOM and layout features might depend on accessibility work).
So from an implementer point of view, trying to encode the team that would do the work into the ranking tool is harder than it might sound.
One can imagine providing categories of features to help people find things that they're interested in. The counter argument is that people might just filter down to the kind of proposals they think they want, and end up missing things that were more important but got put in a different category.
In the end this simple approach proved helpful to us (Mozilla) last year, so we decided to do more or less the same again.
Fixed! Thanks for the suggestion. There was a whole read-only mode already there for when the process closes. I just didn't think of using it when the user is logged out.
Responsive iframes been a long time coming.
Good to see.
In cases like this, the iframe has to manually call window.requestResize(). And… that just doesn't feel like a big step up from the hacks we do today.
This example is almost true, but not entirely. For example the getBoxQuads API was something that testing tools wanted, which led to it being standardised [1]
More generally there can be surprising dependencies between features when it comes to implementation (e.g. both DOM and layout features might depend on accessibility work).
So from an implementer point of view, trying to encode the team that would do the work into the ranking tool is harder than it might sound.
One can imagine providing categories of features to help people find things that they're interested in. The counter argument is that people might just filter down to the kind of proposals they think they want, and end up missing things that were more important but got put in a different category.
In the end this simple approach proved helpful to us (Mozilla) last year, so we decided to do more or less the same again.
[1] https://github.com/w3c/csswg-drafts/issues/10537
The current interop has CSS features, WebRTC, WebTransport, IndexedDB, PWA stuff, etc:
https://wpt.fyi/interop-2026
Fixed! Thanks for the suggestion. There was a whole read-only mode already there for when the process closes. I just didn't think of using it when the user is logged out.
> When authorized, the GitHub App will be able to determine which resources you can access that the app can also access.
The 'app' is used for login only. It has no access to resources.