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

Thanks Rik,

 

This helps a lot.

 

Cheers.

David

 

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

 

 

On Thu, May 23, 2013 at 5:06 PM, David Dailey <ddailey@zoominternet.net>
wrote:

So let me see if I understand:

 

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

 

no, it's simply a shorthand that makes them easier to use than filters.
(just like the CSS filter shorthands which are already quite successful.)

 

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?

 

no, if anything, this will make SVG filters better.

 

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?

 

that is the CSS filters spec. See
https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html

 

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)??

The HTML drawing model is fundamentally different from SVG. See
http://www.w3.org/TR/CSS21/zindex.html

We have every intention to bring CSS blending to SVG as well; it just
requires different terminology (ie there are no stacking contexts but noone
has implemented non-isolated groups in SVG which is needed for the old spec
to work.)

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!"

 

We certainly don't want to cripple SVG...

 

 

 

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.