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

On Thu, May 23, 2013 at 5:17 PM, Michael Mullany <michael@sencha.com> wrote:

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

Yes, 'enable-background' is the big stumbling block.
My hope is that containing things between stacking context will give us
interoperability and still be useful.


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

Likewise!
Here's a patch for webkit: https://bugs.webkit.org/show_bug.cgi?id=110427

It's gated because the reviewers want to make sure that we can implement it
for the HMTL render model first (because that's where SVG is going)


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