W3C home > Mailing lists > Public > www-style@w3.org > July 2015

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

From: Daniel Holbert <dholbert@mozilla.com>
Date: Mon, 6 Jul 2015 09:08:43 -0700
To: Florian Rivoal <florian@rivoal.net>
Cc: www-style list <www-style@w3.org>
Message-ID: <559AA80B.5050906@mozilla.com>
On 07/03/2015 02:14 PM, Florian Rivoal wrote:
>> On 03 Jul 2015, at 20:45, Daniel Holbert <dholbert@mozilla.com> wrote:
>> So you're proposing that "contain:paint", on its own, would just end up
>> producing "overflow:auto"?
[...]
>> 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. 

But the whole point of the "contain" property is to enable
optimizations.  And the spec's two suggested optimizations don't make
any sense with this suggested "overflow:auto" change.  Particularly the
second one.

The first suggested optimization: "If the containing element is
off-screen or obscured, the UA can directly skip trying to paint". In
this scenario (which I think is a large use-case for contain:paint),
your concerns about authors not having considered font-size differences
etc. are not really worrisome, because the content isn't visible anyway.

The second suggested optimization: "the UA can reserve 'canvas' space
for the element exactly the elementís size."  This optimization can't
actually be performed, if scrolling is possible.  (If scrolling is
possible, browsers may need to overpaint to be able to respond quickly
to scrolling, so they'll need to reserve a larger 'canvas'.)

http://dev.w3.org/csswg/css-containment/#containment
Received on Monday, 6 July 2015 16:09:16 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:52:18 UTC