css type selectors
html and css are closely connected, no doubt about that. When we style a web document we do it through the mark-up of the document. It's one of the pillars of modern web design and we all take it for granted. But take a closer look and you'll find that this way of working isn't always as logical as it sounds. This article will focus on the way html and css coexist and the effect this should have on the way we write our css.
avoiding inconsistencies
When people start off writing css the results are often pretty chaotic. Starters focus on making things work, which leaves css files badly structured and littered with inconsistencies. It was like that for me too. But the more I learned about css, the more I saw the need to avoid these inconsistencies and to optimize my way of writing css.
Of course, there is no one way to write css, so from time to time I had to decide which choices would be most beneficial in the long run. One particular problem had me puzzled for quite some time and it wasn't until recently that I found some good arguments to base my decision on.
/* css selector with type selector */ ol.breadcrumb /* css selector without type selector */ .breadcrumb When looking into the way I composed my css selectors I asked myself whether it would be useful to include the type selector to a class selector. The little piece of code above illustrates the decision I was trying to make. The choice is easy when a class selector can appear on multiple html elements, but what if the class was unique to one html element?
coming up with arguments
There are things to be said about both ways of working. For one, if you leave the type selector off it will decrease the length of your selector which improves the readability of your css file, especially when many selectors are stringed together. Less scrolling sideways is a good thing. On the other hand, adding the type selector does give you extra information on the class and might make it easier to recognize elements as you got the html element to help you out.
A more important argument popped up when I was revising our deliverables (our company only does front-end, so we deliver templates to be implemented by partners). Adding the type selector locks the css to the html code. By doing this, you create an extra checkpoint for people to implement the templates you deliver. If, for example, they used an <ul> element to mark up the breadcrumb it wouldn't be styled and they would know there was something wrong with the implementation. The argument was good enough for me and I started to include the type selector.
flexibility, the magic word
This went well for a while, but soon I also started to notice the drawbacks of locking css to html. I became more aware of the semantic meaning of some html elements and as I read through several discussions I saw the need to change a few things. One of those things was the breadcrumb, which I changed from an <ul> to an <ol>. When I did that, all the css styling dropped off even though the component itself hadn't really changed. Not a good thing.
It may not seem very likely for things like this to pop up often, but with html5 and xhtml2 in the pipeline I wouldn't be surprised if quite a few html implementations will change over time. And when that happens, it would be nice to simply change the html templates without having to touch the css. So flexibility became my key argument for leaving the type selector off, but something still didn't feel quite right.
the theory
If you really think about applying css to html on a very basic level, it doesn't make too much sense. html might be a semantic language, but at the same time it's very generic. Of course we can add styles and layout to a paragraph, but most mark-up elements are too generic to really tell us anything about the actual component we're styling (think of everything marked up with a <div>).
Going back to our breadcrumb, you'll see that I've used a list to implement it. But a breadcrumb is a pretty specific implementation of a list, which is in itself a very generic term. As a matter of fact, the most important semantic information in this case comes from the class we added on the list (the microformats principal). The reason why we use the list element is because we don't have any better, more semantic ways to implement our component.
Whenever this is the case, I believe it is safe to omit the type selector, as the added information is too generic for the component we're styling, and could be prone to change. In the case of our breadcrumb, the <ol> could be changed to <nl> (navigation list) over time, but even that would still be a generic definition. So from now on, I simply omit the type selectors whenever I'm styling a component that hasn't the exact same semantic meaning as the html element (I still use the ul selector to style plain bulleted lists for example).
concluding
The interesting part here is that many consider it logical to apply css to general semantic elements, while it is definitely not. When we are writing css we are styling components, and these components should be addressed only through their adequate html equivalents. In most cases, this means leaving the type selector off as it is simply too generic to be of any value.
An argument I'm pretty content with, and allows for more flexible css. Double gain.