[Bug 10808] text with unknown direction gets corrupted when inserted in content with opposite direction

http://www.w3.org/Bugs/Public/show_bug.cgi?id=10808

--- Comment #34 from fantasai <fantasai.bugs@inkedblade.net> 2010-11-04 14:33:27 UTC ---
(In reply to comment #26)
> Is CSS is going to be changed so that...with dir=rtl, =ltr, and =auto setting
> some logical flag in the markup? If so, I can spec the HTML side of that.

Yes. The intention is that the direction of the element is resolved to either
LTR or RTL by the HTML. This resolved per-element direction can then be
selected by :ltr or :rtl, and would also (or thereby, as you point out) set the
CSS 'direction' property as appropriate.

(In reply to comment #27)
> If this isn't already captured in Writing Modes or Text

The Writing Modes spec does not define anything about how the element's auto
direction resolution is accomplished. It does define a 'plaintext' value for
'unicode-bidi', but this does not affect the element's direction resolution: it
only affects the base direction resolution of the CSS bidi paragraph. This
value was designed for use in <textarea> and <pre> elements, where paragraph
breaks are not indicated in markup.

(In reply to comment #28)
> Is there a spec anywhere I can reference to easily define how to determine
> whether an element's logical direction is ltr or rtl?

Once you define which bits of text content you want to analyze, use rules P2
and P3 of UAX9: http://www.unicode.org/reports/tr9/#The_Paragraph_Level
As mentioned by Maciej, you'll want to skip the contents of <script> and
<style> elements.

(If you want, I can provide more details on how to spec this feature out.)

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
You reported the bug.

Received on Thursday, 4 November 2010 14:33:29 UTC