W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > July 2011

[Bug 9350] Make <wbr> element conforming

From: <bugzilla@jessica.w3.org>
Date: Mon, 04 Jul 2011 05:09:35 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1QdbPb-0003qB-5W@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9350

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|CLOSED                      |REOPENED
                 CC|                            |xn--mlform-iua@xn--mlform-i
                   |                            |ua.no
         Depends on|                            |9711
         Resolution|FIXED                       |

--- Comment #8 from Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> 2011-07-04 05:09:33 UTC ---
(In reply to comment #7)
> See bug 9711.

Bug 9711 has been reopened. 

(In reply to comment #1)

Maciej:
> Mark Pilgrim points out that <wbr> is used heavily on the popular
> quirksmode.org site, an explanation here:
> http://www.quirksmode.org/oddsandends/wbr.html

1) And as effect, VoiceOver - correctly (because HTML5 defines it as word
separator) - treates "incor<wbr>rect" as two distinct words. See:
http://www.quirksmode.org/compatibility.html 

2) The page also gives this code example: "<div
class="name">getElements<wbr>ByTagName()</div>". And Aryeh will tell you that
if you copy the rendered result to the clipboard, then the <wbr> element will
not be copied to the clipboard, resulting in "getElementsByTagName()". Which
clearly is practical for the developer who wants to copy for reuse.
**However,** it does not seem congruent with HTML5's definition of <wbr> as a
word separator - *nor* with your alginment of <wbr> withi <br> in comment #0 -
that <wbr> does not result in ZeroWidthSpace on the clipboard!

> That page also suggests &#8203; as a possible replacement for <wbr>, but that
> doesn't create a line-breaking opportunity inside white-space: nowrap, so it's
> not exactly the same.

With all due respect for PPK:

* Buggy results: 
- The page lists Opera as supporting <wbr>. But Opera has zero support for
<wbr>.
- Since you looked at that page, IE9 can be addedas not supporting <wbr>
* Buggy tests:
- The page states that 'wbr:after { content: "\00200B" }' adds support for
<wbr> in Opera ... Uh? In other words: We know the reason for the the
misdescription of Opera as supporting <wbr>. 
* Bad alternative solution:
   - He does not offer any tests for zwsp character, which he could have used.
(With the same bad results for screenreaders, plus bad results for the
developeres, which would mean that he could actually discover the problem!).

(In reply to comment #0)
> It's not clear if there is any CSS construct that has equivalent effect to
> <wbr>.

<div style="white-space:pre-wrap">Lorem&#x200B;ipsum</div>
<div style="white-space:pre-line">Lorem&#x200B;ipsum</div>

> <wbr> should also be conforming, with a semantic of "a line break opportunity,
> even in otherwise preformatted text". This seems similar in spirit to the other
> elements named.

You are partly right: Yes it would be logical to treat <wbr> inside <pre> the
exact same way as ZeroWidthSpace is treated inside <pre>, with the
justification that <br> inside <pre> is treated exact same way as Line Feed
inside <pre>. 

*However*, then it must be added that <br> - unlike <wbr> in
Firefox/Webkit/Konqueror - gets copied to the clipboard  as a line break/line
feed. And hence, <wbr> should also, congruently, be copied to the clipboard as
a ZeroWidthSpace.

 (Perhaps, inside the browser's clipboard, it will be represented as an element
node (?), but at least when pasted into an exrternal text editor, *then* it
should be converted to a ZeroWidthSpace.)

> In any case it seems perverse to suggest that authors should "use appropriate
> elements or CSS instead" of <wbr>, when there are no elements that provide an
> alternative, and apparently no CSS either.

The only "perverse" thing is that it mention "elements", as there are no
elements, other than <wbr>. But there were nothign perverse with mentioning
CSS. See above.

> <wbr> is still used on the Web, often enough that browser engines must
> implement it.

This is questionable. IE8/IE9/Opera survives without implementing it. I
actually think it would have been preferrable to treat <wbr> as a void
<span>-like element without any line break opportunity whatsoever. Or perhaps
more realisticly: Make <wbr> an element that only has effect in Quirks-Mode.

> Out of the Alexa top 10, only YouTube uses it:
> http://www.w3.org/html/wg/wiki/index.php?title=HTML5_Authoring_Conformance_Study

That link was hard to become wise from. Can you show a Youtube page that is
using it?

(In reply to comment #2)
> In testing, I found that Gecko and WebKit allow <wbr> to override white-space:
> nowrap, but not white-space: pre. Zero-width space does not override either.

Gecko *still* behaves the same way. Whereas Webkit now, behaves like your
zealot reading of the spec suggested: it <wbr> has effect for white-space:pre
too. And for IE in Quirks-Mode you will find that <wbr> has zero effect in in
combination with white-space:pre. Test page:
http://malform.no/testing/html5/wbrwhitespace/index.html
This hints that the need for browsers to support <wbr> is much more minimal
than you suggest. And, at the very least, there can be no reason to make it
work with white-space:pre.

-- 
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 05:09:42 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 16:31:13 UTC