W3C home > Mailing lists > Public > www-style@w3.org > August 2009

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

From: fantasai <fantasai.lists@inkedblade.net>
Date: Thu, 13 Aug 2009 12:40:18 -0700
Message-ID: <4A846C22.3030103@inkedblade.net>
To: "Tab Atkins Jr." <jackalmage@gmail.com>, www-style@w3.org
Tab Atkins Jr. 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.
> 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.
> ...
> 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.
> ...
> So, the functional color syntax appears to give literally no benefit,
> while adding a *lot* of mental/typing complexity.  Kill it.
> ...
> 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 is exactly what I meant. :) I think this is much, much easier to
understand, in addition to being easier to type.

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

I like Brad's suggestion of drawing the vector through through the
center at the given angle and maxing it at the edges. If a single point
is specified (background-position style), then the vector starts there
and continues at the angle. If a length is specified after the angle,
then the vector ends after that length.


   135deg              - starts and ends at the edges of the box, going
                         at 135deg from its start point and intersecting
                         the center

   top left 135deg     - starts at the top left corner, goes at 135deg
                         until it hits the bottom
   top left 135deg 4em - starts at the top left corner, goes 4em at 135deg

   gradient(bottom 0deg 4em / white, transparent) /* fade effect on bottom edge */

The same syntax works for radial gradients, except the default start
point would be the center rather than the edge.

   135deg              - starts at center of the box, going 135deg from its
                         start point until it hits the edge of the box

Received on Thursday, 13 August 2009 19:41:03 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:38 UTC