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

Re: Jan 10 2011 FXTF telcon cancelled

From: David Singer <singer@apple.com>
Date: Tue, 11 Jan 2011 17:13:08 +0100
Cc: Dirk Schulze <vbs85@gmx.de>, public-fx@w3.org
Message-Id: <3FC1454E-CEF7-42F6-A911-6BB6068625BA@apple.com>
To: Erik Dahlstrom <ed@opera.com>
any hopes we could get an indicative subject line on this thread? I nearly missed it, thinking it was about a telecon and not a technical subject :-(

On Jan 11, 2011, at 16:55 , Erik Dahlstrom wrote:

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

David Singer
Multimedia and Software Standards, Apple Inc.
Received on Tuesday, 11 January 2011 16:14:17 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 11 January 2011 16:14:17 GMT