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 13120 - Delegate <wbr> support to quirks-mode - make it have zero effect in no-quirks and almost-standards
Summary: Delegate <wbr> support to quirks-mode - make it have zero effect in no-quirks...
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: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL: http://dev.w3.org/html5/spec/text-lev...
Whiteboard:
Keywords:
Depends on: 9350 9711 10342 13098
Blocks:
  Show dependency tree / graph
 
Reported: 2011-07-02 11:06 UTC by Leif Halvard Silli
Modified: 2011-08-04 05:04 UTC (History)
5 users (show)

See Also:

Attachments

Description Leif Halvard Silli 2011-07-02 11:06:02 UTC 
REQUEST: <wbr> should be made obsolete, in favour of the zero with space character (zwsp). 

JUSTIFICATON: According to the spec, the usecase for <wbr> is  "something which, for effect, is written as one long word". However:

(1) The <wbr> usecase is extremely narrow. 

(2) <wbr>'s benefits over the zero width space character are unclear. It can be styled, and it apparently isn't copied to the clipboard. It can also be said to be easier to type. But if these effects are so important, why don't we also create similar elements for the other whitespace/invisible characters of Unicode? Other whitespace/invisble characters can also be difficult to type, so why does this character need element representation?

(3) In praxis, authors do not have a clear picture of what the usecase for <wbr> is. For example, Aryeh in a comment seemd to think the usecase is to avoid that long words make a table stretch (plus the extra benefit over the zero width character hat <wbr> is not copied to the clipboard): http://www.w3.org/Bugs/Public/show_bug.cgi?id=13098#c8  Other authors, again (like myself) have seemed to think <wbr> has something to do with hyphenation.

(4) The zwsp should be used seldomly and concsiously. The fact that it is difficult to type, is a feature! (Though, OTOH, there are _several_ named character references for it which makes it easy enough to type!) But the fact that <wbr> (which conceptually represents the zwsp character)  is valid, will make authors use is it much more often than the use case permits. Why? Because its validity "favors" the zero width space character over the other invisble/whitespace Unicode characters that do not have an HTML element to represent their effect.

(5) Authors in reality need something else: When a line break happens in the middle of a word because the word contains a <wbr> element,  the result is something which visually looks like two words. While this is in line with <wbr> as HTML5 specifies it, what most authors using <wbr> *really* want/need, is a <shy> element which would make the word become *hyphenated* at the point where <shy> is located. So, if <wbr> remains valid, we should create a lot more white space elements as well.

(6) Internet Explorer version 8 and 9 has removed support for <wbr> - they now only support it in Quirks-Mode. Opera still does not support it. In contrast, the zero width character is supported by both Webkit; Firefox, Opera and IE - in standards mode as well.

(7) Keeping this element conforming only distracts authors and vendors attention from more important things. (For instance, some web browsers, like Konquerer and some text browsers, have support for <wbr> but do not have support for the zwsp character.)

(8) Even if we make it obsolete, conforming HTML5 parsers are still required to support it. Thus, it is pretty risk free. In fact, <wbr> wasn't even mentioned in HTML4, so the fact that it gets obsolete status, can in fact be seen as a form of recognition ...

(9) Currently (in HTML5/XHTML1.x), the <wbr> is non-conforming. And since the benefits of <wbr> are so unclear while its drawbacks are so clear, it makes no sense to spend time advocating its validity.
Comment 1 Leif Halvard Silli 2011-07-02 11:09:23 UTC 
(In reply to comment #0)

Typo:

> (9) Currently (in HTML5/XHTML1.x), 

Sorry. Meant **(in HTML4/XHTML1.x)**.

>  the <wbr> is non-conforming. And since the
> benefits of <wbr> are so unclear while its drawbacks are so clear, it makes no
> sense to spend time advocating its validity.
Comment 2 Leif Halvard Silli 2011-07-02 11:57:04 UTC 
(In reply to comment #0)

JUSTIFICATION continued:

10) FUD: Keeping <wbr> valid only serves to sustain FUD about how well browsers support the Zero Width Space character (zwsp). For example, pointing to the lackign support for zwsp in very legacy IE6, Wikipedia gives the impression that <wbr> is better supported than the Zero Width Space character: [link]

   ]] In HTML pages this space can be used as a potential line-break in long words as a replacement for the non-standard <wbr> tag. However, the zero-width space is not supported in all web browsers, most notably Internet Explorer version 6 and below[1]. [[

[link] http://en.wikipedia.org/w/index.php?title=Zero-width_space&oldid=435186349

The reality is of course the opposite: Zero Width Space character is *better* supported than <wbr>.

[11] Too many options: HTML5 includes 5 named character references for the zwsp character.  Thus authors have enough options. The <wbr> option only serves to create confusion about the benefits of  the character versus the element.

[12] If "simple to type" is an argument then &zwsp; can be made a valid named character references, as requested in Bug 1310.
Comment 3 Leif Halvard Silli 2011-07-02 11:58:49 UTC 
(In reply to comment #2)
> (In reply to comment #0)

Typo:

> [12] If "simple to type" is an argument then &zwsp; can be made a valid named
> character references, as requested in Bug 1310.

Sorry, meant Bug 13108.
Comment 4 Leif Halvard Silli 2011-07-02 13:13:00 UTC 
(In reply to comment #2)
> (In reply to comment #0)

> 10) FUD: Keeping <wbr> valid only serves to sustain FUD about how well browsers
> support the Zero Width Space character (zwsp).  [...] IE6, Wikipedia 

The IE6 bug actually only occurs in combination with certains fonts that are lacking the zwsp characters: http://dunae.ca/2009/better-web-typography-with-spaces-and-hyphens/

I am not able to reproduce this bug - may be because the fonts have improved?

It is anyway purely an aficionado bug in a irrelevant web browser. (Aficionados will be able to fix it - probably like this: <span style="font-family:serif">&#x200b;</span>.)
Comment 5 Leif Halvard Silli 2011-07-02 13:28:05 UTC 
Test cases: http://malform.no/testing/html5/wbrzerowidthspace.html
Comment 6 Aryeh Gregor 2011-07-03 17:16:10 UTC 
Use-cases were presented by Maciej in bug 9350, where he pointed out that its behavior does not match zwsp or any construct specifiable using CSS.  Specifically, it overrides white-space:

"""
The wbr element is expected to override the 'white-space' property and always provide a line-breaking opportunity.
"""
http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#phrasing-content-1

*** This bug has been marked as a duplicate of bug 10342 ***
Comment 7 Leif Halvard Silli 2011-07-04 05:56:55 UTC 
(In reply to comment #6)
> Use-cases were presented by Maciej in bug 9350, 

Bug 9350 has been reopened.

> where he pointed out that its
> behavior does not match zwsp or any construct specifiable using CSS. 
> Specifically, it overrides white-space:
> 
> """
> The wbr element is expected to override the 'white-space' property and always
> provide a line-breaking opportunity.
> """

These argumetns have been questioned in 8th comment of Bug 9350: http://www.w3.org/Bugs/Public/show_bug.cgi?id=9350#c8

> http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#phrasing-content-1
> 
> *** This bug has been marked as a duplicate of bug 10342 ***

Obsoletation isn't enough. Parser support for <wbr> should be delegated to quirks-mode. Thus, this bug has been renamed to: "Delagate <wbr> support to quirks-mode - make it have zero effect in no-quirks and almost-standards".

JUSTIFICATION for delagating it to quirks-mode: 

* <wbr> is conceptually very unclear and misunderstood. There is no unique usecase.
* no single browser implements it in sane way - they all differ
   See: http://www.w3.org/Bugs/Public/show_bug.cgi?id=9711#c2
* IE has already delagated support to Quirks-Mode only.
* Making <wbr> have zero effect in standards mode is pretty risk free: Due to the fact that no browser really implements <wbr> in full,  the text levels effects (that is: the effects on searching, selection, doubleclicking, clipboard copying) are in some cases zero and in other cases close to zero. 

For more arguments, see my comments in the bugs that I have made this bug dependent on.
Comment 8 Aryeh Gregor 2011-07-06 19:53:11 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: Quirks mode is evil -- it makes the platform significantly more confusing and complicated, both for authors and implementers.  We want to keep the differences between quirks and standards to an absolute minimum.  The only grounds for standardizing quirks are if they have to be quirks for web compat, or (theoretically) if the behavior is extremely horrible but we can't get rid of it completely but we could get away with making it a quirk.

In this case, if we don't want support for <wbr>, we can remove support entirely.  As you point out, compat is not an insurmountable issue here, since browsers don't consistently support it anyway.  Thus we should get rid of it if we don't want it, and keep it in all modes if we do.  Making it quirks-only is the worst of all worlds.
Comment 9 Michael[tm] Smith 2011-08-04 05:04:05 UTC 
mass-moved component to LC1