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

On Aug 20, 2009, at 1:30 PM, Andrew Fedoniouk  
<news@terrainformatica.com> wrote:

>> 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%,

Ah, right. I don't know how I missed that part before.


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

Well some familarity is always required, such as knowing which value  
is which in background-position, or which length is the blur in box- 
shadow.  Having a understandable keyword indicate a starting side/ 
corner is no more fuzzy that many other CSS values.

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

That's CSS, baby. You're talking about completely changing the style  
of property values starting now, just for this and future properties?

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

Sure. Sounds nice. What will you call your new styling language?  
CSSON? I'd like to continue writing style in CSS though, until that  
gains significant traction. So you'll still need a parser for  
translating CSS into CSSON.

Received on Thursday, 20 August 2009 22:20:12 UTC