Re: Filter Templates

On Wed, Jan 26, 2011 at 11:24 AM, Patrick Dengler <patd@microsoft.com>wrote:

> 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 think that's what we should do. I think there will be steady creep of
common filters being added to CSS, but I think that's OK as long as the
mapping from the canned CSS filters to the SVG filter machinery is precisely
defined in every case, so implementation will be easy.


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

I've said this before and I'll say it again: for performance,
implementations already need to ignore the regions the author gave and
compute their own minimal regions. So mx/my/mw/mh should be dropped from the
spec. Furthermore, we should get rid of the -10%/-10%/120%/120% hack and say
that by default the filter region is infinite. Easier for authors, easier
for implementors.

Rob
-- 
"Now the Bereans were of more noble character than the Thessalonians, for
they received the message with great eagerness and examined the Scriptures
every day to see if what Paul said was true." [Acts 17:11]