Re: [css3-ui] Proposal for an "overlay" value for 'overflow'

On Jan 24, 2013, at 1:53 PM, Simon Fraser <smfr@me.com> wrote:

> On Jan 24, 2013, at 11:58 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> 
>> I just learned of this this morning, but apparently WebKit has a
>> long-existing extra value for 'overflow' called "overlay":
>> <https://bugs.webkit.org/show_bug.cgi?id=32388>.  It's not prefixed or
>> anything.  Its effect is identical to "auto", except it forces the
>> scrollbars, when generated, to be overlay rather than space-filling.
>> That is, the scrollbars act like abspos elements attached to the
>> end/after edges of the element, and if there's insufficient padding on
>> those edges, will happily overlap content at the edge.
>> 
>> Here's an example of it in action: <http://jsfiddle.net/rNxgD/>.  View
>> in a WebKit-based browser, obviously.
>> 
>> This is apparently used by a small amount of web content, and some
>> Apple content, which means we can't remove it from our engine easily.
>> It seems potentially useful for general CSS, though.  How do others
>> feel about standardizing this?
> 
> Can you provide more data on pages that use this in the wild?
> 
> I don't believe we have any content at Apple that cares about overflow:overlay;
> if we do, then we should move it under a prefix.
> 
> I don't think we should standardize this value.
> 
> Simon

I just tested the jsfiddle in Lion, and the results seem to depend on the "General" System Preference for the "Show scroll bars" setting. If it is set to "When scrolling", there is no difference between the two property values. If it set set to "always", then 'overlay' does indeed overlap and obscure the content. (Reload the page after changing the system pref, or you get other results). 

It doesn't seem to useful in Mac Safari. Maybe it does something nicer looking on Chrome in Android or something, if it perhaps used more transparent scrollbars?

Received on Thursday, 24 January 2013 22:23:12 UTC