CSS: Style the Non-Obvious

Published on March 18, 2009 (↻ February 5, 2024), filed under Development (RSS feed for all categories).

This and many other posts are also available as a pretty, well-behaved ebook: On Web Development.

One of the qualities you have to acquire as a web developer is to see the non-obvious, and to use that skill to your code’s advantage. Let me explain by two simple examples.

<div id="breadcrumb">
  <a href="/">Home</a> →
  <a href="/whatever">Whatever</a> →
  <em>Anyway</em>
</div>

First, let’s take some classic code for breadcrumb trails. What do you do if you like to adjust the styling of the arrow delimiters?

The novice to intermediate web developer will do something like adding another element, for instance a span element (<span>→</span>). Maybe he’ll garnish it with a class. We’ve seen much like that.

The interesting part, as always (recall Gary Klein), is adding in expertise. The markup used in the breadcrumb navigation example leaves plenty of options to adjust styling of the arrows by just using the outer container (#breadcrumb) as a styling hook and to overwrite styling of the inner elements if necessary. For instance, you could use relative positioning for the a and em elements to visually move up or down the greater than signs. This is “styling the non-obvious.”

Another simple and popular case is a plain navigation menu:

<ul id="nav">
  <li>Home
  <li><a href="/however">However</a>
  <li><a href="/whatever">Whatever</a>
</ul>

In practice, if the goal is to highlight the location you’re currently at, many web developers add extra markup, too, like a special ID or class or even another element. In most cases you don’t need to do that, you’d just style the “invisible”:

li { font-weight: bold; }
li a { font-weight: normal; }

…which here allows to highlight the active nav items by a bold font face, whereas the standard items that are all exemplified by an anchor would use a normal font weight.

I’m not sure whether the point needs further explanation just now, I just wanted to get it out. There are reasons why great CSS techniques are great (and called CSS, not HTML techniques). Experienced CSS developers always try not to alter markup to accomplish certain styling.

About Me

Jens Oliver Meiert, on November 9, 2024.

I’m Jens (long: Jens Oliver Meiert), and I’m a frontend engineering leader and tech author/publisher. I’ve worked as a technical lead for companies like Google and as an engineering manager for companies like Miro, I’m a contributor to several web standards, and I write and review books for O’Reilly and Frontend Dogma.

I love trying things, not only in web development (and engineering management), but also in other areas like philosophy. Here on meiert.com I share some of my experiences and views. (Please be critical, interpret charitably, and give feedback.)

Comments (Closed)

On March 18, 2009, 21:05 CET, Harry Roberts said:
Ah, finally, someone saying what I’ve always thought. Good point well made sir.
On March 19, 2009, 1:23 CET, Louis said:
CSS with the tree architechture of the DOM is finally reduced to an ensemblist model. The “non-obvious” being the complement in this metaphor.
On March 19, 2009, 1:50 CET, e2l said:
Your “nav” example:

you lose the “meaning” for users with deactivated CSS (textbrowser, visually impaired, …), don’t you?
On March 19, 2009, 13:56 CET, Ivan said:
@e2l, not really. Even with the styles turned off you can still differ bitween normal text and links and you get them on separate lines.
On March 21, 2009, 18:35 CET, Jens Oliver Meiert said:
Harry, e2l, Ivan, thanks 😊

Louis, looks like it, yes 😊
On March 23, 2009, 21:04 CET, Peter said:
An experienced CSS developer will always aim for an accessible and semantic document tree, and will always try to be creative to make sure no additional empty elements are needed just to style the website.

Good point Jens, I agree. 😊
On March 24, 2009, 17:15 CET, Niels Matthijs said:
Experienced css designers will write lean, flexible and strong code. They will not fiddle and make spaghetti out of their css documents. They will write understandable css which others will be able to work with.

And most of all, they are not afraid to add an extra element to their xhtml if this means cleaner, leaner and more flexible css.

Anyway, there is no way to differentiate between active and disabled pages in your navigation item. How’s that for lack of semantics.
On March 24, 2009, 17:52 CET, Thomas Thomassen said:
I go for lists for breadcrubs or navigation bars.
If I don’t simply use space inbetween, but insert some ornament I either use a positioned background image, if I want to be really conservative in my backwards compatibility, or I just use :after to insert an extra element. Often this is followed by an :last-child:after statement that removes the appended element for the last item in the list.
On March 24, 2009, 21:35 CET, Rene Saarsoo said:
I mostly agree with Niels Matthijs - this tehnique can severely effect the readability of your CSS. Styling the non-obvious can lead to non-obvious code.

I used to apply this techique more when I was younger and meaner CSS hacker, but now I’m mostly steering towards more maintainable CSS.

But like any powerful tool, it can be quite useful when applied with care.
On March 25, 2009, 11:48 CET, Jens Oliver Meiert said:
Peter, exactly; thanks!

Niels, apart from raising the question how adding something makes anything leaner, I just like to say that this post is not about being “afraid to add an extra element” or not. I hope we can agree that all this “depends.”

Thomas, fair enough, although one might object against using lists for breadcrumbs (and both against single and nested lists), as the elements of a breadcrumb trail rather reflect a hierarchy.

Rene, nice hearing from you again! Abstractly, there can be issues, yet I think everyone got the point of the post. Other than that I cannot do the thinking for other people, so the minimum goal here is to inspire.
On March 28, 2009, 18:35 CET, Jordan Clark said:
I do tend to find myself doing this quite a lot sub-consciously. I do, however, agree with e2l about the nav issue: I think a <strong> element around “Home” would help improve accessibility for non-visual users, and those with CSS disabled.

Great tip, though!
On March 31, 2009, 9:37 CEST, Niels Matthijs said:
>> Niels, apart from raising the question how adding something makes anything leaner

It doesn’t make the html leaner, but it sure helps to make the css leaner, as the separate elements can be styled in a more conform way. Your example will become messy and unmanageable when you’ll start adding margins or paddings to the a-tag for example. And I think we all know how quickly design-changes like that can be made.

And what if they want the “home” text in bold, italic, font-size higher and bordered? I’ve seen worse requests in my life.

As a self-proclaimed non-novice and non-intermediate web developer, I’d add a span around the Home text, even add a class on it so they could all be styled based on one selectable item (of course, the class is only there because ie6 has no child selector support).

And in the end, my css file will be a lot cleaner and easier to understand, grouping styling declaration for common elements. And often leaner too, as it you don’t need to overwrite unnecessary rules.
On March 31, 2009, 15:50 CEST, Jens Oliver Meiert said:
When it comes to adding emphasis to the “Home” location in the second example (now mentioned a couple of times), arguably that’s a matter of preference but not a matter of accessibility. I hope those who prefer adding emphasis understand the point regardless 😊

Niels, I understand where you’re heading, however I believe that this depends. It clearly wouldn’t be wise to sacrifice CSS efficiency if there’s a legit workaround, e.g. by tweaking document semantics.