RE: Filters spec: CSS vs SVG

Hi Dean,

 

In terms of what I've used enable-background for, it seems pretty essential
for using feDisplacementMap, which I think most who have used it would argue
is both one of the coolest and most useful of all the filters:

 

http://www.w3.org/Graphics/SVG/IG/resources/svgprimer.html#feDisplacementMap


 

Several examples there can be seen.

 

In addition to non-linear warping, it can be used for memory conservation in
jig-saw puzzles, forcing shapes (like the text of corporate logos) into
other shapes, simulated 3D animation (e.g.
http://srufaculty.sru.edu/david.dailey/svg/eggcloning3.svg )  and pond
ripples (e.g. http://srufaculty.sru.edu/david.dailey/svg/waves.html ) .

 

For many years I have argued that feDisplacement is the best part of SVG
filters, and I have believed myself when I did so! Opera and IE/ASV have
supported this for some years and some interesting content involving them
and especially the 3D stuff they enable has begun to emerge in less
experimental and more practical areas, I believe. There were some cool demos
at SVG open 2009 I think. I'm not sure how to do this without enable
background, though I'm writing off the top of my head here, and may be
proven wrong.

 

You ask what I do when browsers don't support it.  I do what I've done for
several years when browsers don't do things: I tell folks which browsers do
and which don't support it. This behavior has been pretty consistent among
authors for the past 10 years, I think. Fallback content for browser
inconsistencies in the SVG world has been sort of like hitting a moving
target - browsers have been catching up fast in the past few years but
trying to program around it (as with some of Erik and Vincent's wonderful
work) puts more burden on authors than I would be content advising learners
to do. That's what specs are for!

 

cheers

David

 

 

From: Dean Jackson [mailto:dino@apple.com] 
Sent: Friday, May 06, 2011 8:58 PM
To: David Dailey
Cc: 'Rik Cabanier'; 'Chris Lilley'; 'Erik Dahlstrom'; public-fx@w3.org;
'www-svg'; 'Jon Frost'
Subject: Re: Filters spec: CSS vs SVG

 

 

On 07/05/2011, at 10:51 AM, David Dailey wrote:





If Rik's summary here is consistent with what other folks are saying, then
I'm happy, and the urgency of my previous message can be deleted!

 

Even though my reply slightly disagrees with some parts of Rik's summary, I
believe you can "remain calm and carry on".

 

The one exception might be if you're making a lot of use of
enable-background, in which case the group would be probably interested to
know which implementation you're using, and what you do with the content in
implementations that do not support it.

 

Dean

 





 

cheers

David

 

From: www-svg-request@w3.org [mailto:www-svg-request@w3.org] On Behalf Of
Rik Cabanier
Sent: Friday, May 06, 2011 8:39 PM
To: Dean Jackson
Cc: Chris Lilley; Erik Dahlstrom; public-fx@w3.org; www-svg
Subject: 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.