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

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

From: Lea Verou <leaverou@gmail.com>
Date: Mon, 30 Jan 2012 12:38:11 +0200
Message-ID: <4F267313.5090206@gmail.com>
To: Simon Fraser <smfr@me.com>
CC: Brad Kemper <brad.kemper@gmail.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, "www-style@w3.org list" <www-style@w3.org>
 
>> 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.
As an author, I would expect round joins too.

>> 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.
That's not a problem that's specific to spread radius. It's present currently as well, when letter-spacing is tight [1].

> box-shadow allows negative spread. Would you simulate that on text-shadow by taking the inner edge of the stroke?
Adobe Illustrator has an "Offset path" feature, which accepts both positive and negative offsets. Not sure what exact algorithm they use, but I think that's the kind of behavior most authors would expect (with "round join" selected).
If I had to reverse engineer it, I'd say it works by adding or subtracting strokes, just like you described.


[1]: http://dabblet.com/result/gist/1703763/


-- 
Lea Verou (http://lea.verou.me | @LeaVerou)
Received on Monday, 30 January 2012 10:38:45 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:49 GMT