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

Brad Kemper wrote:
>>> 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?
Am I? Where?
>
>> 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.
I am not sure I understand the nature of your sarcasm here. Why do you 
need to change anything you are doing now?
Proposed syntax does not affect existing features in CSS. Even this 
background() function above is not changing anything in the way you do
design. It just adds additional feature - define/undefine set of related 
CSS attributes as a single unit. Not more not less.

Say you have set of existing styles that you carefully crafted in years. 
And now you've got UA that started to support, say, background-size.
It is just enough for someone or even for you to change background-size 
in default style and you will need to update bunch of other rules to 
suppress it.
Having function that allow you to define the set as a whole plus 
existing mechanism allowing to redefine particular attribute will give 
you more choices
of making better and stable designs.

--
Andrew Fedoniouk.

http://terrainformatica.com

Received on Friday, 21 August 2009 00:01:41 UTC