Presentational elements like <i>, <b>, <small> and <hr> have been redefined in HTML5 with semantic meanings, or, in a couple of cases, made non-conforming. The <u> element had been in the non-conforming camp, but a couple of semantic use cases led it back into the fold. While most of us will never need it (and some will jeer), on the odd occasion, it might be just the element you need.
Before HTML5, <u> was solely for applying a presentational style of underlining to text. HTML 4 discouraged “font-style” or presentational elements, and even deprecated <u>, advising us to use CSS instead. Even before this, <u> was frowned upon as underlines are the browser default for links, and making normal text look like links gives users a bad case of clicky-clicky frustration. <u> was initially non-conforming in HTML5.
There are, however, a couple of non-link places where text is traditionally underlined to convey meaning, as the HTML5 specification’s definition mentions:
The
uelement represents a span of text with an unarticulated, though explicitly rendered, non-textual annotation, such as labeling the text as being a proper name in Chinese text (a Chinese proper name mark), or labeling the text as being misspelt.
Before we get to them, let’s quickly cover an unarticulated, though explicitly rendered, non-textual annotation. This means
(WHATWG IRC, Ian Hickson) — the annotation’s meaning is implied by context.<u> is for when you are annotating something, but not explicitly saying what it is
Chinese proper name marks #
And what exactly are those you ask? I had to ask Wikipedia myself:
In Chinese writing, a proper name mark (Simplified Chinese: 专名号, zhuānmínghào; Traditional Chinese: 專名號) is an underline used to mark proper names, such as the names of people, places, dynasties, organizations. … This method of recognizing proper names in text is similar to the English use of a capital letter.
Wikipedia gives the following example, which I’ve formatted using <u>:
<u class="pnm">屈原</u>放逐，乃賦<cite class="bnm">離騒</cite>。<u class="pnm">左丘</u>失明，厥有<cite class="bnm">國語</cite>。（司馬遷 《<cite>報任安書</cite>》）屈原放逐，乃賦離騒。左丘失明，厥有國語。（司馬遷 《報任安書》）
Qu Yuan was exiled, and thus composed the Li Sao. Zuo Qiu lost his sight, hence there is the Guo Yu. (Sima Qian, “Letter to Ren'an”)
<u> for Chinese proper name marks where appropriateIf you’re using Firefox 6+ you’ll also see the appropriate wavy underline for a Chinese book name mark on the quote’s source, courtesy of CSS3’s text-decoration-style: wavy;. I’ve used <cite> for book name marks as it’s more appropriate than <u>. You can find out more about wavy in CSS Text Level 3.
Using <u> for spell-checking feedback #
While you’re probably not marking up classical Chinese prose, a more familiar use case is for a spell-checker to indicate incorrect text. The default formatting in word processors is typically a red underline for spelling errors, and a green underline for grammatical errors:
.spelling-error {
text-decoration: none;
border-bottom: 1px dashed red;
}
.grammatical-error {
text-decoration: none;
border-bottom: 1px dashed green;
}
<p>hello doctor i am having a huge body <u class="spelling-error">oder</u> <u class="grammatical-error">it is smell really bad</u></p>hello doctor i am having a huge body oder it is smell really bad
<u> for annotating spell checker feedbackWhile we’ve turned off the default text-decoration style, <u> will back us up if CSS is disabled, and potentially provide more information for assistive technology. After all, if it’s semantic it should be in HTML, not CSS.
Some word processors use wavy underlines. This CSS would have the same effect in a supporting browser:
.spelling-error {
text-decoration-line: underline;
text-decoration-style: wavy;
text-decoration-color: red;
}
.grammatical-error {
text-decoration-line: underline;
text-decoration-style: wavy;
text-decoration-color: green;
}Or, using text-decoration as a shorthand property, and adding a default declaration for non-supporting browsers:
.spelling-error {
text-decoration: underline; /* for backwards compatibility */
text-decoration: underline wavy red;
}
.grammatical-error {
text-decoration: underline; /* for backwards compatibility */
text-decoration: underline wavy green;
}Again, you can read more about the upgraded text-decoration properties in CSS Text Level 3.
Using <u> for indicating family names #
Another use for <u> is to annotate a family name when this might be confusing — Chinese, Japanese, Korean and Vietnamese (among others) all traditionally write names in a different order than the western-centric “given-name family-name”. While applying a blanket western ordering is fairly common (especially when publishing in English), it’s good form to use culturally appropriate ordering. If the audience might misunderstand, the family name can be underlined, capitalised, or otherwise annotated to make the name order explicit. For example, the CIA’s World Fact Book capitalises the family name:
After World War II, the Communists under MAO Zedong established an autocratic socialist system …
This ties in nicely with the hCard microformat, as the “implied n optimisation” doesn’t work with these non-western ordered names, and we need a wrapper element to indicate each part of the name anyhow.
<style>
.family-name {text-decoration: underline;}
</style>
<p>
<span class="vcard" lang="ja-latn">
<span class="fn n">
<u class="family-name">Son</u> <span class="given-name">Goku</span>
</span>
</span>
is the main protagonist in
<span class="vcard" lang="ja-latn">
<span class="fn n">
<span class="given-name">Akira</span> <u class="family-name">Toriyama</u>
</span>
</span>’s <i lang="ja-latn">manga</i> “Dragon Ball”.
</p>Son Goku is the main protagonist in Akira Toriyama’s manga “Dragon Ball”.
<u> to indicate the family name in non-western names via underliningOf course you can then change the style via CSS, for example
.family-name {
text-decoration: none;
text-transform: uppercase;
}
Son Goku is the main protagonist in Akira Toriyama’s manga “Dragon Ball”.
<u> to indicate the family name in non-western names via capitalisationThe benefit of using <u> for this is the family name will be indicated even when CSS is disabled, ensuring the annotation isn’t lost. Assistive technology may also be able to inform the user of this in the future.
But do we need <u>? #
A lot of people bitten by the web standardista bug have somewhat of an allergic reaction to ex-presentational elements in HTML5, after influential articles like Tantek Çelik’s “<b>ed and <br>eakfast markup”. Given <u>’s ignoble past, I expect the reaction to its return will also lead to some poo-pooing. As we already mentioned, however, if it imparts meaning, it should be in HTML. These use cases involve semantic meaning, and even without assistive technology support, <u> conveys some meaning to sighted users via the browser-default style text-decoration: underline;.
Regardless of whether an element is deprecated (HTML 4, XHTML 1) or non-conforming (HTML5) or just plain uncool, browser makers still have to support it for backward compatibility with all those awesome web pages from the days when <blink> was hawt. Because of this, if there’s a semantic use case for an ex-presentational element, it’s definitely better to reform it rather than minting a new element with no backward compatibility. You might think <mark> sounds pretty similar, but the default browser styling would be completely wrong for proper name marks, and semantically less appropriate for spelling errors too.
As Ian Hickson explains:
The presentational markup that was
<u>,<i>,<b>,<font>,<small>, etc, is gone. However, there are certain use cases that did not yet have elements yet were important enough to warrant us supporting them. By reusing existing elements, we are able to support them without having to wait for new elements to be implemented. By doing so in a way that closely matches how those elements were actually used in practice (at least to the same extent as other elements have been correctly used in practice) we can not only have older UAs support these new elements automatically, but we can do so in a way that does not introduce an undue volume of invalid pages.
Conclusion
Given the potential to confuse underlined text with links, using text-decoration: underline; on anything other than <a> is bad pretty much all the time. Generally <u> is not the element you’re looking for, even for Chinese book name marks (<cite> would be more appropriate). However, for at least these three use cases, it’s good to have a semantic option, something better than <span>.
So…in a hypothetical world where you did need to code for one of these situations, would you use <u> or something else like <span>? Let us know in the comments!
37 Responses on the article “The return of the u element”
Nice explanation! Thank you =)
If it gets approved then why not? With CSS, we can easily control how <u> gets presented, and if visitors react that they’re confused if it’s a link or not, then obviously they are using an old browser that doesn’t support CSS or partially only.
In that case, we can simply tell them “upgrade to the latest FF, Chrome/Chromium, Opera, Safari, and/or IE. Your browser is too old, this is how it actually looks like – wavy lines / all uppercase, not an underline”.
謝施洗
;)
Thanks for the explanation! I would use the instead of span now!
Let’s be honest, HTML5 gets what Hixie wants and we should stop wasting our time wondering why or thinking our opinions matter. Better to just get on with it all.
If we continue to “bring back” previously deprecated elements into HTML5
<i>,<b>, how will validators determine whether it is being properly used or not? I realize validators can’t police the content being used within them necessarily, but isn’t all that’s going to happen is a lot of html docs that didn’t pass validation before (because they were using deprecated elements) will pass now (even though the use of that element in the doc doesn’t map to the intended semantic use in HTML5)?Fixing annotations of proper names does not belong in HTML either, it should be in the charset. Western languages use uppercase letters provided by shift+letter on the keybord, giving a different character code displayed by the font. Chinese etc seems to need a similar method. Using markup is just wrong.
Then suddenly the u-element should have another meaning as well? That something is misspelled or gramatticaly incorrect? WTF? Yeah, I’m really going to mark up all my errors instead of fixing them. If they were intentionally there, they are not errors and should not be marked up as such.
Who cares about “validators”? They are just a tool for YOU to use for YOUR OWN use in writing syntactically correct code. If YOU want to use – and know it’s for a legit reason – then all YOU care about is that there is a to close it.
The HTML5 consortium is, by definition, arbitrary – a set of guidelines for “smart” people to use to be “nice” for parsers and other “meta” functions; NOT a “big brother” to enforce a preconceived notion on the web – “or else”; and only very rarely an effort for which the developer derives much personal gain. All I can say is that: now I’m using HTML5 more and more, I’m doing a whole lot more typing, navigating back and forth from content files to css files more, and wading through a much more difficult to read HTML content files – all of which makes ME less productive. I sure hope that SOMEONE is (or will) be getting some benefit from this soon.
[and, now that the <u> is back in favor will be allowed to use the element in this site’s comments as well?]
Pretty enormously shocked that this tag is back. The redefinition is so awkward and shoe-horned, and few will use it correctly, but I’m happy to have more options.
Nice article, as usual (I, for one, had no clue the underline was used to mark proper names!) But most importantly:
/giggle The title of this article came through as “The return of the element’ (with “element” being underlined on my RSS reader.
In those use cases I’d still use something more appropriate than <u>. You mention that Mark is styled inappropriately by default, but you restyle U for your examples. Why not restyle something appropriate rather than making do with something entirely visual.
Your examples of use cases are actually working against you. They are entirely visual. Red and green for errors, underlined for names, etc. These mean nothing to the visually impaired.
There were very good reasons for it being depricated before. I really haven’t seen a good reason for bringing it back.
Hey all,
Thanks for your feedback! Just remember the article’s conclusion: “Generally
<u>is not the element you’re looking for” ;)@h — you are wrong. Many things have changed in the spec due to user feedback, and
<u>returning is an example. You should have commented on the<hgroup>article :p@Rick Lowes — validators can’t check this kind of thing, but that’s not a problem.
@Bjørn Johansen — “Fixing annotations of proper names does not belong in HTML” Quick, tell microformats.org to stop marking up names in hCards because they can programmatically detect names using only CAPITAL LETTERS!
Also, re: marking up spelling and grammatical errors — they might not be your errors. I’ve updated your comment by way of example ;-)
@DJ — “The HTML5 consortium” I think you mean the W3 Consortium? Also, maybe you need a new text editor with snippets and autocomplete — I don’t find much of a change in complexity between HTML 4 and HTML5, and both are way easier to read than during the days of table layouts. We have no plans to add
<u>to the comment code whitelist atm, but if you have a valid need for it feel free to ping me.@BrianMB — I agree completely. However, try to improve the definition and you’ll find it’s actually pretty good, all things considered :)
@Francesco Rizzi — sheesh, we must not be escaping titles properly. Embarrassing! I’ll try to fix it. Thanks!
@Tschet — You can’t rely on CSS, which is why I mentioned browser defaults, and in these use cases underline does convey semantic meaning to sighted users. According to it’s current definition,
<u>is the most semantically appropriate element for these use cases. These examples are as “entirely visual” as bold for<strong>and italic for<em>.<u>is not currently treated differently to<span>by speech readers (afaik), but the same is true of any new phrasing element (<time>,<mark>etc), so that’s a non-argument. Hopefully it will be in the future.This of course is yet another really bad idea – mixing and applying 2 unrelated concepts to what was originally just a presentational element now adds meaning to legacy content where there may not have been meaning previously.
Here, which is it?
伊恩 <u>Hicksonn</u> 再次弄錯了
(Ian <u>Hicksonn</u> got it wrong again.)
Just sayin’…
For those who think that this is Hixie simply forcing through a bad change, it should be noted that in this case, he was somewhere between sceptical and opposed to making this element conforming. See http://lists.w3.org/Archives/Public/public-html/2011Jan/0377.html and http://lists.w3.org/Archives/Public/public-html/2011Mar/0643.html
Generally, I think it’s a good idea to redefine these old presentational elements, when there’s a semantic use case. They’re likely to be supported in browsers for a long, long time anyway. Marking up Chinese names is a use case for U in my opinion.
When I became aware of my misuse of TABLE for layout, I started asking myself as a rule of thumb, “Would I use a table in an offline context?” The same applies to using U. In marking up Chinese names, U is more like SUB, for instance, than like FONT.
@John Foliot — Why to people underline things? I’d say it’s almost always for some form of emphasis or differentiation, and the element’s definition fits that use fine. There’s no need to know specifically what the
<u>indicates as this is provided by context — the important part is the text in the<u>is flagged for the user’s attention.Neither of your examples actually show an overlap based on the three use cases I covered. An example that actually has overlap would be
<u>Leee</u> Jun-fan kicked ass again. However, the important part is the word “Leee” is flagged for the user. Based on context (and for these use cases that’s writing or reading) they’ll assume it’s one or the other.@Alohci — Hixie doing something based on use cases rather than his dictator-for-life status? Inconceivable! :|
I’m not completely opposed to repurposing old tags, and I’m not against the use-cases you give having appropriate tags, but I do have two major objections to this particular case.
Firstly, as has been stated, there are several possible meaning here for <u>. That means that there is no significant semantic meaning provided by <u>. Simply “flagging up” seems a fairly weak usage. We can flag things up in plenty of ways already, and cases with specific, important meanings should perhaps have specific tags, if they are important enough.
Secondly, and probably more importantly, the web is still absolutely full of underlining. Just read through a bunch of blogs, and people are doing it all the time. They are doing it for emphasis, and so <u> is basically being used where <em> or <strong> should be used, and is being used practically as a form of emphasis. I’m absolutely certain that people will continue to do this, and if we couldn’t educate people not to use <u> for emphasis, I just can’t image we’ll be able to educate people for a few special-use cases.
Because of that, <u> will mainly be used wrongly and it would have been better to introduce a separate tag(s) for the special use cases, if needed. If <u> is to be brought back, it should probably be as another form of emphasis.
All in my humble, not expert opinion, of course.
Whilst there has been much discussion about the evils of the underline, an example of where it is necessary is to replicate the visual elements in a published work.
For example, a game called Advanced Squad Leader uses cardboard counters. These cardboard counters have specific visual elements in which the underline has a specific meaning. The Strength Factor of a unit might be 4-4-7. However, another unit would have any or all three numbers underlined indicating other capabilities. This is extremely awkward to do using with text decoration:underline. No other syntax marker works either since these are secondary capabilities compared to the Strength Factor.
So just because your specific needs do not have a use for the underline tag, does not mean there are not many different publishing needs where it can be useful and meaningful.
@Jeff DeBraal
But this is exactly the point. The underline is a visual element in this case, which means that CSS is the appropriate medium to apply the appearance. It may be difficult to do, but that doesn’t stop CSS being the right way to do it. HTML should not be used to provide the visual identity for an element.
The truth is, of course, that people will continue to use it whenever they want, and browsers will support underlining, irrespective of whether it’s in the spec or not, but that doesn’t mean it’s the right way to do it. I do sympathize with this case, and if the ‘u’ tag was used as another emphasis element like em and strong, that would be fine, but it doesn’t appear to be the case in the current spec.
@Patrick Samphire — while I agree that “Simply ‘flagging up’ seems a fairly weak usage”, it is still a reflection of the semantic uses people are using the
<u>element for. The alternative is not new elements for these use cases (they’re all way too minor for that), the alternative is no<u>element. Since it’s already there and browsers have to support it, why not use it?@Jeff DeBraal — agree. For me it’s just another (albeit specialised) tool in our toolbox. If you don’t need it, you can pretend it was dropped :)
@Patrick Samphire — “The underline is a visual element in this case”. If the underlining was solely stylistic I’d agree, but Jeff said that “numbers underlined indicat[es] other capabilities”, so this is semantic information. That means
<u>would be more appropriate than<span class="other-capabilities">etc.@Oli
I think it requires semantic information, yes, but I don’t think the ‘u’ provides any semantic information in this case. Semantics is all about providing additional meaning. Nothing about the way ‘u’ is interpreted passes any information about the meaning in this case. In no specification does ‘u’ provide anything that suggest that the text (or number) “indicates other capabilities”, and so in this context ‘u’ provides no more semantic meaning than ‘span’ or anything else.
All ‘u’ appears to say in this latest incarnation is “there’s something here, we’re just not sure what”.
Anyway, this is nit-picking, I know. The truth is, 99% of the times ‘u’ will be used will be so something is visually underlined, just as it is now, and so it’ll remain a visual indicator rather than anything actually semantic.
@Patrick Samphire — These two sentences seem to contradict each other:
“‘u’ provides no more semantic meaning than ‘span’ or anything else”
“All ‘u’ appears to say in this latest incarnation is ‘there’s something here, we’re just not sure what’.”
Also, why do people visually underline things? Unless you subscribe to ransom note-style usage, I think it’s to flag the text for some reason. I completely agree that in almost all cases ppl should be using
<strong>or<em>instead, but the spec definition still seems applicable to popular usage.Many commenters seem to perceive that just flagging something is not semantic, because there’s no explicit indication of what the flagging means. For me the flagging alone, with the meaning coming from context, is semantic in these use cases.
Fair enough. Personally, I think span also is a flag, even though it has no default styling. However, I get your point.
@Patrick Samphire — for me
<span>is pretty much semantically neutral as it represents a string of text, which is the default content model (unknown elements are treated as<span>by default). But I’d argue that<div>isn’t because that’s a block of content, so I can see where you’re coming from ;)To underline post title in Blogger, it is easier to use < u > than < span > . Simplicity saves lots of time.
@Mae
The HTML produced by blogger (and similar systems like LiveJournal) is so awful than you might as well use whatever you like. You won’t be able to make it any worse.
This is a really good article about ul tags. I like the descriptive approach for spell checks!
“While you’re probably not marking up classical Chinese prose,” — actually, that’s exactly what I’m doing! Thanks for a good summary and a useful article.
Hi, I am using <u> to mark the access keys of buttons in my HTMl5 web app:
<button accesskey="f"><u>f</u>ile</button>IMHO this is a good use too, but I am open to other solutions. I know about <span> with a class name, but I see no advantages in using that – it just seems overkill and verbose. Moral: the distinction between semantics and presentation can sometimes be blurred!
Maybe this is obvious to some people but what should I use if I am reproducing text in which the author used underline as a way to emphasize text? For example, a court opinion from say 1975.
If am trying to reproduce it exactly and obviously can’t control what the author did in 1975 but want to tag it properly what should I do? If I don’t use
<u>to underline, should I use something like<em>? This seems just as bad as using<i>.I appreciate the effort to split semantics from presentation, but to many of these tag decisions are based on the assumption that we are only dealing with new content with which we have control over the style used.
sorry, I didn’t mark code in the previous comment. I was asking about using
<em class="underline">in place of<u>Edward,
The point of using em with a class in this situation is that, as you point out, the author is using underline as a means of emphasis. Therefore, the appropriate *semantic* mark-up to use is the emphasis element, em. *Visually*, the emphasis is represented by an underline, and you use CSS to set the visual display characteristics on the web.
So, em with a class is exactly the right way to mark up this content.
It pleases me to see traditional tags allowed if, and only if, they are used properly. For me, that’s especially true of <i> and <b> which are essential for typographically correct text while adding no special emphasis. For an example, s’il vous plaît, I don’t want to <em>phasize a foreign word or phrase, I want to <i>talicize it. Same with HMS Titanic and titles of books and periodicals. Look it up in The AP Stylebook.
My personal rule is simple: I never use <i> (or <b>) without a proper attribute, like lang=”fr”. Neither <i> nor <b> have been depricated; that’s for a good reason. There should be no problem when they’re used properly. The same should be true of <u> when it is styled properly, used judiciously, and attributed accurately.
HTML5 isn’t so much repurposing tags, as it is clarifying their use.
Thank you for the article. Though this article is a little dated, its content still holds true.
With that, I believe there is an aspect that is not being considered that holds an exception to the <u≶ tag that most of the people concerned with code and “technical stuff” are less aware of. (No offense meant to technically-oriented people, I am one myself.)
I create web pages and some pretty intricate web properties with php & HTML and I’ve really enjoyed how the whole nature of css has evolved over the years.
However, I have also learned online marketing and have developed some fairly decent copywriting skills. I find one of the most difficult things to convey with the written word in English (can’t speak for any other language) is emotion and emphasis.
Using a particular word is only part of the communication. Outside of that, the only other entities we have are: capitalize, bold, italics, underline and highlighting (and, personally, I think highlighting is a bit cheesy, but do use it on occasion).
This falls in the realm of ‘communication’ syntax over “rules” of what a tag is supposed to do, in my opinion.
It’s kind of like capitalization rules in headlines. Proper English rules say to NOT capitalize insignificant words. But any good copywriter knows to capitalize EVERY word in the headline (there are proven psychological reasons for this, beyond the scope of my comment). The “rules” say one thing, but the practical application falls outside of those rules.
So, while the <u> tag may have an application based on a set of “rules” for HTML tags that make perfect sense, there are a number of people out there who will always need to underline text simply for emotional emphasis in their communication. Isn’t this the very reason why we moved from <i> to <em> …for the benefit of screen readers to add emphasis for the blind? Italics is really more about emphasis, even though it has “logical” grammar rules that apply in places where emphasis is not appropriate.
The ‘TECHNICAL’ aspect of this is efficiency of code. Yes, I can always use, for example, <span style=”text-decoration: underline;”>words to be underlined</span> …or some cleverly crafted css tag in my style sheet, but in a world where we’re all focused on trying to increase the efficiency of our systems (or, we all should be), it just doesn’t make sense to me to increase the rendering overhead by an additional 42 characters (in my example above) for the mere fact of following a rule. Sure, 42 characters really isn’t all that much, and we’re probably not even adding more than a nano-second to the page render time, especially with compression, coupled with the fact that 4 and 6-core processors with DDR3 and high-speed Internet are more commonplace than ever.
Still, it seems technologically counter-productive.
In the natural world, there are always those annoying exceptions to everything… rules of English have exceptions. Science & physics always have their exceptions.
When I create pages and code, I’m *very* focused on the user experience…which should be rule #1 that takes precedence over all other rules. Isn’t that why we’re doing this whole HTML5 thing in the first place? It’s all about improving the user experience and making it easier for developers to give the user a great experience without having to learn advanced coding languages or use special plugins, java, flash, etc.
I admit that sometimes I become a bit anal about my page efficiency and have spent many hours studying how browsers render pages, how to tweak Apache, and learning ways to make my web pages “appear” as instantly as possible with shortened css properties & variables, sprites, crafting css properties that are the least ‘expensive’ to render and eliminating every possible server request and even unnecessary space within the code. (Unnecessarily heavy code -like people who still use old table layouts with 3x’s the amount of code over a properly crafted div tag- just irks me.) I even go to the point of seeking out the most efficient image rendering engines to give me the smallest image possible while maintaining a quality image.
Adding 42 characters to code (as in my example above) where 2 characters worked perfectly seems highly counter-productive to the user experience …even if it doesn’t fit nicely into a box of fixed rules.
Just my opinion.
Thanks for reading.
Underlined links? I remember them! But i haven’t seen many of them in the last five years or so. There may have still been a few people who associated underlining with a link when this article was written, but i doubt there are still any now.
Underlining a text can have a semantic function in a context where it is necessary to differentiate various kinds of emphasis, but where italics or bold text would be inappropriate to use. For instance, consider a translation of some classic work such as Kant’s Critique of Pure Reason. In original text there are sentences and words that are emphasized. In translation those emphasized lines are translated with italics. If one wishes to emphasize of how some line is translated, it would be wrong to use italics, because it would be confused with emphasized words or sentences in original. Here would underlines be more appropriate. They do not serve to decorate a text, but to emphasize the text in question, and as such, they have rather a semantic function.
Best regards,
Aleksandar
Let’s face it, they are 2 totally different elements. just does not underline. And underlining a word has been a form of emphasis the older generation understands. Keep it seperate.
<< Even before this, was frowned upon as underlines are the browser default for links, and making normal text look like links gives users a bad case of clicky-clicky frustration. >>
seems like an odd rationale–underlined text had a specific meaning before the invention of the web:
<>
http://grammar.yourdictionary.com/punctuation/rules-for-underlining.html
so it looks like underlined hyperlinks is where the W3C went wrong, or was it the big browsers that went wrong, in their impl–who decided that hyperlinks should b rendered underlined by default?
Leave a Reply to Edward