Re: [CSS3] Some thoughts about functions, notation and gradient().

Brad Kemper wrote:
>
> On Aug 20, 2009, at 9:11 AM, Simon Fraser wrote:
>
>> On Aug 19, 2009, at 9:19 AM, Andrew Fedoniouk wrote:
>>
>>> Brad Kemper wrote:
>>>> On Aug 18, 2009, at 11:28 PM, Andrew Fedoniouk wrote:
>>>>> background-color: linear-gradient(
>>>>>                    start:0% 0%,
>>>>>                    stop: 100% 100%,
>>>>>                    color-stop: 0% white,
>>>>>                    color-stop: 50% red ,
>>>>>                    color-stop: 100% blue );
>>>> I think that is way too verbose.
>>>
>>> But human readable and machine parse-able.
>>>
>>> Proposed syntaxes I've seen so far in linear-gradient() are
>>> not readable (that is subjective of course) and not
>>> unambiguously parseable.
>>>
>>> That use of '/' as a some kind of separator with absolutely non-clear
>>> grammatic nature is very bad.
>>
>> I'm strongly in favor of the more verbose, but much more 
>> human-readable form above. Compared to that, the current suggestions, 
>> like:
>>
>> linear-gradient(30px center / 50% / green -50%, wheat -30%, wheat 
>> 30%, green 50%)
>>
>> seem like complete voodoo.
>
> I agree with not liking that vooodoo.
>
>>
>> In these days of auto-completing editors and authoring tools, 
>> conciseness isn't necessarily the primary concern. I'm much rather 
>> have a syntax that I can type without having to look it up, and can 
>> quickly visually scan without having to count slashes.
>>
>> This gradient discussion has gone on a long time, and it feels like 
>> there's is premature convergence onto a very non human-friendly 
>> syntax. It's time to step back, summarize the conversation, and boil 
>> the proposals down to a few contenders.
>
> A lot of what you are calling non-human-friendly is from adding extra 
> gewgaws for edge cases. But Andrew's example doesn't handle any of 
> those (and doesn't even indicate direction of the gradient), and 
> should be compared instead to the simplest form of what we are 
> converging around:
>
> background-color: linear-gradient(top /  white, red, blue );
Not quite. It indicated the direction even more clearly than in your case.

Here:

background-color: linear-gradient(
                   start:0% 0%,
                   stop: 100% 100%,
                   color-stop: 0% white,
                   color-stop: 50% red ,
                   color-stop: 100% blue );

Gradient line starts at position 0,0 (top-left corner) and ends at 100% 
100% (bottom-right corner).

'top' used in your notation can be interpreted as "at top", "on top", 
etc. too fuzzy to be short.

If you have only angle then you can do this:

background-color: linear-gradient(
                   angle: 190deg,
                   color-stop: 0% white,
                   color-stop: 50% red ,
                   color-stop: 100% blue );

If you want to define gradient that starts from 10px from top-left and 
offset by 10px from the bottom-right then you can do

background-color: linear-gradient(
                   start:10px,
                   end: 10px, /* ends uses offsets from bottom/right 
corner */
                   color-stop: 0% white,
                   color-stop: 50% red ,
                   color-stop: 100% blue );

>
> That to me is both concise and clear, and doesn't involve counting 
> slashes or looking things up. It says simply, start the gradient at 
> the top and then evenly space three color stops from there until the 
> end of the box. I think it is not only easier to write, but easier to 
> read. And if you don't want evenly spaced color-stops, then you can 
> add distances and/or percentages, and it is still very easy to read 
> and understand:
>
> background-color: linear-gradient(top /  white 30px,  red 40%, blue 
> 80% );
>
> That simply says, start the gradient at the top, with the three color 
> stops located at points from there until the end of the box positioned 
> first (white) at 30px from the start, then the red at 40% of the box 
> height, and the blue at 80% of box height. It's still very simple.
>
Think about all this in big scale. Do you want to invent bunch of 
micro-formats for each function that we going to add?

As an implementor I would like to see common and generic 
format/framework/foundation where
various features can be added  without rewriting CSS parser for each 
function.

As a user I would like to see common format just to minimize learning 
curve for each feature added.

And yet about functions.

Consider this:

div
{
   background:  background( color: red, image: url(...), repeat: 
repeat-x, attachment: fixed );
   /* defines background as a block of values that will be overridden as 
all-or-none */
}

and now if I will write
div.specific
{
   background:  background( color: blue );
}
it will redefine whole set of values defined in previous style 
definition for the div.

I think that such a function will also be quite useful.

--
Andrew Fedoniouk.

http://terrainformatica.com

Received on Thursday, 20 August 2009 20:31:31 UTC