Re: [css3-text] Should text-shadow have 'spread'?

On Jan 30, 2012, at 4:21 AM, Brad Kemper wrote:

> I just caught up to the existence of this whole thread. I'm down to 92 unread www-style messages in my inbox...
> 
> More below:
> 
> On Jan 23, 2012, at 11:56 AM, Simon Fraser wrote:
> 
>> On Jan 23, 2012, at 11:43 AM, Tab Atkins Jr. wrote:
>> 
>>> On Mon, Jan 23, 2012 at 11:26 AM, Simon Fraser <smfr@me.com> wrote:
>>>> I don't think 'spread' should apply to text-shadow, yet CSS3 Text suggests that text-shadow follows box-shadow <http://dev.w3.org/csswg/css3-text/#text-shadow>.
>>>> 
>>>> For rectangles and rounded-corner rectangles, 'spread' is easy to implement by insetting or outsetting the rectangle bounds. For arbitrary shapes, spread is vastly more difficult to implement, requiring either some complex path math, or pixel-based computations that are expensive to do at drawing time. There are also complexities related to whether spread makes sharp corners rounded etc.
>>> 
>>> WebKit already has text-stroke, which should be nearly the same thing
>>> as a spread.
>>> 
>>> If we don't have spread, authors will continue to hack it into working
>>> with 4 or 8 text-shadows, which has some visual glitches and isn't
>>> great for performance.
>> 
>> If we can define the rendering of text-shadow with 'spread' to be equivalent to shadowing text with an enlarged stroke value, then that's OK, but I'm afraid that might give unexpected results because of miter joins (resulting in long spiky bits), winding rules (resulting in unexpected holes) etc.
> 
> When I suggested "spread" for box-shadow, I had in mind that it would be especially useful for text-shadow, but we weren't working on text-shadow at the time. Blurred text is much more likely to blur away the thin strokes while leaving heavy, more opaque spots behind in other areas. Spread can help with that. Spread can also make the shadows themselves more readable, if the text is transparent or far away, for an artistic effect. There are also nice specular highlight effects that could be achieved by using negative spread with little or no blurring, not to mention complex embossing effects involving multiple text-shadows with varying amounts of spread and blur and offsets. 
> 
> I also do not see mention of 'inset' in the text-shadow spec. Inner shadows in display text is a great effect for design, and also for the embossing effects mentioned above.
> 
> Here is someone who found a hacky way to get inner shadows in Webkit:
> http://www.gordonhallart.com/blog/2011/04/27/creating-a-true-inset-text-effect-using-css3/
> 
> And here is my post to a previous discussion we had about both inner shadows and spreads in text-shadow:
> http://lists.w3.org/Archives/Public/www-style/2011Mar/0017.html
> 
> In the picture I linked to in that post...
> http://www.bradclicks.com/cssplay/hello.png
> ...the 3D effect of the second example could have been done more convincingly if the inner shadows had some negative spread, so that more blur could be used on each without also intruding from opposite sides. 

I have no objection to 'inset' on text-shadow, as I think it is possible to implement relatively easily.

> There are more replies in that thread. My feeling is that spread should be roughly equivalent to adding strokes to the shadow before blurring. Miter joins are not needed, and should not be included (possibly added in some future version with an additional keyword), and we could stick with round joins. Remembering that the effect is primarily to create something that looks like shadows, and will often be blurred, rounded joins are more often than not completely appropriate. I think the main use-case for mitered joints is when someone wants to use text-shadow as a hack for text border effects, and we don't need to optimize for that.
> 
> I don't know why winding rules would be a problem; if the glyph is drawn correctly, then the shadow should be drawn correctly too, as it is just the same shape, with the same counter spaces, thickened up with a stroke of the same color, then color opacity applied, and then the whole thing blurred. There might be opacity problems if the shadows are applied one glyph at a time and the glyph shadows overlap (creating areas of double opacity), but that it a relatively minor problem that is corrected by applying the shadows once for entire spans of text instead of one glyph at a time.

I mentioned winding issues because I played around with using -webkit-text-stroke and text-shadow on fonts like Zapfino, and saw some unexpected behavior, like the dots of 'i's not having shadow for some reason.

box-shadow allows negative spread. Would you simulate that on text-shadow by taking the inner edge of the stroke?

If we're going to define spread behavior for text-shadow based on stroking, I think we should do the same for box-shadow, and specify the miter behavior.

Simon

Received on Monday, 30 January 2012 09:33:40 UTC