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

Re: [CSS3 Text] shadow stacking levels

From: David Hyatt <hyatt@apple.com>
Date: Wed, 23 Jan 2008 14:30:09 -0600
To: Alan Gresley <alan1@azzurum.com>
Cc: fantasai <fantasai.lists@inkedblade.net>, www-style@w3.org, "L. David Baron" <dbaron@dbaron.org>
Message-id: <97583A06-FB57-4386-9702-E6C7B7B5A695@apple.com>

On Jan 23, 2008, at 11:49 AM, Alan Gresley wrote:

> fantasai wrote:
>
>>> <span>Hello</span><span style="margin-left:-20px;">world</span>
>>>
>>> In the above example, if I put a text-shadow on the span with the
>>> negative margin, the shadow is going to overlap the text in the  
>>> previous
>>> adjacent span, since the text already overlaps.
>>>
>>> Even ignoring this issue, like I said before, in our  
>>> implementation the
>>> shadow draws at the same time as the text.  It is a byproduct of the
>>> text drawing operation.  Even without the negative margin, an offset
>>> could be specified that has the shadow of the second span drawing  
>>> on top
>>> of the text in the first span.
>>
>> Yes, that second effect is something I think UAs should be  
>> encouraged to
>> avoid. Putting an invisible element boundary in the text shouldn't  
>> cause
>> the shadow to, for no visually apparent reason, stack over  
>> preceding text.
>> I understand that doesn't work nicely in your implementation;  
>> that's fine,
>> that's why it's a should and not a must.
>>
>> ~fantasai
>
>
> The 'visually apparent reason' for drawing a shadow that way is that  
> that's what a shadow does. A tree will cast it shadow over the grass  
> below. So elements later in the source will cast a shadow over  
> elements earlier in the source.  So depending on the source order,  
> shadows can behave as just described or only cast a shadow under  
> itself. A use case is a well known layout with two floats one with a  
> negative margin.
>
> http://css-class.com/test/css/drop-shadows/drop-shadow-over- 
> element.htm
>
>
> Please view in Safari. If the blue float doesn't cast it shadow over  
> the pale yellow float, how am I to draw that shadow? I hope not with  
> background images.
>
>
> Alan

This is a good example that illustrates my point.  Thanks!

I understand that the sentence says "should," but I still think it  
needs to be removed.  No implementation is going to actually try to  
see if the shadow intersects the glyphs of other text in the document  
and clip it out if that is the case.  That would be way too slow....  
and any implementation that tries to draw the shadows as a separate  
layer entirely behind other foreground content should be deemed  
incorrect in my opinion, since doing so would break Alan's example.

SHADOWS ARE NOT LIKE BACKGROUNDS. They should not draw in a separate  
phase just so that they can sit behind all backgrounds/borders in the  
same stacking context (box-shadow) or sit behind all foreground  
content in the same stacking context (text-shadow).  The "should"  
sentence mplies that you wish the drawing worked this way, but it  
doesn't.

In Alan's example, the box-shadow draws with the border/background of  
the box, and so the shadow of the later box is naturally cast over the  
background/borders of the previous box.  That is how shadows should  
work.

dave
(hyatt@apple.com)
Received on Wednesday, 23 January 2008 20:30:24 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:58 GMT