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

[fantasai:]
> 
> 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; 
L4 of what? Text? Is L3 Text that close to LC/CR ? I don't think it's very
author-friendly to ship a prefixed version of the property just for spread. 
And as long as the values we parse are a superset of what is conformant I'd 
rather keep our support for spread, to be honest.

>we all agree on what the syntax should be, but figuring out exactly how 
> it works seems to require a bit more discussion. 

Is there a reason not to start the discussion now?

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

If that was the goal then why did we change the draft back in 2010 to say that
values are interpreted as for box-shadow when the latter includes values like
spread and inset ? 

>That way it's more obvious that there are
> implementations that don't support the fourth value.

I don't quite follow what this means. The current draft refers to box-shadow
which has a 4th value. Some implementations support it in text-shadow, some
don't, as can happen with a draft. If the concern is that there are already
multiple unprefixed implementations of text-shadow with no spread and we'd rather
snapshot that definition in L3 then we had no business taking a dependency on 
box-shadow two years ago. Either way I don't care about making it 'more obvious' 
what 'some implementations' do; we need to resolve that the interoperable, testable
 definition of text-shadow should be in L3 Text REC. 
> 
> ~fantasai
>

Received on Tuesday, 24 January 2012 01:15:12 UTC