- From: Brad Kemper <brad.kemper@gmail.com>
- Date: Wed, 5 Aug 2009 08:19:00 -0700
- To: W3C style mailing list <www-style@w3.org>
Here is another demonstration that shows it is a problem not just with the BODY element getting a scroll bar, but other elements as well: http://www.bradclicks.com/cssplay/shadow_vs_layout2.html Just hover over the red parts to see scroll bars appear. The lower one changes the layout drastically. By the way, this also shows a difference between box-shadow in Safari and Firefox. In Safari, the shadow is visible when you hover over the top box, but not in Firefox. I didn't investigate enough to know why. Maybe its a bug. On Aug 4, 2009, at 3:05 PM, Brad Kemper wrote: > > > > > On Aug 4, 2009, at 2:12 PM, "Tab Atkins Jr." <jackalmage@gmail.com> > wrote: > >> On Tue, Aug 4, 2009 at 4:07 PM, David Hyatt<hyatt@apple.com> wrote: >>> Here's another idea that just occurred to me. We could say that >>> shadows, >>> outlines, etc. can never cause a scrolling mechanism to appear, >>> but just >>> leave it at that. >>> >>> In other words you never let the shadows cause scrollbars to be >>> created (or >>> destroyed), but if scrollbars happen to already be there (because >>> of some >>> other overflow), then you can safely include the visual overflow >>> as part of >>> the scrolling area. >> >> To be honest, that's what I thought we were asking for. I'm pretty >> sure it's what I intended to ask for, at least. >> >> What's the difference between this and what you thought was being >> proposed before? > > > The difference is that it would still muck with the design by > widening and/or deepening the page beyond the where everything else > on the page is racked into. So if there was a scrollbar due to > content not fitting, the user wouldn't stop at the natural page > limits when they scrolled down and/or right. >>
Received on Wednesday, 5 August 2009 15:19:40 UTC