fix inline bidirectional support for RTL

It seems to me you didn't switch your default language from English to an RTL language.

Pager does work for me - see http://dev.drupal.org.il - with two issues:
1. The order of numbers should be opposite - "... 3 2 1" and not "1 2 3 ...".
2. There should be a space between the string "לעמוד הבא" (which means 'next page') and the number to the right of it (currently "1", but it should be "3" for the reason mentioned in #1).

Amnon
_{-
Professional: Drupal Israel | Drupal Development & Consulting | Eco-Healing | Effective Hosting Strategies | בניית אתרים
Personal: Hitech Dolphin: Regain Simple Joy :)}

On a second check, Bakr is right! In Firefox, there is no space between the numbers whatsoever (#2 above was tested in IE).

I've tested - it happens in all RTL themes.

IE7 status and FF status screenshots attached

In FF, if you float the li to the right, you get the expected result.
I'll test it on IE and see what happens.

If you guys want this fixed. Review this patch: http://drupal.org/node/210479

It's due to "display:inline" being used for the list items but there's nothing in-between to separate the elements. In effect, it treats the list as one string with no breaking space to sort it rtl.

cross posted

Actually a duplicate. The other issue will fix it.

Verified - patching Drupal 6.0 RC2 with the other issue solved it.

Sorry, I didn't look deep enough. Although the other issue seems to solve the problem. display:inline for the list items has some other odd properties only apparent with RTL.

for example, this is what we expect in the first page.

« last ‹ next 8 7 6 5 4 3 2 1

But with that patch from the other issue, you get this instead. Close, but still not quite right.

      |—————|
« last next › 8 7 6 5 4 3 2 1

And page to 2 we'd expect this.

« last ‹ next 8 7 6 5 4 3 2 1 previous › first »

Instead we get this with the patch.

      v        |———————————————————————————————|
« last first » ‹ previous 1 2 3 4 5 6 7 8 next ›

Notice a pattern? Text that falls within the ends will not move into RTL flow. The last example is some odd quirk. The "v" is where it should be placed but it moves out of the flow. It still treats the text like it's in the middle preventing RTL changes.

The above is how it's rendered in Safari 3. The behavior in FF 2 is similar but not exact. The last example above is rendered like this in FF 2.

  |——————————————————————————————————————————|
« first ‹ previous 1 2 3 4 5 6 7 8 next › last »

That simply looks like a LTR flow but it's not. the "«" and "»" are swapped. Hard to detect but it is happening. They are respecting RTL but the text in between is behaving like the Examples before it.

What I'm trying to say is that it's not easy. Floats will work but that means the standard of commenting styles with /** LTR **/ won't be as effective since the two ways of flowing the elements will be completely different but it looks like we have little choice.

That's what we get for being cutting edge I guess. Browser consistently is far worse in RTL than the already difficult LTR. Anyone notice that you can't even scroll horizontally in RTL mode? sigh..

Ugh, well, RTL support is not that good among browsers unfortunately. (I don't have better input here yet, sorry).

Okay, did a little more research and found a good fix. :)

According to the specs, in-line elements do not inherit the dir attribute. It only applies to block level elements.

http://www.w3.org/TR/REC-html40/struct/dirlang.html#h-8.2.2

Inline elements, on the other hand, do not inherit the dir attribute. This means that an inline element without a dir attribute does not open an additional level of embedding with respect to the bidirectional algorithm. (Here, an element is considered to be block-level or inline based on its default presentation. Note that the INS and DEL elements can be block-level or inline depending on their context.)

But according the the xhtml spec: http://www.w3.org/TR/2002/WD-xhtml2-20020805/mod-bidi.html#sec_11.1.2.

When a block element that does not have a dir attribute is transformed to the style of an inline element by a style sheet, the resulting presentation should be equivalent, in terms of bidirectional formatting, to the formatting obtained by explicitly adding a dir attribute (assigned the inherited value) to the transformed element.

This is what we are doing right here I think.. li is block level, right? And we are forcing it inline but it's not following those rules if I'm reading it correctly. Another layer to this could be how browsers are really reading the page. DTD for xhtml I believe is read as plain html. Well anyway...

The solution was to add a property of "unicode-bidi:embed". This forces inline elements to inherit the direction. Listed in a Microsoft site of all places. I couldn't find it on W3C but it seems to work in Safar and FF.

http://www.microsoft.com/globaldev/handson/dev/Mideast.mspx#EKE

I applied it to all elements for system-ltr.css. This may be too much. If needed, we can apply it to specific inline elements as needed. I'll leave it up to you guys with true RTL languages to judge. I'm faking it with english on my install.

Changing title. This goes beyond pagers.

btw, the other patch to add new lines for list items helped. Without it, we'd still be scratching our heads.

Forgot the ending semi-colon.

subscribe

@dvessel: Not tested this yet, but only as an reminder... don't forget browsers are turning lists or link lists if they render a RTL string... i wasn't aware about this, too. So it could be difficult if you are not importing Hebrew or Arabic strings... however you understand them or not - i'm with you - I don't understand them, too.

This works against HEAD. I'm marking this RTBC.

hrmm, the list item patch fixed it. Using not using a true RTL language was the problem.

Useful info. Relevant beyond drupal.