Re: Shadows vs. layout

On Aug 3, 2009, at 4:17 PM, Brad Kemper wrote:

>
>
> Sent from my iPhone
>
> On Aug 3, 2009, at 1:05 PM, David Hyatt <hyatt@apple.com> wrote:
>
>> If you consider the vertical overflow case, it really doesn't make  
>> sense to cut off the shadows (and in fact it could look visually  
>> ugly to do so).  There's no reason to.  I understand the desire to  
>> avoid horizontal scrollbars, but I don't think the vertical case  
>> should be compromised just to accommodate the horizontal case,
>
> I diagree with this too. I've had designs before in which a precise  
> amount of padding separated solid-colored elements from the edges  
> with a consistent width band of white. Now you are suggesting that  
> the white page background should extend below that if there is  
> something with a shadow position near that edge, and that is just  
> the wrong thing to do.
>
>> and I hate the idea of the engine having to track two completely  
>> separate overflow concepts.  This is a really nasty implementation  
>> burden to have to bear.
>>
>> You're basically asking WebKit to take its unified concept of  
>> overflow and break it up into two separate types of overflow.
>
> I can't immediately see why treating the right and bottom edges the  
> same as the top and right (with respect to overflowing visual  
> effects that ate not supposed to affect layout) is burdonsome.

I assume you meant top and left.

top and left overflow are still computed (they're relevant when  
overflow is visible obviously).  You just don't see scrollbars in  
those cases because it would be strange to have 0,0 be at a position  
that might result in scrollbars not being flush left and flush top.   
It is basically an implementation decision on the part of user agents  
not to make top/left overflow accessible at all (in LTR).  This  
applies to all overflow (and not just the overflow you want to special  
case like shadows and border images).  It has nothing to do with the  
problem of not including shadows in scrollable overflow information,  
so I am not sure why you're bringing it up.

Having two types of overflow means that when it comes time to  
calculate scroll dimensions, you have to omit the shadow information.   
This means that overflow information that is propagated to containers  
now has to come in two flavors...  the overflow information *has* to  
be cached for efficient dirty rect intersection testing on repaints,  
so you're left with the choice of either caching two sets of  
propagated numbers or just not using the cached numbers when computing  
scroll information.   The first solution will impact memory.  The  
second solution will impact performance.  Neither solution makes me  
very happy as an implementor.

dave
(hyatt@apple.com)

Received on Monday, 3 August 2009 22:19:59 UTC