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: Did Not Understand Request
Change Description: no spec change
Rationale: There are far more values than just 'nowrap' and 'pre'.

If you want me to change this to list specific values for 'white-space', could you list all the values and say for each one whether it should override or not?

The (In reply to comment #1)

> If you want me to change this to list specific values for 'white-space', could
> you list all the values and say for each one whether it should override or not?

List of 'white-space' values for which <wbr> should cause a line break opportunity:

     *{white-space:pre-line}
     *{white-space:pre-wrap}

Thus:<wbr> should *NOT* provide line break oportunity for white-space:pre or white-space:nowrap.

JUSTIFICATION: 

(1) Basic premise: <wbr>'s effects should, for sanity, be as much aligned with the ZERO WIDTH SPACE character as possible.

(2) Authors: Since <wbr> has extremely bad and uneven cross browser support, HTML5 should not encourage its use by attaching "attractive" side effects to it  (other than those that follow by necessity due to the fact that it is an element and not a character). "Extra" features will only make it hard to explain and will also make authors use it for the extra (read: the wrong) reasons. By extra features, I have in mind: white-space, clipboard, search/find or doubleclicking behaviour that differs from Zero Width Space (ZWSP).

(3) Accessibilitiy: HTML5 defines <wbr> as a word separator. And screenreaders, such as VoiceOver, therefor read "pres<wbr>ident" as "pres ident" rather than as "president". A real world example: VoiceOver reads "incor rect" and not "incorrect" in the table of this page:  http://www.quirksmode.org/compatibility.html  (Note: If the user makes use of a browser which does not support <wbr> at all (such as IE8/IE9), then he/she will not experience this issue.)

(3) Vendors: If there are problems with the way the ZERO WIDTH CHARACTER works, then vendors need to work on these problems instead of promoting <wbr> as a solution with problem solving sideeffects.

(4) The "unique" features of <wbr> seems to be the result of the bad/uneven implementation status rather than very well thought out features. To demonstrate this, hereby follows some test results, which compares treatment of <wbr> with treatment of shy and zwsp.

   A) Should a search for the single word "president" also match "pres<wbr>ident"?
       http://malform.no/testing/html5/wbrwhitespace/#wordtest
       Both <wbr> supporting and not wbr supporting browsers in this regard actually treat <wbr/> like they treat  <span></span>. Thus e.g. Firefox treats <wbr> different from zwsp. But it would be incorrect to promote <wbr> because browsers - erroneously- fail to treat it as a word separator when performing search. Instead, it should be made to work like Zero Width Character. If this causes problems, then Chrome and Webkit trunk have a solution: they more or less ignore *all* non-printing characters when performing a search. In other words: fine tuning of search facilities is what is needed, rather than promotion of <wbr>.

   B) Doubleclicking the two words "pres" and "ident" that are separated by <wbr>:
       http://malform.no/testing/html5/wbrwhitespace/#wordtest
       Those browsers that do ignore <wbr> do in principle also select both words as one word. (Exception: IE8 is severely broken - it doesn't even permit an empty <span></span> inside the word/between the words.) Amongst those browsers that *do* support <wbr>, then Firefox does not select both words. Konqueror behaves like Firefox. Thus doubleclicking inside Konqueror and Firefox makes not difference between <wbr> and the way ZWSP character (is supposed to) work. Opera ignores <wbr> - but in the rest of the details, it behaves like Firefox. Webkit trunk and Chrome partly jumps over the problem by more or less ignoring all non-printing characters, hence they do select both words. But Webkit/Chrome do make a minor distinction between <wbr> and the ZeroWithSpace: if you doubleclick *before* the ZeroWidthSpace, then only the first word is selected. While if you click after the ZeroWithSpace, then both words are selected. (For <wbr>, Chrome/Webkit makes no such minor distinction.) 

   C) Copying words with <wbr>/SHY/ZWSP to the clipboard
       http://malform.no/testing/html5/wbrwhitespace/#wordtest
       Is <wbr>, SHY and ZWSP copied to clipboard?
       Opera:
           WBR: no, *because* it doesn't support <wbr>.
           SHY: only if causing a hyphenation.
           ZWSPC: yes always.
       IE8:
           WBR: no, *because* it doesn't support <wbr>.
           SHY: yes, always
           ZWSPC: yes always.
       Webkit trunk/Chrome/Konqueror/Firefox
           WBR: no
           SHY: Yes, always
           ZWSPC: yes always.

     SUMMARY: I think this proves that <wbr>'s "unique" features (which were used to justify <wbr>'s validty in bug 9350, are due to sloppy  - or lack of - implementation rather than anything elese. Hence, there is no reason for the rendering section of HTML5 to maintain any of these "unique" features.

(5) CSS + correct white-space value can create the exact same effect as <wbr> is supposed to have. Thus there is no reason provide authors with an option to provide line break opportunities inside whites-space:pre. Furthermore, Webkit is pretty unique in its treatmetn of <wbr> - there is no reason to encourage its behaviour. Hereby follows some test results that demonstrates that CSS + correct white-space value is sufficient.

  A) All browsers that support both CSS and SOFT HYPHEN or ZERO WIDTH *do permit* that line breaks can occur on these characters whenever white-space:pre-line or white-space:pre-wrap is used. Tested in: Webkit, IE8/IE9, Firefox 5, Opera 11.50, Konqueror 4.6.4. (Konqueror showed a bug in its support for Zero Width Space, but supports Soft Hyphen)
      Test cases: 
      http://malform.no/testing/html5/wbrwhitespace/#pre-wrap
      http://malform.no/testing/html5/wbrwhitespace/#pre-line

(2) Only Webkit breaks the line inside  white-space:pre.
      IE8/IE9, Firefox 5, Opera 11.50, Konqueror 4.6.4 do *not*.
      Test case:
      http://malform.no/testing/html5/wbrwhitespace/#pre

(3) Only Webkit and Konequeror break the line inside white-space:nowrap
      IE8/IE9, Firefox 5, Opera 11.50 do *not*.
      Test case:
      http://malform.no/testing/html5/wbrwhitespace/#nowrap

(In reply to comment #2)

>    C) Copying words with <wbr>/SHY/ZWSP to the clipboard
>        http://malform.no/testing/html5/wbrwhitespace/#wordtest
>        Is <wbr>, SHY and ZWSP copied to clipboard?
>        Opera:
>            WBR: no, *because* it doesn't support <wbr>.
>            SHY: only if causing a hyphenation.
>            ZWSPC: yes always.
>        IE8:
>            WBR: no, *because* it doesn't support <wbr>.
>            SHY: yes, always
>            ZWSPC: yes always.
>        Webkit trunk/Chrome/Konqueror/Firefox
>            WBR: no
>            SHY: Yes, always
>            ZWSPC: yes always.


Forgot to add: <br> *is* copied to the clipboard as a linefeed character (at least it results in a linefeed when pasting into plain text). Therefore it does not make sense to not copy <wbr> as a ZWSP character to the clipboard. The fact that <wbr> is not currently copied to the clipboard has nothing to do with its "element features" as opposed to ZWSP's "character features". If users need a way to copy e.g. source code examples without zwsp in the clipboard, then this needs to be solved in a different way.

(In reply to comment #2)
>    B) Doubleclicking the two words "pres" and "ident" that are separated by
> <wbr>:
>        http://malform.no/testing/html5/wbrwhitespace/#wordtest

> Amongst those
> browsers that *do* support <wbr>, then Firefox does not select both words.
> Konqueror behaves like Firefox.

And IE in QuirksMode (where it supports <wbr>) does also not select both words.

(In reply to comment #0)

> In testing, I found that Gecko and
> WebKit allow <wbr> to override white-space: nowrap, but not white-space: pre."

Actually, despite that you challenge the spec text, your picture of the facts is incorrect and thus far too positive (towards the current spec text).

FIRSTLY: Reality is that Firefox 5  does *not* behave as you say. That is: <wbr> does not override white-space:nowrap in FIrefox 5.  Thus Webkit, Konqueror and IE in quirks-mode are alone in showing this behaviour. 

Test: http://malform.no/testing/html5/nobr#nowrap

SECONDLY: Although Webkit does perform some kind of line break for <wbr> inside white-space:pre, it is difficult to understand what kind of logics it uses. Apparently, it only breaks the *last* <wbr>, if there is more than one. Note as well, that IE in Quirks-Mode does *not* allow <wbr> to cause a line break. 

Test: http://malform.no/testing/html5/nobr#pre

mass-moved component to LC1

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: The spec now has an example demonstrating what I think is a valid use case for <wbr> in <pre>.