Re: Filters spec: CSS vs SVG

On 11/05/2011, at 9:50 AM, Rik Cabanier wrote:

> Hi Tab,
> 
> the fact that these image producing filters can be pulled in through the feComposite filter means that they're still needed in the new spec.

Maybe via feImage, with some way to express the src as a CSS Image Value? Otherwise it might be worth providing elements for the generators.

> Maybe the same filter syntax can be in place in both specifications.
> 
> Rik
> 
> On Mon, May 9, 2011 at 2:29 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> On Mon, May 9, 2011 at 10:48 AM, Rik Cabanier <cabanier@gmail.com> wrote:
> > On Fri, May 6, 2011 at 5:54 PM, Dean Jackson <dino@apple.com> wrote:
> >> 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?
> 
> Yes, all existing filters should remain, as SVG filters.  In the CSS
> syntax, they're accessible simply by the url() function.
> 
> However, the filters that are just image servers, like feTurbulence,
> won't get a facelift as CSS functions in the Filters spec; instead,
> they'll be part of the Image Values spec, which is the correct place
> to define new image servers in CSS.  (Their current existence as SVG
> Filters appears to be a historical accident, possibly as a result of
> SVG not quite unifying its notion of what an image server is.)

SVG always had paint servers: solid colors, gradients and patterns. It's true that the image generators in filters were never exposed as paint, because they were intended as filter inputs. You probably would rarely want to paint your entire object with raw turbulence - you nearly always put a tint on it (ie. filter).

Dean