This is really good breakdown of what’s different about CSS (compared to other languages).
These differences may feel foreign, but it’s these differences that make CSS so powerful. And it’s my suspicion that developers who embrace these things, and have fully internalized them, tend to be far more proficient in CSS.
A nice intro to variable fonts.
Good advice on print styles from Rachel. The browser support situation is frustrating; I suspect it’s because the people working on browsers would rather get stuck in on shinier stuff.
Chris takes us on a whirlwind tour of radial gradients in CSS.
Patrick is thinking through a way to implement :focus-visible that’s forwards and backwards compatible.
Everything old is new again—sometimes the age-old technique of using a 1x1 pixel image to log requests is still the only way to get certain metrics.
While tracking pixels are far from a new idea, there are creative ways in which we can use them to collect data useful to developers. Once the data is gathered, we can begin to make much more informed decisions about how we work.
These experiments with transitioning variable font styles on hover might be silly, but I can see the potential for some beautiful interaction design.
A starter kit of CSS that gives you some basic styles that you can tweak with custom properties.
For when you don’t need the whole boot.
Also:
Shoelace doesn’t ship with a grid system because you don’t need one. You should use the CSS Grid Layout instead.
I approve this message!
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.