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

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

From: James Robinson <jamesr@google.com>
Date: Thu, 23 May 2013 16:57:52 -0700
Message-ID: <CAD73mdLgczponvNoPw33P8w+TwRhhqWzb8FAAw-WyJZAM=UO1A@mail.gmail.com>
To: Rik Cabanier <cabanier@gmail.com>
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>, "Robert O'Callahan" <robert@ocallahan.org>
On Thu, May 23, 2013 at 4:02 PM, Rik Cabanier <cabanier@gmail.com> wrote:

> After talking this over with our engineers, it turns out that the
> invisible 'layers' that browsers create, are not actually a problem.
> This is because they are composited in order and not as a tree (at least
> on webkit and blink).
> For instance, if you have content like this:
> <video>...</video>
> <div>
> <p>...</p>
> <p style="mix-blend-mode">...
> there will be 3 layers on the back-end: one for video, one for the <div>
> and for the <p> with the blending.
> This content will be composited as a list so <p> will composite and blend
> with the composited result of <video> + <div> which is the desired behavior.

Well no, it depends.  Sometimes it will render in the way you say here, but
sometimes we may blend the <p> together with the <div> before blending that
with the <video> or we may put different subsets of these layers into
separate intermediate surfaces.  We may be forced to blend the <div> and
the <p> together without involving the <video>'s contents if the <div> has
a transform-style: preserve3D, for example.

Whether this produces any observable difference in the final output depends
on exactly why you are depending on the draw order - in general, you really

- James

> I updated the spec and removed that particular issue. I also worded it so
> blending will happen between stacking context (which is what David Baron
> suggested in an earlier email)
> There will still be work needed on the implementation side to plumb this
> i, but I think this will suffice for the specification.
> Rik
Received on Thursday, 23 May 2013 23:58:23 UTC

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