I started my initial “webucation” simply by learning virtually the only consistent (meaning “sure-footed”) language on the web, at the time. Hyper Text Mark-up Language (HTML). As I wrote here previously, just over a month ago in fact (where is the time going?), CSS resets and the manner for which I have and do rely on them have undergone quite the shake up. And as sort of an addendum to said post, not for any other reason than consistency, I’ve reinstated the FSS reset, well half of it anyway, back into FSSFive. But another approach of mine that has experienced quite a realignment is what had to be my very first lesson on HTML. Links. But more specifically how links look in a webpage.
It was 1997. Arguably during the early days of the web. At least with respect nearly everything web related was in flux. Everything still needed to be figured out and settled upon (well as much as anything on the web can be or actually is “settled”). And when I started to learn HTML it was in the dying days of version 3, just prior to the “ratification” of the new specification — version 4 — that saw use for a good 12 years. Version 4 came out in very early ’98, if I remember correctly, and 5 still hasn’t, and won’t for years, reached final draft status. But portions of the web are currently, and have been for a bit, moving to the next “iteration” of HTML, version 5.
As an aside, there is plenty of “in between” stuff I’m failing to mention in the years from 1998 to 2010, XHTML 1 & 2 being the most significant occurrences. That is on purpose. Honestly by the time I graduated College, in the winter of 2001, I had Photoshop on the brain. Bad. It wasn’t until 2005 when I got back onto web design. Previous too ’05 I was “listening” to what was happening but not with enough interest to accurately recall most of it. And not too much before ’08 I was entirely consumed with re-learning how to do develop on the web, again.
Long story short: it oddly seems surreal for me to be back, more or less, at square one. Styling links how I had no other choice but to way back in ’97. What I mean is when I was learning HTML, Cascading Style Sheets (CSS) weren’t around, in any usable fashion at least. It took nearly another year and a half before I took notice and started to use them. And, by that time, I was only ever able to use it for styling text. It would be a couple more years before designers could even consider — though it was still largely unsupported in many browsers — playing with CSS for layout. Not that I did, for layout I mean, much before 2006, shamefully.
Back to it. Technically since there was no CSS it meant there was no reliable way to style link colours, link underlines or link behaviours past the point of the browser defaults. All links were blue and underlined, all the time. Wait a second, that’s not correct. That’s right, you could set the various link colours, depending on state (whether it was normal, visited or active), in the opening body tag. Wow, I barely recall having to do that. But I’m sure you couldn’t do anything with the underlines.
Then CSS was born, giving you much finer control over such detail. Whether you should change how links display is another conversation, entirely, for another time. But personally, against the advice from one of my professor’s in by far the best course I attended in College, a web usability course, I played with virtually everything you could change. Merely because I could.
But, again, it wasn’t until I started working on this site, and specifically when I started to read Harry Roberts’ articles, the articles that inspired my previous post relating to such matters, that I even started to consider following a set practice.
Fortunately very soon after I started working with CSS I got bored with styling links somewhat randomly and arbitrarily. I’d settled, albeit entirely unconsciously, into a practice. A links colour would depend on the style (largely colour) surrounding it but would always feature an underline beneath it, differentiating from the elements surrounding it that it was a link — as I only used underlines with links. Ideally you want to differentiate a link making sure a reader knows it’s a link. As clicking it serves a universal function. I rarely deviated from that approach.
Harry’s nudge
Then along came Harry’s nudge. While I was adamant using the underlines, I made use of a solid, 1 or 2 pixel bottom-border — versus using the a browser’s default text-decoration:underline. I’m quite fond of such a look. I most like the extra space this solution provided between the linked text, where it sat on the baseline and where the actual “underline” is rendered. Being slightly below the fonts descender — on most, non-script, fonts. It seems cleaner to me.
Another benefit of the border-bottom practice is the ability to customize the “underlines” colour. I’m a fan of making the line a less saturated/ intense colour then that of the link colour. Especially if the underline is of the heafty 2 pixel width persuasion. With the text above it, in most cases, being anti-aliased — the name given to a “smoothing out” the rough edges of a font’s edges when it’s displayed at a low-resolution, like on a computer monitor, say — the intended function often seemed to over power the appearance. Like it would draw your attention to it too much in a way that was self-defeating.
Drawbacks
As with most anything that solution has it’s drawbacks. What if you have an abbreviation (abbr) within your link and a defined style attached to it, like a 1 pixel dotted border-bottom underneath, signifying it is an abbreviation — like the RSS abbreviations within the entries and comment links in the footer on this site — a border-bottom would “overwrite,” thus hiding that style. Giving a user no indication there was more information defining that abbreviation present.
Of course there are ways around such issues. Just stick a slight padding-bottom on abbreviations that reside within links. As my “tests” suggested, not only is outline-bottom not better when used on text-links, as outlines don’t add any added width or height to the box-model, it doesn’t work. But adding a border-bottom to a link doesn’t interfere with a line of text’s line-height the way super-script (<sup>) and sub script text (<sub>) do when their height’s are set in pixels or ems.
But that seems like way more trouble than it’s worth. Only because the default appearance of links provides enough room for both. The underline squeezes between the link text and any border-bottom a web developer chooses to apply to text on a webpage.
Why try and fix what ain’t broken, right?
Points of interest
Those who are taking an interest will no doubt notice I’ve removed the underlines from all links throughout my website, for the time being. And I put them back when a user hovers over a link. Again I’m trying out Harry’s thinking — underlines are obtrusive and ideally should be removed, and positive hovers are better than negative one’s.
While I’m addressing this I should probably note, I’m not entirely sure what I think just yet. While I’m pretty sure my original impressions that links really should be underlined is the most productive way in which to progress, I kind of fancy positive hovers.
What do you think?