radial-gradient() proposal

[Tab Atkins Jr.]

I'm finally happy with my radial-gradient() syntax.  You can view it
at http://www.xanthir.com/:4bhipd (scroll down past the
linear-gradient() examples).

Highlights are reusing *all* of the infrastructure from
linear-gradient (changing only the default values for <bg-position>
and <angle>), and then adding a second argument which takes two
keywords defining the shape and size of the gradient.  I think this
syntax will cover a large majority of radial gradient uses on the web
(unfortunately, radial gradients are much less common due to them
requiring much larger files), while being simple and easy to
understand and write.  Much thanks to David Perrell for giving me the
arguments that inspired this syntax.

Making examples for radial gradients is substantially more difficult
in GIMP than for linear gradients, so instead I'll be putting together
a generator for them this weekend, and will have examples
live-generated from the syntax afterwards.

~TJ

[David Perrell]

Tab Atkins Jr. wrote:
| I'm finally happy with my radial-gradient() syntax.  You can view it
| at http://www.xanthir.com/:4bhipd (scroll down past the
| linear-gradient() examples).

Thanks for the warm regards and kind acknowledgement. Most of your update looks good to me (you even got 'contain' contained). But I'm not understanding the description of the <angle> variable (my initial thought was: "tilted ellipse?"). Why would I want to specify gradient-line direction other than to sides or corners? And what does it mean that a gradient-line extends "in from the starting-point" with default angle "0deg...to the left?"

If the default gradient-line is horizontal and the horizontal axis is the minor axis of a narrow ellipse, then <length> color-stops won't always translate as intended from the shorter to the longer axis. You'd have to specify a 90 or 270deg angle to put the gradient-line on the major axis where <length> measurements are most accurate. That doesn't seem right.

What would be lost if you remove the <angle> option and have the gradient-line run from the start-point to the specified <size> point? That seems simpler and more intuitive, and less apt to produce undesirable effects. I somehow got the impression that's what you were thinking of before you updated your draft.

David Perrell

[Tab Atkins Jr.]

On Sun, Sep 6, 2009 at 11:12 AM, David Perrell<davidp@...> wrote:
> Tab Atkins Jr. wrote:
> | I'm finally happy with my radial-gradient() syntax.  You can view it
> | at http://www.xanthir.com/:4bhipd (scroll down past the
> | linear-gradient() examples).
>
> Thanks for the warm regards and kind acknowledgement. Most of your update looks good to me (you even got 'contain' contained).

No problem, dude.  Your arguments were the big thing that motivated
this, just as Brad's arguments were the major motivation behind my
linear-gradient syntax.

> But I'm not understanding the description of the <angle> variable (my initial thought was: "tilted ellipse?"). Why would I want to specify gradient-line direction other than to sides or corners?

Not sure.  But I think you need to be able to specify the direction
you're measuring in; you at least need to be able to specify between
the major and minor axis of the ellipse.  Using the full <angle> gives
us a direct analogue to linear gradient so there's less relearning,
even if a lot of the power gets wasted.

You do bring up a good point that I want to address, though, and that
it's not possible with an explicit angle to reliably measure lengths
to a corner.  You *can* still do this properly with percentages (a
farthest-corner gradient, frex, still has 100% exactly on the corner),
it's just lengths that are difficult.  However, these are all at an
angle.  I don't *believe* that it's important to get exact length
measurements along an unpredictably-angled diagonal - when you want
that sort of precision you're generally trying to align with something
else on the page, and thus want to measure horizontally or vertically.
 If you can prove me wrong, go ahead.

> And what does it mean that a gradient-line extends "in from the starting-point" with default angle "0deg...to the left?"

I've revised that sentence.  Does it make more sense now?  If I can't
explain it in the language of the proposal, then I need to rewrite it
until I can.

> If the default gradient-line is horizontal and the horizontal axis is the minor axis of a narrow ellipse, then <length> color-stops won't always translate as intended from the shorter to the longer axis. You'd have to specify a 90 or 270deg angle to put the gradient-line on the major axis where <length> measurements are most accurate. That doesn't seem right.

Yeah, if you want your <length>s to run along the vertical axis, you
need to say so.  I don't understand why measuring the lengths along
the minor axis is somehow worse than measuring it along the major,
though - it just depends on what you're trying to align to.  And what
do you mean by 'accurate'?  The fact that translating from the minor
axis to the major axis may be somewhat pixel-ambiguous?  This is true,
but I don't think it's that important.  Again, if you're measuring
along the minor axis, that's the line you want to align with things.
The other axis isn't as important, imo.

> What would be lost if you remove the <angle> option and have the gradient-line run from the start-point to the specified <size> point? That seems simpler and more intuitive, and less apt to produce undesirable effects. I somehow got the impression that's what you were thinking of before you updated your draft.

Elliptical gradients don't derive a single reasonable point from
<size> in the case of closest-side or farthest-side, they have two.
And while the -corner sizes do give a single favored point, I can
easily see myself still wanting to measure along the horizontal or
vertical axis.  I just think that requiring precise <length>s along a
diagonal is a minority case (and can be approximated well enough when
necessary by estimating an <angle>).

In my previous draft I *sort of* meant that.  For elliptical gradients
you could use <axis> to specify what direction to measure <length>s
along: horizontal, vertical, major, or minor.  However, that made a
bit of a hash of things since <axis> meant something *different* for
circular gradients.  The current <size> is a combination of the old
<size> and the circular <axis>, while the elliptical <axis> became
<angle>.

~TJ

[David Perrell]

Tab Atkins Jr. wrote:
| Using the full <angle> gives
| us a direct analogue to linear gradient so there's less relearning,
| even if a lot of the power gets wasted.

Any analogue is oblique and creates confusion. I went through your spec multiple times, trying figure what relationship <angle> had to an ellipse if not the angle of the major axis. Unless you have ellipse axes other than vertical and horizontal, you have no need to specify a gradient-line at an arbitrary angle.
|
| You do bring up a good point that I want to address, though, and that
| it's not possible with an explicit angle to reliably measure lengths
| to a corner.

No, but you can compute the angle to a corner from a start-point, a width, and a height. If your gradient-line corresponds to your size line, then it's very clear how distances relate to the shape. When you have an <angle> that requires a lengthy explanation as to why only two of countless options are really useful, it seems to me it's time to reconsider its value.

| I've revised that sentence.  Does it make more sense now?

Insofar as which way the gradient-line extends, yes. As regards the reasons for providing such an option, no.

| Elliptical gradients don't derive a single reasonable point from
| <size> in the case of closest-side or farthest-side, they have two.

Closest-side, farthest-side, etc., are measured on a vertical or horizontal line from the start-point to a side. Isn't that the line on which you'll most likely want to align things? Consider also that to-a-side and to-a-corner measurements represent the longest lines on which all distances from 0-100% appear within the box.

If specifying specific angles is necessary, then it seems that a variable with keywords instead of angles - where 'size-line' might be the default option - would be better than <angle>.

David Perrell

[Tab Atkins Jr.]

On Sun, Sep 6, 2009 at 4:34 PM, David Perrell<davidp@...> wrote:
> Tab Atkins Jr. wrote:
> | Using the full <angle> gives
> | us a direct analogue to linear gradient so there's less relearning,
> | even if a lot of the power gets wasted.
>
> Any analogue is oblique and creates confusion. I went through your spec multiple times, trying figure what relationship <angle> had to an ellipse if not the angle of the major axis. Unless you have ellipse axes other than vertical and horizontal, you have no need to specify a gradient-line at an arbitrary angle.

It has nothing do with the axes of the ellipse; it specifies the angle
of the gradient-line, which is used solely for placing color-stops.
It is absolutely vital to know the direction of the gradient-line when
position a color-stop with a <length>, because there's quite a bit of
difference in where "yellow 50px" gets drawn on a 200px by 100px
ellipse based on whether you're measuring down the major axis, the
minor axis, or somewhere else entirely.

> | You do bring up a good point that I want to address, though, and that
> | it's not possible with an explicit angle to reliably measure lengths
> | to a corner.
>
> No, but you can compute the angle to a corner from a start-point, a width, and a height. If your gradient-line corresponds to your size line, then it's very clear how distances relate to the shape.

If you know the width and height of the box, sure, though I'd prefer
not to do any trig at all when creating my CSS files.  However, this
syntax has been designed to be maximally useful in the face of boxes
with *unknown* dimensions, where such an angle can only be estimated.

> When you have an <angle> that requires a lengthy explanation as to why
> only two of countless options are really useful, it seems to me it's time
> to reconsider its value.

I'm not sure I understand how an explanation is lengthy.  However, I
do accept that <angle> may be best addressed in some other manner.

> | I've revised that sentence.  Does it make more sense now?
>
> Insofar as which way the gradient-line extends, yes. As regards the reasons for providing such an option, no.

K, good enough.

> | Elliptical gradients don't derive a single reasonable point from
> | <size> in the case of closest-side or farthest-side, they have two.
>
> Closest-side, farthest-side, etc., are measured on a vertical or horizontal line from the start-point to a side. Isn't that the line on which you'll most likely want to align things? Consider also that to-a-side and to-a-corner measurements represent the longest lines on which all distances from 0-100% appear within the box.

Not for ellipses; they measure a horizontal *and* vertical line to the
two nearest sides.  There's no reasonable way to automatically
distinguish between the two.

Similarly, for an ellipse the to-a-corner distance is, I think, rarely
going to be a better choice than the major or minor axis.  Again, you
can't reliably tell which is better automatically; this depends on
your layout needs.

For circles, of course, these questions are all moot.  They align to a
single side, and have only a single radius no matter what direction
you're looking in.

> If specifying specific angles is necessary, then it seems that a variable with keywords instead of angles - where 'size-line' might be the default option - would be better than <angle>.

Specifying angles *is* necessary, even if only to distinguish between
0deg and 90deg.  If I were to do this, I would use keywords like [
horizontal | vertical | major | minor ] to specify which axis of the
ellipse to measure along.  I'm not completely certain this is actually
simpler, though.

~TJ

[Tab Atkins Jr.]

OMIGOD IT'S FINALLY DONE.

http://www.xanthir.com/test.php?width=200&height=100&radial-gradient=top
20px left 20%, ellipse cover, yellow 20px, green, red, blue

Or, properly escaped:
http://www.xanthir.com/test.php?width=200&height=100&radial-gradient=top%2020px%20left%2020%,%20ellipse%20cover,%20yellow%2020px,%20green,%20red,%20blue

It doesn't do full error-testing or anything, but it should accept
very nearly a complete set of CSS syntax in there.  Qualifiers: on
lengths, use px only - I don't have support for any other length type.
 For colors, either use svg color names, or hex values *without the #
in front*.  I didn't want to put in the work to parse an rgb() value.

Tomorrow I'll go and make examples.  For now I'm gonna go relax - that
represents about 12 hours of work.

~TJ

[David Perrell]

Tab Atkins Jr. wrote:
| It has nothing do with the axes of the ellipse; it specifies the angle
| of the gradient-line, which is used solely for placing color-stops.
| It is absolutely vital to know the direction of the gradient-line when
| position a color-stop with a <length>, because there's quite a bit of
| difference in where "yellow 50px" gets drawn on a 200px by 100px
| ellipse based on whether you're measuring down the major axis, the
| minor axis, or somewhere else entirely.

The significance of the gradient-line angle is not in question.

| If you know the width and height of the box, sure, though I'd prefer
| not to do any trig at all when creating my CSS files.

I'm noting that the browser can do the trig based on values known at render time. I'm trying to relieve the author of unnecessary decisions.

| K, good enough.

I'm arguing the contrary.

| > Closest-side, farthest-side, etc., are measured on a vertical
| or horizontal line from the start-point to a side. Isn't that the
| line on which you'll most likely want to align things? Consider
| also that to-a-side and to-a-corner measurements represent the
| longest lines on which all distances from 0-100% appear within the box.
|
| Not for ellipses; they measure a horizontal *and* vertical line to the
| two nearest sides.  There's no reasonable way to automatically
| distinguish between the two.

The ellipses don't measure anything, they are based on the criterion you've specified. Closest-side and farthest-side refer to *one* side except when two sides match that criterion. When they match, the direction of the gradient-line makes no difference because the ellipse is a circle.

| Similarly, for an ellipse the to-a-corner distance is, I think, rarely
| going to be a better choice than the major or minor axis.  Again, you
| can't reliably tell which is better automatically; this depends on
| your layout needs.

Consider your needs when you specify a 'cover' ellipse. Will <length> measurements be useful near the outside edge when you don't know the actual dimensions of the box? If so, wouldn't the longest visible distance be a better length reference?
|
| For circles, of course, these questions are all moot.  They align to a
| single side, and have only a single radius no matter what direction
| you're looking in.

Yes, of course. And if you're looking for analogues, consider that the analogue for a radial-gradient confined to horizontal and vertical axes is a linear-gradient confined to horizontal and vertical directions. A linear gradient is just a bisected radial gradient with an infinite radius. If you are precluding angular axes, you have no direct analogue for <angle>.
|
| Specifying angles *is* necessary, even if only to distinguish between
| 0deg and 90deg.  If I were to do this, I would use keywords like [
| horizontal | vertical | major | minor ] to specify which axis of the
| ellipse to measure along.  I'm not completely certain this is actually
| simpler, though.

Your to-a-side, to-a-corner sizing *does* specify an angle when an angle is needed.

David Perrell

[Tab Atkins Jr.]

On Sun, Sep 6, 2009 at 8:22 PM, David Perrell<davidp@...> wrote:
> The ellipses don't measure anything, they are based on the criterion you've specified. Closest-side and farthest-side refer to *one* side except when two sides match that criterion. When they match, the direction of the gradient-line makes no difference because the ellipse is a circle.

Ah, I think you're somewhat confused here then.  The -side values,
when used with an ellipse, refer to *two* sides - the closest
horizontal *and* the closest vertical.  After all, you can't specify
an ellipse with only one axis - you need some way to determine the
second axis.

You may still be thinking that ellipses automatically match the box's
ratio.  That's no longer true (except by accident).

> | Similarly, for an ellipse the to-a-corner distance is, I think, rarely
> | going to be a better choice than the major or minor axis.  Again, you
> | can't reliably tell which is better automatically; this depends on
> | your layout needs.
>
> Consider your needs when you specify a 'cover' ellipse. Will <length> measurements be useful near the outside edge when you don't know the actual dimensions of the box? If so, wouldn't the longest visible distance be a better length reference?

If you don't know the actual dimensions of the box, <length>s aren't
very helpful anyway.  I recommend sticking with percentages in that
case.

> | For circles, of course, these questions are all moot.  They align to a
> | single side, and have only a single radius no matter what direction
> | you're looking in.
>
> Yes, of course. And if you're looking for analogues, consider that the analogue for a radial-gradient confined to horizontal and vertical axes is a linear-gradient confined to horizontal and vertical directions. A linear gradient is just a bisected radial gradient with an infinite radius. If you are precluding angular axes, you have no direct analogue for <angle>.

It's not meant to be an analogy in those terms, though; it's meant to
match with the definition of gradient-line that linear gradients use.
When talking about gradient-lines, radial and linear gradients use
them nearly identically; the only things different are the default
values and how the ending-point is inferred.

> | Specifying angles *is* necessary, even if only to distinguish between
> | 0deg and 90deg.  If I were to do this, I would use keywords like [
> | horizontal | vertical | major | minor ] to specify which axis of the
> | ellipse to measure along.  I'm not completely certain this is actually
> | simpler, though.
>
> Your to-a-side, to-a-corner sizing *does* specify an angle when an angle is needed.

I recommend playing with the link I provided.  Just feed it the
contents of the radial-gradient() rule.  I've fixed up all the bugs I
can find, so it should work as I want.  (If you can still get an error
using valid syntax, send me the link - I don't care as much about
invalid syntax, because I didn't have the time/will to write a *fully*
intelligent CSS parser.)

Also, I'd keep the width/height fairly small, 300px or so at most.  If
you get too big it causes a noticeable delay as it churns, and eats up
my bandwidth.  ^_^

~TJ

[David Perrell]

Tab Atkins Jr. wrote:
| Ah, I think you're somewhat confused here then.  The -side values,
| when used with an ellipse, refer to *two* sides - the closest
| horizontal *and* the closest vertical.  After all, you can't specify
| an ellipse with only one axis - you need some way to determine the
| second axis.

I question who's confused. The ellipse parameters derive from a single -side value. The gradient-line can also be derived from that -side value.

| If you don't know the actual dimensions of the box, <length>s aren't
| very helpful anyway.  I recommend sticking with percentages in that
| case.

Not a bad recommendation. However, there are valid exceptions.

| It's not meant to be an analogy in those terms, though; it's meant to
| match with the definition of gradient-line that linear gradients use.
| When talking about gradient-lines, radial and linear gradients use
| them nearly identically; the only things different are the default
| values and how the ending-point is inferred.

Could you expound on this further? In what way is the effect of an angular gradient line identical for your linear and radial gradients? I can certainly see how linear gradients are altered by a change of angle. I fail to see how changing the angle affects radial gradients.

David Perrell

[Tab Atkins Jr.]

On Sun, Sep 6, 2009 at 10:32 PM, David Perrell<davidp@...> wrote:
> Tab Atkins Jr. wrote:
> | Ah, I think you're somewhat confused here then.  The -side values,
> | when used with an ellipse, refer to *two* sides - the closest
> | horizontal *and* the closest vertical.  After all, you can't specify
> | an ellipse with only one axis - you need some way to determine the
> | second axis.
>
> I question who's confused. The ellipse parameters derive from a single -side value. The gradient-line can also be derived from that -side value.

I think I understand what you're getting at, but I'm not sure.  To
route around the possibility that we've adopted different definitions
for higher-level terms, let me explain myself in very basic terms, and
let you verify that you understand the situation the same way.
(Please don't take this insultingly ^_^; I just find that when two
people start disagreeing about the truth of simple statements it's
almost always a definitional issue and can be cleared up by rebuilding
the shared terminology from the bottom. Even if they don't find
agreement, they'll remove any confusion about what's being argued.)

Axis-aligned ellipses are defined with at least two parameters.  This
can be the lengths of both axes, or the length of one axis and a value
relating the two axes such as a length ratio or the eccentricity.  In
the radial-gradient rule I define ellipses by simply (implicitly)
specifying the lengths of both axes.

Specifically, when using closest-side, the vertical axis of the
ellipse is the distance from the starting-point to the top or bottom
of the box, whichever is closer, and similarly for the horizontal
axis.  Thus there are two axis-aligned lengths that are relevant when
discussing ellipses; the vertical axis and the horizontal axis.

Now, one can certainly favor a particular axis over the other.
Particularly, there will always be one side of the four that is the
actual closest (or, to be precise, you can always choose a side which
is not farther than any other side), and also one that is the actual
farthest side.  This corresponds to choosing the minor axis under
closest-side, and the major axis under farthest-side.

However, I don't feel that this axis is important *enough* to justify
favoring absolutely (though it may indeed be a decent choice by
default).  In fact, I feel that it's often going to be *more*
important to choose between "horizontal" and "vertical" than between
"major" and "minor", as the former two allow you to control alignment
with other design elements on the page.

So, thoughts so far?  Excepting the final paragraph, do we agree on all points?

> | If you don't know the actual dimensions of the box, <length>s aren't
> | very helpful anyway.  I recommend sticking with percentages in that
> | case.
>
> Not a bad recommendation. However, there are valid exceptions.

Just to be certain, this is purely about the case where you're
aligning with a corner, right, when <size> is closest-corner or
farthest-corner?

Can you illuminate?  I can't personally think of any time when you'd
need to measure precise lengths along a line pointed at an unknown
angle.  (Unknown because it depends on the box dimensions, which
aren't known beforehand - if they *were* known beforehand one could
just use <angle>.)

If there's no need for *precise* lengths, then the angle can be
approximated and used in <angle> so that lengths will be close to the
desired values (they will usually be very close, within a few px I
think), or % can just be used, which produce the same result no matter
where the gradient-line is pointed.

> | It's not meant to be an analogy in those terms, though; it's meant to
> | match with the definition of gradient-line that linear gradients use.
> | When talking about gradient-lines, radial and linear gradients use
> | them nearly identically; the only things different are the default
> | values and how the ending-point is inferred.
>
> Could you expound on this further? In what way is the effect of an angular gradient line identical for your linear and radial gradients? I can certainly see how linear gradients are altered by a change of angle. I fail to see how changing the angle affects radial gradients.

Ah, this may be the source of our mutual confusion, then.  Let me
explain (and if you *do* know all this and instead are objecting to
something else, just let me know):

Start with a 100px by 200px box and a background rule like
"background: radial-gradient(top left, ellipse farthest-side, red,
yellow 50px, green);"  Because <angle> was omitted it defaults to
0deg, which means we measure all lengths from the center (as always)
to the right, with 100% being where this line intersects the
ending-shape (in this case, 100% means 100px).  So we have an
elliptical gradient which transitions from red->yellow for half of its
size, then from yellow->green for the other half.
http://www.xanthir.com/test.php?width=100&height=200&radial-gradient=top%20left,%20ellipse%20farthest-side,%20red,%20yellow%2050px,%20green

But now say we specify "90deg" as the degree.  Now we're measuring
starting from the center and going up, and 100% is now 200px away
because that's the distance to the ending-shape in that direction.
The same rule (with just the addition of the angle) now produces a
gradient where the transition from red->yellow only takes up a
*quarter* of the size, and the yellow->green transition happens over
the remaining 3/4ths.
http://www.xanthir.com/test.php?width=100&height=200&radial-gradient=top%20left%2090deg,%20ellipse%20farthest-side,%20red,%20yellow%2050px,%20green
(It appears that my code for handling <angle> isn't working right at
the moment.  I'll go fix it, but in the meantime here's a link that
shows an equivalent rendering:
http://www.xanthir.com/test.php?width=100&height=200&radial-gradient=top%20left,%20ellipse%20farthest-side,%20red,%20yellow%2025px,%20green
)

Specifying an angle anywhere between 0deg and 90deg creates gradients
somewhat between these two, where the red->yellow transition takes up
somewhere between 25% and 50% of the image.  However, the transition
is always 50px wide *in the direction specified*.  So that's the
significance of specifying the direction.  It lets you be certain that
the <length> you're using will actually align with things properly in
at least one direction.  In any other direction the length might be
stretched or squished as the ellipse deforms from a true circle.

Bringing this back to the original question, radial gradients
determine the color at a particular point be intersecting an ellipse
with the gradient-line - the color at that point of the gradient-line
is the color used for the ellipse.  Similarly, linear gradients
intersect perpendicular lines with the gradient-line, and again the
color at that point of the gradient-line is the color used for the
perpendicular line.

If you've ever used GIMP (I presume Photoshop works similarly), the
gradient-line is precisely the abstraction you use to draw gradients
of both types.  You click and hold at the center point, then drag a
line out to where you want the ending-shape to be and release.  That
line you pull out is the gradient-line that I reference in the
proposal.

~TJ

[Tab Atkins Jr.]

I've also supplemented the proposal with examples now that I have a
generator for them.

Also, the file provided in previous links in this thread will die at
some point in the future (I overwrite files named "test" without
thought).  The more-or-less permanent location of the gradient
generator is now
http://www.xanthir.com/etc/gradient-example/gradient.php.  Feed it
three arguments in the query string: a "width" parameter giving a
length in pixels, a "height" parameter also giving a length in pixels,
and a "radial-gradient" parameter containing the contents of the
radial-gradient() rule.

Frex, the first example on the proposal is generated with this url:
http://www.xanthir.com/etc/gradient-examples/gradient.php?width=100&height=200&radial-gradient=yellow,green

As this uses a hand-implemented CSS parser, it accepts only a subset
of the full CSS language.  Lengths must be provided in either px or %,
angles must be provided in deg, and colors must either be an SVG color
name or a hex value *without the #*.

As before, the proposal itself can be found at:
http://www.xanthir.com/:4bhipd

It hosts both the linear and radial gradient proposals, so scroll down
a bit to see the radial gradients.

~TJ

[David Perrell]

Tab Atkins Jr. wrote:
| Specifically, when using closest-side, the vertical axis of the
| ellipse is the distance from the starting-point to the top or bottom
| of the box, whichever is closer, and similarly for the horizontal
| axis.  Thus there are two axis-aligned lengths that are relevant when
| discussing ellipses; the vertical axis and the horizontal axis.
|
| Now, one can certainly favor a particular axis over the other.
| Particularly, there will always be one side of the four that is the
| actual closest (or, to be precise, you can always choose a side which
| is not farther than any other side), and also one that is the actual
| farthest side.  This corresponds to choosing the minor axis under
| closest-side, and the major axis under farthest-side.

My argument was for a gradient-line that extends directly from the start-point to whichever side is nearest to or farthest from that point. The problem with that, as I see it, is that in some cases the gradient line can be on the same axis for both nearest and farthest sides. I do think it important in some cases to force the gradient line to the longest radius. I might want some tight <length> color stops on the major axis that can't be specified on the minor one, because the values will compress to sub-pixel lengths.
|
| However, I don't feel that this axis is important *enough* to justify
| favoring absolutely (though it may indeed be a decent choice by
| default).  In fact, I feel that it's often going to be *more*
| important to choose between "horizontal" and "vertical" than between
| "major" and "minor", as the former two allow you to control alignment
| with other design elements on the page.
|
| So, thoughts so far?  Excepting the final paragraph, do we agree
| on all points?

Still feel that <angle> is inappropriate for anything except ellipse tilt - that to be consistent with linear-gradient, <angle> would describe the angle of the minor axis. But it looks like that's just me.

| Just to be certain, this is purely about the case where you're
| aligning with a corner, right, when <size> is closest-corner or
| farthest-corner?
|
| Can you illuminate?

Not without doing graphical examples of what happens when the box is resized, so I'll retract my contention (yes, it was about to-corner). Anyway, I doubt the feature would get as much use as, say, aspect-ratio.

| Ah, this may be the source of our mutual confusion, then.  Let me
| explain (and if you *do* know all this and instead are objecting to
| something else, just let me know):

I understand the effects you expound on, but have a hard time seeing the angle as being analogous to linear-gradient's <angle>, which specifies the gradient's direction. The radial-gradient's <angle> only effects the relative position of the color-stops.

"...is always 50px wide *in the direction specified*.  So that's the
significance of specifying the direction.  It lets you be certain that
the <length> you're using will actually align with things properly in
at least one direction.  In any other direction the length might be
stretched or squished as the ellipse deforms from a true circle."

"If you've ever used GIMP (I presume Photoshop works similarly), the
gradient-line is precisely the abstraction you use to draw gradients
of both types.  You click and hold at the center point, then drag a
line out to where you want the ending-shape to be and release.  That
line you pull out is the gradient-line that I reference in the
proposal."

OK, your case is abstractly clarified. And your samples look good.

Now, the gadfly must buzz off. Unfortunate events are forcing me to stop 'fiddling' with specs for a while. Take care all.

David Perrell

[Robert O'Callahan-3]

On Sat, Sep 5, 2009 at 1:53 PM, Tab Atkins Jr. <jackalmage@...> wrote:

I'm finally happy with my radial-gradient() syntax.  You can view it
at http://www.xanthir.com/:4bhipd (scroll down past the
linear-gradient() examples).

 

We landed an implementation of this spec on Firefox trunk today --- with a -moz prefix, of course --- so it'll be in the latest nightly build by now. We think it's pretty complete. So people who want to experiment with this in a browser can now do so. Feedback appreciated.

Rob
--
"He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6]

[Tab Atkins Jr.]

On Tue, Nov 3, 2009 at 3:21 AM, Robert O'Callahan <robert@...> wrote:

> On Sat, Sep 5, 2009 at 1:53 PM, Tab Atkins Jr. <jackalmage@...> wrote:
>>
>> I'm finally happy with my radial-gradient() syntax.  You can view it
>> at http://www.xanthir.com/:4bhipd (scroll down past the
>> linear-gradient() examples).
>
>
> We landed an implementation of this spec on Firefox trunk today --- with a
> -moz prefix, of course --- so it'll be in the latest nightly build by now.
> We think it's pretty complete. So people who want to experiment with this in
> a browser can now do so. Feedback appreciated.

Last night I also integrated the full spec into the dev copy of CSS3
Images[1], so you can check that out if you want an official view of
what's up.  (It's the same as the copy on my site, I just reworked the
examples slightly and used the FF trybuild to generate new pictures.)

[1]: http://dev.w3.org/csswg/css3-images/e

[Simon Fraser-4]

On Nov 3, 2009, at 8:00 AM, Tab Atkins Jr. wrote:

On Tue, Nov 3, 2009 at 3:21 AM, Robert O'Callahan <robert@...> wrote:

On Sat, Sep 5, 2009 at 1:53 PM, Tab Atkins Jr. <jackalmage@...> wrote:

I'm finally happy with my radial-gradient() syntax.  You can view it

at http://www.xanthir.com/:4bhipd (scroll down past the

linear-gradient() examples).

We landed an implementation of this spec on Firefox trunk today --- with a

-moz prefix, of course --- so it'll be in the latest nightly build by now.

We think it's pretty complete. So people who want to experiment with this in

a browser can now do so. Feedback appreciated.

Last night I also integrated the full spec into the dev copy of CSS3
Images[1], so you can check that out if you want an official view of
what's up.  (It's the same as the copy on my site, I just reworked the
examples slightly and used the FF trybuild to generate new pictures.)

[1]: http://dev.w3.org/csswg/css3-images/e

Correct link:

<http://dev.w3.org/csswg/css3-images/#gradients->

Simon

[Tab Atkins Jr.]

On Tue, Nov 3, 2009 at 8:38 AM, Simon Fraser <smfr@...> wrote:
> Correct link:
> <http://dev.w3.org/csswg/css3-images/#gradients->
> Simon

Sorry about that.  Really not sure where that "e" came from.

~TJ

[Brad Kemper]

Do I need to wait until tonight? I am not getting it with the latest  
Minefield.

On Nov 3, 2009, at 3:21 AM, Robert O'Callahan wrote:

> We landed an implementation of this spec on Firefox trunk today ---  
> with a -moz prefix, of course --- so it'll be in the latest nightly  
> build by now. We think it's pretty complete. So people who want to  
> experiment with this in a browser can now do so. Feedback appreciated.

[Robert O'Callahan-3]

On Wed, Nov 4, 2009 at 10:18 AM, Brad Kemper <brad.kemper@...> wrote:

Do I need to wait until tonight? I am not getting it with the latest Minefield.

 

This should have it:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central/

Rob
--
"He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6]

[Ryan Seddon]

On Tue, Nov 3, 2009 at 10:21 PM, Robert O'Callahan <robert@...> wrote:

On Sat, Sep 5, 2009 at 1:53 PM, Tab Atkins Jr. <jackalmage@...> wrote:

I'm finally happy with my radial-gradient() syntax.  You can view it
at http://www.xanthir.com/:4bhipd (scroll down past the
linear-gradient() examples).

 

We landed an implementation of this spec on Firefox trunk today --- with a -moz prefix, of course --- so it'll be in the latest nightly build by now. We think it's pretty complete. So people who want to experiment with this in a browser can now do so. Feedback appreciated.

Why was linear-gradient, radial-gradient decided? To me it would make more sense to have the syntax as gradient-linear, gradient-radial, gradient-repeating-radial etc. They're all gradients and would make more sense, especially if scanning a CSS document you could determine a lot quicker that those styles are all gradients.

-Ryan

[Tab Atkins Jr.]

On Tue, Nov 3, 2009 at 7:41 PM, Ryan Seddon <seddon.ryan@...> wrote:

> On Tue, Nov 3, 2009 at 10:21 PM, Robert O'Callahan <robert@...>
> wrote:
>>
>> On Sat, Sep 5, 2009 at 1:53 PM, Tab Atkins Jr. <jackalmage@...>
>> wrote:
>>>
>>> I'm finally happy with my radial-gradient() syntax.  You can view it
>>> at http://www.xanthir.com/:4bhipd (scroll down past the
>>> linear-gradient() examples).
>>
>>
>> We landed an implementation of this spec on Firefox trunk today --- with a
>> -moz prefix, of course --- so it'll be in the latest nightly build by now.
>> We think it's pretty complete. So people who want to experiment with this in
>> a browser can now do so. Feedback appreciated.
>
> Why was linear-gradient, radial-gradient decided? To me it would make more
> sense to have the syntax as gradient-linear, gradient-radial,
> gradient-repeating-radial etc. They're all gradients and would make more
> sense, especially if scanning a CSS document you could determine a lot
> quicker that those styles are all gradients.

SVG uses <linearGradient> and <radialGradient> already, so it's nice
to conform to the existing naming scheme (modulo the CSS preference
for dashes over camelCase).

~TJ