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

http://www.w3.org/TR/2011/CR-css3-background-20110215/
# Value: none | <shadow> [, <shadow>]*
# <shadow> = inset? && [<length>{2,4} && <color>? ]

http://dev.w3.org/csswg/css3-text/#text-shadow
# Value: none | [<length>{2,3} && <color>?]#
# Values are interpreted as for 'box-shadow' [CSS3BG].

The second sentence is very quickly becoming more confusing than useful.

It might be better to move the 1st, 2nd, 3rd, and 5th bullet under "The components of each <shadow> are interpreted as follows:" from Backgrounds/box-shadow to Text/text-shadow and then make Box-shadow say...
# Values are interpreted as for 'text-shadow' [CSS3Text] with additional parameters (4th length and inset keyword) described below.

-----Original Message-----
From: fantasai [mailto:fantasai.lists@inkedblade.net] 
Sent: Monday, January 23, 2012 2:54 PM
To: www-style@w3.org
Subject: Re: [css3-text] Should text-shadow have 'spread'?

On 01/23/2012 02:02 PM, Sylvain Galineau wrote:
>
> [Simon Fraser:]
>>
>> 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.
>>
> Current IE10 builds support it so we'd certainly like to propose that it
> does. It's author-friendly from a consistency standpoint in that it makes
> the shadow syntax consistent with box-shadow.

I think we should leave it in the L4 draft; we all agree on what the syntax
should be, but figuring out exactly how it works seems to require a bit more
discussion. Also, the CSS2.0 version did not include a spread radius, and
since this spec is the replacement for that, I think we should just include
the 2.0 features. That way it's more obvious that there are implementations
that don't support the fourth value.

~fantasai

Received on Monday, 23 January 2012 23:53:21 UTC