Re: proposed new module: css3 floats and positioning

On 21/05/2011 3:59 AM, Rossen Atanassov wrote:
>
>
>> -----Original Message-----
>> From: Alan Gresley [mailto:alan@css-class.com]
>> Sent: Thursday, May 19, 2011 5:37 PM
>> To: Alex Mogilevsky
>> Cc: W3C style mailing list; Chris Jones; Rossen Atanassov
>> Subject: Re: proposed new module: css3 floats and positioning
>>
>> On 19/05/2011 7:22 AM, Alex Mogilevsky wrote:
>>> We would like to propose a new CSS module: CSS Floats and Positioning
>>> Level3.
>>>
>>> http://www.interoperabilitybridges.com/css3-floats/
>>>
>>> The intent of the new module is to bring together into a consistent
>>> model new kinds of positioning and float behavior, including relevant
>>> parts of CSS Exclusions, GCPM Floats, Grid Positioning.
>> [snip]
>>> P.S. it may be more efficient to hold detailed review and feedback
>>> until/if this is published as an editor's draft. At this point
>>> feedback on ideas and directions is the most valuable.
>>
>>
>> Considering that the main part of the draft spec is regarding positioning schemes,
>> I would have hoped to have seen some mention of overflow. CSS3 Overflow is
>> very neglected at the moment.
>>
>> http://wiki.csswg.org/spec/css3-overflow
>>
>
> You are right about overflow not being mentioned in this spec. This is because we
> don't intend to change anything about it by introducing positioned floats or shapes.


I'm not asking you to change anything about the behavior of overflow. 
I'm asking that this spec fills in the missing parts about overflow 
behavior.


>> Regarding offset values with auto:
>>
>>     | Right - Like top, but specifies how far a box's
>>     | right margin edge is offset to the left of the
>>     | right edge of the box's containing block.
>>
>>     | Left - Like top, but specifies how far a box's
>>     | left margin edge is offset to the right of the
>>     | left edge of the box's containing block.
>>
>>
>> This is only true in LTR inline direction. The reverse happens in RTL inline
>> direction. I do not that the links for 'containing block' are pointing to CSS2.
>>
>
> Right, the verbatim is taken directly from CSS 2.1 section 9.3.2.
> http://www.w3.org/TR/CSS21/visuren.html#positioning-scheme
> Since we don't intend to change anything about the containing block model,
> all references about it point back to the CSS 2.1 spec.


Please see 11.1.

http://www.w3.org/TR/CSS21/visufx.html#overflow-clipping

   | Whenever overflow occurs, the 'overflow' property specifies
   | whether a box is clipped to its padding edge, and if so,
   | whether a scrolling mechanism is provided to access any
   | clipped out content.


Does the spec mention what side of the viewport it should overflow?


We only know from 9.10 that overflow is different in RTL.

http://www.w3.org/TR/CSS21/visuren.html#direction

   | In addition, it specifies such things as the direction of
   | table column layout, the direction of horizontal overflow,


2.2.1 Box offsets of this CSS3 spec should suggest that the below 
behavior in Opera is wrong.


http://css-class.com/test/bugs/opera/opera-rtl-offset-bug.htm


>> Regarding 'positioned' floats:
>>
>> How do the 'positioned' floats interact with a sibling later in the flow that has a
>> value that establishes a 'block formatting contexts'? I do see this.
>>
>>     | A positioned-float box may intersect with other
>>     | elements in the same or other block formatting
>>     | contexts. Note that this may cause elements to
>>     | overlap and they may not be floated around the
>>     | positioned-float box in all cases.
>>
>
> The shape of positioned floats is propagated to all elements regardless if they are
> BFC or not. Elements that want to opt out of that behavior can do so by having
> 'flow-wrap:none' specified.
>
>> What is the _same_ BFC? Is this the BFC that the 'positioned' float is within?
>>
>> What is the _other_ BFC? Sibling element? Cousin element? Child element?
>> Parent element?
>>
>
> This is verbatim taken directly from CSS 2.1 section 9.5.1.
> See http://www.w3.org/TR/CSS21/visuren.html#floats


CSS 2.1 section 9.5.1 does not explain why IE8, IE9 and IE10 should have 
this behavior.

http://css-class.com/test/bugs/ie/ie8-haslayout-bidi.htm


>> Can the draft spec work gracefully with Writing mode draft spec.
>>
>> http://dev.w3.org/csswg/css3-writing-modes/
>>
>
> There should really be no difference for dealing with positioned floats in respect to
> writing mode and regular absolutely positioned elements.


Really.

http://css-class.com/test/css/bidi/kanji-test1-extra.htm

http://css-class.com/test/css/bidi/mongolian-test1-extra.htm


I do suggest that you read my list message from last year and study the 
test cases linked from it.

http://lists.w3.org/Archives/Public/www-style/2010Mar/0544.html


I have said on numerous occasions that the web is broken for RTL authors 
and the RTL world and the reason is that CSS 2.1 is a spec for LTR and 
there no concept that certain overflow should always be  hidden 
depending on if it is LTR or RTL.

How long do such authors have to code in this manner?

http://www.ndaworld.org/



-- 
Alan Gresley
http://css-3d.org/
http://css-class.com/

Received on Saturday, 21 May 2011 10:51:47 UTC