W3C home > Mailing lists > Public > www-style@w3.org > February 2014

Re: [css-containment] ED of Containment ready for review (was overflow:clip)

From: Ojan Vafai <ojan@chromium.org>
Date: Wed, 12 Feb 2014 16:32:53 -0800
Message-ID: <CANMdWTtTDRiWYYVnN1WLTmHm5jsaud72Ew7x9QF2u9_T5sRrsQ@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>, Philip Rogers <pdr@chromium.org>
Cc: Charles Walton <charleswalton@google.com>, "Robert O'Callahan" <robert@ocallahan.org>, Elliott Sprehn <esprehn@chromium.org>, Levi Weintraub <leviw@chromium.org>, Simon Fraser <smfr@me.com>, "www-style@w3.org" <www-style@w3.org>
On Thu, Dec 26, 2013 at 2:48 PM, Tab Atkins Jr. <jackalmage@gmail.com>wrote:

> On Tue Dec 10 2013 at 5:33:25 PM, Charles Walton <charleswalton@google.com>
> wrote:
>> If criteria 2 + 3 (the scroll-related ones) are removed, I don't see a
>> big benefit in expanding the syntax beyond the current "none | strict"
>> values. Being said, I'm not sure I fully understand the impact of those new
>> generated content properties.
> The point of the expanded syntax I proposed is precisely to allow the
> scroll-related ones to still be available, if you need them.
>> Also, are there any problems with SVG-esque stuff, like imported clip
>> paths? Say "#shape" was defined within a "contain: strict" element - could
>> it be referenced outside that element?
> That is a good question.  Probably no, I would think.  Levi, Ojan,
> thoughts?

Very late to this. It's not clear to me what should happen here. My
intuition is that we'd want to disallow this. The things contain:strict is
trying to achieve are style recalculation and layout isolation. So, in this
case, laying out the contents of the contain:strict element would require
first laying out the #shape element. It could be made to work, but I'm not
sure we'd want to.
Received on Thursday, 13 February 2014 00:33:40 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:19 UTC