The element has been interoperably implemented and deployed for a long time, and it is the sixth frequently used phrase element, meaning that it is significantly needed.
Because people (actually, usually WYSIWYGs and CMSes) continue to use deprecated tags (deprecated in HTML4/XHTML1), they are “significantly needed.”
Someone tell me where the <font> tag is and why it should not also be “conforming” (maybe that’s coming up)? 'Cause I see way more <font> tags (mostly generated by HTML email clients such as Outlook, which, face it, is pretty darn popular software) than I see <u> tags.
…
I hadn’t even realised <s> was made legal again. Holy chalupa.
So, anyway, it looks like now, for all of you embracing HTML5 already, have at it with your <u> tags! Weeeeee.
Doesn’t surprise me and if U comes back due to popularity then FONT must come back too, the future is bright… You get a legitimate reason to use previously deprecated elements because they were considered hip for WYSINWYG tools.
“Conforming” isn’t the same as “valid”, apparently, though I’m still trying to find out the difference. Apparently something can be “conforming” and “deprecated”. It might have to do with parsing (deprecated tags who follow the syntax rules conform to SGML and are supported by browsers but are not valid) or maybe it means <u> was simply entirely absent.
WYSIWYG editors traditionally provide three buttons: bold, italic, underlined. Normal users find it weird that <b>, <i> and <u> have different status. They should either be
* all conforming (defined as either semantic element, presentational element or mixed element)
* all deprecated but conforming
* all non-conforming
The new “standard” is rapidly becoming a list of all the tags people like to use rather than the ones that it makes sense to have.
Let’s scrap HTML5 (under whatever name they are calling it today) NOW to save millions of web sites having tags that will be flagged as deprecated in HTML6 (which will be HTML4 with the few extra tags and attributes from HTML5 that actually make sense).
While I agree that text styling should be done in css I also believe they are making the right decision in bringing back the <u> tag. I think all of the following - <u>, <i> and <b> - should be part of html. Why? Because sometimes I may really need to mark up text as underlined - not styling it to look like underlined but really meaning it’s underlined. Imagine presenting a novel or a piece of poetry in html - when I open a book and see an underlined word I want to mark it up as underlined, when I see a word in italics I want to mark it up as italics, etc. Wrapping it in a span and adding css is not the proper method in this case because I am not the author of the book and I have no idea what meaning the author assigns to underline and italics. In English italics is often an emphasis (and I could use <em>) but it may not be emphasis and in other languages it certainly is not. <span> is semantically meaningless and I want to mark the text up properly. In such cases <u>, <i> and <b> become semantic in the sense that they convey most closely what the author meant - and all we know he meant was to underline, make italics or bold. I’ve read opinions of people who copied books in libraries in html and they complained about the lack of <u>, <li> and <b> in (x)html strict - and their complaints are valid.
Of course, these tags can be misused and they shouldn’t be used to style links, menus, headings, etc. on normal web sites. They have their purpose and they should stay. <u>, <i> and <b> are the most common styling methods used in typography since ages and it would be impractical to get rid of them.
Underlining is a style, it doesn’t have semantic meaning.
Sure, it may do in some cultures but in others it may have a different typographical meaning, and this is supposed to be a worldwide standard.
Personally I see the <u> tag in the same way as I’d see a <red> or <blue> tag. The fact its underlined isn’t ‘meaning’ - the “meaning” is actually “this bit is rather important” in Latin-based written languages. In mandarin (which is obviously non-latin), though, I believe it traditionally denotes a proper noun (whereas in English we capitalise the first letter) - in mandarin (according to about.com) emphasis is denoted by placing the text to be emphasised between 是 and 的.
This isn’t entirely relevant to typical documents but I’m using it to emphasise the difference between what <u> does and what I believe one should be using.
HTML, in my opinion, is simply meant to tell the browser what something is, not how it should behave. Its the job of the browser, with help from a style sheet, to decide how it should behave.
[ot]To be fair I think its about time that HTML was retired in favour for something more advanced, more extendable and more open. I think we should have the barebones of HTML and get rid of all the tags which have meaning but don’t have much real-world use. On top of that, make it pluginable - which essentially means that one could invent their own tags. If a developer wants <red> to mean <span style=“color: #f00;”>, they can as long as they define it.
A standard library could be implemented which gives current tags such as <u> etc, but isn’t included by default.[/ot]
Because sometimes I may really need to mark up text as underlined - not styling it to look like underlined but really meaning it’s underlined. Imagine presenting a novel or a piece of poetry in html - when I open a book and see an underlined word I want to mark it up as underlined, when I see a word in italics I want to mark it up as italics, etc.
Actually, the only reason anything’s underlined in Western text (I’ll ignore the Chinese argument, mostly because I think I agree with it) is because typewriters couldn’t usually bold or italicise text that needed bolding or italicising for non-emphasis reasons.
<i>Felis catus</i> <– can’t use em there, nor a span
The <b>RMS Titanic</b> <– can’t use strong there, nor a span
Underline at best was nothing more than a replacement for these… not for computers, but for typewriters, which we are not using HTML with (unless you’re doing some wicked steampunk stuff). That, coupled with the fact that underlining on the web got a different meaning (“click me! I’m clickable! I said click me dammit!”), <u> was (correctly) deprecated while <i> and <b> remained.
I’m so opinionated I’m opining my opinions opinionatedly. And it’s awesome.
I’m gonna go spike my hair green and break out my Dead Kennedys CDs (or vinyl, probably more appropriately) if we’re going back in time here. Next up: the return of the MARQUEE tag.
I see HavenWorks (possibly the worst website ever made) is now down - probably by the threat of competition posed by the impending rush of bad-practise.
Underlining could have a place in a bibliography, for example. Some citation formats require it.
Using this results in an anchor with no underline:
<a>testme</a> or not
Using this treats the text as a link when it’s really not
<a href="">testme</a> or not
I have encountered some rare cases where underlining was required (though I can’t recall specifics at the moment), so in order to retain strict doctype compliance, CSS was needed:
Including <u> would eliminate that necessity of that. But for usability purposes, I do understand why it shouldn’t be included: it can easily cause confusion since links are usually indicated with an underline.
Waiting for “S” to return as well here… and it all goes back to what I’ve been saying about HTML 5 – it’s designed ENTIRELY to undo the progress STRICT gave us.
Redundant tags doing the exact opposite of why certain tags weren’t adopted and others were deprecated – like VIDEO and AUDIO being redundant to OBJECT, and EMBED now being officially back in (also redundant to OBJECT)… tags like CANVAS that have NO **** BUSINESS being a tag in the first place. (If it only works with javascript, it should probably only be attached via .js – and it would be a lot more useful if you could apply canvas rendering to ANY tag), elements like HEADER that seem to exist JUST for the people who slap div#header around tags for no good reason, and a uselessly vague specification that allows so many styles and formats to be mixed willy-nilly that any attempt at making a ‘validator’ is completely pointless. You may as well go back to coding HTML 3.2 than to use HTML 5 – they’re pretty much the same thing! (Or should we say HTML 3.2 with a Tranny doctype slapped on it?)
Again, there’s a REASON I’m sticking with XHTML 1.0 STRICT (and only encourage either X1.0 Strict or 4.01 Strict for general use) – HTML 5 is a needlessly convoluted train wreck that offers nothing USEFUL in terms of actual markup.
Almost everything “useful” in HTML 5 isn’t even HTML; The scripting, CSS and other stuff they’ve thrown under it’s umbrella to make it sound more impressive than it really is has NOTHING to do with markup, or in the case of some things like CANVAS SHOULD have nothing to do with it.
This is just more proof of what I’ve been saying for two years – HTML5 is just a fatter version of Transitional; it exists SOLELY to give the people who never embraced strict or separation of presentation from content another excuse to just vomit up half-assed code any old way.
… as is repeatedly proven by just about everything I’ve seen done using HTML 5.
Presumably the new <u> tag will take an href just like the <a> tag does because anything underlined in a web page should be a link as that is what the underline in a web page means. Anything in a web page that is underlined and doesn’t function as a link is BROKEN.
“A link on a web page will look like this: This is a link.”
I’m not being facetious - I encountered the need to do this just within the last few days. I didn’t want the example to be an actual link - after all, where would it link to?
