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

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 20 Aug 2009 15:06:40 -0500
Message-ID: <dd0fbad0908201306x677cd898we30ca3a54000c427@mail.gmail.com>
To: "L. David Baron" <dbaron@dbaron.org>
Cc: Simon Fraser <smfr@me.com>, Andrew Fedoniouk <news@terrainformatica.com>, Brad Kemper <brad.kemper@gmail.com>, www-style <www-style@w3.org>
On Thu, Aug 20, 2009 at 12:25 PM, L. David Baron<dbaron@dbaron.org> wrote:
> I wouldn't mistake convergence of a small number of people for
> convergence.
> The more you write, the fewer people will read it.  This is as you
> should expect.  I have completely lost track of the discussion
> because there have been too many messages in it for me to keep up
> with (and large numbers of messages with too much quoted material).

Agreed and understood.  I apologize for the heavy-quoting; I forget
that not everyone uses mail clients that automatically fold quotes.

> However, I'll take this as an opportunity to give my thoughts on the
> current document.  (It would be really nice if the current version
> I'm commenting on were archived somewhere, though, so that this
> discussion would make sense when people read it later.)

Snapshot of the proposal as it stands now:

Always-current version, subject to change:

> I don't like the use of '/' as a delimiter; it feels to me that if
> you're writing something like:
>  a / b, c, d
> the natural grouping of that syntax is:
>  (a / b), c, d
> whereas in this draft it means:
>  a / (b, c, d)
> I'd prefer replacing the '/' with ',' over the current syntax,
> though I'd also be open to better alternatives.

The primary reason we switched to using / originally was because we
used , to separate the two bg-positions, and the ambiguity of the
direction/position being either the first or the first two bits.  Now
that we use "to" to separate the two bg-positions, we could switch
back to ",".  It was only inertia keeping it as it is.  I can swap it

> I don't know why you chose the default starting point for <angle>
> without <bg-position> to be one of the box's corners.  This leads to
> asymmetric results for both 'inside' and 'outside'.

It seemed most reasonable.  Reading back a bit, I see that Fantasai
suggested that angles should start at the center as well, with the
bg-position used to place the starting point somewhere else.  I don't
know how I missed that previously.

I've got no opposition to changing that; I'm not particularly attached
to the angle syntax.

> Why not say
> that the gradient line is symmetric around the center of the
> background positioning area, at the given angle.  For inside, the
> length of the gradient line would be the length that touches the
> edges of the background positioning area.  For outside, the length
> of the gradient line would be the longest length such that the
> perpendiculars to the ends of the gradient line intersect the
> corners of the background positioning area.  (Longest because there
> are shorter such lengths, but they intersect the wrong corners.)

So are you proposing that something like this:

linear-gradient(45deg, red, white)

should produce an image like:


> Given that, I'm not sure what the use case is for <bg-position>
> <angle>.  I think it makes more sense to use an angle with zero
> points or two than it does with one.  (Using an angle with two
> points would follow the same rules as using it for zero, except
> using the rectangle formed by those two points instead of the
> background positioning area.)

It's to change the starting-point of the gradient-line.  The line then
ends based on inside|outside.

> But I suspect I may have missed something in all those messages I
> haven't read; feel free to point me to the relevant use cases (or,
> even better, add an example to the document showing why the current
> approach is better).

I'm not certain it is.  I'm definitely open to changes in the angle syntax.

> I also fear that the syntax may be too compact and thus unreadable,
> but I'm also not sure that there are any alternatives that I prefer.

That's possible, but hopefully it ends up being easy in practice.  It
seems like it will for me.

> The proposal also needs to address radial gradients at some point.

Indeed.  I've got some ideas, and even more important, some questions
about how people see them acting.  Radial gradients are inherently
more complicated than linear ones.  I was planning on starting on that
when I got linear-gradient pinned down, so I could use a similar

Received on Thursday, 20 August 2009 20:07:41 UTC

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