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