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 10342 - Make <wbr> element not conforming
Summary: Make <wbr> element not conforming
Status: RESOLVED WONTFIX
Alias: None
Product: HTML WG
Classification: Unclassified
Component: LC1 HTML5 spec (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: contributor
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords: a11y
Depends on:
Blocks: 13120
  Show dependency treegraph
 
Reported: 2010-08-10 19:04 UTC by Rouven We
Modified: 2011-11-30 21:28 UTC (History)
5 users (show)

See Also:


Attachments

Description Rouven We 2010-08-10 19:04:48 UTC
First, I know this runs completely against Bug #9350. Since I'm neither in the WG nor have I've ever been involved into a process like this I don't know if this is the right process but I will just put my thoughts here for consideration:

Major:
-The <wbr> element is unnecessary because it clutters the DOM with things that can be expressed as unicode characters or named character references (often &shy; would be preferential since it adds a hyphen, else one that corresponds to U+0200B)
-With <wbr> present but no corresponding element for a shy hyphen I fear a large use of <wbr> were a shy hypen would be in order.

Minor:
-It is not supported in Internet Explorer 8.
Comment 1 Ian 'Hixie' Hickson 2010-09-10 23:11:26 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: I think bug 9350 indicated that there are use cases for this and that it is widely used, while the costs of allowing it are minimal. So I don't see much value in dropping it. Nobody is forced to use it, indeed using &shy; is perfectly fine too.
Comment 2 Aryeh Gregor 2011-07-03 17:16:10 UTC
*** Bug 13120 has been marked as a duplicate of this bug. ***
Comment 3 Leif Halvard Silli 2011-07-04 05:55:43 UTC
(In reply to comment #1)

> Status: Rejected
> Change Description: no spec change
> Rationale: I think bug 9350 indicated that there are use cases for this and
> that it is widely used, while the costs of allowing it are minimal. So I don't
> see much value in dropping it. Nobody is forced to use it, indeed using &shy;
> is perfectly fine too.

* I sharte Rouven's concerns.

* My comment in Bug 9350 questions that there is any use case - there are only bad and misundestood implementations: http://www.w3.org/Bugs/Public/show_bug.cgi?id=9350#c8

* In particular, browsers vary to a high degree: Bug 9711, in particular comment 2: http://www.w3.org/Bugs/Public/show_bug.cgi?id=9711#c2

* In fact, <wbr> should not only become obsolete - it should also only have effect at all in quirks mode: Bug 13120.
Comment 4 Michael[tm] Smith 2011-08-04 05:35:10 UTC
mass-move component to LC1
Comment 5 Ian 'Hixie' Hickson 2011-11-30 21:28:34 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: On balance, I think the use cases argued for in the aforementioned bug argue for keeping the element despite its current issues.