Viewport scrolling to reach overflow from root element [Was: Re: Shadows vs. layout]

Brad Kemper wrote:
> 
> On Aug 3, 2009, at 4:08 PM, David Hyatt wrote:
> 
>> 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).

This behaviour has always intrigued me, but I've never been able to find 
anything in the CSS21 spec which covers it.  There's the mysterious:

"Even if 'overflow' is set to 'visible', content may be clipped to a
UA's document window by the native operating environment."[1]

but in this particular case, overflow on the root element is set to 
'auto' not 'visible', at least in the default stylesheets of most 
desktop graphical browsers.

Is this behaviour in violation of the spec?  Note that it doesn't just 
apply to positioned elements; all overflow is clipped left/top including 
that resulting from placing negative left/top margins on in-flow content 
etc.

[1] http://www.w3.org/TR/CSS2/visufx.html#overflow


Regarding accessibility:

Robert O'Callahan wrote:
> On Tue, Aug 4, 2009 at 3:25 PM, Brad Kemper <brad.kemper@gmail.com>
> wrote:
> 
>> On Aug 3, 2009, at 4:08 PM, David Hyatt wrote:
>> 
>> 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".
>> 
> 
> You've never been able to do it on the right, at least not in Gecko.
> 
> Note that doing it on the left stuffs up accessibility. It really
> shouldn't be done at all.
> 

Whilst I fully agree, the irony is that "accessibility" is usually the 
reason for using this "off-screen" technique in the first place!  It 
used to be well known that certain screen readers would ignore content 
which was set to display:none but read out content that was hidden with 
more ingenuity, hence the proliferation of techniques such as 
"positioning off left/top" to hide semantically useful yet visually 
unnecessary section titles etc.  Personally I prefer to zero each 
component of the box model and then set
position:absolute;overflow:hidden;
since this approach works "as specified" and makes no assumptions as to 
browser-specific behaviour.

However, I very much wonder whether this issue is still relevant (if it 
ever was), or whether it'll be one of those folkloric practices which 
continue for years after the affected UAs are dead and buried.

Cheers,
Anton Prowse
http://dev.moonhenge.net

Received on Tuesday, 4 August 2009 14:37:19 UTC