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

On Wed, Feb 12, 2014 at 5:44 PM, Robert O'Callahan <robert@ocallahan.org>wrote:

> On Thu, Feb 13, 2014 at 1:32 PM, Ojan Vafai <ojan@chromium.org> wrote:
>
>> 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.
>>
>
> It would be some amount of work to make clip-path: url(#shape) work when
> #shape is in a contain:strict element. However, it would also be some
> amount of work to make sure that clip-path: url(#shape) does NOT work when
> #shape's nearest contain:strict ancestor is not the nearest contain:strict
> ancestor of the styled element (which I assume is what you'd really want).
> I'm not sure the former is much more work than the latter.
>

That's a good point. I suppose my leaning towards disallowing it comes from
wanting the containment to be as strict as possible so that web authors can
use contain:strict and not need to worry about the exceptions that break
the containment. The downside to that is that it means SVG clip paths now
need to know about contain:strictness, which is a bit of a bummer.

Received on Thursday, 13 February 2014 04:17:01 UTC