css generated content pt2/aftermath
In the previous article on css generated content I described the technique used to insert content through css. It's a pretty nifty technique and the first time I came across it my mind starting working overtime. Still, you have to use it with caution and never forget the reason you are using it. So let's take a more in-depth look at some of the marginal effects of this method.
paddings and margins
First some positive news. Since we now avoid working with images, we don't need to worry about applying a padding as large as the width of the image anymore. This used to be the best method to avoid text overlapping the image, and the only way to guarantee equal spacing between the items in an em-based layout. So no more need for that.
ul li:not(:first-child):before {content:"|"; margin:0em 0.5em;}
As for the margins we need to apply, we can now do this on the pseudo-element. Pseudo-elements are inline elements by default, but this is pretty much okay as we only need to apply a left and right margin. But even better, if we apply it on the pseudo-element, we are able to define the whole separator style (symbol + spacing) in one very elegant line of css, as you can see above.
Of course, this won't work in all browsers, only FF and Safari support these rules. But still, pretty nifty. What happens is that we apply a :before pseudo-element to all li elements, except for the first one. And to my own surprise, this actually worked!
don't overdo it
Don't be like me, don't overuse this method. There are a couple of reason why you would benefit from adding content to your css, but this technique is not really available purely for your benefit. One thing I did at first, was adding the "/" between both article titles on my blog in css. Keep in mind that most (if not all) browsers won't let you select css generated content, so whenever someone copied the title, there would be no "/" between both titles, messing up the logic of the whole construction.
There are other such examples. One could make a .currency and apply whatever currency sign that applies to the site
in css. By doing that, you could easily change the currency when the user makes the change (on a shopping module for example). But again, the
currency sign is a character that belongs in the source code. Imagine someone browsing without css. He wouldn't have a clue of the currency
being used.
css generated content is used for content or characters that have a purely visual purpose, never forget this. Whenever a character is supposed to be read or should be copied when selected, keep it in your source file, even if that means more work for you.
screen readers ?
One thing I haven't figured quite out yet is how screen readers are supposed to handle css generated content. From my point of view, they should be ignoring it all together (which they actually do I believe). But this behavior seems to be considered a bug or a shortcoming when I was looking around for some answers.
So maybe I'm missing some examples where css generated content should be seen by screen readers. Still, the idea that screen readers should read css generated content sounds very counter-intuitive to me. Accessibility experts, raise your voices please!
and so ...
And so the conclusion is pretty simple. Cool method, keep it in the back of your mind, but the practical use is very limited at the moment. Until css support picks up and the old generation of browsers dies, this will only remain wishful thinking.
Hi, I heard that incoming IE8 won't be supporting :after / :before pseudoelements (like current beta ver). If so, first and foremost a popular easy clearing method (:after element with 'clear:both' property) unfortunately won't be working. Hopefully Microsoft will include the support, otherwise it can be drama :/
@mef: The easy clearing method is popular, but may not be the best way to contain floats as it may create layout issues across browsers. I have a demo page that compares 4 different methods to contain floats without structural markup.
As a web accessibility specialist (not an expert though), this does raise some interesting points. You rightly point out that using this to insert a currency symbol would not help with accessibility. I also think that this would apply in the example mentioned in the previous article about the ">" symbol used for breadcrumb navigation. When this was first introduced, although it wasn't necessarily obvious what it meant it didn't take much experimentation to work it out (as with tag clouds). It has now become a de-facto standard and is probably understandable by most people who have been using the internet for any length of time. Although it is a visual thing it clearly now has some semantic meaning, so to exlude it from screen-reader users is to deny them something that makes the web easier to use. I don't know how a hierarchy like this could be conveyed via a screen-reader but I do think it is important to look for ways to do so. In the case of a tag cloud for example, the relative importance of the different links is conveyed by font-size, this can fairly easily be conveyed to a screen-reader user by putting the links into an ordered list, the order varying depending on the relative importance or popularity of the links. Not everything visual can or should be translated into a text/audio version but the more that can be done, the better we make the web for everyone.
From the previous article : "So in the case where you're styling a breadcrumb trail, I think you could argue that the separators were part of the content."
Just to play devils advocate : I think that in the case of a menu or a breadcrumb trail, that you could just as easily argue that the HTML is intended to be the "data" portion of the "data / display" relationship, and data doesn't just mean the strict text content, but the structure and relationship. If you're using a UL to indicate that, then it's already semantically correct ( and screenreaders can benefit from it ) and you can change appearance via the css, as the choice of a separator does not affect the content.
For instance windows vista will display paths as "My Computer > My Folder" whereas previous versions of windows will use "My Computer\My Folder".
And I still personally think that using a border or graphic as a custom bullet would be a better solution that can be made to function in all browsers. Seems like a win/win to me. If multiple graphics are an issue you can use positioning for the image to fit several graphics inside a single compressed PNG.
Though I do agree with your final conclusion - it's a neat technique to keep in mind, but practical usage is fairly limited. Especially when you consider IE and many of the other factors that have been brought up in the comments for this article and it's predecessor. I also think it comes heavily down to assessment for the individual cases where it may or may not make sense logistically and semantically. =)
Hmmm, here I don't agree at all. Data shouldn't provide structure and relationship, that's the function of html. I've wrote a huge article about that here
Well, a graphic doesn't size with the font, and I still think a border gives you not enough graphical control (and only works with pipes). Though I agree that the presented method is not really usuable right now. Still the way to go though :)
I don't agree at all. thanks for good article
* required fields