<wbr> should have the same bidi effects as a U+200B, the zero width space

RESOLVED FIXED in mozilla13



Layout: Text
6 years ago
5 years ago


(Reporter: Aharon (Vladimir) Lanin, Assigned: smontagu)


(Depends on: 1 bug, Blocks: 1 bug, {dev-doc-complete})

Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)



(2 attachments)



6 years ago
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 &#x200B; 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?).


6 years ago
Depends on: 178671

Comment 1

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

Comment 2

6 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

Comment 3

6 years ago
Created attachment 599879 [details] [diff] [review]
Assignee: nobody → smontagu
Attachment #599879 - Flags: review?(ehsan)

Comment 4

6 years ago
Created attachment 599880 [details] [diff] [review]
Aharon's test as reftest
Attachment #599880 - Flags: review?(ehsan)

Comment 5

6 years ago
Thanks! I am no Mozilla reviewer, but the patch looks very clean to me.
Comment on attachment 599879 [details] [diff] [review]

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+
Attachment #599880 - Flags: review?(ehsan) → review+

Comment 7

6 years ago
Flags: in-testsuite+
Hardware: x86_64 → All
Target Milestone: --- → mozilla13
I've explained the bidi behavior in https://developer.mozilla.org/en/HTML/Element/wbr
and added a note for the fix in:
Keywords: dev-doc-complete
Sorry I jumped somewhat the gun. I will amend the doc if it doesn't land in Fx 13 or is backed-out.
Last Resolved: 6 years ago
Resolution: --- → FIXED
Well, and not surprisingly https://hg.mozilla.org/mozilla-central/rev/dc07bfbf0a44
Blocks: 735850
You need to log in before you can comment on or make changes to this bug.