This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 9919 - Remove kbd, samp, and maybe var, like acronym; expand <code>/<tt>/<i> or whatever to replace them
Summary: Remove kbd, samp, and maybe var, like acronym; expand <code>/<tt>/<i> or what...
Status: CLOSED WONTFIX
Alias: None
Product: HTML WG
Classification: Unclassified
Component: pre-LC1 HTML5 spec (editor: Ian Hickson) (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL: http://www.whatwg.org/specs/web-apps/...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-06-14 00:00 UTC by contributor
Modified: 2010-10-04 13:57 UTC (History)
6 users (show)

See Also:


Attachments

Description contributor 2010-06-14 00:00:30 UTC
Section: http://www.whatwg.org/specs/web-apps/current-work/#the-samp-element

Comment:
samp and kbd are practically unused and just clutter the language.  They
should be removed, like acronym, and code should be broadened to include their
semantics (or maybe tt should be re-permitted and defined in the fashion of b
and i).

Posted from: 68.175.61.233
Comment 1 Christopher Yeleighton 2010-07-23 05:03:40 UTC
(In reply to comment #0)
> samp and kbd are practically unused and just clutter the language.  They

That was a bold statement.  Do you have frequency data you could share?

> should be removed, like acronym, and code should be broadened to include their
> semantics (or maybe tt should be re-permitted and defined in the fashion of b
> and i).

Note that KBD means "user input", and user input is a different thing than the result of it.  Example: Pressing <KBD >Ctrl <KBD >C</KBD ></KBD > does not produce any result (<TT ></TT >).
Comment 2 Aryeh Gregor 2010-07-23 18:13:23 UTC
(In reply to comment #1)
> That was a bold statement.  Do you have frequency data you could share?

Sure.  For instance (thanks to Philip, although as he warns, it's five years old):

http://philip.html5.org/data/tag-count-pages.txt

shows out of 130,000 or so pages, 43 use <kbd>, and 54 use <samp>.  That's under 0.05%.  They're used less often than a considerable number of elements that don't actually exist.  <var> probably falls in the same boat (just use <i> instead).  Although <ins>, <del>, and some other elements are used as infrequently, there are no good replacements for those, so I won't include them in this request.

> Note that KBD means "user input", and user input is a different thing than the
> result of it.  Example: Pressing <KBD >Ctrl <KBD >C</KBD ></KBD > does not
> produce any result (<TT ></TT >).

Yes, but HTML does not need to respect all possible semantic distinctions.  It could include <noun> and <adjective> tags too, hypothetically, but almost no one wants to mark up nouns or adjectives specifically.  Such marginal use-cases are what things like class="" and microdata are for.  Dedicated elements are only needed for very important or widely-used semantics.

It's safe to say these elements are only in the language at all because they were in old versions of the language and no reason was seen to remove them.  (The editor could confirm this.)  This fits in with the general idea not to make previously conforming pages non-conforming without good reason.  However,

1) It's inconsistent with how <acronym> is treated.  The only difference I'm aware of in that case is that <acronym> was already removed in XHTML2 -- however, many elements were removed from XHTML2 but retained in HTML5.

2) The number of affected pages would be tiny compared to the number affected by getting rid of elements like <tt> and <u>.  As long as so many authors are being forced to adjust their pages because of elements that are removed as obsolete or useless, we may as well take the opportunity to tidy up the language a bit more by removing a few extra very rarely used elements.

In short, I think that the addition of these elements to the language has been proven to be an error; and while it was a fairly harmless error, the fix is correspondingly harmless, so we may as well take it.
Comment 3 Aryeh Gregor 2010-07-23 18:17:42 UTC
(In reply to comment #2)
> Sure.  For instance (thanks to Philip, although as he warns, it's five years
> old):

Sorry, I misunderstood him.  He estimates it's maybe two years old.
Comment 4 Christopher Yeleighton 2010-07-24 08:20:47 UTC
(In reply to comment #2)
> (In reply to comment #1)
> > Note that KBD means "user input", and user input is a different thing than the
> > result of it.  Example: Pressing <KBD >Ctrl <KBD >C</KBD ></KBD > does not
> > produce any result (<TT ></TT >).
> 
> Yes, but HTML does not need to respect all possible semantic distinctions.  It
> could include <noun> and <adjective> tags too, hypothetically, but almost no
> one wants to mark up nouns or adjectives specifically.  Such marginal use-cases
> are what things like class="" and microdata are for.  Dedicated elements are
> only needed for very important or widely-used semantics.
> 

I only wanted to say that TT is not a good replacement for KBD.
Comment 5 Ian 'Hixie' Hickson 2010-09-08 07:12:19 UTC
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: Yeah, they're not used much and should probably not have been introduced. But I don't buy that they're going to cause any extra harm in the future, unlike, say, <abbr>, which was actively causing harm on an ongoing basis. IMHO removing these would just annoy people who use them (likely early adopters and people who care about HTML, exactly the people we _don't_ want to irritate), without actually measurably helping anyone else out.
Comment 6 Aryeh Gregor 2010-09-08 19:09:14 UTC
Meh.  Okay, no big deal either way.