Re: Shadows vs. layout

On Aug 3, 2009, at 2:26 PM, Tab Atkins Jr. wrote:

> On Mon, Aug 3, 2009 at 1:55 PM, David Hyatt<hyatt@apple.com> wrote:
>> Or put another way, imagine an Aqua button with shadows on it near  
>> the
>> bottom of a page.  Or imagine an iChat balloon done using border  
>> images
>> (with overflow using that syntax, a similar concept to shadows).   
>> Scrolling
>> to the bottom should not "cut off" the shadow portion of those  
>> objects.
>
> If done correctly, the important part of the iChat balloon will be
> included within bounding box, using (suppressed) borders to push the
> text around correctly.  Otherwise it will overflow right onto other
> elements, which is not desirable.
>
> I'm fine with a shadow being 'cut off' by being overflow.  It is, in
> fact, what I *want* in virtually all cases.  Frex, several sites I've
> designed have been fixed-width with shadows on either side of the
> content-column.  Unless I can do some hacks with backgrounds on the
> body (not always possible), I have to shrink the content area so that
> it's guaranteed to fit within 800px width without the shadows
> overflowing.  I'd much prefer the shadows (done in CSS, rather than my
> current method of doing them in images) don't interact with the box
> size at all.

If you consider the vertical overflow case, it really doesn't make  
sense to cut off the shadows (and in fact it could look visually ugly  
to do so).  There's no reason to.  I understand the desire to avoid  
horizontal scrollbars, but I don't think the vertical case should be  
compromised just to accommodate the horizontal case, and I hate the  
idea of the engine having to track two completely separate overflow  
concepts.  This is a really nasty implementation burden to have to bear.

You're basically asking WebKit to take its unified concept of overflow  
and break it up into two separate types of overflow.

I also don't think it's as simple as just throwing a sentence into the  
shadows section.  Two other examples (glyphs and border images) have  
been brought up as well.  WebKit also has its own custom text stroking  
CSS properties, which are somewhat similar to the glyph problem.

We're talking about really changing the definition of what overflow is  
here and breaking it up into two categories.  If this is really how  
people want to proceed, I think we'd need better defined language in  
the actual overflow section of the CSS spec to explain how the two  
types of overflow work.

Especially in the vertical case, though, the idea of not being able to  
scroll to shadows or border images or glyphs that spill out really  
doesn't feel right to me.

dave
(hyatt@apple.com)

Received on Monday, 3 August 2009 20:05:47 UTC