W3C home > Mailing lists > Public > www-style@w3.org > October 2013

Re: [css-overflow-clipping] First Draft of Overflow Clipping now available!

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 2 Oct 2013 14:15:13 -0700
Message-ID: <CAAWBYDAOQQUtNDHTe1bRTsFtZHpS33E6LGzfO1u109qCgwVAnw@mail.gmail.com>
To: "Robert O'Callahan" <robert@ocallahan.org>
Cc: www-style list <www-style@w3.org>
On Wed, Oct 2, 2013 at 1:36 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> On Wed, Oct 2, 2013 at 1:33 PM, Robert O'Callahan <robert@ocallahan.org> wrote:
>> On Wed, Oct 2, 2013 at 4:17 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>>> If it's not, then descendants of the element can paint/affect layout
>>> of stuff outside of the element.
>>
>> Yes, but why is that important in this case?
>>
>> Is the idea here that descendants of an overflow:clip element that's outside
>> the viewport don't even need to have style resolved on them? So we
>> anticipate authors creating a lot of elements that are overflow:clip and
>> positioning them over a large area?
>
> Precisely.  (Authors already create self-contained elements positioned
> over long documents; being assured of the possibility of optimizing
> these would be nice.)

Actually, discussing this with Ojan just now, we realized that the
feature isn't currently sufficient to allow this optimization.  There
are still a few things that have "global" effects, like counter
increments.  To address this properly, we'll need to sandbox counter
scopes, and make sure there's nothing else that leaks out of an
element.

This makes me much less happy about making this an 'overflow' value.
I'd prefer a separate property which just locks down an element.
Thoughts?

~TJ
Received on Wednesday, 2 October 2013 21:15:59 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:51:02 UTC