- From: L. David Baron <dbaron@dbaron.org>
- Date: Thu, 14 Mar 2013 10:21:24 -0700
- To: Rik Cabanier <cabanier@gmail.com>
- Cc: Dirk Schulze <dschulze@adobe.com>, "robert@ocallahan.org" <robert@ocallahan.org>, "public-fx@w3.org" <public-fx@w3.org>
On Thursday 2013-03-14 09:55 -0700, Rik Cabanier wrote: > 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. Dropping background-blend-mode simplifies it a lot, because you only have to consider elements that form stacking contexts when addressing it. -David -- 𝄞 L. David Baron http://dbaron.org/ 𝄂 𝄢 Mozilla http://www.mozilla.org/ 𝄂
Received on Thursday, 14 March 2013 17:22:00 UTC