Re: Shadows vs. layout

On Aug 3, 2009, at 12:23 PM, fantasai wrote:

> Brad Kemper wrote:
>> I recently discovered something while attempting to use box-shadow  
>> that I found frustrating, and I am not sure if it is a bug or  
>> something that CSS addresses or should address. I could not find  
>> anything in the spec that addresses the issue:
>> It is my understanding that box-shadow is not supposed to affect  
>> layout. However, when I have a shadow in an element that is  
>> positioned close to the right side of the page, and the shadow is  
>> offset to the right, it can actually cause the page to become  
>> wider, and create horizontal scroll bars. Positioning the element  
>> and the shadow to the left does not share the same problem. [1]  
>> Text-shadows DO show the same sort of behavior. [2]
>> This seems like the wrong behavior to me. Aside from the fact that  
>> an absolutely positioned item is also not supposed to affect  
>> layout, and does anyway, the purely visual effect of a shadow is  
>> such an ephemeral thing that it should never, ever, affect layout.  
>> I just can't imagine a situation where I would want the page to  
>> become wider because I added a shadow to it.
>> I found this problem while trying to recreate the rather largely  
>> blurred shadows of Mac OS X, and discovered that it limited how  
>> close to the right side I could get without having a scroll bar  
>> appear. There didn't seem to be any other way around it without  
>> changing the overflow properties of the container block to hidden  
>> and giving it a fixed width, which was not an option for me.
>> I didn't find anything in the spec about the meaning of "does not  
>> affect layout", but I think for the shadow properties at least it  
>> should elaborate that adding a shadow does not increase the size of  
>> its container in any circumstance.
>> [1] http://www.bradclicks.com/cssplay/shadow_vs_layout.html
>> [2] http://www.bradclicks.com/cssplay/text-shadow_vs_layout.html
>
> I completely agree. Added
>  "Shadows never affect layout, and do not trigger scrolling."
> to the spec, hopefully that's clear enough.

I strongly disagree with this change and think it warrants further  
discussion.

Shadows in WebKit are visual overflow.  If you put a box-shadow on an  
object near the bottom of a document, you'd expect to be able to  
scroll to see that shadow.  It shouldn't simply be cut off.  I see no  
reason why shadows would be special cased versus all of the other  
kinds of visual overflow that can occur on a page.

Shadows are clipped if they spill out of a box with overflow:hidden  
specified. They are obviously overflow.  Why should overflow:scroll/ 
auto deliberately ignore this overflow just when scrolling? That makes  
no sense to me, and is more memory-intensive to code.  You're saying  
the engine has to track shadows as visual overflow for the purposes of  
accurate container repainting, but then somehow track a completely  
second set of visual overflow numbers that exclude shadows just to  
ensure that you don't include shadow overflow when scrolling?  That's  
nuts.

dave
(hyatt@apple.com)

Received on Monday, 3 August 2009 18:45:41 UTC