- From: David Dailey <ddailey@zoominternet.net>
- Date: Thu, 23 May 2013 21:55:59 -0400
- To: "'Rik Cabanier'" <cabanier@gmail.com>
- Cc: <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>
- Message-ID: <00cc01ce5821$dc3b4540$94b1cfc0$@net>
Thanks Rik, This helps a lot. Cheers. David From: Rik Cabanier [mailto:cabanier@gmail.com] Sent: Thursday, May 23, 2013 8:18 PM To: David Dailey Cc: public-fx@w3.org; www-style list; www-svg; David Baron; Robert O'Callahan Subject: 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.
Received on Friday, 24 May 2013 01:56:43 UTC