Keeping up with Modern CSS and HTML APIs takes real time these days. You get comfortable with responsive design, and then the platform ships something that changes how rendering works: semantic HTML drawn inside a canvas, or CSS picking the image source instead of the markup. The settled way of doing things keeps moving.
Rendering HTML inside a canvas
The HTML-in-Canvas API is getting a lot of attention right now, and for once the attention is deserved. It is a native primitive that renders real, accessible HTML inside a <canvas> element, so you are not reaching for an html2canvas workaround. Content lands in the accessibility tree, and Ctrl+F search works inside the texture. If you build heavy data visualizations or complicated UI animations, that changes what is affordable.
For now you need Chrome 146 or later plus the chrome://flags/#canvas-draw-element flag, so it is squarely experimental. Still, mixing 3D WebGL scenes with ordinary HTML components on one surface is the part I want to try. We wrote more about where the browser is heading in modern CSS patterns.
Replacing an image with pure CSS
I thought I had seen every trick for swapping images until I went back to the content property. Replacing an <img> source straight from CSS has been part of Modern CSS and HTML APIs for close to a decade, and I almost never see it used in production.
On a legacy theme where the markup is off limits, you can change the image source and the alt text from the stylesheet. That is enough for a quick patch, or for swapping branding, without going back into the PHP templates.
/* The naive approach usually involves background-image hacks.
The better way uses the content property directly. */
img {
content: url('new-high-res-image.png') / "New descriptive alt text";
}
/* It even works with image-set() for responsive delivery */
img.header-logo {
content: image-set(
url("logo-1x.png") 1x,
url("logo-2x.png") 2x
);
}Where sizes=”auto” helps
Responsive images have been a drag on WordPress performance for years. Between working out breakpoints and keeping srcset honest, it is easy to get wrong. For lazy-loaded images, sizes="auto" takes most of that off your hands.
Rather than hardcoding media queries into your HTML, the browser works out the right size from the layout at runtime. That fits what the WordPress Core performance roadmap is after, which is better native image handling.
E-ink quirks and other platform updates
Most of us design for high-refresh OLED screens, so a project like Rekindle is a useful jolt: e-ink has its own constraints. Media Queries Level 5 gives us update and monochrome for exactly this, but the proprietary browsers on Kindle and Boox devices tend to ignore them. Messy, and a decent argument for wanting Modern CSS and HTML APIs to behave the same on every device.
Firefox 150 shipped :muted and light-dark() with image support, and Safari Technology Preview 242 is trying out fuller attr() functions. Good news on both counts, though the gaps between browsers mean fallbacks are still part of the job.
If this modern CSS stuff is eating your dev hours, hand it over. I have been wrestling with WordPress since the 4.x days.
What I would do with this
Baseline support on its own is not a reason to adopt anything. sizes="auto" I would use now, on lazy-loaded images. content replacement I would keep in the back pocket for themes I cannot edit properly. HTML-in-Canvas stays on the watch list until it works without a flag, however much I want to build something with it.
