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

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.

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.

Side note: zero-width non-joiner does not create a breaking opportunity, though it is otherwise very similar to zero-width space.

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: Partially Accepted
Change Description: see diff given below
Rationale:

This appears to be mostly redundant with ZWSP, but it's probably a usability win to allow it rather than requiring that people use <wbr>.

(I don't think the nowrap thing is especially compelling as an argument in favour of ZWSP rather than <wbr>. If anything, that's an argument to avoid <wbr>, since it means it is rather quirky already.)

Checked in as WHATWG revision r4956.
Check-in comment: Make <wbr> valid.
http://html5.org/tools/web-apps-tracker?from=4955&to=4956

Thanks!

See bug 9711.

(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.

(In reply to comment #8) [ .... ]
> (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


> * 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>. 

Yet another argument in favour the view that <wbr>  is nothing but a wrapper for the Zero Width Space character: If support for wbr:after { content: "\00200B" } is equal to support for <wbr>, then even IE8 and IE9 supports it. See test page: http://malform.no/testing/html5/wbr-haslayout

Reopening an already-fixed bug a year later is probably not the best way to have  the matter reconsidered. By our process this bug really should have made it to CLOSED state already.

(In reply to comment #10)
> Reopening an already-fixed bug a year later is probably not the best way to
> have  the matter reconsidered.

What is the best way? I am ready to author a Change Proposal. 

Because <wbr> seems like one of  the most pointless and unjustified additions to HTML5 ever. It seems to have been added solely to bless a Webkit parsing peculiartiy. There hasn't been provided any real use cases. And Opera folks are still resisting the solution in the spec as much as am able to read the bugs. And I find it unlikely that the Webkit behaviour is any worth standardising around - why would e.g. Firefox change its sane behaviour for the Webkit one? 

> By our process this bug really should have made
> it to CLOSED state already.

I would suggest looking at the facts first and foremost. Speaking of which, I believe that this (newly updated) test page covers every rabbit hole possible when it comes to wbr: 

http://malform.no/testing/html5/nobr

Btw, there is one option that has not been discussed, and that is to treat <wbr> not as a word seperator in the semantic sense but simply an equivalent of 

       emptyElement{display:inline-block}

Because <wbr>, according to my test page (and when we look away from Webkit's peculiarities) is equivalent to an empty element with display:inline-block. This solution would also avoid that <wbr> causes "pres<wbr>ident" to be read by screen readers as two different words.

(In reply to comment #11)

> This solution would also avoid that <wbr> causes "pres<wbr>ident" to be read by
> screen readers as two different words.

Uh, I spoke to soon. We would not (necessarily) avoid it.  At least VoiceOver currently treats the following span element as a word separator, even if it has span{display:inline;}:

       pres<span></span>ident

(In reply to comment #12)
> (In reply to comment #11)

> Uh, I spoke to soon. We would not (necessarily) avoid it.  At least VoiceOver
> currently treats the following span element as a word separator, even if it has
> span{display:inline;}:
> 
>        pres<span></span>ident

Oh,  I forgot: VoiceOver's behavior is simply due to a bug in Webkit: The test page I pointed to above shows that Webkit is the only webbrowser which treats a span element as a line-break opportunity.

So, we *could* solve the issue by changing the semantics of <wbr> *and* instead of saying that <wbr> is equal to wbr{content:"\00200B"},  say that it is equal to wbr{display:inline-block}.

(In reply to comment #11)
> (In reply to comment #10)
> > Reopening an already-fixed bug a year later is probably not the best way to
> > have  the matter reconsidered.
> 
> What is the best way? I am ready to author a Change Proposal. 
> 
> Because <wbr> seems like one of  the most pointless and unjustified additions
> to HTML5 ever.

When you justified <wbr>, you pointed to Webkit's idiosyncratic implementation of it, and portrayed Webkit's interpetations as more or less the "standard" way that browser implements it. E.g you described <wbr> as breaking with CSS and gave the impression that it was *necessary* to break with CSS.

Well, my test page shows that Webkit's implementation differs from everyone elses.  In addition, Webkit is only surpassed by Konqueror when it comes to word boundaries bugs. (E.g. the fact that Webkit sees as inline <span/> as a word boundary.)

Even the Editor showed himself to be not 100% at ease with the "fixed" solution - why else the he add comment 7, after the bug was "fixed".?

Since this bug was fixed by pointing to Webkit's behaviour, the entire element IMO needs to be reevaluated if we reach the shared conclusion that Webkit's behaviour is particular to that browser.

For the record: It would be much more easy to accept a *sane* interpretation of <wbr> - e.g. the one found in Firefox. which as far as I can see, *fully* aligns <wbr> with ZERO WIDTH SPACE.

Webkit bugs related to <wbr>:
---

(1) https://bugs.webkit.org/show_bug.cgi?id=26414
      Note that it is its treatment of <wbr> inside *{white-space:pre} that is the source  of this bug! The right border of the table comes too early, proably because the parser thinks that a line-break has occured, whereas in reality, the line continues outside the righth side of the viewport and should have resulted in a page that stretched outside the viewport.  (As it does in Firefox/Opera/IE). The issue  can also be spotted in Konqueror, which is the browser which  is resembles Webkit the most when it comes to <wbr>.

(2) https://bugs.webkit.org/show_bug.cgi?id=19827
      This bug came because www.google.com, at an eariler point in time, sent a SPACE to Webkit when it sent <wbr> to Firefox.  (It is hard to track why it did so, anymore. But the bug claims that Webkit back then did behave like Firefox and IE. [Which, as I have documented, is not true.] So, actually, <wbr> might not have caused the effect in Webkit that it did in Firefox and in IE6 and IE7 - which could be the reason Google did nto use it. )

More <wbr> confusion in the wild:
---
(*) http://reference.sitepoint.com/html/wbr
     Site point's reference (sic) says: """ The wbr element’s purpose is to suggest/hint to the browser where within a word/phrase would be the most appropriate point for it to be broken (indicated with a hyphen) in the event that the browser viewport or containing element is reduced in size such that wrapping occurs. """
    When it compares it to a hyphen, then it has misunderstood it. <wbr> splits a word into two words.

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: Partially Accepted
Change Description: see comment 4
Rationale: Re-resolving as fixed.

* There is existing browser support of some form in all browsers, which means we have to spec it and implementers have to implement it, unless you can get major implementers to drop support.

* Once a feature has to be implemented anyway, the threshold for making it valid is low.  If this were a new feature request, it would be rejected, but we prefer to make existing features valid unless there are relatively good reasons against.  That minimizes useless validator noise and encourages authors to use validators more.

* There are some use-cases for <wbr>.  They aren't very strong, but given that we're stuck with it anyway, they're strong enough to make it valid.

* The fact that existing browsers implement <wbr> inconsistently and authors are confused about it is not a strong argument against making it valid.  Both of those things are true about many preexisting web features.  Either we have to drop support entirely, or specify it and get browsers to converge, regardless of validity.


I recommend that you do not continue to reopen bugs on this issue.  You have two viable options:

1) File bugs against browsers and try to get them to agree to drop <wbr> support entirely.  If implementers are willing to drop support, we can remove the element entirely, which is a win for simplicity of the platform.  I suspect it's widely enough used that you won't be able to convince them, though.

2) Follow the instructions in the boilerplate at the top of this comment to escalate to an issue: "add the TrackerRequest keyword to this bug, and suggest title and text for the Tracker Issue".