Two days from now (?), François has posted an article on identifying file types visually via css generated content; Signaler les liens non HTML. I have my own thoughts about this technique, and have been meaning to write about it. I’ll use his examples to draw a comparison to my own — not because one is better, but because I think it’s interesting to see how they differ.
First, let’s consider this css example from François’s article — I will compare each part of it to my own views:
a[href$=".pdf"]:after { content:'\2005(PDF)'; }
The first part of the rule is a type selector which matches the html anchor element (a). However, I want the rules to apply to all hyperlinks: whether they are indeed anchor elements; link elements made visible (via link { display: table-cell }, for example); or different (think xhtml2).
The anchor element is by no means a universal associative for hyperlinks. The href attribute, however, is. That being said, I use an attribute selector for the href attribute (whether it has content or not):
[href] {}
The second part of the rule (
) is an attribute selector that matches the end of the value of the [href$=".pdf"]href attribute.
In my opinion, file extensions are recessive to mime types: in theory, any file extension could point to any type of file (think of xhtml files having an .php extension, for example). Also (and my previous point has to do with this), I often hide file extensions on my personal site, so the technique wouldn’t work out for me.
That being said, I want to match the exact value of the type attribute:
[href][type="type/subtype"] {}
François uses
in his example. Personally, I like to make the distinction between pseudo-classes and pseudo-elements by using a single colon for pseudo-classes, and two colons for pseudo-elements. Agreed, this is css 3 — which is not a recomended standard yet — but the number of user agents that support css generated content, but not the :after::after pseudo-element are minimal.
This wraps up the selectors:
[href][type="type/subtype"]::after {}
For the actual generated content, I use the same technique as François, save for some details: I use square brackets instead of parentheses, I don’t escape the space (\2005), and I want abbreviations like pdf to be rendered in small caps.
[href][type="type/subtype"]::after { content: ' [pdf]'; font-variant: small-caps }
Of course, you don’t have to stop there quite yet. For example, you could apply the css of Eric Meyer’s Buttons to the generated content like this:
[href][type="application/rss+xml"] {
content: ' [RSS]';
font: bold 10px Verdana, sans-serif;
padding: 0 0.5em;
border: 1px solid;
text-decoration: none;
background: #F60;
color: #FFF;
border-color: #FFC8A4 #7D3302 #3F1A01 #FF9A57; }
In his article, François enriches his generated content with images. This is a fun technique that I have practiced in the past, but the fact that this generated content doesn’t scale properly when I change my font size annoys me to an extent where I'd rather not impliment it.
The key lays in pointing to svgfiles from within a stylesheet, but support for that is — currently — so poor, I’ll rather save my words on that for some later time.
ACJ0 comments so far.