W3C home > Mailing lists > Public > www-style@w3.org > May 2013

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

From: Michael Mullany <michael@sencha.com>
Date: Thu, 23 May 2013 17:19:29 -0700
Message-ID: <CABTYPJmwj9H_+65Hb1176ma1WAFVSV8tOQeVav3mC9WcREpc=g@mail.gmail.com>
To: David Dailey <ddailey@zoominternet.net>
Cc: Rik Cabanier <cabanier@gmail.com>, public-fx@w3.org, www-style list <www-style@w3.org>, www-svg <www-svg@w3.org>, David Baron <dbaron@dbaron.org>, "Robert O'Callahan" <robert@ocallahan.org>
>
>  (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.****
>>
>> ** **
>>
>
>
Received on Friday, 24 May 2013 00:27:35 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:30 UTC