W3C home > Mailing lists > Public > www-style@w3.org > November 2007

Re: [CSS3 Text] shadow stacking levels

From: David Hyatt <hyatt@apple.com>
Date: Sat, 03 Nov 2007 03:35:49 -0500
To: fantasai <fantasai.lists@inkedblade.net>
Cc: www-style@w3.org
Message-id: <DB63A502-7271-44E8-B25C-7B01B0CE5481@apple.com>

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


On Nov 3, 2007, at 12:03 AM, fantasai wrote:

> Unlike text-decoration, text-shadow according to its current CSS3  
> Text definition
> inherits and is painted by each text run's parent element. With  
> that premise,
> given the style rule
>   span { text-shadow: ...; }
> the HTML snippets
>   <span>sometext</span>
> and
>   <span>some</span><span>text</span>
> won't be rendered the same: the shadow of the next element will  
> overlap the
> foreground text of the previous. That just looks wrong. Is there some
> way to specify text-shadow so that that doesn't happen?
> ~fantasai
Received on Saturday, 3 November 2007 08:36:10 UTC

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