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: Wed, 6 Mar 2013 16:53:13 -0800
Message-ID: <CAGN7qDAAW9UXJB6snPfj2uMcx08hUGL3XQLgha3ntG7zGwf+Dg@mail.gmail.com>
To: "L. David Baron" <dbaron@dbaron.org>
Cc: robert@ocallahan.org, public-fx@w3.org
Thanks for posting that blog.

In order to specify blending an compositing throughout CSS in a way that
will be interoperable across browsers, the grouping in CSS must be
specified as clearly and with as much precision as the ordering is. This
means that everything inAppendix E of CSS 2.1, plus all the additions to it
from newer CSS modules that have not been fully tracked, needs to specify
not only the ordering of the drawing operations but also their grouping.


I think this is most important. As you mention, that spec does not talk
about grouping.
The compositing spec's assumption was that a stacking context constitutes a
group but nothing else is.

However, we now know that certain stacking contexts (only certain 2d
transforms so far) are not really groups.
The compositing spec also introduces mix-blend-mode on:

box-shadow | text-shadow | background | border | content

that will create a group (but not a stacking context)

I'm unsure if I share your concern of the drawing order.
The only way to run into these associative problems is by compositing in
offscreen buffers. So yes, we should fix the stacking context/grouping
problem but once that is fixed, it should negate this particular issue.

On Wed, Mar 6, 2013 at 4:32 PM, L. David Baron <dbaron@dbaron.org> wrote:

> On Wednesday 2013-03-06 16:13 -0800, Rik Cabanier wrote:
> > On Wed, Mar 6, 2013 at 3:19 PM, L. David Baron <dbaron@dbaron.org>
> wrote:
> > > Background images themselves are atomic, but you still need to
> > > specify what they're blended with.  And since they don't create a
> > > stacking context, they sit in the middle of the very-complicated
> > > rules for painting stuff within a stacking context.
> > >
> >
> > yes, but your spec describes that order (except it doesn't handle
> multiple
> > backgrounds yet) so that should not be a big deal.
>
> It wouldn't be a big deal if the backgrounds were composited only
> against each other.  But
>
> https://dvcs.w3.org/hg/FXTF/raw-file/fac7acff8efc/compositing/index.html#background-blend-mode
> says:
>   # Each background image will blend with the element's background
>   # and the background images at a lower z-index.
> I interpret "the element's background" as "the things behind the
> element", which also matches your explanation in:
> http://lists.w3.org/Archives/Public/public-fx/2013JanMar/0084.html
> where you wrote:
>   # The background that is available for the
>   # blend operation at that time is everything up to an ancestor that
> created a
>   # stacking context.
>
> In this case you'd need to describe the grouping fully as I wrote
> here in http://dbaron.org/log/20130306-compositing-blending :
>   # In order to specify blending an compositing throughout CSS in a
>   # way that will be interoperable across browsers, the grouping in
>   # CSS must be specified as clearly and with as much precision as
>   # the ordering is. This means that everything in Appendix E of CSS
>   # 2.1, plus all the additions to it from newer CSS modules that
>   # have not been fully tracked, needs to specify not only the
>   # ordering of the drawing operations but also their grouping.
> rather than describing only the parts I outlined in my post as I
> continued to say in:
>   # If non-default compositing and blending is limited strictly to
>   # elements that create stacking contexts, as I have proposed
>   # (which means removing background-composite and
>   # background-blend-mode), then the specification problem becomes
>   # substantially easier, in that we at least only need to specify
>   # and interoperably implement the grouping of those of the drawing
>   # operations that involve elements creating stacking contexts,
>   # which means, I think, that the grouping would only need to be
>   # specified between:
>   #
>   # 1. Together, items (1) through (2) in the top level of Appendix E
>   # 2. Each item in item (3) in the top level of Appendix E
>   # 3. Together, items (4) through (7) in the top level of Appendix E
>   # 4. Each item in item (8) in the top level of Appendix E
>   # 5. Each item in item (9) in the top level of Appendix E
>   # 6. Together, (10) in the top level of Appendix E
> which is what would be necessary if the background-* properties were
> dropped, or if they applied only to blending with other background
> layers and not the backdrop of the element (which would be
> relatively easy, but I suspect not very useful).
>
> -David
>
> --
> 𝄞   L. David Baron                         http://dbaron.org/   𝄂
> 𝄢   Mozilla                           http://www.mozilla.org/   𝄂
>
Received on Thursday, 7 March 2013 00:53:40 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 7 March 2013 00:53:40 GMT