css musings

Getting the hang of css can be tricky business. Certainly now that different ideologies are fighting for dominance css has become a genuine source of confusion. The devil is often in the detail though, so I'll be sharing some smaller tips and hints that should help you perfect your css skills, while crushing some of the more hardened myths in the meantime.

focus on :focus / the keyboard's hover

date
May 29, 2013
permalink

I care about accessibility, I truly do. But whenever I'm stuck in css limbo or pondering some html fluffiness I tend to neglect it, if only just a little. Building a website is a minefield and there's only so much time, sadly accessibility is often the first to go. How to solve this? Just try to build accessibility right into your work flow, forcing you to apply some commonly forgotten accessibility rules without having to explicitly think about them all the time. One such example? :focus styles.

:focus is the keyboard user's :hover, but keyboard users are easily forgotten in the development/test process. I'm a mouse man myself, as are most people who surf the web. But there's still a sizable user base who prefer keyboard navigation (occasionally, maybe often, some always) and they shouldn't be left in the cold. It becomes a serious problem when you realize that default browser :focus styling can cause some harm to your visual design. There are workarounds of course, but none are without danger. In most cases, people just remove the default :focus styles and forget to apply a new style. Not good.

Since :focus doesn't really differ from :hover from a conceptual point of view, we can safely bind both styles together. This is accepted behavior, but writing it out in full each time can be quite bothersome, to the point where it once again gets neglected. I at least never really managed to anchor it into my work flow. That's where less/sass could help us out though (featured code is less).

/* :focus reset*/ *:focus {outline:none;} /* less function */ .hover(@css) {&:hover, &:focus {@css}} /* use in css */ .selector {[rules]} .selector {.hover(~"[rules]");}

Instead of writing the :hover code directly, we just copy the original selector and use a nested less function to apply the same :focus and hover styles. You can of course apply the less function directly into the original selector, but personally I find it easier to keep track of hover and focus styles when adhering to the above layout. So as long as you don't forget to set your hover states, keyboard users will have the same styles applied as mouse users. Sweet.

css selector length / myth busting

date
May 24, 2013
permalink

If I read one more misguided css post or article on css selector length I think I'm going to explode. Somehow component-based css ideologies managed to brainwash our community and launched a faux best practice that the length of css selectors is something your average csser should worry about. Well, it is not, nor should it ever be.

While css selectors are an important part of the css syntax, the length of a selector is largely defined by the html structure, not by the skills of the csser. Of course people add 'unnecessary' elements to their selectors from time to time (sometimes for clarity, sometimes for future-proofness, sometimes because they're a little too protective of the scope and sometimes out of error). But there is no way you could ever restrict the length of a css selector to a specific number (I read some blogs going as low as just 3 of 4 elements). In the end the html dictates the length of a css selector, the csser's job is to write the correct selectors.

If you want to apply a modular approach to your css code you need to make sure you know your way around preprocessors. While a modular css approach can only be encouraged, massacring your html code for it is plain stupid if you could just as well make an abstraction (mixins) of your styling and apply these mixins to the right selectors. That's what preprocessors are for, as they allow you to implement both a modular html and modular css approach.

And unless you're working on a website in the range of the Alexa Top 500, you don't need to worry too much about performance either. It's best to test for yourself of course, but seeing the data on my blog (as someone who doesn't mind writing a selector of 10+ elements if necessary) we're talking actual single-digit milliseconds here, even in "unoptimized" form. Unless you're a true performance zealot that doesn't care about maintainability and correctness, the impact is negligible.

Css selectors aren't about length, they are about html structures and targeting just the right elements.