Robin’s hot take on why CSS is awesome
This week I’ve been reading a bit about An Event Apart Seattle which seemd to be a wonderful event for all. Jeremy Keith’s notes on Rachel Andrew’s talk was particularly interesting and especially this part where Jeremy is paraphrasing Rachel here:
CSS tries to avoid data loss. That’s why the “CSS is awesome” text overflows the box. You don’t want the text to vanish. Visible overflow is messy, but it’s better than making some content disappear.
It’s funny to me that I’ve never thought about this before, but the “CSS is awesome” joke is actually kinda sorta showing how awesome CSS really is. Yes, the overflow is unexpected but the overflow is better than the content being completely unreadable or cut off by its parent in some nasty way by default. Accessibility should always beat any fancy visual design or text alignment.
Chris also jotted down some notes about Rachel’s talk and made note that:
Rachel regularly pointed out that we don’t know how tall things are in web design, which is just so, so true. It’s always been true. The earlier we embrace that, the better off we’ll be. So much of our job is dealing with overflow.
I like that definition of the problem and I totally agree. So much design happens after a designer has handed over the work to an engineer and I think it’s often the hardest part about being a front-end engineer: finding all the variables and all the possible ways in which this one thing could break.
There’s another note that Jeremy makes from Rachel’s talk that I found interesting on this point:
Our previous layout systems relied on percentage lengths for widths. Those values had to add up to 100%, and no more. People tried to do the same thing with flexbox. People made “grid systems” with flexbox that gave widths to everything. “Flexbox is weird!”, people said. But the real problem is that flexbox is not the layout method you think it is. It’s for taking a bunch of oddly-sized things and returning the most reasonable layout for those things. It assigns space in a smart way. That solves the problem of needing to give everything a width. It figures it out for you. If you decide to put widths on everything, you’re kind of working against flexbox.
I think this is how layout systems like flexbox and grid have changed things – they’re technologies that are finally acknowledging how much of our work is dealing with unpredictable interfaces. Anyway, the reason why I bring all this up is that it reminds me of one of my favorite articles about CSS. It’s something we published a while back called CSS is Awesome and in that post Brandon Smith argues that:
CSS is hard because its properties interact, often in unexpected ways. Because when you set one of them, you’re never just setting that one thing. That one thing combines and bounces off of and contradicts with a dozen other things, including default things that you never actually set yourself.
One rule of thumb for mitigating this is, never be more explicit than you need to be. Web pages are responsive by default. Writing good CSS means leveraging that fact instead of overriding it. Use percentages or viewport units instead of a media query if possible. Use min-width instead of width where you can. Think in terms of rules, in terms of what you really mean to say, instead of just adding properties until things look right. Try to get a feel for how the browser resolves layout and sizing, and make your changes and additions on top of that judiciously. Work with CSS, instead of against it.
Another rule of thumb is to let either width or height be determined by content. In this case, that wasn’t enough, but in most cases, it will be. Give things an avenue for expansion. When you’re setting rules for how your elements get sized, especially if those elements will contain text content, think through the edge cases. “What if this content was pared down to a single character? What if this content expanded to be three paragraphs? It might not look great, but would my layout be totally broken?”
CSS is weird. It’s unlike any other code, and that makes a lot of programmers uncomfortable. But used wisely it can, in fact, be awesome.
I love so much about this, especially the whole “give things an avenue for expansion” advice. And I reckon this is where so much of my issues with CSS comes into play – I make things too specific, too brittle. I don’t acknowledge all the different ways this one thing might be used or interacted with and I don’t consider the avenues for expansion.
I also adore the advice around trying not to set specific width or height values and, ever since I read this post, I’ve been much more considerate about how content flows in a browser. And finally, this kinda ties into what I realized just the other day: that there’s a considerable difference between layout and appearance when it comes to the web. I wrote about this very subject the other day:
So I’ve begun to think about all CSS as fitting into one of those two buckets: appearance and layout. That’s important because I believe those two types of styles should almost never be baked into one set of styles or one class. Layout on the page should be one set of styles, and appearance (like what a checkbox actually looks like) should be in another. And whether you do that with HTML or a separate CSS class is up for debate.
It’s nothing revelatory or anything and I’ve kind of known about this distinction for a while, but I think all this stuff is tied together; dealing with overflow, accepting the flow of content in a browser, and trying to be considerate of all the daily edge cases that go into web design work.
Web design is unpredictable because our content is unpredictable – but this is what makes our work different from print or any other form of design. And now we finally have the tools to make our interfaces awesome.
SPONSOR
Netlify
Here’s how quick, powerful, and flexible hosting a site on Netlify can be: 1) Connect your repository (like GitHub, GitLab, Bitbucket) 2) Tell it which branch, which directory, and what build command to run 3) That’s it! Netlify will deploy your site live in seconds.
From the Blog
An Introduction to Web Components – This is just day one! We have a five-part series this week digging into the native browser take on components.
Web Standards Meet User-Land: Using CSS-in-JS to Style Custom Elements – Speaking of Web Components, Custom Elements is a major aspect of those. And just because you’ve chosen the native browser version of components, doesn’t mean you have to give up on technologies generally thought of being in conjunction with React-style components, like the CSS-in-JS library emotion.
Design Systems and Portfolios:
In my experience working with design systems, I’ve found that I have to sacrifice my portfolio to do it well.
Little Things That Tickled My Brain from An Event Apart Seattle – There is another bit in here about CSS “data loss,” the concept that alignment causing content to render in a place that is entirely inaccessible (e.g. overflow) and some new flexbox keywords that can prevent that.
7 things you should know when getting started with Serverless APIs – Simona Cotin’s first byline on CSS-Tricks.