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

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

From: Brad Kemper <brad.kemper@gmail.com>
Date: Mon, 30 Jan 2012 07:34:35 -0800
Message-Id: <FA4D6BE0-9CF1-437C-81A2-5B3987773F5C@gmail.com>
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, "www-style@w3.org list" <www-style@w3.org>
To: Simon Fraser <smfr@me.com>
On Jan 30, 2012, at 1:31 AM, Simon Fraser <smfr@me.com> wrote:

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

Weird. So, the stroke was OK, and the shadow included the stroke weight in general, but the dot (which perhaps ended up with more stroke that fill showing, or maybe had stroke overlapping itself) disappeared from the shadow? It's strange, but it doesn't sound like the sort of bug the spec would have to deal with.

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

Yes. If the stroke is centered on the path, then the inner edge of the stroke would be equivalent to a negative offset.

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

I thought we more or less did so, describing how the 90deg corners remain sharp before blurring takes place.
Received on Monday, 30 January 2012 15:35:16 GMT

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