My key takeaways from CSSDay 2024

This was the second time I went to CSSday and I had just as much fun this time as the last. It's incredible to see so many developers embrace and love CSS even more than I do.

It's the only CSS conference in the world (at least I think it is), which seemingly makes CSS a niché thing to be interested in. That's weird, because CSS is the only way to create user interfaces on the web. Yes, we have frameworks and libraries to help us, but CSS is our way of instructing the browser what our UI is going to look like and how it should behave.

Anyway, just a thought. But that's not what this post is about, so here's the things I've learned at this year's conference (in no spesific order).

Design tools falls behind browser possibilities as CSS evolves rapidly

Matthias Ott gave a great talk about new possiblities in CSS and highlighted a growing gap between design tools and modern CSS and the issues that follow. The most notable ones were the fact that design tools still focus on building "screens".

Modern web design need more flexibility than just designing for "mobile", "tablet" or "desktop" screens.

This all boils down to the somewhat stale "mobile-first" approach that we've been sticking to for 10-15 years now. What our user interfaces look like on different screens are today not as important as a component's individual look and behaviour based on user settings and context. Container queries gives us the ability to change a component drastically depending on where it's being used. The :has selector also opens up to altering behaviours or looks depending on the context, and users have larger control over how they want to consume web content through settings in the browser, preferred themes or the use of assistive technology.

Modern CSS solutions makes it possible to create dynamic font sizes based on the viewport through the clamp function. In a design tools however you can only create static font sizes. Design tools lacks a lot of font-weight options and several other font settings that CSS provides. Matthias pointed out that stuff like this creates a divide between the staticness of graphic design and the dynamicness of development.

This whole talk sparked the age-old question of "should designers code?". As someone who's previously worked as a designer and now being a full time front-end developer it's easy for me to say yes to this question, but at the same time I believe it isn't entirely that big of a deal if a designer can code or not. The question has always been about collaboration between designers and developers. We have different strengths and not everyone can be a jack-of-all-trades (or a unicorn). However, designers need to understand that the web has evolved and that we need to think about components and interfaces in a new way. Therefore it's not as much about the design tool flaws as it's about pivoting our mindset a bit. A designer can still design "mobile" and "desktop" screens, but perhaps we should let the developers "fill in the gaps". A developer has the tools available to them to create dynamic font sizes, so let them do that. They have the ability to stress test components used inside different containers or with different user settings applied (like a user's increased font-size settings in the browser, or the use of prefers-reduced-motion).

Having developers influence design decisions do not take away the important work designers do, quite the opposite actually. Let's empower each other - and our users will benefit from it.

Or as Adam Argyle is pointing out in a post on X:

"web designers, sit with your web developers
web developers, sit with your web designers"

I'll stop being afraid to over-engineer my CSS

Kevin Powell did a fun talk about the criticism he recieved when he posted a video about using the min() function to reduce the amount of code in a classic wrapper class, claiming his solution was a form of over-engineering. The video in question:

The backlash to the video sparked an interesting debate: "is something over-engineered just because it's an unfamiliar pattern?".

Well, Kevin encouraged us (and convinced me) through a series of demos and great slides that it's time we step out of our comfort zone and normalize new CSS features like functions, custom properties, logical properties and grid.

In the near future I'll challenge myself to rewrite some of the layout code on this website using newer techniques.

I'm going to avoid aria-label as much as possible

I actually kinda knew this already, but I still use aria-labels. Therefor it was nice to have the reasons for why we should avoid them explained thoroughly by Sara Soueidan. She talked us through a lot of the problems people who use assistive technologies face when we drop the ball on accessibility.

My main takeaway from her talk was how we should prioritize when to use HTML content vs. aria-label vs. aria-laballedby, making me understand it better than ever before. Here's the prefered order of prioritization:

1. Use HTML content always, unless you for some reason are unable to do so

Labelling something (like a list of navigation or the text of a icon link) with text content inside a HTML tag is better than using aria-label. Content will be announced by screen readers and it will get translated by automatic tools like Google Translate. ARIA will not necessarily be translated and therein lies its problems.

If you need to hide the label, use a visually-hidden class instead of aria-label:

<!-- ❌ -->
<a href="https://facebook.com/profile" aria-label="Visit our Facebook profile">
  <svg aria-hidden="true">...</svg>
</a>

<!-- ✅ -->
<a href="https://facebook.com/profile">
  <span class="visually-hidden">Visit our Facebook profile</span>
  <svg aria-hidden="true">...</svg>
</a>

2. Label something with aria-labelledby

If you're not able to add HTML content to the element that need labelling you can always place an HTML tag somewhere else in your code and connect the two with id and aria-labelledby.

<div class="toolbar">
  <button aria-labelledby="orderedList"><svg aria-hidden="true">...</svg></button>
  <button aria-labelledby="bulletList"><svg aria-hidden="true">...</svg></button>
</div>

<span id="orderedList">Insert ordered list</span>
<span id="bulletList">Insert bullet list</span>

3. Use aria-label only when other options isn't available

I can't imagine a scenario in my daily work where point 1 or 2 is not possible, so I'm creating a rule of thumb for myself not to use aria-labels at all. There probably are cases where I'd might need them, but I'll try to avoid them as much as possible from now on.

PS: Adrian Roselli has a great post about the pros and cons on this topic.

Size based media queries can fully be replaced by container queries

Kevin Powell's encouragement to start using the newer features of CSS made me realize that I should embrace container queries to the full.

From now on I’m going to stop using media queries for viewport related changes and replace them with a container query based on the <body>. Container queries support other units like ch, and also handles rem better.

I’ll still use media queries for reduced motion, medias like print, pointer types and dark mode, but in short I’m going all in on CQs now.

/* ❌ */
@media (min-width: 1200px) {
  ...
}

/* ✅ */
html {
  container-name: viewport;
  container-type: inline-size;
}

@container viewport (min-width: 80rem) {
  ...
}

CSS is mystical, so it's important to de-mystify it when teaching someone

What's nice about CSSDay is that it's a room full of 300 really experienced front-end developers and some of the brightest minds in the CSS community — and still people nod in unison when Josh Comeau talked about him always mixing up justify-content and align-items. Knowing that the most experienced people in the biz struggles with simple stuff like this dampens my imposter syndrome.

He also gave an in-depth explanation of why it's called align-items and not align-content (like justify-content) when you want to align something on the cross axis of a flexbox og in a grid.

His talk "How to teach CSS" really drove home the fact that CSS is mystical and sometimes seems inlogical, but there are explanations to everything. And for those of us who sometimes teach CSS it's important to demystify it for the people we're trying to teach, so that it's easier to understand.

And that's what I'll do from now on: I'll stop saying "it's just how it is" when people ask me "why do I need to set display: block on an image to remove the weird white-space at the bottom?".

Notice the weird white-space beneath the image.

(Spoiler: the reason is because an <img> tag is an inline element, meaning it will align itself to the baseline of text. By default text in a HTML document will have a line-height of 110% to 120% unless you've overridden it. The <img> inherits the line-height of the document, giving it some white-space at the bottom (just like text does, although we never question that). The solution is to set the image to display: block so that it doesn't align to the baseline anymore (because block elements don't do that)).

To summarize

There was great talks from everyone, for instance two talks about the ongoing work that's being done with the long awaited masonry functionality (I could listen to Rachel Andrew talk about this all day by the way, she's so good). I could ramble on for pages upon pages about all the inspirational stuff I've experienced at the conference, but I'll leave it here.

I suggest everyone should watch the talks for themselves when they get available on the Youtube-channel a month or so from now on.

Many thanks to the CSSDay organizers for hosting such a great conference. I'll definately come back in 2025 👏.