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: Tue, 5 Mar 2013 21:16:04 -0800
Message-ID: <CAGN7qDDaT6Ce8gDE6OqrtnMnLeUMcq9-jWEmVT1rYS_K+Adatg@mail.gmail.com>
To: robert@ocallahan.org
Cc: public-fx@w3.org
On Tue, Mar 5, 2013 at 6:06 PM, Robert O'Callahan <robert@ocallahan.org>wrote:

> On Tue, Mar 5, 2013 at 7:45 PM, Rik Cabanier <cabanier@gmail.com> wrote:
>> If you follow the spec [1], each background image is drawn during the
>> step '2. background image of element'. The background that is available for
>> the blend operation at that time is everything up to an ancestor that
>> created a stacking context.
> Hmm. I see that the spec says "Everything in CSS that creates a stacking
> context <http://www.w3.org/TR/CSS21/zindex.html> must be considered a
> group." I don't like that. An ancestor that created a stacking context just
> because it's absolute-positioned with z-index not 'auto' shouldn't impact
> blending and shouldn't create an isolated group; it'll create a performance
> penalty for existing Web content.

I agree,but it's just reality.
The graphics libraries that support the browser's rendering, are not
powerful enough to create true, non-isolated groups. Even if they did, I
would have a hard time convincing mobile browsers since it takes a lot more
processing and extra buffers to implement.

> You also say "In SVG, every element must create a group. This seems costly
> but implementations can optimize this by not treating elements with default
> arguments as groups." You also need to check that the element doesn't
> contain any descendants that use non-default blending. This can be done but
> it could be costly.

Why is that? a <g> with no properties such as opacity should be treated as
a passthrough. This is how things are already defined in SVG.

There are still questions how exactly this should be defined. The model
currently states that all groups in SVG, should have 'accumulate' for their
'enable-background' property.
In reality, neither Firefox or WebKit implement this and silently create
stacking context-like idioms under the hood. (Noone has noticed this
because neither browser gives the user the ability to get to the backdrop)

> BTW I noticed that you require clip-to-self behavior for compositing. This
> is tricky because it means you have to define for everything that can be
> rendered by CSS exactly what the clip-to-self shape is, and it's not always
> obvious. For this reason we adopted non-clip-to-self behavior for canvas.

True. but clip-to-self is really what authors expect.
(Note that I called this out in canvas chapter of the spec [1])
This is one of the reasons that compositing will have to be implemented at
a later date when the graphics libraries and the hardware are more
I would be happy to move this to the next level of the spec.

> BTW^32 knockout groups are subtle and under-defined because an "element"
> doesn't correspond one-to-one with actual drawing operations. For example,
> if I have an element with a background, border and outline, all of which
> overlap, does the border knock out the background? Does the outline knock
> out the border? Note that there could be other content between the border
> and the outline in z-order.

yes. Like the spec states:

"The end result is as if every shape composites with a ‘clear’ operation
(with clip-to-self enabled) first before it blends and composites."

For instance, if you draw text with multiple shadows and the text color and
shadows have opacity, knockout would ensure that you won't see the shadow
through the text or shadow under the other shadows.

> Getting back to the point of this thread: it seems to me that
> background-composite and background-blend-mode are not that useful if we
> have mix-blend-mode and mix-composite. You can do the same sorts of
> effects, just with more markup. With Web Components and intelligent use of
> pseudo-elements, you might not even need more markup. I think I'm still in
> favour of eliminating background-composite and background-blend-mode.

I don't disagree. I proposed to move it to a later date a couple of months
ago but people objected.
Since the implementation cost is low and the concept easy to grasp, why not
add it now?
People use background images all the time and I believe that authors would
like to blend them just like they do in PhotoShop.
The first example that one of our designers made used mix-blend-mode. He
just rewrote it to use background-blend-mode and the markup was much

Received on Wednesday, 6 March 2013 05:16:31 UTC

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