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: Florian Rivoal <florian@rivoal.net>
Date: Tue, 7 Jul 2015 23:09:36 +0200
Cc: www-style list <www-style@w3.org>
Message-Id: <FEAA961E-6AC0-40E1-8261-9D8A323A2ACB@rivoal.net>
To: Daniel Holbert <dholbert@mozilla.com>

> On 06 Jul 2015, at 18:08, Daniel Holbert <dholbert@mozilla.com> wrote:
> 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.

I see this the other way around. This first optimization works just fine with my suggested change. If the element is offscreen, paint containment will work just as well with overflow:auto as with overflow:clip. You can skip the whole thing and you're good. If you're on screen, then this optimization does not apply either way, and overflow:auto avoids content getting lost.

> 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'.)

This optimization does indeed need both contain:paint and overflow:clip.
If this were the only effect of contain:paint, I'd be fine with it, because doing this would explicitly be the goal of this property. But since containt:paint has other useful and observable effects, I think there is a fair chance that this one might happen accidentally, on element that weren't meant to overflow, because the author environment and the user environment differ, and then we get unintended content loss.

 - Florian
Received on Tuesday, 7 July 2015 21:12:10 UTC

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