W3C home > Mailing lists > Public > public-fx@w3.org > January to March 2011

Re: Jan 10 2011 FXTF telcon cancelled

From: Erik Dahlstrom <ed@opera.com>
Date: Tue, 11 Jan 2011 16:55:53 +0100
To: "Dirk Schulze" <vbs85@gmx.de>
Cc: public-fx@w3.org
Message-ID: <op.vo5ijcbqgeuyw5@localhost>
On Tue, 11 Jan 2011 15:50:37 +0100, Dirk Schulze <vbs85@gmx.de> wrote:

>
>>>
>>>> Also, I saw some discussions about the meaning of stdDeviation and  
>>>> blur radius. It would be great to harmonize all the definitions for  
>>>> CSS shadows, Canvas shadows and feDropShadow.
>>>
>>> Do you have a pointer to that discussion? I agree that it would be  
>>> good to see if it's possible harmonize the definitions.
>>
>>
>
> I'm still unsure about the sense of making feDropShadow a new filter  
> effect. The common use case will be something like that:
>
> <filter id="dropShadow">
>   <feDropShadow stdDeviation="5" dx="10" dy="10" shadow-color="black"  
> shadow-opacity="0.5"/>
> </filter>
>
> <g filter="url(#dropShadow)">
>   <rect width="30" height="30" fill="red"/>
>   <circle cx="30" cy="30" r="20"/>
>   <text x="40" y="40">SVG Filter</text>
> </g>
>
> Means just a simple drop shadow and nothing else.
>
> Are there really use cases, where we filter the result of feDropShadow?I  
> guess it will be unlikely.

Well, it's simpler to write than the corresponding  
feGaussianBlur+feOffset+feFlood etc. I think there are cases where that  
would be handy.

> On the other hand, this implementation still cause the long known  
> confusions for web developer. In many cases the shadow will be clipped  
> because of the hard clipping region of (-10%, -10%, 120%, 120%) of the  
> boundingBox of the target.

That's a separate issue, it affects all filter primitives (even if blur is  
the most common example). I think the svg filters should probably default  
to not clipping instead, e.g by introducing some sort of auto region  
calculation.

> For horizontal or vertical lines, nothing will be drawn at all, because  
> 120% of a height of 0 is still zero -> everything gets clipped away.
>
> On WebKit it is really simple to use drop shadows. We have a CSS  
> property called '-webkit-svg-shadow'. The definition is similar to  
> box-shadow:
>
> <g style="-webkit-svg-shadow: 10px 10px 5px rgba(0, 0, 0, 0.5);">
> ...
> </g>

Have you considered proposing that syntax as an extension of the 'filter'  
property instead? E.g filter: [<url> | <drop-shadow-shorthand>]

...
> Theoretically multiple shadows are possible (not yet supported by  
> WebKit), something that is impossible to do just with feDropShadow and  
> still difficult with the other effects.

I think it's possible to do:

<filter id="dropShadow">
   <feDropShadow in="SourceGraphic" stdDeviation="5" dx="10" dy="10"  
shadow-color="black" shadow-opacity="0.5" result="s1"/>
   <feDropShadow in="SourceGraphic" stdDeviation="2" dx="15" dy="30"  
shadow-color="blue" shadow-opacity="0.5" result="s2"/>
   <feDropShadow in="SourceGraphic" stdDeviation="10" dx="5" dy="20"  
shadow-color="yellow" shadow-opacity="0.5" result="s3"/>
   <feMerge>
     <feMergeNode in="s1"/>
     <feMergeNode in="s2"/>
     <feMergeNode in="s3"/>
   </feMerge>
</filter>

> Even horizontal or vertical lines get a shadow (Same for one dimensional  
> figures).

Right, that's a limitation of how objectBoundingBox units work in svg.  
Again, separate issue. I agree that that can be undesirable for filters,  
same as for gradients.
/Erik

-- 
Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed
Received on Tuesday, 11 January 2011 15:57:00 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 11 January 2011 15:57:00 GMT