Re: Shadows vs. layout

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 think it's correct behavior that you would be able to scroll to  
reveal an absolutely positioned element.   The only way an absolutely  
positioned element is considered part of your overflow is if you are  
in the containing block ancestor chain for that element, so it's  
logical that it would be considered part of your overflow that you  
could scroll to.   Absolutely positioned elements also contain non- 
trivial content like text and images that you should be able to  
interact with.

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

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.

dave
(hyatt@apple.com)