Re: [css-overflow] interaction between "overflow-x" and "overflow-y", when one of them is "clip"

> On 03 Jul 2015, at 20:45, Daniel Holbert <dholbert@mozilla.com> wrote:
> 
> Thanks for the response!
> 
> On 07/03/2015 09:20 AM, Florian Rivoal wrote:
>> maybe we can turn it around, and say that
>> contain:paint should turn visible into auto, not clip. That
>> would do the same as clip if the content does not overflow,
>> but would require authors to be explicit about dropping content
>> if that's what they want.
> [...]
>> Bottom line, my suggestion is to:
> [...]
>> - change overflow:visible + contain:paint to compute into
>>  overflow:auto + contain:paint
> 
> So you're proposing that "contain:paint", on its own, would just end up
> producing "overflow:auto"?

It would also cause the element to act as a containing block for absolutely positioned and fixed positioned descendants, which I believe is the most important part when it comes to performance. The difference between clip and hidden helps as well, but I'd guess it matters less.

> I don't think that matches the intent of "contain:paint"... the point is
> to "contain painting", i.e. to clip.

From the definition of contain:paint:

"This ensures that the descendants of the containing element don’t display outside its bounds"

I'm still ensuring that. 

> And RE your concern about requiring authors to be explicit -- they *are*
> being explicit if they're using "contain: paint". That is them
> *explicitly asking* to drop any painting that falls outside of the
> element's bounds.

You're explicitly asking not to paint outside, but overflow:auto does that as well (when combined with being a containing block for abspos and fixpos).

You're not being explicit about what you want to happen to content that wouldn't fit. Don't paint outside, sure, but do what instead? clip is the fastest way to do that, auto is the safest way.

Given that the contain property is about speed, I'm not totally opposed to clip, but in general it is safe to bet that authors will fail to account for variation in rendering environment some of the time, and when that happen, ugly and/or slower is better than unreadable.

 - Florian

Received on Friday, 3 July 2015 21:14:35 UTC