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)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla13

People

(Reporter: aharon, Assigned: smontagu)

References

(Depends on 1 open bug)

Details

(Keywords: dev-doc-complete)

Attachments

(2 files)

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?).
Depends on: 178671
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.
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
Attached patch PatchSplinter Review
Assignee: nobody → smontagu
Attachment #599879 - Flags: review?(ehsan)
Attachment #599880 - Flags: review?(ehsan)
Thanks! I am no Mozilla reviewer, but the patch looks very clean to me.
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+
Attachment #599880 - Flags: review?(ehsan) → review+
Sorry I jumped somewhat the gun. I will amend the doc if it doesn't land in Fx 13 or is backed-out.
https://hg.mozilla.org/mozilla-central/rev/9658d5eee1e9
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: