Re: Shadows vs. layout

Sent from my iPhone

On Aug 4, 2009, at 11:27 AM, David Hyatt <hyatt@apple.com> wrote:

> On Aug 3, 2009, at 10:25 PM, Brad Kemper wrote:
>
>>
>> On Aug 3, 2009, at 4:08 PM, David Hyatt wrote:
>>
>>> On Aug 3, 2009, at 5:58 PM, Brad Kemper wrote:
>>>
>>>>
>>>>
>>>> On Aug 3, 2009, at 1:45 PM, fantasai  
>>>> <fantasai.lists@inkedblade.net> wrote:
>>>>
>>>>> Brad Kemper wrote:
>>>>>> Sent from my iPhone
>>>>>> On Aug 3, 2009, at 1:08 PM, fantasai <fantasai.lists@inkedblade.net 
>>>>>> > wrote:
>>>>>>> I'm not sure about border-image outside the border area,  
>>>>>>> whether that should
>>>>>>> trigger scrolling or not. I'm leaning towards leaving the  
>>>>>>> standard behavior.
>>>>>>> But shadows definitely should not trigger scrolling.
>>>>>> I don't have the link handy, but in that write-up I did a while  
>>>>>> back explaining how the border-images should not take up space,  
>>>>>> I think many of the use cases and examples I gave would not  
>>>>>> work well at all if they pushed container dimensions to the  
>>>>>> right and bottom. A central idea was that page geometry would  
>>>>>> be the same with or without the border-image.
>>>>>
>>>>> Well, yes, the outset shouldn't affect layout. But whether it  
>>>>> should
>>>>> trigger overflow is another issue.
>>>>
>>>> Overflow does affect layout, doesn't it? If my image bordered  
>>>> element is inside another element that is floated, then the width  
>>>> of the floated element changes based on whether or not the  
>>>> overflow from the border-image is widening it or not. That then  
>>>> affects what other elements can sidle up alongside it.
>>>>
>>>> Also, suppose my BODY element has 16px of padding and no margin  
>>>> or border. Now I put a 32px wide border-image around it with a  
>>>> 32px offset. In that case, I would expect the border-image to be  
>>>> clipped on all four sides (or at least three). If it was clipped  
>>>> on the left and top but scrollable to the right and bottom, that  
>>>> would just be weird.
>>>
>>> That oddity already exists with all scrollable overflow.  Make an  
>>> absolute positioned element with a negative top/left and a right/  
>>> bottom that goes out past the bottom right edge of the container.   
>>> You'll see that you can't scroll to reveal the top/left corner of  
>>> the object but will be able to reveal the right/bottom.
>>>
>>> I would not get too hung up on this, as it has more to do with  
>>> user agents not having a decent model for scrolling to reveal the  
>>> top/left area without putting the scrollbar at a bizarre position  
>>> to start.  I don't think it's particularly relevant to the  
>>> discussion, since this bizarre behavior is just part of all  
>>> scrollable overflow.
>>
>> The intended relevance was that even though the ship has sailed for  
>> the idea of changing how positioned elements can expand the  
>> scrollable page size (as people are using that already for layout  
>> and changing it now would be disastrous), it would be best to  
>> reduce the amount of bizarre oddities and unexpected, difficult to  
>> explain seeming inconsistencies. I understand why technically you  
>> don't really consider it all that inconsistent, but it is hardly  
>> obvious to authors. If a page/pane beneath the viewport is a  
>> certain size and then I add a purely visual effect that is not  
>> supposed to affect layout, then I really don't expect that pane to  
>> grow larger. That includes what happens with abs pos elements, but  
>> I realize we can't change those now, so I am just hoping for a  
>> better situation re: other non-layout effects not changing layout  
>> (including parent widths).
>>
>
>
> You keep bringing absolutely positioned elements up, and I don't see  
> how they are relevant to this discussion at all.

I am not bringing it up repeatedly, I was responding to your message  
in which you brought it up as an already existing "oddity" and  
"bizarre" but explainable behavior. I responded by saying I agree it  
is odd and bizarre and non-intuitive for authors, and that we should  
not have similar bizarre oddities for shadows, etc. as we do now in  
current implementations. That is how I see it as relevant, which I was  
explaining in answer to your statement that "I don't think it's  
particularly relevant to the discussion, since this bizarre behavior  
is just part of all scrollable overflow." if it is all part of the  
same shared behavior, then of course it is relevant to the  
conversation about why this behavior is unwanted for scrollable  
overflow created by decorative effects that (like positioned elements)  
are in theory not supposed to influence the rest of the layout.

> I think it's correct behavior that you would be able to scroll to  
> reveal an absolutely positioned element.   [...]

OK. I have a different point of view, but as I mentioned before, I am  
not advocating that this be changed.

> The argument for what to do with shadows should be based on how we  
> think shadows should work, not on what we do with other types of  
> overflow.

I agree (as long as you are including other decorative non-layout- 
affecting decorative properties like outline, border-image, etc. with  
shadows). Current implemetions seem to be following the same overflow- 
affecting-layout philosophy for shadows as for positioned items, so I  
mention positioned items to say that I think shadows should not follow  
that same philosophy.

> To me it is illogical not to show scrollbars for shadows, since I  
> think all overflow should be consistently reachable via the  
> scrolling mechanism (bizarre top/left inaccessibility issues being  
> irrelevant, since they apply to all overflow).

That is where we disagree. Your reason for showing scrollbars for  
positioned items (and other types of overflow-inducing items) was that  
they can have vital content that may need to be reachable and  
accessible. That is simply not the case with decorative visual effects  
like shadows.

And while you consider the top/left behavior to be a bizarre remnant  
of something else, it's final effect on the page (of not noticably  
changing any geometries and not being something that creates  
scrollbars by itself) is exactly what we would like the result of  
shadow to be for all four sides.

You want all overflow to be consistently reachable. I do not. I want  
purely decorative overflow such as shadows (which are not sipposed to  
influence layout) to have the same lack of influencing the geometry as  
they do on the top and left, even if that top left behavior is  
currently the unintended side effect of something else.

> I seem to be the only one who feels this way, though, which is why I  
> am asking that this new overflow behavior at least be specified in  
> the overflow property definition rather than as a weak sentence in  
> the shadow section of the backgrounds/borders module.  As Robert  
> said, if we really are adding an entirely new kind of overflow,  
> e.g., "ink overflow", we need to specify it formally and explain how  
> it works.

I agre 100%.


>
> dave
> (hyatt@apple.com)
>
>