W3C home > Mailing lists > Public > public-fx@w3.org > January to March 2013

Re: Utility of background-composite and background-blend-mode?

From: L. David Baron <dbaron@dbaron.org>
Date: Wed, 6 Mar 2013 16:32:50 -0800
To: Rik Cabanier <cabanier@gmail.com>
Cc: robert@ocallahan.org, public-fx@w3.org
Message-ID: <20130307003250.GA2530@crum.dbaron.org>
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:33:18 GMT

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