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

Re: [css3] support for filters

From: Alan Gresley <alan@css-class.com>
Date: Thu, 06 Jan 2011 17:05:26 +1100
Message-ID: <4D255BA6.8090804@css-class.com>
To: Rik Cabanier <cabanier@adobe.com>
CC: Simon Fraser <smfr@me.com>, Cameron McCormack <cam@mcc.id.au>, Charles Pritchard <chuck@jumis.com>, "ed@opera.com" <ed@opera.com>, "www-style@w3.org" <www-style@w3.org>
On 6/01/2011 4:13 PM, Rik Cabanier wrote:
>> [1] so I have argued that the same should apply for box-shadow
> There is a good description of this on
> http://www.bradclicks.com/cssplay/drop-shadow/Drop-Shadow.html The
> name 'box'-shadow does imply that you're adding a shadow to an
> element's bounding box so drop-shadow is probably what you're looking
> for...

Brad's drop-shadow concept (like my concept) was debated in 2008 on this 
list [1]. What I looking for is box-shadow that does both. The CSS WG 
decided that shadows should be masked. Since the current grammar and 
syntax is in the wild and un-prefixed, the only way of doing this now is 
something like this.

   box-shadow: 10px 10px 10px 0 <color> cast;

Without the keyword 'cast', the initial value would be mask.


Inner box-shadow should always be masked since they do behave somewhat 
like highlights but at the same time, there should be a way to achieved 
negative spread (Brad just didn't understand the concept).

   box-shadow: 10px 10px 0 -5px <color> inset;


This would create highlights as seen here [2] (the white light 
reflecting from the spheres). It would create a inset shadow that is 
smaller than the box that has the inset shadow. This list message [3] 
give a little insight in highlights with box shadow.


>> [2]. I don't agree that a shadow of a parent element should cast a
>> shadow upon it's children (wouldn't make sense) but I do believe
>> the shadow of a parent element should be seen through the
>> background of the parent or children if they have semi-transparent
>> backgrounds.
> True. When you apply a filter to an element, you need to create a
> bitmap of the element and all its children. Then you calculate the
> shadow using this bitmap. Then the shadow bitmap is put on the stage
> followed by the original bitmap. (The element with the filter is
> called an isolated group in PDF speak). With this approach the
> children won't cast shadows on each other but they will interact with
> the shadow if they contain opacity.


No, if the source order is altered (negative margins, etc), then shadows 
appear over sibling elements. This list message [4] cover this somewhat. 
The interplay of the shadow in this svg document,

http://css-class.com/test/svg/shadow-transparent-background.svg

is totally govern by the source order. If the rect with the salmon 
background appears later in the source than the other rect elements, 
then it would be painted higher and partially cover both the transparent 
yellow box and the shadow.


>>> Text-shadow probably was introduced to work around that issue.
>> What issue?
> The issue that box-shadow only adds a shadow to an element's box and
> not to its content.
>
> Rik


A shadow of a box should not be cast over the contents of it.


1. <http://lists.w3.org/Archives/Public/www-style/2008May/0165.html>
2. <http://en.wikipedia.org/wiki/Global_illumination>
3. <http://lists.w3.org/Archives/Public/www-style/2008May/0221.html>
4. <http://lists.w3.org/Archives/Public/www-style/2008Jan/0483.html>



-- 
Alan http://css-class.com/

Armies Cannot Stop An Idea Whose Time Has Come. - Victor Hugo
Received on Thursday, 6 January 2011 06:07:00 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:35 GMT