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?).
Firefox has the same issue, but a (very small, very clean) patch has already been submitted, see https://bugzilla.mozilla.org/show_bug.cgi?id=729047.
The bug has been fixed in Firefox with a trivial fix. Any chance that the fix in WebKit is just as easy? This bug is causing a problem in Gmail.
From the Webkit Github Source - I can see that it is now implemented as below: https://github.com/WebKit/WebKit/blob/ed28c30276c6a9fa5e866e970ca70964f888672a/Source/WTF/wtf/unicode/CharacterNames.h#L117 Further, using test case from Comment 01, I am getting same output in Safari 15.5 on macOS 12.4 as other browsers (Chrome Canary 104 and Firefox Nightly 103), where the output is 123,456 (as expected). Thanks! It was fixed because of http://bugs.webkit.org/show_bug.cgi?id=58741 as per commit history - https://github.com/WebKit/WebKit/commit/bc52425620fdec309ed3a414cf87bc799dea7587 Since it is now implemented, can we mark this as "RESOLVED CONFIGURATION CHANGED" or "RESOLVED DUPLICATE OF 58741"? Thanks!
(In reply to Ahmad Saleem from comment #3) > From the Webkit Github Source - I can see that it is now implemented as > below: > > > https://github.com/WebKit/WebKit/blob/ > ed28c30276c6a9fa5e866e970ca70964f888672a/Source/WTF/wtf/unicode/ > CharacterNames.h#L117 > > Further, using test case from Comment 01, I am getting same output in Safari > 15.5 on macOS 12.4 as other browsers (Chrome Canary 104 and Firefox Nightly > 103), where the output is 123,456 (as expected). Thanks! > > It was fixed because of http://bugs.webkit.org/show_bug.cgi?id=58741 as per > commit history - > https://github.com/WebKit/WebKit/commit/ > bc52425620fdec309ed3a414cf87bc799dea7587 > > Since it is now implemented, can we mark this as "RESOLVED CONFIGURATION > CHANGED" or "RESOLVED DUPLICATE OF 58741"? Thanks! v.nice! Thanks!