W3C home > Mailing lists > Public > www-style@w3.org > August 2009

Re: Gradient syntax proposal

From: Brad Kemper <brad.kemper@gmail.com>
Date: Mon, 17 Aug 2009 13:46:59 -0700
Message-Id: <18DF7477-4FB1-4261-89D9-18C46A80E9FB@gmail.com>
To: David Perrell <davidp@hpaa.com>
Cc: fantasai <fantasai.lists@inkedblade.net>, "Tab Atkins Jr." <jackalmage@gmail.com>, "<www-style@w3.org>" <www-style@w3.org>
I kind of like this idea.

On Aug 17, 2009, at 11:27 AM, "David Perrell" <davidp@hpaa.com> wrote:

> fantasai wrote:
> | I would prefer restricting stops to percentages. The swapping effect
> | is confusing, and I don't see any reason you'd /need/ to use lengths
> | when you can specify the length of the overall gradient already.
> Let's say I want to ensure that the first 2 stops of a vertical  
> gradient span a distance based on em dimensions. The 3rd should be  
> 50% of the remaining length. So, with current proposals, I want:
> linear-gradient: top / aqua, darkblue 1em, darkblue 2em, aqua calc(. 
> 5 *(100%-2em)), blue;
> If the element height becomes less than 4 em, this is going to  
> become totally corrupted if ascending order isn't enforced. I would  
> rather have it degrade to a sharp delineation between darkblue and  
> aqua.
> Perhaps a better option is to allow mixed location dimensions and  
> require locations in order, but say that <percentage> between  
> <length> locations applies to the span between the <length>  
> locations. I believe that would solve all the degradation issues and  
> simplify the spec. If this were the case, what's desired above would  
> be spec'd like this:
> linear-gradient: top / aqua, darkblue 1em, darkblue 2em, 50%, blue;
> 50% applies to the halfway point between 2em and the end point.
> This not only makes sense, it will never degrade into something  
> totally unlike what's desired. And if you do use all the same types,  
> it will be exactly as if the same types were *required* with the  
> current proposals.
> David Perrell
Received on Monday, 17 August 2009 20:47:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:38 UTC