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

Re: Gradient syntax proposal

From: Brad Kemper <brad.kemper@gmail.com>
Date: Fri, 14 Aug 2009 16:24:46 -0700
Message-Id: <BB3ED5A8-DDB1-4168-AB43-65C5F0C7F425@gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: fantasai <fantasai.lists@inkedblade.net>, "www-style@w3.org" <www-style@w3.org>


Sent from my iPhone

On Aug 14, 2009, at 3:16 PM, "Tab Atkins Jr." <jackalmage@gmail.com>  
wrote:

> On Fri, Aug 14, 2009 at 4:57 PM, Brad Kemper<brad.kemper@gmail.com>  
> wrote:
>> On Aug 14, 2009, at 1:47 PM, fantasai  
>> <fantasai.lists@inkedblade.net> wrote:
>>> Brad Kemper wrote:
>>>>
>>>> On Aug 13, 2009, at 4:35 PM, Tab Atkins Jr. wrote:
>>>>>
>>>>> Just linear gradients for now:
>>>>>
>>>>>
>>>>> http://www.xanthir.com/document/document.php? 
>>>>> id= 
>>>>> d65df9d10442ef96c2dfe5e1d7bbebf7aa42f2bcf24e68fc3777c4b484fa8a4ce55fed2189cac20ccad8686127f4c08917c4ca8b7614e9f89c2a950ec083a9c6
 

>>
>>
>>>>>
>>>>> ~TJ
>>>>>
>>>> I won't get into my objections to [inner | outer] right now, but  
>>>> about
>>>> the rest of this:
>>>
>>> We could make the default 'outer', which should address your  
>>> concerns, no?
>>
>> If others really think this is necessary and are willing to add  
>> this extra
>> complexity, yes.
>
> I've changed the default to 'outside'.
>
> If implementors don't like it, I can always remove the keyword.  I
> just think it would be useful to me.
>
>>> I'd use the keywords 'inside' and 'outside', btw. I think they fit  
>>> better,
>>> and also they're already in the parsing system (for list-style- 
>>> position).
>>>
>>>> One of the things I really hate about using "<bg-position>,
>>>> <bg-position>" is that comma to separate the two lengths or  
>>>> keywords on the
>>>> left from those on the right. Since commas are already being used  
>>>> to
>>>> separate color-stops, this just makes the whole thing harder to  
>>>> read,
>>>> because they are no longer used consistently to group like  
>>>> things. When they
>>>> are used only for color-stops, then you can see in a glance how  
>>>> many
>>>> color-stops there are instead of having to study it more closely  
>>>> with a line
>>>> full of distances and commas. For instance, I find the following  
>>>> very hard
>>>> to read, and it probably doesn't even make sense (which is  
>>>> another problem
>>>> with this kind of construction). |linear-gradient(10px 30%, 100%  
>>>> 4%, 50%
>>>> green, 20% blue)|
>>>
>>> I completely agree. How about using a keyword?
>>>
>>>  linear-gradient(10px 30% to 100% 4%, green, blue 20%, navy);
>>
>> Do you really think people will really need to start on such a  
>> precise xy
>> point instead of just some distance or percentage from the corner?  
>> I don't,
>> but maybe calc() can be used to figure that distance from the corner.
>>
>> If I wanted to start say, 30% from the top, and end at the bottom,  
>> I would
>> write that as "linear-gradient(top, green 30%, blue 20%, navy)". Or  
>> if I
>> wanted to be a few degrees off from straight down, I would do
>> "linear-gradient(-87deg, green 30%, blue 20%, navy)". I think these  
>> are both
>> much cleaner, and provide all that an author will really need.
>
> All right, changed my mind.  That looks confusing as *hell*.  It looks
> like you meant to write "blue 20%, green 30%, navy" but swapped them
> for some reason.

What? Why? Wasn't green her first color? Wasn't it supposed to start  
30% from the top?

> I don't like it at all.

Mine was simpler.

>
>>>  linear-gradient(left to right green, 50% blue, 100% navy);
>>
>> That's very close to what I suggested, except for the "to right" part
>
> Yeah, but allowing the literate form (in addition to the short "left"
> form) makes a *wonderful* parallel to the full <bg-position>
> construction, so it's easy to learn and understand.  This suggestion
> from Elika was a definite win in my mind.
>
> Though, it'd be written with a "/" between the direction and the
> color-stops in my current proposal.
>
> ~TJ
Received on Friday, 14 August 2009 23:25:38 GMT

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