Re: Filters spec: CSS vs SVG

On Fri, May 6, 2011 at 5:54 PM, Dean Jackson <dino@apple.com> wrote:

> 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>.
>
>
I was thinking more along the line of HTML vs SVG. For instance, SVG has <g>
that is used for grouping but there is no such thing in HTML (almost
everything could be a group in that world). At some point we will have to
create a similar grouping concept in HTML.
I know there's already implied grouping when you use transforms or
animations, but I'm unsure if this is already formalized.

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

There was a discussion between you and Tab Atkins about this under the title
'generators in filters'.
I thought the consensus was to move these to the image values module. Are
you suggesting instead that they are available in images values and filters?

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

After reading a bit more on this filter, I agree.


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