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

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.

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.

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

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

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?

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

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

So, in more specific language: If the start color doesn't have a %,
it's assumed to be 0%.  If the end color doesn't have one, it's
assumed to be 100%.  If any middle colors don't have one, they're
assumed to be spread equally between surrounding colors that *do* have
one (counting start and end).

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".  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's fine in my opinion
- I find it very confusing to put colors out of order.  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.

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.  I'd prefer that I be allowed to specify a single keyword
per, and have the other component of the point assumed.  The rules
would be:

1. If both points omit the vertical or horizontal component, then the
missing component is assumed to be "center".  For example,
"left,right" gets expanded to "left center, right center" which would
just create a horizontal gradient, as expected.
2. If the horizontal or vertical component is omitted from one point
but present in the other as a keyword, then the missing component is
assumed to be the opposite of the present component.  For example,
"left,bottom" gets expanded to "left top, right bottom".
3. If the horizontal or vertical component is missing from one point
but present in the other as something other than a keyword, the
missing component is assumed to be "center".  For example, "left,right
10%" gets expanded to "left center, right 10%".

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.

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 18:54:24 UTC