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

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

>  (as an aside - filter animation performance with SMIL on IE10 is actually
>> pretty spectacular.)
>>
>
> please replace "SMIL" with "JavaScript" - of course (doh)
>
>>
>>
>>
>> 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.****
>>>
>>> ** **
>>>
>>
>>
>