9097 2010-02-20 11:24:21 +0000 Add wbr { content: "\200B"; } (ZWSP)? 2011-12-01 00:06:03 +0000 1 1 1 Unclassified HTML WG LC1 HTML5 spec unspecified All All RESOLVED WONTFIX http://www.whatwg.org/specs/web-apps/current-work/#punctuation-and-decorations P3 normal --- 9711 13098 1 contributor contributor ayg ian mike public-html-admin public-html-wg-issue-tracking xn--mlform-iua public-html-bugzilla oldest_to_newest 32470 0 contributor 2010-02-20 11:24:21 +0000 Section: http://www.whatwg.org/specs/web-apps/current-work/#punctuation-and-decorations Comment: Add wbr { content: "\200B"; } (ZWSP)? Posted from: 91.182.134.139 by ms2ger@gmail.com 32680 1 ian 2010-02-25 11:20:51 +0000 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: Is that really equivalent in all cases? I'd rather just leave it up to prose unless that really does match all cases correctly. 32696 2 zcorpan 2010-02-25 22:37:19 +0000 I think it doesn't make a difference (for Opera/WebKit) in the normal case and doesn't do what's desired inside <nobr>. 50621 3 ayg 2011-07-03 17:17:39 +0000 *** Bug 13098 has been marked as a duplicate of this bug. *** 50636 4 xn--mlform-iua 2011-07-04 10:09:28 +0000 (In reply to comment #1) > Rationale: Is that really equivalent in all cases? I'd rather just leave it up > to prose unless that really does match all cases correctly. Though browsers are extremely buggy and uneven w.r.t. how they implement - or *whether* they implemnent <wbr>, the answer is yes, it *is* equivalent in all cases: normal, pre, nowrap, pre-wrap and pre-line. Test page: http://malform.no/testing/html5/nobr The test page shows that unless the browser has a genereal bug in its CSS generated content support *or* a bug in its implementation of Zero Width Space character, then the proposed wbr{content:"\00200B"} matches reality. Caveat: I disagree that <wbr> should have any effect inside white-space:pre and white-space:nowrap. (In reply to comment #0) > Add wbr { content: "\200B"; } (ZWSP)? +1 But you forgot two zeroes: wbr{content:"\00200B"} (In reply to comment #2) > I think it doesn't make a difference (for Opera/WebKit) in the normal case Your statement is incorrect, with regard to Opera. The proposed style (see above) does work very well with Opera. Not only does it work well in Opera: if we change the selector from wbr{} to wbr:before{}, then it also works very well in IE8. Test case for white-space:normal: http://malform.no/testing/html5/nobr#normal > and doesn't do what's desired inside <nobr>. Test case: http://malform.no/testing/html5/nobr#nowrap IE-in-quirks mode, IE6, IE7, Webkit and Konqueror do *not* define the desired behavior. The desired behaviour is defined by Firefox 5, IE8, IE9 and Opera. See bug 9711 (see 5th comment). 50639 5 xn--mlform-iua 2011-07-04 11:49:10 +0000 Peter Paul Koch implemented wbr in Opera as wbr{ content: "\00200B" }. However, he was unable to make it work in IE8: http://www.quirksmode.org/oddsandends/wbr.html However, it turns out that one can enable it in IE8, very easily, if only one uses wbr{display:inline-block} to trigger the infamous hasLayout. Peter Paul Koch's test case, with the hasLayout trigger: http://malform.no/testing/html5/wbr-haslayout 50702 6 xn--mlform-iua 2011-07-05 23:55:36 +0000 (In reply to comment #5) > However, it turns out that one can enable it in IE8, very easily, if only one > uses wbr{display:inline-block} to trigger the infamous hasLayout. Peter Paul > Koch's test case, with the hasLayout trigger: > http://malform.no/testing/html5/wbr-haslayout SORRY, incorrect: it does *not* trigger hasLayout. CORRECT INTEPRETATION: *{display:inline-block} creates a line-break opportunity. Every tested browser treats an empty element with {display:inline-block} as a line-break oportunity. See my *heavily* updated test page: http://malform.no/testing/html5/nobr Thus, instead of wbr{content:"\00200B"}, we could simply say wbr{display:inline-block}. This is far more compatible with existing web browsers, as well. 50715 7 xn--mlform-iua 2011-07-06 09:39:40 +0000 I would like extend ms2ger's proposed style, wbr{content:"\00200B";} with one more style rule: nobr wbr{white-space:normal} Those two style rules are together able to replicate the <wbr> effect inside <nobr> See new test page: http://malform.no/testing/html5/nobr+wbr 50730 8 xn--mlform-iua 2011-07-06 17:00:33 +0000 (In reply to comment #7) Or perhaps better, this solution: /* Outside NOBR: */ wbr { display:inline-block; } /* Inside NOBR: */ nobr wbr { display:inline; white-space:normal; content:"\00200B"; } NOTE: For IE7/IE6/IE Quirks-Mode, wbr{inline-block;} also works inside NOBR, but in the other browsers, wbr{inline-block} makes it **not** work in NOBR. 53672 9 mike 2011-08-04 05:16:14 +0000 mass-move component to LC1 60709 10 ian 2011-12-01 00:06:03 +0000 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: I see no benefit to doing this, and it's quite risky.