- From: <bugzilla@jessica.w3.org>
- Date: Thu, 30 Sep 2010 09:05:40 +0000
- To: public-i18n-cjk@w3.org
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 09:05:43 UTC