Overflow and bidi was (Re: [CSSWG] Minutes and Resolutions 2010-03-24)

fantasai wrote:
[snip]
> Float bidi issue
> ----------------
> 
>   <glazou> http://lists.w3.org/Archives/Public/www-style/2009Dec/0088.html
>   glazou: Defer to ftf, then.
>   glazou: Float bidi issues, then.
>   TabAtkins: As far as I can tell, the first link is asking whether, when
>              we float:start or end, the scrolling/overflow behavior of the
>              containing box should change.
>   dbaron: Frex, if you're in ltr and you ahve an auto left margin, it
>           right-aligns the block if it's narrower than the container,
>           but left-aligns if it's wider so you don't have content
>           that's unscrollable.
>   <dbaron> ... and the question, I think, is whether we want to do the
>            same thing for floats.
>   dbaron: So the question is if we want to do the same thing for floats.
>   dbaron: Last time we tested, I think some impls did this.
>   fantasai: I think start and end should compute to a used value of left
>             or right, and then should just act normally.
>   TabAtkins: I agree.  That means there's no issue?
>   glazou: So, fantasai, there's nothing to do?
>   fantasai: Nothing special to do for start/end.
>   fantasai: dbaron's talking about a different issue, not actually related
>             to start and end.
>   TabAtkins: Yeah, the first email is indeed talking about something
>              independent of float:start/end.
>   glazou: Do we need to bring this up during ftf?
>   dbaron: I think someone needs to write some tests and figure out what
>           implementations do.  I may have done it in the past.
>   glazou: Let's defer this to a later time, then.
> 
>   Filed as http://wiki.csswg.org/spec/css2.1#issue-165

> Writing mode and directional properties
> ---------------------------------------
[snip]
>   glazou: David, how does mozilla implement margin/paddings in an rtl 
> context?
>   <dbaron> http://lists.w3.org/Archives/Public/www-style/2009Dec/0269.html
[snip]


In rtl context, the issue is not with float and bidi or absolute (or 
fixed) positioning and bidi. This is rather about the _direction_ of 
overflow and bidi.

FF, IE8 (and sometimes WebKit and Opera) treats floats and absolute 
(or fixed) positioning in the reverse in rtl with overflow and how 
positioned elements are offset in respect to the initial containing 
block. Elements are shown in the overflow (scrollable too) or are hidden.

If implementations didn't do this, then a menu construction like this,

<http://css-class.com/test/css/bidi/dropdown-menu-ltr.htm>

will not show correct in a rtl case.

<http://css-class.com/test/css/bidi/dropdown-menu-rtl.htm>


In the rtl test, both Safari and Opera show the ap. elements (they are 
not hidden) which can be scrolled too.


Here is a series of test cases involving float and bidi.

<http://css-class.com/test/css/bidi/visible-overflow-containing-block-ltr.htm>


Here is a series of test cases involving absolute positioning and bidi.

<http://css-class.com/test/css/bidi/visible-overflow-containing-block-ltr-ap-left.htm>


In this test case (second test in float series).

<http://css-class.com/test/css/bidi/hidden-overflow-containing-block-ltr.htm>


We see that Opera, Safari and IE7 is breaking the spec [1] 9.5.1.

# The left outer edge of a left-floating box may not be to the
# left of the left edge of its containing block. An analogous
# rule holds for right-floating elements.

For rtl this would read.

# The right outer edge of a right-floating box may not be to the
# right of the right edge of its containing block.


Opera, Safari and IE7 shows that right outer edge of a right-floating 
box is to the right of the right edge of its containing block.


1. <http://www.w3.org/TR/CSS21/visuren.html#float-position>


-- 
Alan http://css-class.com/

Armies Cannot Stop An Idea Whose Time Has Come. - Victor Hugo

Received on Wednesday, 31 March 2010 12:02:55 UTC