Re: Filters spec: CSS vs SVG

Am 05.05.2011 um 10:03 schrieb Rik Cabanier:

> Dirk,
> 
> since this is a new spec, why do we need to worry about backward compatibility?
> There is no existing content that is using this new specification...
If both are accepted in parallel, we have to support both. Something that I'd like to avoid. My understanding for Filters 1.0 was a common filter specification for CSS and SVG. And many people are afraid that their content won't work if we redesign Filters. And speaking for WebKit, we won't support two different versions of SVG, nor of Filters. At the moment we implement SVG 1.1 (including SVG Filters) and will turn to 2.0 step by step. If SVG 2.0 won't be backward compatible, content for SVG 1.1 won't work in WebKit anymore. We just don't have the resources to support both specifications.

> 
> Can you tell me why the compositing spec and fecomposite are different? In previous discussions, some people wanted to avoid access to the background for now so we can focus on getting simple filters in.
While the new Compositing specification is more working with the context and how an object gets blended to underlaying shape drawings, feComposite is working with objects (just SVG filter primitives so far). This is a different to Composite, because the order of the objects in the DOM doesn't matter. You just reference them as you need them. This is relevant in Filters, since you want to combine different filter primitives. And we don't have a strict hierarchy for Filters (beside that we draw the result of the last primitive of a Filter). 

Dirk


> Rik
> 
> On Wed, May 4, 2011 at 11:40 PM, Dirk Schulze <vbs85@gmx.de> wrote:
> In all discussions about the new Filter specification, the backward compatibility to SVG Filters was very important. Thats why the new specification can't drop existing features easily. But to make e.g. 'enable-background' deprecated for filters is not really the worst thing, since most viewers don't support it anyway. Regarding filter-regions: I think nobody will drop this, but filter-regions could be optional - the same for primitive-regions (may needs more discussions). If the user defines them, the viewer has to clip on these regions. If the regions are not applied, the viewer calculates the bounds itself.
> It will be hard to drop 'feComposite' or 'feMerge' because of backward compatibility. Also the new composite specification and 'feComposite' have different use-cases. 
> 
> Dirk
> 
> Am 05.05.2011 um 06:27 schrieb Rik Cabanier:
> 
>> Hi Jeff,
>> 
>> that was what I thought as well. However, Erik's comments and the conversation in the fx meeting are suggesting that we're changing the current spec and that the new keyword apply to both CSS and SVG attributes.
>> 
>> Rik
>> 
>> On Wed, May 4, 2011 at 5:41 PM, Jeff Schiller <codedread@gmail.com> wrote:
>> David,
>> 
>> As far as I understand, this is a new spec for styling HTML/CSS with quick filter effects using CSS.  This is not removing SVG Filters.
>> 
>> Think about it like SVG gradients vs. CSS gradients.  Or SVG transforms vs CSS3 transforms.
>> 
>> Jeff
>> 
>> 
>> On Wed, May 4, 2011 at 5:28 PM, David Dailey <ddailey@zoominternet.net> wrote:
>> I’m confused. Apparently I’m not subscribed to all the relevant lists as the proposal to gut filters functionality appears first to have been made known in this particular email.
>> 
>>  
>> Again, I am confused. Is it that people are really seriously proposing to gut all existing functionality from filters chaining?
>> 
>>  
>> Is there a process by which formal objections might be filed if so?
>> 
>>  
>> It sounds like a remarkably bad set of proposals if this is what people are actually discussing!
>> 
>>  
>> Not only would it break existing content (that some people argue doesn’t matter anyhow, being only ten years’ worth) but it breaks what one can do!
>> 
>>  
>> Surely Rik’s summary must be overstated, as so backwards a set of steps would seem to be remarkably backward!  
>> 
>>  
>> What am I missing here?
>> 
>>  
>> David
>> 
>>  
>>  
>>  
>> From: www-svg-request@w3.org [mailto:www-svg-request@w3.org] On Behalf Of Rik Cabanier
>> Sent: Wednesday, May 04, 2011 5:30 PM
>> To: Erik Dahlstrom
>> Cc: public-fx@w3.org; www-svg
>> Subject: Re: Filters spec: CSS vs SVG
>> 
>>  
>> Thank Erik!
>> 
>> I didn't know that this was a replacement for the current spec.
>> 
>>  
>> So far, I think these are the following proposed changes:
>> 
>> - remove section 6, the filter effects region
>> 
>> - remove backgound-image and background-alpha
>> 
>> - remove section on the enable-background keyword
>> 
>> - change default behavior of an unknown filter to 'ignore' instead of the 'null filter'
>> 
>> - remove filters that create an image and move them to the image-values spec (ie feTurbulence)
>> 
>> - remove the feComposite filter and replace with the CSS/SVG compositing spec
>> 
>>  
>> Rik
>> 
>> On Wed, May 4, 2011 at 4:41 AM, Erik Dahlstrom <ed@opera.com> wrote:
>> 
>> On Tue, 03 May 2011 20:30:05 +0200, Rik Cabanier <cabanier@gmail.com> wrote:
>> 
>> All,
>> 
>> in yesterday's meeting is sounded that the CSS Filter spec is going to
>> affect the regular (non-CSS) SVG filter spec as well.
>> Did I understand this correctly?
>> 
>>  
>> It's "Filter Effects 1.0", and the spec can be found here:
>> 
>>  https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/publish/Filters.html
>> 
>> As agreed in earlier discussions in the taskforce we're making one spec. It includes both SVG and CSS definitions.
>> 
>>  
>> If so and we remove/change filters or features from the filters proposal, is
>> someone going to update the SVG filters?
>> 
>>  
>> No, the Filter Effects 1.0 spec replaces the SVG Filters 1.2 spec.
>> 
>>  
>> I was under the impression that we were going to leave SVG filters (and
>> compositing) alone and define a new simpler proposal that would only apply
>> to CSS styled HTML and SVG content.
>> 
>>  
>> We are defining a simpler syntax for filter effects, however I'm not convinced it's a good idea to ignore SVG Filters which are widely implemented at this stage, and considering that diverging from that potentially makes it harder to reuse existing code.
>> 
>> The general idea so far has been: use svg <filter> markup for the more complex filter effects, use css shorthands for simple filter effects.
>> 
>> 
>> -- 
>> Erik Dahlstrom, Core Technology Developer, Opera Software
>> Co-Chair, W3C SVG Working Group
>> Personal blog: http://my.opera.com/macdev_ed
>> 
>>  
>> 
>> 
> 
>