W3C home > Mailing lists > Public > www-style@w3.org > March 2011

Re: [css3-background] Default shadow color

From: Brad Kemper <brad.kemper@gmail.com>
Date: Fri, 11 Mar 2011 14:30:44 -0800
Message-Id: <1A168C2E-C715-48AB-8F2C-20E350D4D489@gmail.com>
Cc: Lea Verou <leaverou@gmail.com>, fantasai <fantasai.lists@inkedblade.net>, "www-style@w3.org" <www-style@w3.org>
To: "L. David Baron" <dbaron@dbaron.org>


On Mar 11, 2011, at 10:15 AM, "L. David Baron" <dbaron@dbaron.org> wrote:

> On Friday 2011-03-11 07:19 +0200, Lea Verou wrote:
>> Just wanted to point out that shadow interpolation from (or to)
>> 'none' (the initial value) is also undefined.
>> This results to each browser doing a different thing:
>> http://jsfiddle.net/leaverou/3gw4K/
>> - Webkit ignores inset until the transition is finished
>> - Opera doesn't transition at all
>> - Gecko seems to get it right (right as in looks smooth and not weird)
> 
> I think, depending on how you interpret the spec, it may or may not
> be defined.  The transitions spec currently says:
>  # shadow: interpolated via the color, x, y and blur components
>  # (treating them as color and numbers where appropriate). In the
>  # case where there are lists of shadows, the shorter list is
>  # padded at the end with shadows whose color is transparent and
>  # all lengths (x, y, blur) are 0. 
> 
> When I implemented this in Gecko, I assumed that 'none' was a list
> of length 0, and the rule for handling uneven-length lists applied.

That is a very reasonable interpretation. 

> But we should probably state that explicitly.

I agree. 

> The other interesting edge cases are:
> 
> * animation between inset and not-inset.  We refuse to animate,
>   which I think is probably the best choice.

My preference is to have a midpoint of 0 0 0 0 for the offsets, blur, and spread, while transitioning the color normally. 

> * animation between an item with a color and an item without (which
>   ties in to the other recent discussion about what the default
>   color for a shadow ought to be).  We also refuse to animate here.

I would have thought you'd animate between the color and currentColor, but if that other discussion results in any change, that should make the choice here clear too. if I understand what you are saying below, you'd probably prefer if we just made color a required value for shadows. 

>   (And I think we probably handle animation of an item without a
>   color against a missing item incorrectly, since we don't do the
>   fade from transparent correctly.)  I'm not sure what the right
>   thing here is, and I'd need to think further about how hard it
>   would be to extract the correct computed value if we're using
>   'currentColor' for the no-color case.  It's probably pretty hard
>   if we're going to stick to our current no-color behavior for
>   shadows, which is to use 'currentColor' *and* to inherit it as
>   'currentColor', e.g., in
>     <p style="text-shadow: 3px 3px">
>       hello <span style="color:green">hello</span>
>     </p>
>   I think that behavior is incorrect according to the "Computed
>   Value:" line in css3-text (for text-shadow), but correct
>   according to the "Computed Value:" line in css3-background (for
>   box-shadow).  Those "Computed Value:" lines should probably be
>   consistent...
> 
> -David
> 
> -- 
> L. David Baron                                 http://dbaron.org/
> Mozilla Corporation                       http://www.mozilla.com/
> 
Received on Friday, 11 March 2011 22:31:25 GMT

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