Closed
Bug 729047
Opened 12 years ago
Closed 12 years ago
<wbr> should have the same bidi effects as a U+200B, the zero width space
Categories
(Core :: Layout: Text and Fonts, defect)
Core
Layout: Text and Fonts
Tracking
()
RESOLVED
FIXED
mozilla13
People
(Reporter: aharon, Assigned: smontagu)
References
(Depends on 1 open bug)
Details
(Keywords: dev-doc-complete)
Attachments
(2 files)
1.97 KB,
patch
|
ehsan.akhgari
:
review+
|
Details | Diff | Splinter Review |
1.38 KB,
patch
|
ehsan.akhgari
:
review+
|
Details | Diff | Splinter Review |
Currently, data:text/html,<div dir=rtl>123,<wbr>456</div> is displayed as 456,123 (when it is not wrapped to two lines). There are three things wrong with this: - It gives you the wrong number with no hint to the user of what happened. We want it to display as 123,456, as if the <wbr> was not there. - It is not what IE9 does (it displays 123,456) - It seems to disagree with the HTML5 spec (http://dev.w3.org/html5/spec/Overview.html#phrasing-content-1), whose default style sheet section says: wbr { content: '\200B'; } Please note that U+200B, the ZERO WIDTH SPACE, is (unlike all the other space-type characters, e.g. U+200A, the HAIR WIDTH SPACE) of bidi class BN, which effectively has no effect on the bidi ordering of the content around it (see http://unicode.org/reports/tr9/#Boundary_Neutrals). Thus data:text/html,<div dir=rtl>123,&%23x200B;456</div> displays as we want it to, i.e. 123,456. Unfortunately, the HTML5 spec currently gives no more explicit indication of the effects the <wbr> is supposed to have on the bidi ordering of the content around it, and I have filed a bug on HTML5 (https://www.w3.org/Bugs/Public/show_bug.cgi?id=16001) about that. Also, the content spec in the default style sheet is rather strange, given that the <wbr> definition (http://dev.w3.org/html5/spec/Overview.html#the-wbr-element) explicitly says that "content inside wbr elements must not be considered part of the surrounding text". Nevertheless, I think that there is sufficient reason to change the bidi behavior of <wbr> to match that of U+200B (when the line is not wrapped at the <wbr>), without waiting for the last word from the HTML5 spec. Please note that currently there are no good workarounds to this bug. Using ​ instead of <wbr> results in a stupid invisible character in the page, which is no fun if the user cuts, pastes, and edits the content. Furthermore, unlike <wbr>, it does not work inside a <pre>. And adding wbr { content: '\200B'; } to the page's style currently does not seem to have any effect (perhaps the content pseudo-property is not supported yet?).
Reporter | ||
Comment 1•12 years ago
|
||
Does it really depend on bug 178671? The bidi behavior of <wbr> could be fixed without implementing <wbr> in CSS. Indeed that is what I would prefer given 178671 still being open since 2002 :-) - unless a fix already seems to be imminent.
Assignee | ||
Comment 2•12 years ago
|
||
I think that fixing this via bug 178671 would be cleaner, but that seems to have various hidden pitfalls. See especially bug 178671 comment 8 and attachment 544285 [details] (from bug 485241). I'll test a bidi-only fix on try
Assignee | ||
Comment 3•12 years ago
|
||
Assignee: nobody → smontagu
Attachment #599879 -
Flags: review?(ehsan)
Assignee | ||
Comment 4•12 years ago
|
||
Attachment #599880 -
Flags: review?(ehsan)
Reporter | ||
Comment 5•12 years ago
|
||
Thanks! I am no Mozilla reviewer, but the patch looks very clean to me.
Comment 6•12 years ago
|
||
Comment on attachment 599879 [details] [diff] [review] Patch Review of attachment 599879 [details] [diff] [review]: ----------------------------------------------------------------- ::: layout/base/nsBidiPresUtils.cpp @@ +1141,5 @@ > // U+FFFC" > + // <wbr>, however, is treated as U+200B ZERO WIDTH SPACE. See > + // http://dev.w3.org/html5/spec/Overview.html#phrasing-content-1 > + aBpd->AppendUnichar(content->Tag() == nsGkAtoms::wbr ? > + kZWSP : kObjectSubstitute); Please use content->IsHTML(nsGkAtoms::wbr). Also, please fix the indentation.
Attachment #599879 -
Flags: review?(ehsan) → review+
Updated•12 years ago
|
Attachment #599880 -
Flags: review?(ehsan) → review+
Assignee | ||
Comment 7•12 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/dc07bfbf0a44 https://hg.mozilla.org/integration/mozilla-inbound/rev/9658d5eee1e9
Flags: in-testsuite+
Hardware: x86_64 → All
Target Milestone: --- → mozilla13
Comment 8•12 years ago
|
||
I've explained the bidi behavior in https://developer.mozilla.org/en/HTML/Element/wbr and added a note for the fix in: https://developer.mozilla.org/en/Firefox_13_for_developers
Keywords: dev-doc-complete
Comment 9•12 years ago
|
||
Sorry I jumped somewhat the gun. I will amend the doc if it doesn't land in Fx 13 or is backed-out.
Comment 10•12 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/9658d5eee1e9
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Comment 11•12 years ago
|
||
Well, and not surprisingly https://hg.mozilla.org/mozilla-central/rev/dc07bfbf0a44
You need to log in
before you can comment on or make changes to this bug.
Description
•