Accesskey n skips to in-page navigation. Skip to the content start.

Go to W3C Home PageGo to Architecture Domain home page  Internationalization 
 

Notes: bidi-override scope in CSS2

This is a working document, containing notes summarizing email and other discussions. It is never a finalized document. The text is subject to constant change, and is not guarranteed to be complete or up-to-date. It should not be cited for authoritative reference.

Background

These notes relate to the handling of right-to-left and left-to-right overrides in CSS and to some extent in HTML and xHTML. They draw on information in the following mail threads:

Suppose we have the following code in an XML application such as XHTML2, embedded in content with a base direction of ltr:

<div dir="rlo">Some inline text 
and more inline text on another line 
<p>A paragraph of text</p>
Some more <em>inline</em> text
</div>

and the following CSS style in the same document:

*[dir="lro"] { unicode-bidi: bidi-override; direction: ltr}
*[dir="rlo"] { unicode-bidi: bidi-override; direction: rtl}

Embedded block elements should not reject the override

With CSS2.1 the result of the markup above would be:

enil rehtona no txet enilne erom dna txet enilni emoS
A paragraph of text
txet enilni erom emoS

My assumption as a user would be that if I apply the override CSS properties to a block level element, all of the contents of that block element would be ordered as indicated by the override setting, not just the inline text (despite the fact that <bdo> was an inline element in HTML.).

The CSS specification and current implementations in user agents such as Firefox and IE should be changed to reflect such behaviour.

From the email:

Martin Dürst: Given the spec text that Richard has copied in his email, what Bert says below seems to be correct, but I have tried to make some sense of it, and can't. What's the reason for having bidi-override apply to the direct inline descendents of an element only? It doesn't seem to make sense from an user point of view, and it doesn't seem to make sense from an implementer's point of view, and I can't immagine that we designed it that way when we designed it (which was 9 or 10 years ago.

Steven Pemberton: I agree that this would be my expectation. (I have never understood why the override stops with nested blocks, and assumed it was because someone like Richard Ishida had said it must :-) )

Mati Alouche: I agree.

rlo text should not be automatically right-aligned

Given the CSS and markup above, the div when displayed would currently be right aligned. This is due to the presence of the direction property, the value of which affects the initial setting of text-align.

I think that the alignment of the text should be independent of the application of an override.

For example, if I have some English text that is discussing the order of characters in memory, and I add an example in a blockquote, I would not expect the example text to be right-aligned. In the absence of an inherited text-align property, the following markup:

<p>The text is stored in logical order, so 
the order of characters in memory would be:</p>
<blockquote>פעילות הבינאום, W3C</blockquote>

would result in the blockquote content being displayed right-aligned:

The text is stored in logical order, so the order of characters in memory would be:

פעילות הבינאום, W3C

To make the blockquote left-aligned, I would currently have to add the CSS text-align: left to the blockquote, or an enclosing element.

This perhaps means that, rather than unicode-bidi: bidi-override, we should have unicode-bidi: rlo/lro. The user could then apply the direction property if they wanted to change the default alignment. This seems to be a more constent use of the direction property, which is currently fulfilling two roles when used with unicode-bidi:override: a. setting the base direction of the block, b. indicating the desired direction of the override.

This approach would also provide consistency with the expectations of HTML users, who use the <bdo> inline element for directional overrides. The code:

<p>The text is stored in logical order, so 
the order of characters in memory would be:</p>
<blockquote><bdo dir="ltr">פעילות הבינאום, W3C</bdo></blockquote>

would produce a blockquote with text that is left-aligned.

CSS2 and CSS 2.1 behaviour is different

Whereas the CSS2 spec says "If the element is inline-level or a block-level element that contains only inline-level elements, this creates an override.", the CSS2.1 spec says "For block-level, table-cell, table-caption, or inline-block elements this creates an override for inline-level descendents not within another block-level, table-cell, table-caption, or inline-block element."

This means that with CSS2 the result for the code at the top of the page would be:

Some inline text and more inline text on another line 
A paragraph of text
Some more inline text

whereas with CSS 2.1 the result would be:

enil rehtona no txet enilne erom dna txet enilni emoS
A paragraph of text
txet enilni erom emoS

Bert Bos: Forget about the old CSS2 Rec. It is progressively being obsoleted first by the revised edition ("CSS 2.1") and then by the various CSS3 modules as they arrive. (Unfortunately, CSS 2.1 is still a WD, but in practice it has much fewer bugs than the old Rec.)

Contradiction in CSS explanation wrt bidi control codes?

Both CSS2 and CSS2.1 say "The final order of characters in each block-level element is the same as if the bidi control codes had been added as described above, markup had been stripped, and the resulting character sequence had been passed to an implementation of the Unicode bidirectional algorithm for plain text that produced the same line-breaks as the styled text."

I'm not entirely sure what the expected output of that would be, but I don't think it would be the same as any of the above results. So I think the CSS spec may contradict itself here.

Steven Pemberton: And I'm not sure there is enough wording to support how nested blocks in override work.

Matti Alouche: I think the output would be:

txet enilni emoS
enil rehtona no txet enilne erom dna
txet fo hpargarap A
txet enilni erom emoS

Tests

PS: I put together a short test page that takes the code above and does three things:

  1. applies unicode-bidi: bidi-override; direction: rtl; using a class attribute to the div
  2. remove the class attribute and add &#x202E; (RLO) immediately after the opening tag and PDF immediately before the closing tag
  3. same as [b] but with all markup inside the div removed

The results are as follows:

  1. IE6, Firefox and Opera behave as per CSS2.1 - ie. inline text is reordered, but text in the block is not.
  2. Firefox and Opera do the same as in [a], but IE (including IE6 and IE7 CR1) do not reorder the line of inline text after the paragraph
  3. IE, Firefox and Opera reorder all the text and display without line breaks

Author: Richard Ishida, W3C.

Valid XHTML 1.0!
Valid CSS!
Encoded in UTF-8!

Content first published 2006-10-31. Last substantive update 2006-10-31 GMT. This version 2006-10-31 17:12 GMT

Page location: http://www.w3.org/International/notes/notes-rlo-blocks-css.en.php

For the history of document changes, search for notes-rlo-blocks-css in the i18n blog.