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