css generated content pt2
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.