W3C home > Mailing lists > Public > www-style@w3.org > January 2011

RE: Filter Templates

From: Patrick Dengler <patd@microsoft.com>
Date: Tue, 25 Jan 2011 22:24:48 +0000
To: Tab Atkins Jr. <jackalmage@gmail.com>, Brad Kemper <brad.kemper@gmail.com>
CC: www-style list <www-style@w3.org>, "public-fx@w3.org" <public-fx@w3.org>
Message-ID: <4A2DB3AE4504E944AF122BBFBA7FBA1F58237412@TK5EX14MBXC114.redmond.corp.microsoft.com>
I have been thinking about this as well.  I've been reading Eric's draft on SVG Filters: http://dev.w3.org/Graphics-FX/modules/filters/publish/SVGFilter.html

He has proposed (along with others?) that we introduce new primitives such as : feDropShadow.

On further reflection I've had the following thoughts:

I believe there are up to 100 (?) different 'high level-canned' effects that can be achieved via Adobe or Inkscape and composed successfully from the 17 SVG primitives.  We vaguely alluded to wanting to think about how to present the web developer with these canned effects and how they relate to SVG.  This I am sure is what led to Eric's incorporation of feDropShadow.

Would CSS eventually adopt all/most of these designer effects or limit them to only a handful (i.e. box-shadow, blur)?

My suspicion is that the primitive nature of SVG effects are unapproachable my most developers, so the most common higher level canned effects should probably be expressible in CSS proper (i.e. box-shadow).  
In order then to achieve more granular control or the wider range of designer effects, you would most likely use a tool and then incorporate that into your page and reference them as per Rob's spec and Mozilla's support or filters on HTML (I've been having fun with animating these as well).

I'm wondering if anyone else has similar thoughts.

As an additional note, I also see the introduction of mx,my,mw and mh and though the purpose seems to better performance I am wondering if I am missing something else. If it is only performance I think we need to be careful here. I've gone down the path of what is relative performance.


Patrick Dengler

-----Original Message-----
From: public-fx-request@w3.org [mailto:public-fx-request@w3.org] On Behalf Of Tab Atkins Jr.
Sent: Tuesday, January 11, 2011 10:41 AM
To: Brad Kemper
Cc: www-style list; public-fx@w3.org
Subject: Re: Filter Templates

On Tue, Jan 11, 2011 at 10:22 AM, Brad Kemper <brad.kemper@gmail.com> wrote:
> Let me begin by saying I know very little about SVG, but I am trying to slowly learn more.
> There has been talk before about "canned" SVG filter effects. I would like to propose (or at least, discuss the merits of) accomplishing this via a templating element inside the filter element, that defines what values it takes from the CSS declaration.

> Thus, for the following SVG filter that defines a certain drop shadow effect:
>        <filter id="bradsDropShadow" x="0" y="0" width="1" height="1"
>                          filterUnits="userSpaceOnUse">
>                  <feTemplate values="feFlood.flood-color && 
> [feOffset.dx feOffset.dy feGaussianBlur.stdDeviation]"/>
>                  <feFlood flood-color="black" in="SourceAlpha" 
> result="Colorized" />
>                  <feGaussianBlur stdDeviation="2" in="Colorized" />
>                  <feOffset dx="2" dy="2" />
>                  <feMerge>
>                           <feMergeNode />
>                           <feMergeNode in="SourceGraphic" />
>                  </feMerge>
>        </filter>
> Given the above "feTemplate" values, it could be used in a declaration like this:
> filter: url(#bradsDropShadow) 4px 5px;
> ...and the two lengths would be mapped to the "dx" and "dy" of feOffset.dx, and the omitted values would take their default values from the regular filter values ("black" for flood-color and "2" for stdDeviation in the above example), as long as the order and so forth of the feTemplate values were satisfied.
> Could that work?

I like the idea, though I'm much more iffy on the syntax.  But overall, sounds pretty good.


Received on Tuesday, 25 January 2011 22:26:26 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:55 UTC