One thing I gained a stronger awareness of (simply from working with checkboxes) is that it’s important to progressively enhance UI components, so that a fancy custom one is able to fall back to the default browser styles and functionality. This way, a user can still access the UI if JavaScript or CSS fail.
Rebuttals to the most oft-asked requests for browsers to change the way they handle CSS.
A really interesting proposal from Lea that would allow CSS authors to make full use of selectors but without increasing specificity. Great thoughts in the comments too.
Following on from Ire’s post about linting HTML with CSS, here’s an older post from Ebay about how being specific with your CSS selectors can help avoid inaccessible markup getting into production.
In a post called Side Effects in CSS that he wrote a while back, Philip Walton talks about different kinds of challenges in writing CSS:
There are two types of problems in CSS: cosmetic problems and architectural problems.
The cosmetic problems are solved by making something look the way you want it to. The architectural problems are trickier because they have more long-term effects—maintainability, modularity, encapsulation; all that tricky stuff. Philip goes on to say:
If I had to choose between hiring an amazing designer who could replicate even the most complicated visual challenges easily in code and someone who understood the nuances of predictable and maintainable CSS, I’d choose the latter in a heartbeat.
This resonates with something I noticed a while back while I was doing some code reviews. Most of the time when I’m analysing CSS and trying to figure out how “good” it is—and I know that’s very subjective—I’m concerned with what’s on the outside of the curly braces.
selector {
property: value;
}
The stuff inside the curly braces—the properties and values—that’s where the cosmetic problems get solved. It’s also the stuff that you can look up; I certainly don’t try to store all possible CSS properties and values in my head. It’s also easy to evaluate: Does it make the thing look like you want it to look? Yes? Good. It works.
The stuff outside the curly braces—the selectors—that’s harder to judge. It needs to be evaluated with lots of “what ifs”: What if this selects something you didn’t intend to? What if the markup changes? What if someone else writes some CSS that negates this?
I find it fascinating that most of the innovation in CSS from the browser makers and standards bodies arrives in the form of new properties and values—flexbox, grid, shapes, viewport units, and so on. Meanwhile there’s a whole other world of problems to be solved outside the curly braces. There’s not much that the browser makers or standards bodies can do to help us there. I think that’s why most of the really interesting ideas and thoughts around CSS in recent years have focused on that challenge.
Here’s a fun game to help practice those CSS selectors.
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.
I somehow missed this when it was first published last Summer: a collection of twelve obscure CSS knowledge grenades.
You learn something new every day. I just learned twelve somethings.
A tool for getting instant visual feedback on your nth-child selectors. Considering that the way I figure out nth-child selectors is to try randomly changing numbers until it works, this should be quite useful for me.
A terrific bit of smart CSS thinking from Heydon Pickering.
You know he’s speaking at Responsive Day Out, right?
This visual approach to demonstrating how CSS selectors work is really handy.
David gives a quick rundown of some of the selectors we can expect to see in CSS4.
I really like this proposal to allow for more nuanced linking using CSS selectors in fragment identifiers (though I worry about the overloading of the # symbol in URLs).
I agree with Oli’s conclusion:
Save IDs for fragment identifiers or JavaScript hooks.
This is an excellent idea from Andy: selector queries. Like media queries but at the component level. Quite often it isn’t the width of the viewport that matters, it’s the width of the containing element for whatever you’re trying to style.
Nicholas and Nicole have unveiled the CSS companion to JS Lint. And yes, it will your hurt your feelings.
The selector of the beast does not exist.