Re: Filters spec: CSS vs SVG

>From now on I'm going to use the term Markup filters rather than SVG filters.

On 07/05/2011, at 10:38 AM, Rik Cabanier wrote:

> Thanks for the clarification Dean!
> In summary:
> - we will have 1 spec for both SVG and CSS
> - CSS might have features that don't apply to SVG. The spec needs to call this out.

I don't think we plan any at the moment. What we call CSS filters is simply an extension to the existing "filter" property that allows some effects using keywords.

I would hesitate to add anything to CSS that could not be replicated in markup. As I said, if we come up with new effects then they should be added in both places. eg. filter: awesomeeffect(10) and <feAwesomeEffect>.

> - Likewise SVG might have features that don't apply to CSS.
> - We should NOT remove existing SVG features (unless everyone agrees that they aren't necessary and are unused)

I don't mind if the group wants to remove some unused/unnecessary/difficult features from markup - such as enable-background. All I suggest is that we do it in a staged fashion, where they are first labelled as deprecated. But if people feel strongly that they should be removed immediately, I'll accept that too.

> With this in mind, I'll reword my original list:
> - remove section 6, the filter effects region
> - mark backgound-image and background-alpha as applying only to SVG content. Revisit when CSS compositing is defined.
> - mark section on the enable-background keyword as applying only to SVG content. Revisit when CSS compositing is defined.
> - 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) for CSS. Leave SVG behavior intact

I think all existing markup filters should remain and be available to all content via the filter property.

> - mark the feComposite filter as only applying to SVG. A future CSS/SVG compositing spec can address this better.

Again, I think if you have a <div> with a filter property of "url('filterlibrary.html#whatever')", then the whatever filter can use all the existing markup filter effects, including feComposite. Note that feComposite only describes the compositing within the filter chain - it doesn't affect the result of the filter composited into the document. That's where the new compositing spec comes in.

Dean

> 
> On Fri, May 6, 2011 at 12:12 PM, Dean Jackson <dino@apple.com> wrote:
> 
> On 06/05/2011, at 8:15 AM, Rik Cabanier wrote:
> 
>> Hi Chris,
>> 
>> these were just the changes that have been discussed on the FX mailing list. 
>> In the start of this thread, I said that I wasn't aware that this was intended to be a replacement for SVG filters.
>> 
>> I personally don't think that this should be the case and I'm fairly sure that Dean didn't intend this either.
> 
> My understanding was, and still is, that the Filters specification is supposed to cover both the SVG and CSS use cases - ie. it is a replacement for the SVG filters module.
> 
> The CSS parts were intended to be additions that could be described in SVG. Whether or not an implementation actually uses SVG filters is a detail left up to them. Also, the CSS part was intended to be less powerful than SVG filters - that's where the "dropping" of features comes from. They are just not available in CSS, giving the implementation the option to never implement them.
> 
> It did get slightly confusing when the suggestion to drop enable-background from SVG filters came up. It seems most implementors are happy with this. My comment was that it was fine to remove it, but since there is content out there that uses it (eg. Adobe Illustrator output) then we probably should mark it as deprecated for a while before complete removal.
> 
> 
> Enable-background is important for the SVG compositing spec. 
> Unless we want to simplify SVG blending (which I'm not opposed to), it is necessary.
>  
>> The CSS filter spec just took the general approach of the SVG filter specfor simplicity. If possible, we should not change behavior of overlapping functionality but it should be OK to remove or add keywords.
> 
> At the moment I don't think there is anything in the CSS part that requires a change in the SVG part. At least nothing that implies removal of SVG features.
> 
> I expect in the future we'll be tempted to add more effects - these should be added to both CSS and SVG. If an effect is not appropriate in CSS, it's ok for it to be SVG-only. SVG is always the way to do the more complex effects.
> 
> [Aside: If we start thinking of this spec as CSS vs Markup filters, rather than CSS vs SVG, it might be helpful. There is only a little bit of actual SVG in Filters]
> 
> Can you elaborate on what you mean with 'CSS vs Markup'?
>  
> 
> Dean
> 
>> 
>> For now, the filter spec is supposed to be as simple as possible both for implementors and web designers.
>> This means:
>> - easy syntax for basic filters. More complicated filters can be done using a subset of SVG filter. The reason for their use is that they were already well defined.
>> - no access to the background or blending for ease of implementation
>> - no enable-background. This concept does not exist in the HTML.
>> - no section support. HTML generally is not a fixed layout so 'sections' don't make much sense.
>> 
>> I agree that IF this is a replacemet spec, we need to thread more lightly...
>> 
>> Rik
>> 
>> On Thu, May 5, 2011 at 5:01 AM, Chris Lilley <chris@w3.org> wrote:
>> On Wednesday, May 4, 2011, 11:29:45 PM, Rik wrote:
>> 
>> RC> Thank Erik!I didn't know that this was a replacement for the current spec.
>> 
>> RC> So far, I think these are the following proposed changes:
>> RC> - remove section 6, the filter effects region
>> RC>  - remove backgound-image and background-alpha
>> RC> - remove section on the enable-background keyword
>> RC> - change default behavior of an unknown filter to 'ignore' instead of the 'null filter'
>> RC>  - remove filters that create an image and move them to the
>> RC> image-values spec (ie feTurbulence)
>> RC> - remove the feComposite filter and replace with the CSS/SVG compositing spec
>> 
>> Given that your first sentence quoted above makes clear that you understand that this is a replacement spec that covers both HTML/CSS as well as SVG (and SVG/CSS) usage - please provide an analysis of the impact of such *radical* changes to existing on existing uses of SVG filters.
>> 
>> 
> 
>