Re: Filters spec: CSS vs SVG

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

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
- mark the feComposite filter as only applying to SVG. A future CSS/SVG
compositing spec can address this better.

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