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 04:29:30 -0600
To: fantasai <fantasai.lists@inkedblade.net>
Cc: www-style@w3.org, "L. David Baron" <dbaron@dbaron.org>
Message-id: <84B9FD1B-3D01-4320-8357-E91E64430293@apple.com>

On Jan 22, 2008, at 4:05 PM, fantasai wrote:

> David Hyatt wrote:
>> In WebKit, we don't really have any control over when the shadow  
>> paints.  It is drawn as a side effect of another drawing operation  
>> (in this case the drawing of the text itself).  Therefore it is not  
>> drawn by the parent element for us.  It's drawn by the same  
>> operation that draws the text glyphs.
>> I'd kind of prefer that this paint order either match what we do or  
>> remain unspecified, since we really don't have any choice here.
>> It's important to understand this concept that shadows are a  
>> byproduct, cast by an actual drawing operation.   It's just  
>> sensible graphics API to have the shadow drawn at the same time the  
>> actual drawing operation occurs so that the antialiasing etc. can  
>> be handled smoothly where the shadow meets the glyphs.
>> I think we might be able to clip out the glyphs and draw (i.e., the  
>> hack we did for box-shadow), but that would probably look bad at  
>> the edges of the clip (as box-shadow looks bad today in WebKit).
>
> Ok, I've added the following text:
>
>  # The shadow must be painted behind the element's text but in front  
> of
>  # its visible background. UAs should avoid painting text shadows over
>  # text in adjacent elements belonging to the same stack level and  
> stacking
>  # context.
>
> Does that make sense?
>

You should cut the last sentence.  The rest is about as specific as I  
think you want to get.

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

dave
(hyatt@apple.com)
Received on Wednesday, 23 January 2008 10:29:51 GMT

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