The Selector-Space Race
The article “Writing Efficient CSS Selectors” made the front page and generated some discussion on Hacker News today. These are always interesting articles, but rarely of practical value, and show just another way the software development community refuses to scrutinize CSS at the development process level.
Performance is only one concern of a website project. I’ve found that a greater risk by far is scalable stylesheet manageability, a topic with little useful engineering attention. Any decent-sized project is going to have to decompose their presentation declarations into manageable artifacts. This eases collaboration but has the unwanted side-effect of hiding existing selectors in multiple files. Add to this a tight project timeframe, a development team that regards CSS as a second-rate language (as almost all that I’ve encountered do, worsening the more senior they are), and CSS’ lack of usable “selector-spacing” (in the namespace sense), and you have a recipe for thermonuclear battles over selector specificity.
Selector and naming conventions can basically eliminate this problem. Module root elements have a class name that starts with a letter; module nested elements have a class name that starts with a dash. These are combined using the child selector (not the descendant selector!) to constrain their applicability by implying a much stricter subject structure. Each module goes into a separate file in a single directory, where each file shares the name of the module’s root class name.
This brings selector specificity to the forefront and establishes practical, explicit selector-spacing. What was once super-ambiguous, e.g.
body { color: black; }
.menu .item { color: orange; }
.menu .item .menu { color: black; }
.menu .item .menu .item { color: orange; }
/* and on */
is now very precise:
body { color: black; }
.menu > .-item { color: orange; }
Is it the most efficiently-interpreted ruleset? No, and I don’t care. It’s the most efficiently-manageable ruleset. (At least until Web Components are ubiquitous.)
Follow me on Twitter for the latest updates, and make sure to check out my community opinion social networking project, Blocvox.
1
1 Comment
Commenting options at bottom.[…] I’m always on the lookout for thought-provoking discussion about CSS, since I find it so rare. Smashing Magazine can occasionally turn up quality information about CSS, as they did recently in a guest piece that described the nose-to-tail rebuild of the London Times’ website. An interesting read overall, the part that stood out most to me detailed their approach to CSS. They anticipated pain around HTML view re-use and re-composition (into various layouts), and sought to structure their CSS accordingly. I applaud their efforts (despite dropping the goal of semantic naming, which would seriously concern me), and noticed that it resembled an approach I had taken early in Blocvox’s development. I weighed in to share my experiences, and wanted to reproduce it here as a follow up to techniques described in my recent post about the motive for modular CSS. I started with the same use of long/multipart class names, and although it is performant, I found it a bit cumbersome to develop with. In my approach, I strictly adhered to representing each level of structure in the class name, so a link in the headline would have the class name ‘.apple_headline_link’. This made nesting or un-nesting elements require a lot of tedious class renaming, making rapid experimentation very burdensome. […]