The last couple of weeks looked quiet on the web platform, though it is hard to call it sleepy when the roadmap for the whole year just dropped. Modern CSS features are going from experimental hacks to baseline reality faster than most WordPress devs can track. Between the Interop 2026 announcements and new pseudo-classes landing in Safari, this is the year we get to delete some of our clunkiest JavaScript workarounds.
The Interop 2026 roadmap: no more “it works in Chrome”
If a client has ever called you because their checkout looks broken on a three-year-old iPhone, you know what browser inconsistency costs. Chrome, Safari, and Firefox just published their targets for Interop 2026, and they are aiming at high-demand features like @property and container queries behaving the same way everywhere.
That part matters more to me than any single new property. I have burned too many hours debugging race conditions in ResizeObserver just to fake what container queries do natively. If you want to see how we are already backing away from heavy abstractions, I wrote about Tailwind components vs utilities.
Style queries: the difference between : and =
Temani Afif recently pointed out a distinction in style queries that is easy to miss. Most developers write the colon (:) for a literal match, but the equals sign (=) lets the browser evaluate the computed value of a variable instead. That matters as soon as you are dealing with calc() results or relative units in your WordPress theme’s theme.json.
/* Literal match - fails if --Problems is calc(98 + 1) */
@container style(--Problems: 99) {
.element { color: red; }
}
/* Computed match - works even if it's a calc() result */
@container style(--Problems = 99) {
.element { color: green; }
}Middle truncation without the JS bloat
I once had a client who insisted their WooCommerce product filenames be truncated from the middle (e.g., very-long-product-name...final.jpg). Back then I reached for a messy regex-based JS snippet that felt like overkill for the job. Between the Flexbox tricks Wes Bos has been sharing and possible native support for ::highlight(), a CSS-only version is getting close.
Native text-overflow: middle-ellipsis is still an open ticket on the W3C draft, but these workarounds already ship far lighter than the legacy scripts they replace. Same story as the other modern CSS patterns that took over from older hacks.
Declarative dialogs instead of jQuery modals
This one is HTML more than CSS, but the Invoker Commands API is the update I have been waiting for. You can open a modal <dialog> without a single line of JavaScript, using the commandfor attribute on the button. It is native, accessible, and works in all modern browsers as of recently.
<button commandfor="my-modal" command="show-modal">Open Modal</button>
<dialog id="my-modal">
<p>No JavaScript required!</p>
<form method="dialog">
<button>Close</button>
</form>
</dialog>Smarter type scales with :heading
Safari Technology Preview 237 started trialing the :heading pseudo-class. Instead of h1, h2, h3, h4, h5, h6 { ... } you write :heading. Put that together with pow() and a whole typographic scale fits in a few lines of CSS. I am already working out how it fits into my Gutenberg block CSS strategies.
If this stuff is eating your dev hours, I can take it on. I have been wrestling with WordPress since the 4.x days, and I know which new features are safe in production and which will break your layout on older browsers.
Stop writing CSS like it is 2015
The platform is getting to the point where you do not need a library for every small UI interaction. border-shape gives better control over component corners, style queries make themes more reactive, and both land in the same place: less code to ship. Do not get distracted by the shiny stuff. Pick the features that clear your actual bottlenecks.
