Re: Proposal for overflow painting order

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.

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.

Cheers,
Anton Prowse
http://dev.moonhenge.net

Received on Saturday, 7 February 2009 10:59:28 UTC