Re: Shadows vs. layout

On Mon, Aug 3, 2009 at 3:05 PM, David Hyatt<hyatt@apple.com> wrote:
> 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).

Agreed that the vertical overflow case is different in practice.
People are used to vertical overflow; it's normal and accepted.
Horizontal overflow, however, is rare and horrifying when it occurs
accidentally.

>  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.

Sorry.  ;_;  I'm still going to ask you to bear it, though.

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

Yup.

> 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.

text-shadow can cause the problem too.

> 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.

As we acquire more properties that produce no-geometry visual effects
(shadows, stroking, border-image, etc.) and these become more common,
this is going to become a problem.  I don't want these properties to
go unused because designers fear horizontal scrollbars appearing
unpredictably.

I also, though, don't want to be severely restricted in how I can use
abspos elements because I'm defensively slapping overflow-x:hidden on
everything.

We *do* need specific language to this effect so we can handle
no-geometry visual effects better in the future.

> 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.

I agree with you in the vertical case (more generally, in the
block-direction case).  I just never want text-direction overflow from
effects like these.

~TJ

Received on Monday, 3 August 2009 20:16:54 UTC