I think Chris is on to something here when he identifies one of the biggest issues with CSS growing out of control:
The developers are afraid of the CSS.
If you want to understand the thinking behind this style guide guide, be sure to read Brad’s style guide guide guide.
A smart approach to creating patterns as symbols in Sketch. Sounds like diligence and vigilance is required to make it work, but then, that’s true of any pattern library.
A great piece from Danielle on the different mental models needed for different languages. When someone describes a language—like CSS—as “broken”, it may well be that there’s a mismatch in mental models.
CSS isn’t a programming language. It’s a stylesheet language. We shouldn’t expect it to behave like a programming language. It has its own unique landscape and structures, ones that people with programming language mental maps might not expect.
I believe that this mismatch of expectation is what has led to the current explosion of CSS-in-JS solutions. Confronted with a language that seems arbitrary and illogical, and having spent little or no time exposed to the landscape, developers dismiss CSS as ‘broken’ and use systems that either sweep it under the rug, or attempt to force it into alignment with the landscape of a programming language — often sacrificing some of the most powerful features of CSS.
I had a chat with Toby Osbourn over Skype. He’s writing a book all about print stylesheets so that’s we talked about.
It’s fascinating to look back at this early proposal for CSS from 1994 and see what the syntax might have been:
A one-statement style sheet that sets the font size of the h1 element:
h1.font.size = 24pt 100%The percentage at the end of the line indicates what degree of influence that is requested (here 100%).
A nice rundown of some of the fun you can have with viewport units.
I’m very glad the problems with vh units I wrote about a little while back is getting fixed in Chrome for mobile.
Dan describes his approach to maintainable CSS. It’s a nice balance between semantic naming and reusable styles.
Warning: the analogies used here might make you very, very hungry.
Harry clearly outlines the performance problems of Base64 encoding images in stylesheets. He’s got a follow-up post with sample data.
Sensible advice from Harry—only style what you mean to style.
This is a very thoughtful analysis of different approaches to writing maintainable CSS, which—let’s face it—is the hard bit.
I often joke that I don’t want to hire a code ninja. Ninjas come in the middle of the night and leave a bloody mess.
I want a code janitor. Someone who walks the hallways of code, cleaning up pieces, dusting up neglected parts, shinning up others, tossing unnecessary bits. I prefer this gentler, more accurate analogy. This is the person you want on your team. This is a person you want in your code reviews.
Also, can I just say how refreshing it is to read an article that doesn’t treat the cascade like a disease to be wiped out? This article even goes so far as to suggest that the cascade might actually be a feature—shock! horror!
The cascade can help, if you understand and organize it. This is the same as any sophisticated software design. You can look at what you’re building and make responsible decisions on your build and design. You decide what can be at a top-level and needs to be inherited by other, smaller, pieces.
There’s a lot of really good stuff in here to mull over.
My hope for this article is to encourage developers to think ahead. We’re all in this together, and the best we can do is learn from one another.
Here’s a fun game to help practice those CSS selectors.
A way of declaring the scope of an element’s layout and paint styles, which browsers can then use as a hint to optimise performance. It’s already shipping in Chrome and Opera.
Ensure that your class names never go out of sync with your style declarations with this one simple trick:
Take any CSS rule you want to apply, replace : by -, and dots by -dot-, and you get the name of the corresponding universal css classname.
The only thing missing is immutability, so I would suggest also putting !important after each declaration in the CSS. Voila! No more specificity battles.
Enduring CSS (not int the sense of “put up with” but in the sense of “long-lasting”) is a new book by Ben Frain all about writing and maintaining modular reusable CSS.
You can read the whole thing for free online or buy an eBook.
We tend to use a variant of BEM in our CSS at Clearleft. Glad to see that when we’ve hit these issues, we’ve taken the same approach.
Wonderfully creative use of CSS gradients, borders, box-shadows, and generated content.
I very much agree with Orde’s framing here: I don’t think it makes much sense to talk about “above the fold” CSS …but it makes a lot of sense to talk about critical CSS.
And, yeah, it’s another example of progressive enhancement.
A terrific quiz about browser performance from Jake. I had the pleasure of watching him present this in a bar in Amsterdam—he was like a circus carny hoodwinking the assembled geeks.
I guarantee you won’t get all of this right, and that’s a good thing: you’ll learn something. If you do get them all right, either you are Jake or you are very, very sad.
This is a well-reasoned, thoughtful article on avoiding class names in CSS …but I don’t agree with it. That said, perhaps there’s a reasonable middle ground to be found between this extreme stance and the opposite (but in some ways just as extreme) stance of OOCSS.