W3C home > Mailing lists > Public > public-fx@w3.org > January to March 2013

Re: Utility of background-composite and background-blend-mode?

From: Rik Cabanier <cabanier@gmail.com>
Date: Thu, 14 Mar 2013 09:55:21 -0700
Message-ID: <CAGN7qDDca1joz6NX084Ck55a+QasS8pQuD6B7oCFFFCeMtFOOw@mail.gmail.com>
To: "L. David Baron" <dbaron@dbaron.org>
Cc: Dirk Schulze <dschulze@adobe.com>, "robert@ocallahan.org" <robert@ocallahan.org>, "public-fx@w3.org" <public-fx@w3.org>
On Thu, Mar 14, 2013 at 9:19 AM, L. David Baron <dbaron@dbaron.org> wrote:

> On Thursday 2013-03-14 05:44 -0700, Dirk Schulze wrote:
> > No, not WebKit's rules. And I do not think that we want to specify
> > buffering. A behavior in situations like scrolling for blending
> > should be specified and browser need to follow. I see that this
> > can be challenging but would be most desireabale. After all,
> > scrolling should not affect the browser experience of the user on
> > the visual side - especially for blending.
>
> As I said in http://dbaron.org/log/20130306-compositing-blending , I
> think there's a lot less to specify and a lot less to drive towards
> interoperability if compositing and blending operations are limited
> to things that create stacking contexts.  This limitation would be
> present if background-blend-mode and background-composite are
> dropped, which I think should be done.


David,
the exact same issue will happen if blending applies to elements (in which
case stacking contexts are created).
For instance, an element with blending that is a child of an element that
uses fixed positioning will render differently today in FF and WK.

Dropping background-blend-mode will not solve this problem.
Received on Thursday, 14 March 2013 16:55:51 GMT

This archive was generated by hypermail 2.3.1 : Thursday, 14 March 2013 16:55:52 GMT