[Bug 16001] Clarify bidi aspects of <wbr>

https://www.w3.org/Bugs/Public/show_bug.cgi?id=16001

Glenn Adams <glenn@skynav.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |glenn@skynav.com

--- Comment #1 from Glenn Adams <glenn@skynav.com> 2012-02-16 16:53:42 UTC ---
(In reply to comment #0)

> If one looks closer at the spec, in the default style sheet section, one gets
> more information on <wbr>, though. The style sheet says:
> 
> wbr { content: '\200B'; }
> 
> U+200B, the ZERO WIDTH SPACE, is of bidi class BN, which effectively has no
> effect on the bidi ordering of the content around it. This is consistent with
> what IE does, but not with what Firefox and Chrome do. Strangely enough,
> however, while Firefiox and Chrome display <div dir=rtl>12&#x200B;34</div>
> correctly, as 1234, IE 9 displays it incorrectly, as 3412...
> 
> It would be best if the bidi effects of <wbr> were specified explicitly, up
> front, in the section on the wbr element. For example, it could state that
> <wbr> must have the same effect on the bidi ordering as U+200B, the ZERO WIDTH
> SPACE, i.e. no effect at all.

Better would be to specify that its bidi level be equal to the resolved bidi
level of its content. If its content is the default \200B, then it is the same
as ZWSP; but if its content is redefined to another character or character
sequence, then that content should apply.  For example, if the default style
sheet is overridden as:

wbr { content: '\200E'; }

then it would be treated as LRM, a non-neutral.

On the other hand, the current definition of wbr [1] says:

"Any content inside wbr elements must not be considered part of the surrounding
text."

So it is unclear what role the content property has in this regard.

[1] http://dev.w3.org/html5/spec/Overview.html#the-wbr-element

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Thursday, 16 February 2012 16:53:48 UTC