Re: Shadows vs. layout

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


> In fact Web sites even deliberately hide elements offscreen using  
> large negative left/top values, so we couldn't scroll to reveal this  
> stuff at this point even if we wanted to. :)

I could be wrong, but I thought we used to be able to do that on the  
right also a few years ago, and then that got "fixed".