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

David,

I've been doing a lot of SVG filters across the edge browsers, and I'm
happy to say that the compliance rate has become pretty great. Webkit/blink
has the most bugs but I've been filing them against Chromium as they come
up and they've been getting fixed gradually. enable-background (ironically
given the current discussion) is probably the biggest feature area that
needs catchup (only implemented in IE10 and opera (for now)). (as an aside
- filter animation performance with SMIL on IE10 is actually pretty
spectacular.)

Sadly, the "trapdoor" support for SVG filters to be applied to DOM content
via the url(#filter) mechanism is very incomplete in webkit/blink right now
- only color transformations feComponentTransfer & feColorMatrix seem to be
working.

(I would really like to see the new blend modes added into SVG because they
add functionality that is not possible with feBlend as it stands.)

-- michael

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….****
>
> **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.****
>
> ** **
>