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 :(
I vote for them basically every year and have submitted in the past. Every year I'm told that there's no way for WPT to properly test print stuff so those proposals are pointless
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.
A lot of these are CSS-related. Not sure why so much effort is still being devoted to piling kludges upon kludges on the train-wreck that is CSS.
CSS is one of the worst (web) technologies, breaking the very concept of composability, a core technique of complexity management. It also has all sorts of constructs trying to replicate the features of a proper programming language. Rampant use of CSS is an architectural smell.
And yet people will defend it to death. Every large project I have inherited has massive CSS files filled with hairy rules, utterly unmaintainable despite whatever people will tell you.
In my own projects now, large or small, I refuse to use CSS broadly. Except for a few global styles in a single small CSS file, I use inline styles for pretty much everything, combines with other code in a neatly composable components. This works very well.
Sorry for my strong opinions, but in my view the over-reliance on CSS and amount of work on it has held back the web from being what it really can be for rich apps. What we should be aiming for is to build in rich and very customizable components right into HTML with real-world sophistication. And allow websites to be installed as apps easily. These alone will do more for the web that all these CSS band-aids.
> In my own projects now, large or small, I refuse to use CSS broadly. Except for a few global styles in a single small CSS file, I use inline styles for pretty much everything, combines with other code in a neatly composable components. This works very well.
Inline styles are CSS. It sounds like you find components easier to compose when their CSS is applied directly to elements rather than via selectors, which is totally reasonable. But doesn't that undercut the broader claim that CSS itself somehow inherently breaks composability?
The problem with CSS is the cascade and how it is not scoped. It's like global variables in code. And that can be traced back to it's roots 20+ years ago as a way to style "documents" vs applications that are naturally composed of self-contained UI components.
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.
I love the ranker. Good job, guys; you should open source it.
Cheers! It's here https://github.com/mozilla/interop-stack-rank
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 :(
Anyone could submit a proposal. Look out for that part of the process next year.
I vote for them basically every year and have submitted in the past. Every year I'm told that there's no way for WPT to properly test print stuff so those proposals are pointless
You can suggest an "investigation area", which is essentially "how can we make the tests better".
Where are the proposals without signing in?
https://github.com/web-platform-tests/interop/. But… yeah, they should be on the site even before you log in. Let me fix that…
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.
You also need to know which resources I can access on GitHub. You don’t need that.
This seems like bad wording on GitHub's part https://docs.github.com/en/apps/using-github-apps/authorizin...
> 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.
How’s the gap decoration proposal coming along? Last update was the Edge post introducing it…
https://blitz.is/wpt/css/css-gaps
So nobody's even started on it except Chrome.
It's shipped in Chromium only. It's one of the Interop 2027 proposals, so it's one of the choices in the list.
A lot of these are CSS-related. Not sure why so much effort is still being devoted to piling kludges upon kludges on the train-wreck that is CSS.
CSS is one of the worst (web) technologies, breaking the very concept of composability, a core technique of complexity management. It also has all sorts of constructs trying to replicate the features of a proper programming language. Rampant use of CSS is an architectural smell.
And yet people will defend it to death. Every large project I have inherited has massive CSS files filled with hairy rules, utterly unmaintainable despite whatever people will tell you.
In my own projects now, large or small, I refuse to use CSS broadly. Except for a few global styles in a single small CSS file, I use inline styles for pretty much everything, combines with other code in a neatly composable components. This works very well.
Sorry for my strong opinions, but in my view the over-reliance on CSS and amount of work on it has held back the web from being what it really can be for rich apps. What we should be aiming for is to build in rich and very customizable components right into HTML with real-world sophistication. And allow websites to be installed as apps easily. These alone will do more for the web that all these CSS band-aids.
> In my own projects now, large or small, I refuse to use CSS broadly. Except for a few global styles in a single small CSS file, I use inline styles for pretty much everything, combines with other code in a neatly composable components. This works very well.
Inline styles are CSS. It sounds like you find components easier to compose when their CSS is applied directly to elements rather than via selectors, which is totally reasonable. But doesn't that undercut the broader claim that CSS itself somehow inherently breaks composability?
OK, but CSS is not just styles; its in the name: Cascading Style Sheets. The cascading is the problem. Plus it trying to be a programming language.
The problem with CSS is the cascade and how it is not scoped. It's like global variables in code. And that can be traced back to it's roots 20+ years ago as a way to style "documents" vs applications that are naturally composed of self-contained UI components.
It should be noted that as of now there are pretty good ways to deal with the cascade
> Every large project I have inherited has massive CSS files filled with hairy rules, utterly unmaintainable despite whatever people will tell you.
Sounds like a very good reason to work on css features to make it simpler to use
Some of these are pretty huge.
Responsive iframes been a long time coming.
Good to see.
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.
I remember <iframe seamless> being proposed many many years ago. I wonder why that was rejected.
This needs to support category specific ranking. A feature like WebBiDi has nothing to do with the CSS engine team.
> 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.
[1] https://github.com/w3c/csswg-drafts/issues/10537
Why does that matter? These are browser features in general for the upcoming interop-2027
The current interop has CSS features, WebRTC, WebTransport, IndexedDB, PWA stuff, etc:
https://wpt.fyi/interop-2026