W3C home > Mailing lists > Public > www-style@w3.org > August 2009

Re: Shadows vs. layout

From: David Hyatt <hyatt@apple.com>
Date: Mon, 03 Aug 2009 13:44:59 -0500
Cc: Brad Kemper <brad.kemper@gmail.com>, W3C style mailing list <www-style@w3.org>
Message-id: <4EF68202-ACE5-4A28-85A7-566FF7C36CDF@apple.com>
To: fantasai <fantasai.lists@inkedblade.net>
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  

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  

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

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:38 UTC