W3C home > Mailing lists > Public > www-style@w3.org > May 2008

Re: box-shadow and features (was [css3-background] Issues and Proposed Resolutions)

From: Brad Kemper <brkemper@comcast.net>
Date: Thu, 15 May 2008 08:35:50 -0700
Cc: fantasai <fantasai.lists@inkedblade.net>, www-style@w3.org
Message-Id: <B766C190-8F38-4930-BCE7-8C8DA8FBEDA2@comcast.net>
To: Alan Gresley <alan@css-class.com>

On May 15, 2008, at 1:35 AM, Alan Gresley wrote:

> Brad Kemper wrote:
>> On May 14, 2008, at 4:46 PM, Alan Gresley wrote:
>>> fantasai wrote:
>>>> Alan Gresley wrote:
>>>> If an inner glow/shadow were added, then it would be painted  
>>>> inside the
>>>> padding box and not outside it. This is analogous to the way the  
>>>> outer
>>>> shadow is painted outside the border box and not inside it. :)
>>> Well doesn't that mean the inner glow/shadow is painted above the  
>>> background instead of how box-shadow works normally? :-)
>> If I understand you correctly, it would be, but I don't understand  
>> the objection. It would create a stacking context in the box,  
>> similar to the way opacity does. The element's background would be  
>> underneath the inner shadow. It is not that different conceptually  
>> from outer shadows, except that it is the negative space that is  
>> casting the effect instead of the positive space.
> Precisely, a new staking context would be created thus, your inner  
> shadow will be stacked higher than the text in the element? This is  
> what David was referring about avoiding here.
> http://lists.w3.org/Archives/Public/www-style/2008Jan/0483.html

I don't think so. David talks there about what stage the shadow draws.  
He says that you should not draw the box background, then the shadow  
for all the text, then the text. Instead the shadows are drawn one  
glyph at a time, without regard to how they intersect other glyphs.

The inner shadow would not be stacked higher that the text in the  
element. It would merely by one of the higher layers within each glyph  
of the text. I have not heard anything to indicate that this would be  
a problem any worse than opacity, text outlines, or outer shadows.

> Anyway opacity also effect the text (become lighter) inside the  
> element and the stacking context that is created.
>>>>> How are authors suppose to create depth of field if box-shadow  
>>>>> doesn't work like true shadows or highlights?
>>> Firstly you can mask the box by giving the box an opaque  
>>> background, like blue. Opacity doesn't just effect the box but the  
>>> contents of the box like text and what happen with the stacking  
>>> order and z-index?
>> z-index only effects the element as a whole, and not the stacking  
>> order of its sub-elements (sub-elements like background colors,  
>> multiple background images, border images, borders, internal  
>> shadows, etc.).
> I referring to the whole stacking context and z-index problems where  
> shadow and background can not intermingle as they now do in Safari.

I believe David Hyatt recently said that the way z-index and internal  
stacking contexts intermingle in WebKit is actually a bug.

> If new staking context's was created here and there then this would  
> be impossible do to.
> http://css-class.com/test/css/shadows/text-shadow-over-elements1.htm
>>> What about a spread that go inside the box.
>> What about it? I don't understand your point. There are some of  
>> those shown on the page referenced above, and also at this one with  
>> borders and translucent shadows (think rgba):
>> http://bradclicks.com/cssplay/Shadows2.html
> Well this is how the minus value for spread would work (I presume).  
> The darkest part of the shadow become smaller.
> ----------------
> |              |
> |              |
> |              |
> |       XXXXXXX|XX
> |       XXXXXXX|XX
> --------X-X-X-X|XX
> Thus emulating perspective.

OK. I guess. I still don't see a problem.

> Alan
Received on Thursday, 15 May 2008 15:36:35 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:36 UTC