With great power, comes great creativity: thoughts from CSS Day 2024

For the last month I’ve been conducting an almost mini tour of Europe. Designed to coincide with a few events I wanted to attend (or avoid), it ended with my now traditional trip to Amsterdam for CSS Day, which this year celebrated its tenth edition.

As ever, I went for the inspiring talks, stayed for the Bitterballen and left with a better understanding of CSS and the overall state of this language for design. A few themes emerged.

Continued refinement

As a conference focused on CSS, its no surprise that representatives from Apple and Google would use it as an opportunity to present their differing proposals for enabling masonry-like layouts.

From Google, Rachel Andrew began by reflecting on the last decade of CSS and looking back at the talk she gave at CSS Day in 2015. As I remarked in my post about last year’s event, this was at a time when talks felt largely theoretical with mention of properties we might be able to use one day. Now, it’s perfectly reasonable to ask if we really need anything more added to CSS. Perhaps the focus should be on refining what we already have?

Before presenting Google’s proposal for a new layout mode to enable the poorly-named-but-likely-to-stick masonry layout, Rachel made the case for fixing a long-standing and fundamental omission from CSS: reading order.

While it has long been possible to change the visual ordering of content (such that it differs from what might be read aloud or navigated using a keyboard), the introduction of flex and grid layouts made it easier to trigger this antipattern.

Firefox’s original implementation of grid layout updated the reading order to follow that which was presented visually, and while some developers wished that was the correct approach, it was a bug that was soon fixed. This essentially left browser makers saying here’s a cool thing, please don’t use it.

Rather than have browsers attempt to work out the correct order, so often dependent on context, the proposed reading-order-items property would allow authors to define this explicitly on a layout container (but not globally so as to prevent misuse).

Why reading-order-items and not reading-order? The later is more concise, yet the former aligns with similarly named properties used on layout containers (and makes it easier to add properties for child containers if needed in later revisions). What do you think it should be called?

Improved understanding

As ever, naming things is hard. Harder still once you’ve lost the perspective of a web developer.

This is the lesson Nicole Sullivan shared as she presented Apple’s masonry proposal. When she joined the WebKit team, she had no idea why people kept using the initials VC (and was afraid to ask). Having eventually realised it stood for ‘video conference’, Nicole was determined not to adopt this opaque term herself. Before long, she was using it habitually, at which point she realised she had lost the perspective of an outsider. This is why browser makers are so keen to get feedback from developers on their proposals.

I found both presentations utterly fascinating, and while I don’t feel especially strongly about either proposal, I feel this debate serves as a powerful reminder that the web’s strength comes from having differing perspectives and a diversity of implementations.

Elika Etemad, no stranger to writing CSS specifications, described CSS as:

a stylesheet language that allows the intent of a designer to be communicated to a browser that executes on it flexibly, robustly, powerfully, understandably, performantly, and compatibly, across all platforms, devices, languages, and writing systems.

That’s a pretty tall order! Not only do CSS properties specified in different modules need to work collectively, they also need to interoperate with properties from other modules too – all while ensuring the overall language remains coherent and understandable.

Josh Comeau explained how he likes to teach CSS as being a series of different modes that you can switch in and out of. Having written CSS for quarter of a century, his explanation of why z-index works in some cases and not others – and that it is not always dependent on the position property being set – was a revelation to me.

As the surface area of CSS grows, the harder it can become to interpret what’s going on. That’s just as true for rendering engines, as it is for developers.

Tab Atkins-Bittner spoke about the new anchor positioning module, which builds upon absolute positioning. It’s going to take a while to get my head around how it works and what it can enable, but I was particularly struck hearing that the value for anchor-name needs to be prefixed with a double dash, similar to how custom variables are named.

Thankfully, somebody asked in the questions session afterwards why this was the case. Tab responded that browser vendors found it difficult to implement the animation property shorthand given it could include a user-defined animation-name. Wanting to avoid this situation again, in this module (and likely others going forward) user-defined values are prefixed with -- so they can be more easily parsed by rendering engines.

While earlier specifications weren’t able to incorporate this lesson, I suspect a best practice will emerge that’ll see developers prefixing all custom values with --, regardless of whether this is a requirement or not. I’m certainly going to start doing this.