[Bug 9711] <wbr> must not override white-space:pre (or differ from Zero Width Space in any other needless way)

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

Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |xn--mlform-iua@xn--mlform-i
                   |                            |ua.no
         Resolution|NEEDSINFO                   |
            Summary|"The wbr element is         |<wbr> must not override
                   |expected to override the    |white-space:pre (or differ
                   |'white-space' property and  |from Zero Width Space in
                   |always provide a            |any other needless way)
                   |line-breaking opportunity." |
                   |-- "In testing, I found     |
                   |that Gecko and WebKit allow |
                   |<wbr> to override           |
                   |white-space: nowrap         |
            Summary|but not white-space: pre."  |
                   |(from http://www.w3.        |

--- Comment #2 from Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> 2011-07-04 03:37:42 UTC ---
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

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Monday, 4 July 2011 03:37:47 UTC