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 15:29:35 -0600
To: fantasai <fantasai.lists@inkedblade.net>
Cc: Alan Gresley <alan1@azzurum.com>, www-style@w3.org, "L. David Baron" <dbaron@dbaron.org>
Message-id: <123A3611-FC52-48E1-9194-BC5819AF00B5@apple.com>

On Jan 23, 2008, at 6:02 PM, fantasai wrote:

> I want to see this:
>  <p style="text-shadow: xxx;">Some text</p>
> and this
>  <p style="text-shadow: xxx;">Some <span>text</span></p>
> where the span has no styling applied to it whatsoever, be rendered  
> exactly
> the same. I think that's a reasonable expectation. If the author  
> desires
> some kind of layering effect, he can use position: relative; and z- 
> index to
> make the span move forward in the stacking order. If you can't do it  
> in your
> implementation, that's fine, I'm not proposing to require it. I'm only
> proposing to recommend it.
> There are different ways to optimize text rendering, and it's entirely
> plausible that a layout engine will collect together cross-element  
> runs
> of text that share the same styling and send the entire run to the  
> text
> renderer at once. In such a case, the shadows will not overlap as in  
> your
> implementation.

Sure.  That's even an optimization that I expect we will implement  
soon.   This is exactly why I think it's dangerous to over-specify how  
text shadows draw  (box-shadow is at much more predictable, since when  
borders/backgrounds draw is very well-specified).  Because shadows are  
tied to the exact drawing operations you make, you really can't  
guarantee how a browser will render the text shadows in those examples  
if the shadows overlap adjacent text.

I still take issue with the "should" sentence, though, in the case  
where spans are deliberately overlapping (obviously the shadow has no  
reason to avoid drawing over the other span's text in the negative- 
margin case).

Received on Wednesday, 23 January 2008 21:29:49 UTC

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