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

On Wed, Aug 19, 2009 at 1:28 AM, Andrew
Fedoniouk<news@terrainformatica.com> wrote:
> Am I alone who failed to decipher these records (taken from Tab's URL [1]
> with GUID the Ultimate):

Haha, I have no clue what I was thinking when I decided that I needed
a guid that long.  In any case, I wrote myself a shorturl resolver
last night, so here you go:

http://www.xanthir.com/x/4bhipd

> background: linear-gradient(top / yellow, blue);
> background: linear-gradient(top to bottom / yellow, blue);
> background: linear-gradient(-90deg / yellow, blue);
> background: linear-gradient(top left to bottom left / yellow, blue);
> background: linear-gradient(top / yellow 0%, blue 100%);
> background: linear-gradient(top left / yellow, blue);
> background: linear-gradient(top left to bottom right / yellow, blue);
> background: linear-gradient(0 0 to 100% 100% / yellow, blue);
> background: linear-gradient(-45deg inside/ yellow, blue);
>
> ?
>
> I'd like to rise the question/discussion about function notation in CSS.
> It seems that CSS development is at the phase when we see the demand of
> extended functionality using forms similar to the linear-gradient feature.
>
> It is clear so far that such function notation has to be:
>
> 1) human readable as much as possible;
> 2) should allow decomposition and so parts of the function to be accessible
> independently by scripts and modules like CSS Animation & Co.
> 3) Should be compatible with the rest of CSS.
>
> As an initial idea I propose to use function notation with
> [named] arguments:
>
>  <name> '(' [<argument>] [ ',' <argument> ]* ')'
>
> Where:
>  <name> is a name token standard for the CSS;
>
>  <argument> is single value or pair of values:
>
>      <value>  [ ':' <value> ]?
>
>  <value> here is either
>        a) some name-token/keyword like: top ;
>        b) or value like: 12px, 90deg, etc;
>        c) or function including the calc();
>        d) or whitespace separated list of items above.
>
> Therefore parameters can be named or not. There is no
> requirement for uniqueness of names of parameters in single function
> "call". E.g. (color-stop: 0% red, color-stop: 100% blue).
>
> Here is real life example that I would like to harmonize using such
> notation. In my engine I have following attribute that accepts various
> functions/filters:
>
> img:hover {
>  foreground-image-transformation:
>                    contrast-brightness-gamma(0.75,0.5,1.2);
> }
> used to highlight the image on hover. The notation is not so pretty -
> not extendable.
>
> By using proposed function notation I will be able to define this as:
>
> img:hover
> {
>  foreground-image-transformation:
>             color-filter(contrast:0.75, gamma:1.2 );
> }
>
> Or:
> img:hover
> {
>  foreground-image-transformation: color-filter(tint-of:red);
> }
>
> And here is an example of how the linear-gradient could be defined:
>
>  background-color: linear-gradient(
>                      start:0% 0%,
>                      stop: 100% 100%,
>                      color-stop: 0% white,
>                      color-stop: 50% red ,
>                      color-stop: 100% blue );
>
>
> In JS components of such function alike declaration can be accessed as:
>
> el.style.backgroundColor["linear-gradient"]["start"] = ...
> el.style.backgroundColor["linear-gradient"]["stop"] = ...
> el.style.backgroundColor["linear-gradient"]["color-stop"][0] = ...;
> etc.
>
> In CSS Animation:
>
> @keyframes 'color-in-gradient'
> {
>    from {
>      background-color.linear-gradient.color-stop[0]: 0% white;
>    }
>    to {
>      background-color.linear-gradient.color-stop[0]: 50% red;
>    }
> }
> (in fact the Animation itself can be re-thought in terms of functions)
>
> All above is not perfect of course but at least we should (IMO) start
> moving in that direction as soon as possible. Before it will not be too
> late.
>
> [1]
> http://www.xanthir.com/document/document.php?id=d65df9d10442ef96c2dfe5e1d7bbebf7aa42f2bcf24e68fc3777c4b484fa8a4ce55fed2189cac20ccad8686127f4c08917c4ca8b7614e9f89c2a950ec083a9c6

I generally approve!  Named argument lists are very useful in Lisp and
Python, for precisely the types of cases you bring up - where there
are many possibilities that can be combined in various ways, and it's
annoying to specify default values every time for the arguments you
don't want to do anything with.


On Wed, Aug 19, 2009 at 7:32 AM, David Perrell<davidp@hpaa.com> wrote:
> Andrew Fedoniouk wrote:
>
> |                        color-stop: 50% red ,
> |                        color-stop: 100% blue );
>
> It occurs to me why it looks so wrong to have the percentage precede the
> color (besides the fact that it makes no sense to have an optional parameter
> precede a required one).
>
> As a graphic designer/production artist, I spent years spec'ing color in
> screen percentages. You put a percent in front of a color and I see it as a
> percentage of color ink, not a color-stop on a gradient line.

That's been removed now.  Enough people complained that I just made
the desired ordering required.

~TJ

Received on Wednesday, 19 August 2009 13:13:46 UTC