I've just stumbled upon a problem with using the :after pseudo-element for appending tails. The :after and :before pseudo-elements are part of the CSS2 standard and as such are supported by the vast majority of browsers.. except from MS Exploder (including the latest versions) :-(

Personally, I see no problem in implementing a feature through a solution that is 100% standard-compliant and supported by most browsers with the exception of ONE standard-uncompliant browser, even if this means that those still using IE won't be able to use this feature.

The argument might even run like this: want to see all the features of this engine? then use a good, standard-compliant browser. Since it's not core functionality, but a sort of extra feature, I wouldn't mind taking a decision that would probably displease most IE users.

I'd like to have your opinion before going any further in this direction, though.

You are absolutely right, :after is a **much more semantically clean method**, as it doesn't pollute the markup. I would just accept that IE does not show any differentiation for links, and users of better browsers get a bonus. Most IE users wont notice anyway, and it is not a core functionality...

I'd use :after (or :before) anyway - but make sure that several link types (at least external links) have a meaningful title attribute as well. Not "go to" or something, but wording that indicates you'd be leaving the site - something like "off-site" might be sufficient.

This has the added advantage that screen readers (provided they are configured to use "verbosity") would read the title as well, and thus get a signal they may not get with a CSS-generated image (although an added character might be read).

Supplementing my quick note about using a title attribute on a link - I was not entrirely sure of the mechanisms of screen readers in this when I wrote that - something about how screen readers handle this:

Current generation screen readers default to reading screen text for links when present; they can be set to read the title attribute *instead* or (for JAWS, anyway) to read whichever is longer. Whether any screen reader actually (can be set to) read both is unclear (but doubtful). In addition, screen readers (and some browsers) can provide a list of links as a navigation aid.

This implies a strategy:
1. create a good link description (it should be meaningful even if taken out of context);
2. if the link description is good but the link could benefit from a longer description, provide the longer description in a title attribute - in such a way that it can *replace* the link description rather than supplement it (since a screen reader will read one or the other but not both).

In the case of an image link, the image itself is the link "description", so the image's alt text should be a textual equivalent of that link description (i.e., be able to replace the image). After that, apply the guideline above for a link description.

A (trivial) example: assume a link to a Frequently-Asked Questions section; the link is formed by an icon symbolizing 'FAQ". The link could be coded like this:
<a href="faq.html" title="Frequently-Asked Questions"><img src="faq.png" alt="FAQ"></a>
In a graphical browser, the word "FAQ" would replace the image if images are turned off (or until the image is loaded); on mouse-over the text "Frequently-Asked Questions" would be displayed (where, and how depends on browser annd configuration).
In a screen reader the link would be announced as "Link: FAQ" or "Link: F A Q" or as "Link: Frequently Asked Questions" depending on the user's settings. (This is a generic approximation of how links are read - links are always announced as such.)

JW, thanks for this very clear how-to :)

I think its a ver good idea

Yeah, it's so clear now - even to myself - that I found I will have to change a bunch of title attributes (and alt texts) in my own sites since I was not aware of the "replacement" characteristic that a title can have with respect to link descriptions. I found Lynx does the very same thing (good test if you don't have a screen reader to test with) so I now have loads and loads of identical links. As if I didn't already have a lot of stuff to catch up with....

One thing that seems to be missing for the list is a tail for internal page anchors.
Currently the only way to use them is to create an external html link to the internal page and anchor. Definately should have its own tail unless of course there is an scheduled date to implement internal anchors directly in the Wiki.

http://wikkawiki.org/AnchorAction - much confusion, bit a couple of successes(?)
http://wikkawiki.org/TableofcontentsAction - not touched in a long while

Instead of using :after (or :before) another possible CSS-only method for link markers is to add padding to a link and then put a background image in the space created by the padding.

Problem: not all browsers support this either... though I think support is slightly better. I've started to use this for external links on my Travel blog now - but I'm not entirely happy: I still haven't found a way to distinguish links that works with all "current" browsers (startnig from IE5), is accessible, and does not depend on non-structural markup.