Of course there are a few options for templating/build systems to work around this (e.g. only output styles on the first instance, using a class name rather than going schemaless), effectively a very minimal rendering overhead trading off a small chance of conflicts.

Duplication compresses well (brotli for single doc, dictionaries for cross doc) so the network overhead is minimal.

But currently browsers don't handle large volume of <style>s well (think every component having it's own... huge runtime style recalc overhead) so we need some form of dedupe.

Sweet! ☺️

Yeah, if you use schemaless @scope, you have to inline inside the element in your HTML.

This means every element renders co-located with it's styles, if an element doesn't render, no style is shipped and given HTML is streamed, you effectively get browser-native critical CSS.

If performance improves, schemaless @scope could be a great solution for localising component styles, limited change of clashes, all while giving us critical CSS out-of-the-box with zero build process.

Shared compression dictionaries will mean that penalty of inline CSS across pages is limited too.

Plus data attributes don't offer any API for lifecycle methods (like custom elements do, and custom attributes should), so you end up writing your own mutation observer which is no fun 🤢

Custom attributes will be great for keeping things more composable. I’d estimate 8/10 custom elements I write could (and should) be custom attributes.

I love building custom elements but quickly end up with a deep DOM when keeping them small and nesting, also you often have to code with this nesting specifically in mind.

*2026 page

On the 2026 pay your ticket form is only listing the student and diversity options, not sure if that's intentional?

For what it's worth, you can follow the WebKit standards position here: github.com/WebKit/stand... – it's currently awaiting a response.

And for completeness, here's the one for Firefox: github.com/mozilla/stan...

You’ve given me the curse too now 😭

`width` and `height` are supported on `<source>` for this purpose.

Use <img> for the mobile image, width and height can be anything as long as they as 1:1 ratio.

Add a <source> with your 16:9 image path and an appropriate media query, then set width and height to any values that are a 16:9 ratio.

All correct, except the ‘hand assembled’ part: after each build, I have `zstd` train a dictionary on all my HTML content.

I use a Netlify Edge Function to dynamically rewrite the request path to the .dcz version.

Huge thanks to @patmeenan.com, @programmingart.bsky.social & @yoav.ws for their support on this!

...not to mention Pat & Yoav's work on the spec itself! 🧠 🧠 🧠

I've bought a ticket, so I'll likely see you there @lukewarlow.dev 🙌

I figured I can just gift it to one of my mentees or as a diversity ticket if it turns out I can't make it.

Was there a recording / were David’s slides uploaded anywhere?