FW: [Bug 10838] Make <u> conforming.

I was thinking of re-opening this issue again, but wanted to float my reasoning on this list first. I'm not exactly wild about championing the continued use of <u>. I was going to write into the bug:

--
I'd like to propose a different use case here. While I agree that stylistic markup is undesirable in comparison to semantic markup, we do have obvious history with markup such as <i> and <b>... and <u> as well. 

One form of East Asian emphasis are emphasis marks, such as Japanese bouten. See: http://www.w3.org/TR/2008/WD-jlreq-20081015/#en-subheading2_3_9

While one might choose to use <i> or <b> tags to indicate this form of emphasis (it is just emphasis, after all), using <u> might be semantically closer. <i> and <b> typically are implemented via an actual variation in the presentation of the text itself. <u> would mean text emphasized with something drawn near it or added to it. This doesn't mean that <i> can't be used to underline text (or otherwise decorate it). But providing <u> does give an element whose semantic meaning is closer to "text-emphasis-style" than <i> or <b> suggest.
--

Any comments on my use case? Is it a reasonable one? Or is <i> or such really a better choice for this?

Addison Phillips
Globalization Architect (Lab126)
Chair (W3C I18N, IETF IRI WGs)

Internationalization is not a feature.
It is an architecture.

-----Original Message-----
From: public-i18n-cjk-request@w3.org [mailto:public-i18n-cjk-request@w3.org] On Behalf Of bugzilla@jessica.w3.org
Sent: Thursday, September 30, 2010 2:06 AM
To: public-i18n-cjk@w3.org
Subject: [Bug 10838] Make <u> conforming.

http://www.w3.org/Bugs/Public/show_bug.cgi?id=10838

Ian 'Hixie' Hickson <ian@hixie.ch> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |WONTFIX

--- Comment #6 from Ian 'Hixie' Hickson <ian@hixie.ch> 2010-09-30 09:05:39 UTC ---
The concrete badness is that if we have an element that is purely for
presentational purposes, people will be locked into that rendering for all the
purposes for which they have used it. This contrasts with semantic markup,
where you can restyle a category of content using a style sheet. For example,
you can restyle all the content that is intended to be in a different voice to
be in a different font, rather than just italics. Or you can style keywords in
a different colour as well as being bold.

In general there is also the value of educating authors about using the right
semantic tools - as we push people away from <font> and <u>, they get closer to
using the much more semantic elements like <cite> and <aside>. This further
increases the authoring benefits for those authors and their readers,
especially those readers using non-visual UAs, whose tools can then apply more
appropriate rendering than just guessing at how to express (in this case)
underlines in their medium.

When we added <b>, <i>, <small>, and, most recently, <s>, it was not that we
were adding presentational elements and that we were justifying it by
doublethinking a semantic meaning for them. HTML really does define these
elements now in semantic terms; that they have existing presentations is a
backwards-compatibility boon; that the elements are often already used for the
purposes for which we defined them makes them easier to teach. But that doesn't
make them any less semantic. These definitions are sometimes referred to
disparagingly as "semantic fig leafs", but I think that viewing them that way
misses the point of why these elements exist in the language. They each have
real use cases.


EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are
satisfied with this response, please change the state of this bug to CLOSED. If
you have additional information and would like the editor to reconsider, please
reopen this bug. If you would like to escalate the issue to the full HTML
Working Group, please add the TrackerRequest keyword to this bug, and suggest
title and text for the tracker issue; or you may create a tracker issue
yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: see above.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

Received on Thursday, 30 September 2010 15:29:21 UTC