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
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 views and experiences. (Be critical, interpret charitably, and sendĀ 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.
Read More
Maybe of interest to you,Ā too:
- Next: The Stupidest Style Sheet Name Ever
- Previous: Presentingā¦ the Google Shoe
- More under Development
- More from 2009
- Most popular posts
Looking for a way to comment? Comments have been disabled,Ā unfortunately.
Get a good look at web development? Try WebGlossary.infoāand The Web Development Glossary 3K (2023). With explanations and definitions for thousands of terms of web development, web design, and related fields, building on Wikipedia as well as MDN Web Docs. Available at Apple Books, Kobo, Google Play Books, andĀ Leanpub.