W3C home > Mailing lists > Public > public-fx@w3.org > April to June 2013

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

From: Rik Cabanier <cabanier@gmail.com>
Date: Fri, 24 May 2013 20:51:08 -0700
Message-ID: <CAGN7qDDVB-NfhU=WeX_M4_RVWBPnVWFh0tYmJz6P9wsLmLoAJA@mail.gmail.com>
To: robert@ocallahan.org
Cc: Michael Mullany <michael@sencha.com>, David Dailey <ddailey@zoominternet.net>, "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 Fri, May 24, 2013 at 9:43 AM, Robert O'Callahan <robert@ocallahan.org>wrote:

> On Fri, May 24, 2013 at 11:09 AM, Rik Cabanier <cabanier@gmail.com> wrote:
>
>> I think there is now a clear path on how to calculate the backdrop for
>> HTML
>>
>
> Well, maybe.
>
> Currently the spec says
> "However certain operations that cause the creation of stacking context
> (such as 3D transforms or a non-default blend mode) [CSS21] will cause a
> group to be isolated. This behavior is described in more detail in Isolated
> Gropus." [sic]
> However, nothing in the spec describes exactly what induces an "isolated
> group".
>

No. It would have to be added to http://www.w3.org/TR/CSS21/zindex.html.
Filters, blending and isolation would need to be added.
For blending, the implication is that every stacking context causes an
isolated groupl
This makes the 'isolation' property something that just creates a stacking
context.


>
> Also, I think every isolated group needs to be a stacking context since we
> can't allow two elements in an isolated group to have other content not in
> the group inserted between them in z-order. So every element that's an
> isolated group would have to be a stacking context, and every element
> that's a stacking context would have to be an isolated group, so they're
> almost exactly the same thing.
>

Yes


> Except that SVG images rendered in CSS or via <img> are also isolated
> groups.
>

Yes, because they're treated like images.


>
> If we do that, I think we can probably implement this in our compositor.
> For every element that requires non-standard blending with the background,
> we'd find the nearest ancestor stacking context, which induces an isolated
> group on that element. We'd tell the compositor about those isolated
> groups, and it would then be able to compute the backdrops for blended
> elements within these groups. Needs more thought though.
>
> If that works, I think we should make the CSS/SVG filters
> "BackgroundImage" value be evaluated the same way and dispense with
> "enable-background". Also, it fits better with our priorities to experiment
> with this as part of CSS/SVG filters instead of implementing CSS blending
> and compositing right away.
>

I agree.
Michael's experiment with "enable-background" shows that that property is
not well defined. When you move the blended area, you can see that part of
the backdrop that wasn't covered, was also transposed.
That is a very big problem. For instance, if you have 2 nested blends, the
outer blend would blend the backdrop with itself which is completely wrong.
It seems the SVG spec forgot to mention that the background needs to be
removed once you get to a filter or opacity...
Received on Saturday, 25 May 2013 03:52:00 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:49:45 UTC