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

So let me see if I understand:

 

a)      Is compositing for CSS seen as a replacement or even a substitute
for filters..

b)      Will work on SVG filters be abandoned allowing "compliant browsers"
to (as per the long term wishes of some of them) duck implementation of the
hard stuff?

c)       Will there be a CSS module separate from compositing to handle the
broad spectrum of SVG filters? i.e, is CSS-filters forking into two parts:
compositing and the other stuff?

d)      By virtue of being composited in order and not as a tree,
css-compositing is intrinsically weaker than SVG filters.  On the other
hand, I gather that there is functionality being offered in css-compositing
that is either not present in SVG's feComposite or because of collusion
between certain browsers never going to be implemented by them. If so will
that additional functionality be added into SVG (in a real DOM approachable
sense and not involving  goofy CSS sleight of hand)??

I'm trying to see if I need to pay closer attention to these issues or if it
only matters to the HTML/CSS crowd. Periodically it seems browsers conspire
to cripple SVG, be it through proposing <canvas> or through not implementing
SMIL or SVG-fonts or enable-background  or by moving half-cool stuff to CSS,
and I suppose I should pay enough attention to know when to start reading up
on the laws that govern fair competition!  jiji. Chiste! Or maybe I'll have
to release new chapters of the books I've written and redo 1400 pages of
examples done for class.  But in the words of one implementer "there is no
content out there that matters - we've already looked!"

 

David

 

 

 

 

From: Rik Cabanier [mailto:cabanier@gmail.com] 
Sent: Thursday, May 23, 2013 7:02 PM
To: public-fx@w3.org; www-style list; www-svg; David Baron; Robert
O'Callahan
Subject: [css-compositing] new Editor's draft posted -> update

 

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.

 

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

 

On Tue, May 21, 2013 at 8:40 PM, Rik Cabanier <cabanier@gmail.com> wrote:

As a quick recap, people voiced concerns about the following issues before:

- background-blend-mode blends with the entire backdrop of the element

- does mix-blend-mode create a stacking context?

- what is the backdrop of mix-blend-mode?

 

The spec was changed so:

- images that have background-blend-mode applied will only blend between
themselves and the background color

- mix-blend-mode always creates a stacking context

- the backdrop is the stacking context of your ancestor -> this still needs
more discussion and is marked as an issue since it could be the ancestor
layer.

 

CSS constructs that create groups or layers, is something that developers
are getting more familiar with.

I realize that browser vendors are hesitant to specify them but it looks
that Google is starting to educate its users about them.