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 14:22:48 -0700
Message-ID: <4A775528.5080001@terrainformatica.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
CC: David Hyatt <hyatt@apple.com>, fantasai <fantasai.lists@inkedblade.net>, Brad Kemper <brad.kemper@gmail.com>, W3C style mailing list <www-style@w3.org>
Tab Atkins Jr. wrote:
> On Mon, Aug 3, 2009 at 3:17 PM, Andrew
> Fedoniouk<news@terrainformatica.com> 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).
>> 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.
> To be fair, on the GUI systems you know about, the elements are
> purposely placed so that the shadow doesn't try to 'spill out' of the
> container.  So the question of overflow behavior doesn't come up.

Window rectangle does not include shadow/outline.

At least on Windows it is a bit challenging to get outline rectangle
of the window that includes shadow. So pardon me but I am not buying
"purposely placed so that the...". Haven't seen such purposeful attempts.

The only case when the shadow is just such a background - is a part of 
window (read: DOM element) background itself as here
for example.

> In the web environment the issue is a bit different - it's easy to
> make elements with shadows/outlines/border-images that have parts of
> the visual effect spilling out.

Yes. As in any other GUI system including various WMs.

Andrew Fedoniouk.

Received on Monday, 3 August 2009 21:23:18 UTC

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