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 10862 - Remove the newly added "s" element
Summary: Remove the newly added "s" element
Status: RESOLVED WONTFIX
Alias: None
Product: HTML WG
Classification: Unclassified
Component: pre-LC1 HTML5 spec (editor: Ian Hickson) (show other bugs)
Version: unspecified
Hardware: Macintosh Mac System 9.x
: P2 normal
Target Milestone: ---
Assignee: contributor
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords: TrackerIssue
Depends on:
Blocks: 10953
  Show dependency treegraph
 
Reported: 2010-09-30 15:37 UTC by Shelley Powers
Modified: 2010-11-14 17:08 UTC (History)
9 users (show)

See Also:


Attachments

Description Shelley Powers 2010-09-30 15:37:28 UTC
A new element was recently added to the HTML5 specification. 

Adding new attributes and elements, or removing existing attributes and elements, is a major change. Such changes should be discussed in the group email list before being dumped into the specification.

Using a single letter to address an element has been discouraged in the past, and rightfully so. The letter "s" might be meaningful for a snake, but not for people. The fact that it is supposedly to mark text that is no longer relevant or correct can't be determined just by looking at the element.

In addition, the web is mutable, not static. If text is incorrect or no longer relevant, most web sites either adjust the text or remove the text. The example shows a price change in a web site -- can you imagine Amazon doing something like this? Amazon just changes the price. End of story, and no confusion.

If people want to use this as a marketing technique, as the example demonstrates, then they can use strike-through text to mark out the old value, because the use of an element makes no sense -- the fact that the text has changed isn't meaningful, the use in this case is a marketing ploy.
Comment 1 Shelley Powers 2010-09-30 15:38:04 UTC
Found out about the new element via this WG email entry:

http://lists.w3.org/Archives/Public/public-html/2010Sep/0384.html
Comment 2 Shelley Powers 2010-09-30 15:51:42 UTC
Correction:

Remove the newly re-added element, that was originally deprecated in HTML 4.

At least strike had a meaningful name. So why restore the deprecated element, but remove the non-deprecated element that supposedly has the same meaning?

There is a level of arbitrariness to this that is disturbing. Almost a level of frivolity, as displayed in this comment:

http://www.w3.org/Bugs/Public/show_bug.cgi?id=9429#c12

This was an incredibly inconsistent and illogical decision
Comment 3 Shelley Powers 2010-09-30 16:06:35 UTC
Oops, as was pointed out to me, strike was also deprecated. 

Frankly, making both s and strike obsolete was a legitimate move with HTML5. The purpose of these elements wasn't to mark semantics, it was to provide a line through the text. We can do this with CSS now. We should do this with CSS now.

If we undeprecate s (or strike for that matter), then we have inconsistent implementations on the web: some people have used s or strike purely for line-through presentation, some now, to match some new meaning.

If the intent was to create something more meaningful, then a new element would have been a more logical move, and one that wouldn't create a level of confusion.
Comment 4 Shelley Powers 2010-09-30 16:49:28 UTC
Another demonstration of the inconsistency of decisions is the reason decision the HTML5 editor made about the U element:

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

Ian Hickson wrote:

"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."

So we have arbitrarily decided that u is not semantic, but s is, though the same misuse of both elements occurred in the past, and will continue in the future.

There is no rhyme or reason, or logic, to any of this. I get the impression that a coin was tossed when deciding about each: heads, we keep s; tails, we dump u.

There is no underlying architectural design to these decisions. No overall plan. The editor arrived at them haphazardly--dumping in, and ripping out elements and attributes based seemingly more on a whim, than a solid technical foundation.
Comment 5 Maciej Stachowiak 2010-10-02 04:47:49 UTC
See also bug 9429 (this bug is apparently asking to reverse the editor's resolution on 9429).
Comment 6 Shelley Powers 2010-10-02 12:51:02 UTC
(In reply to comment #5)
> See also bug 9429 (this bug is apparently asking to reverse the editor's
> resolution on 9429).

Well, yes and no. 

I am asking to reverse the editor's decision, but his decision differed from what the original requestor asked. I didn't want the editor to reverse his decision about the s element, only to decide in favor of the strike element (per original bug request). 

I don't believe either element should be made "conforming", because both elements were presentational, not semantic, in earlier versions of HTML. To re-define the element isn't "backwards compatible". It's also going to be confusing to authors.

An additional concern I have is that an element specifically for marking incorrect or irrelevant text isn't necessary. The example he shows isn't particularly semantic, but does demonstrate how strike-through has been used: as a typographic gimmick. People also use it in an editorial sense, to convey an original impression, struck out in favor of a more polite response, such as the following:

He is a <strike>moron</strike>misguided individual. 

This isn't a correction or marking up irrelevant text: it's a typographical ploy. The same as the example that the editor put into the spec (showing an old price in favor of a new--buy now!) And it represents probably the most frequent use of both <s> or <strike>.
Comment 7 Ian 'Hixie' Hickson 2010-11-11 22:54:24 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: See bug 9429 for the rationale for having this element.
Comment 8 Sam Ruby 2010-11-14 17:08:53 UTC
http://www.w3.org/html/wg/tracker/issues/143