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

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