links and classes

Sometimes it's the little things that keep me up at night. Silly structural or semantical tidbits that don't really seem all that important, but return to haunt me time and time again. Never taking the proper time to figure them out can lead to years of doubt and uneasiness, until it finally grows into this "thing" that just needs resolving. So if the following article seems a little ... obsessive, you know where it's coming from. Just bear with me.

special links

Links are everywhere, which is not all that strange considering they're probably the most elementary concept of the internet. Apart from some nesting issues and some semantic debate (do they have semantic value or do they just describe behavior?), links are pretty straight-forward from a html point of view. They usually appear in navigation or larger text sections, so they need little extra mark-up.

But then there are the solitary links. They could be navigation links that don't necessarily belong to a navigation component (prev/next links, read more links, ..), they could be action links (trigger print, trigger rss, ...) or they could be contextual triggers (expand view, flyout handlers, ...). Usually such a link forms a separate entity within a larger component, so wrapping it in a container to separate it from other subcomponents feels somewhat unnecessary.

Most of these links are accompanied by an icon (or if the design is not known yet, have a high probability of being accompanied by one), so a class is usually needed to identify and style the link. For action links, some javascript is usually required too, so it's always better to have a class ready on these type of links. Better safe than sorry.

putting the class on the link

<a class="more">...</a> <a class="print">...</a> <a class="open">...</a>

The obvious way to go is just put the class on the link. I used to work like this for a while, but found myself struggling with the css once too often. The biggest problems arise when setting a link to display:block, enlarging the click area to often undesirable dimensions, but positioning these links can be downright annoying too. If you start to float them, expect some margin/overflow crap from neighboring components.

Also, I'm not a big fan of mixing inline and block level elements on a single structural level, nor do I find the idea of putting two inline links next to each other without any kind of structural separation appealing (fe. a next and prev link). Inline content for me is something that works as a single sentence, which in this example is definitely not the case.

Ditching this approach, I tried option 2.

wrapping

<div class="more"><a>...</a></div> <div class="print"><a>...</a></div> <div class="open"><a>...</a></div>

The other option is to wrap each and every one of those links and add the class to the wrapper (illustrated in the example above). This leaves you with a little more flexibility, but once you start adding a lot of these type of links on a page the codebloat becomes obvious real fast.

I've been using this method for quite a while too, but started to feel bad about adding all the wrappers. I usually don't have too much problems with some extra html, but most of the time the wrappers are absolutely useless and really don't help to solve anything at all. They just amount to more code and are often harder to implement.

Of course you can always tailor your html to a specific design, but coming from a component/design pattern background, that's not really what I'm after here. And so I've been alternating between both options through the years, never really feeling satisfied with either option.

conclusion

What I'd love to see is some additional input, critiques, maybe even some interesting alternatives or some extra arguments to support either one of the options above. I know it's a pretty small issue that most people won't even notice either way, but it sure would be good for my own personal peace of mind to find an option that would put me at ease.

It doesn't have to be perfect, just good enough for now.