W3C home > Mailing lists > Public > www-style@w3.org > May 2013

Re: [css-compositing]new Editor's draft posted

From: Rik Cabanier <cabanier@gmail.com>
Date: Tue, 21 May 2013 23:29:23 -0700
Message-ID: <CAGN7qDBqPiuJ7HYKcxCNEd6fqvv-zCKT8zjyi=_EwQ0u___=Lg@mail.gmail.com>
To: robert@ocallahan.org
Cc: "public-fx@w3.org" <public-fx@w3.org>, www-style list <www-style@w3.org>, www-svg <www-svg@w3.org>, David Baron <dbaron@dbaron.org>
On Tue, May 21, 2013 at 11:16 PM, Robert O'Callahan <robert@ocallahan.org>wrote:

> On Wed, May 22, 2013 at 11:40 AM, Rik Cabanier <cabanier@gmail.com> wrote:
>> - the backdrop is the stacking context of your ancestor -> this still
>> needs more discussion and is marked as an issue since it could be the
>> ancestor layer.
> I don't see how that helps much. An element's ancestor's stacking context
> could contain all kinds of content below the element, which the browser
> could have assigned to layers in various ways.

Those would have been composited already by the time the element that is
blending, is composited. I don't think that is ever done out of order.
So, all those layers are already in the stacking context/layer so it's
possible to examine the pixels.

Someone mentioned that maybe you should only blend with your parent element
(in effect promote it to a stacking context too), but I think that doesn't
solve the problem either...

> CSS constructs that create groups or layers, is something that developers
>> are getting more familiar with.
>> I realize that browser vendors are hesitant to specify them but it looks
>> that Google is starting to educate its users about them.
>> For instance, layers (and their effect on performance) are discussed at
>> Google IO here:
>> https://developers.google.com/events/io/sessions/325933151
>> https://developers.google.com/events/io/sessions/325091862
> I don't think it's a good idea to teach authors to create content
> optimized for one specific rendering implementation.

Yes, the Q & A was touching on that a bit.
Received on Wednesday, 22 May 2013 06:36:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:30 UTC