- From: Andrew Fedoniouk <news@terrainformatica.com>
- Date: Mon, 03 Aug 2009 13:17:54 -0700
- 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 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. -- Andrew Fedoniouk. http://terrainformatica.com
Received on Monday, 3 August 2009 20:18:28 UTC