Re: Proposal for overflow painting order

On Feb 7, 2009, at 4:58 AM, Anton Prowse wrote:

>
> David Hyatt wrote:
>> I'd like to propose a change to the painting order of overflow  
>> objects.
>> In this example:
>> <div style="width:100px;height:100px;background-color:red;margin- 
>> bottom:-100px">This text paints on top of the overflow block.</div>
>> <div style="width:100px;height:100px;overflow:hidden;background- 
>> color:green;"></div> The overflow block is allowed to interleave  
>> with the previous block.  Although its background is on top of the  
>> previous block, the previous block's text paints on top of the  
>> overflow block's background.  This is correct according to the  
>> current painting order rules, which do not special case overflow.   
>> However, this leads to strange renderings, especially when  
>> scrolling mechanisms are present.
>
> The renderings do not seem strange to me in the case where  
> scrollbars are not present; they are the same as if the block were  
> not an overflow block, and without the scrollbars I see no reason  
> why an overflow block should have visually different behaviour in  
> this situation.
>

overflow:hidden is commonly coupled with custom scrollbars though, and  
it can have scrollLeft/Top set on it to scroll the overflowing content.

> When scrollbars are present, it would appear from very brief testing  
> on
> Firefox 3.1b2 that they are drawn by the overflow block's containing
> stacking context in between the painting layer for in-flow inlines and
> the painting layer for positioned 'z-index:auto's.  This does look a  
> bit
> strange because the scrollbars overlay and thus interrupt the inlines.
> WebKit appears to treat the the overflow block as a (pseudo-?)stacking
> context (like floats and relpos 'z-index:auto's?), which does look  
> nicer
> in the case of scrollbars.
>
>> I'd prefer to see overflow special-cased such that it does not  
>> interleave with other normal flow content by default.  I don't  
>> think there is any real benefit to be gained by allowing such  
>> interleaving. It is also more difficult to encapsulate the painting  
>> of the overflow (e.g., if you wanted to optimize it for accelerated  
>> compositing) if the overflow block has to break up its painting  
>> because of surrounding normal flow content.
>
> Whilst I appreciate that implementors have performance concerns, I see
> no real benefit to be gained for authors by forbidding such  
> interleaving
> either, since they can prevent interleaving if they wish by  
> relpos'ing the overflow block.
>
> So from a presentation perspective I am largely indifferent to which  
> is
> used (but I lean away from the proposal because when the default  
> rendering is judged to be undesirable it can currently be "turned  
> off", whereas I think this is not true of the proposed change),  
> whilst from an author perspective I would be reluctant to add a  
> significant extra special case what is already a complex stacking  
> mechanism -- and one which has pretty good cross-browser consensus.

I think this is a minor issue also.  I simply think it is strange  
behavior that interleaving of normal flow content is allowed on a  
block with scrollbars.  Our violation of the spec has never been a  
major compatibility issue in WebKit, so this can just be one of those  
edge cases we fail for the sake of code simplicity and performance.

dave
(hyatt@apple.com)

Received on Saturday, 7 February 2009 22:15:06 UTC