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

Re: Shadows vs. layout

From: Andrew Fedoniouk <news@terrainformatica.com>
Date: Mon, 03 Aug 2009 13:56:20 -0700
Message-ID: <4A774EF4.7030206@terrainformatica.com>
To: David Hyatt <hyatt@apple.com>
CC: fantasai <fantasai.lists@inkedblade.net>, Brad Kemper <brad.kemper@gmail.com>, W3C style mailing list <www-style@w3.org>
David Hyatt wrote:
> On Aug 3, 2009, at 3:17 PM, Andrew Fedoniouk wrote:
>> David Hyatt wrote:
>>> On Aug 3, 2009, at 12:23 PM, fantasai wrote:
>>>> 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)
>> Shadows and other types of outlines do not affect neither box
>> dimensions nor dimensions of its container nor dimensions of
>> scrollable content. By definition. (space/time and so on).
> Overflow obviously doesn't alter border box dimensions either.  It's 
> merely about scrollable content.  Obviously I am not suggesting that the 
> shadow influences the size of the object it's specified on.
>> E.g. window shadow is not causing scroll of desktop window not on Mac
>> not on Windows and not on any other GUI system I know about.
> I think this is not a good example to bring up, since windows don't 
> occur inside other content.  A better example would be iChat balloons or 
> Aqua controls with shadows (which is most of them).  If these control 
> shadows were cut off at the bottom of a page, the controls would look 
> pretty weird.

I did once WM that was using realistic shadows of windows - shadow depth
depends on z-stack order and so could be of pretty complex shape if it 
would cast on other windows. Try to imagine such system inside 
scrollable container and how it will behave if you will bring some 
window to front - window may move out from the cursor if it happens
to be at the bottom. And yet imagine that you will move such window to 
the back. I do not think all this scrolling effects are quite usable. As 
I said neither outline nor shadow should cause change of measured 
content dimensions of any scrollable. Think about dynamic effects at 
least like animated glow or so.

Andrew Fedoniouk.

Received on Monday, 3 August 2009 20:56:51 UTC

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