Re: [CSSWG] Minutes and Resolutions 2009-08-12

Sent from my iPhone

On Aug 13, 2009, at 11:53 AM, "Tab Atkins Jr." <jackalmage@gmail.com>  
wrote:

> On Thu, Aug 13, 2009 at 3:08 AM, Robert O'Callahan<robert@ocallahan.org 
> > wrote:
>> That seems far more complicated than what we currently have. By  
>> writing it
>> as a 'gradient' rule you don't benefit background-clip, background- 
>> position,
>> background-repeat, multiple backgrounds, and falling back to a  
>> background
>> image. It's not extensible to other kinds of gradients, and doesn't  
>> handle
>> repeating gradients. And even so,
>
> Agreed - it should stay as a functional notation denoting an image
> that just happens to be constructed by the browser.

I'm not sure what you are agreeing with. The rest of what you wrote is  
much, much closer to what I was proposing than to the Mozilla/webkit  
versions that Robert O' favors.

> As to the actual syntax:
>
> I think the major loss of the current syntax is the functional
> notation of the colors.  It's a large gain in complexity, increases
> the chance of an accidental mistake, and gains us nearly nothing from
> what I can tell.

Agree.

> The vast majority of gradients will, I believe, be simple 2-color
> fades.  As such, requiring someone to write "from(white),to(black)" is
> almost criminal when they could just write "white,black" or even
> "white black".

Right. Like I proposed.

> More complex gradients are also overcomplexified.  The vast majority
> of complex gradients will be simple n-color fades, going from one to
> the next in turn.  Again, it's criminal to then make someone write
> "from(white),color-stop(50%,orange),to(black)" when they could just
> say "white orange black".

That's an interesting idea, letting the colors be evenly spaced when  
no distance is mentioned. Although I tend to disagree with the notion  
that one people start adding more than two stops that they will  
usually want them evenly spaced. I think the reasons for adding more  
than just start and finish colors (three or more stops would be  
minority use cases) would be more varied than that.

> The only remaining case, discontinuous gradients, are in my opinion a
> tiny minority of a tiny minority, and *still* don't need the
> functional notation.  Currently you can write
> "from(white),color-stop(50%,orange),color-stop(50%,blue),to(black)",
> which can be simplified into just "white,50% orange,50% blue,black".
> Why would you *ever* want the former when you can do the latter?

Right. Although I do think that once you have more than the common two  
stops (0 and 100%) that it is easier to read if there are color/ 
percentage pairs  on each side of the commas (even though that isn't  
compatible with you auto-spacing of color stops beyond the two-stop  
norm). And since color is required for every stop, I prefer to see it  
before the percentage instead of after.

> So, the functional color syntax appears to give literally no benefit,
> while adding a *lot* of mental/typing complexity.  Kill it.

Yes, please. Especially since there are three different functions for  
color stops, and they are so much more verbose.

> As well, I already expressed that I think the majority of gradients
> will be simple 2-color fades, so we shouldn't require % when we have
> two colors - we can safely assume that the first one is 0% and the
> second is 100%.

Right. That's what I proposed too.

> In complex gradients, I think it will be common to
> have colors spaced evenly as well, so we can safely omit the % from
> them as well.

I don't know about that. I could see adding a couple stops between a  
medium color and white, in order to give a pseudo-algorithmic looking  
fade.  I don't see myself doing many blends through rainbows of color.  
Unless I was trying to simulate chrome or reflections, which also  
wouldn't be regulary spaced stops.

> [...]
>
> That is, specifying "white, green, orange, 66% blue, red, black"
> would, in addition to killing my eyes, be equivalent to "0% white, 22%
> green, 44% orange, 66% blue, 83% red, 100% black".

That second part of your equivelency staatement is almost identical to  
what I was proposing for multiple-stop (more than two) gradients. All  
it's missing is an angle and a reversal of each of the paired values.

> You can do LDB's
> rainbow example without doing a lick of math, just by specifying each
> color in turn.
>
> This does mean that the color list is now at least somewhat
> order-dependent, which wasn't true before.

That would be a problem if you wanted to mix fixed lengths and  
percentages in the same gradient, but I dont think that should be  
allowed, because of the odd results it can create.

> That's fine in my opinion
> - I find it very confusing to put colors out of order.

True that.

> You can still
> achieve complete order independence if you just specify the % on each
> color.
>
>
> So, that's colors.  Now the rest.
>
> First, I much prefer using "linear-gradient()" and "radial-gradient()"
> to "gradient(linear,...)" and "gradient(radial,...)".  It lets you
> describe the syntax of each type without having to worry about the
> other - I found the webkit blog explanation of the gradient syntax
> rather confusing because it mixed the radius argument in.  It'll get
> *much* worse if we start allowing more keyword-heavy specifiers, a la
> Brad's suggestion.

Here I disagree. I don't think it is helpful to have two nearly  
identical properties, when the only difference between them is that  
linear need an angle but not a definition of what 100% means, and the  
reverse difference  is true for radials. And which one overrides the  
other? Or does one appear above the other if they ate both specified?  
No one will ever need to use both at the same time (unlike box-shadow  
and text-shadow), so they should just be one.

I am only including one slot for a keyword in mine, and just a lot of  
useful values, but they can be reduced down if you don't think they'll  
all be useful. I think "corners" would be pretty common for shaped  
radials, and maybe "longest-corners" if you want to keep the radial  
circular. I could also accept being able to substitue a fixed radius  
there with something like radius(200px).

> Now, positioning.  For linear gradients, the standard 2-point syntax
> works fine when it's necessary.  I have no problem with that at all.
> However, I'd also like to use left/right/top/bottom in there.
> Webkit's syntax allows it (FF's may too), but requires the use of
> *two* keywords, frex "left top,left bottom" as used in the blog
> example.  [...]
>
> You should also be able to specify an angle directly, rather than as
> two points.  Use any of the degree units, normalized to within [0deg,
> 360deg).  The gradient originates from the corner opposite a ray at
> that angle; in othe words, [0deg,90deg] originate from bottom left,
> [90deg,180deg] originate from bottom right, [180deg,270deg] originate
> from top right, and [270deg,360deg] originate from the top left.

Yes, this is what I was saying, regarding angles. Once you specify an  
angle, you dint need the top, right, bottom, left keywords at all. And  
it is easier to type 90deg than to type "bottom" for the start and  
"top" for the end. You say my propsal is keyword heavy, but it only  
required a single keyword for radials, while yours has two slots for  
utterly redundant keywords for all gradients. They're useless once you  
allow angles.


> At this very moment I'm writing all of this up into a separate
> proposal, which is much much shorter and more concise than the text
> above.  I'll have a link for it by this evening.
>
> ~TJ

Received on Thursday, 13 August 2009 20:20:46 UTC