Comments on gradient syntax proposal

[L. David Baron]

Here are a few minor comments on the current version gradient syntax
proposal at http://www.xanthir.com/:4bhipd .  (It might be good to
have a dated version archived at some point, though.)  I noticed
these issues while reviewing the patch to implement this proposal in
Mozilla.

# if relevant, the angle is normalized to within the range
# [0,360deg)
(occurs once for linear gradients and once for radial)

Normalizing angles is a bad idea for animation.  It makes it
impossible to animate angles through a sweep that includes pointing
left.  I think you should just remove mention of normalization.

# Between two color-stops, the colors are interpolated as SVG
# gradients.

The spec ought to say explicitly whether this means that the
'color-interpolation' property applies.  See
http://www.w3.org/TR/SVG11/painting.html#ColorInterpolationProperty

In the description of radial gradients:

# The image is constructed by creating an infinite canvas and
# painting it with concentric copies of the ending-shape, with the
# color of the painted shape being the color of the gradient-line
# where the two intersect.

Saying that ellipses are concentric doesn't define what they are.  I
think what you want to say is that they are concentric *and* the
ratio of their major axis to minor axis is constant.  (You could,
for example, have concentric ellipses that are confocal, but I
really don't think that's what's desired here.)

# If <shape> is ellipse and <size> is closest-side, the
# gradient-shape is an ellipse sized so that it exactly meets the
# two sides of the box closest to its center.

This needs to say that it's the closest horizontal side and the
closest vertical side, since the two closest sides might be
parallel.

-David

--
L. David Baron                                 http://dbaron.org/
Mozilla Corporation                       http://www.mozilla.com/

[Tab Atkins Jr.]

On Tue, Oct 27, 2009 at 11:24 AM, L. David Baron <dbaron@...> wrote:

> Here are a few minor comments on the current version gradient syntax
> proposal at http://www.xanthir.com/:4bhipd .  (It might be good to
> have a dated version archived at some point, though.)  I noticed
> these issues while reviewing the patch to implement this proposal in
> Mozilla.
>
> # if relevant, the angle is normalized to within the range
> # [0,360deg)
> (occurs once for linear gradients and once for radial)
>
> Normalizing angles is a bad idea for animation.  It makes it
> impossible to animate angles through a sweep that includes pointing
> left.  I think you should just remove mention of normalization.

That makes it more difficult to specify the starting-corner for
gradients that have an <angle> argument.  Would it be sufficient to
move the talk of normalization to that section of the spec, avoiding
any possibility that an implementor accidentally normalizes early?

> # Between two color-stops, the colors are interpolated as SVG
> # gradients.
>
> The spec ought to say explicitly whether this means that the
> 'color-interpolation' property applies.  See
> http://www.w3.org/TR/SVG11/painting.html#ColorInterpolationProperty

Should it apply?  I'm not sure.  I don't have a good grasp of SVG.

> In the description of radial gradients:
>
> # The image is constructed by creating an infinite canvas and
> # painting it with concentric copies of the ending-shape, with the
> # color of the painted shape being the color of the gradient-line
> # where the two intersect.
>
> Saying that ellipses are concentric doesn't define what they are.  I
> think what you want to say is that they are concentric *and* the
> ratio of their major axis to minor axis is constant.  (You could,
> for example, have concentric ellipses that are confocal, but I
> really don't think that's what's desired here.)

I have added the word "similar" to that sentence, which should address this.

> # If <shape> is ellipse and <size> is closest-side, the
> # gradient-shape is an ellipse sized so that it exactly meets the
> # two sides of the box closest to its center.
>
> This needs to say that it's the closest horizontal side and the
> closest vertical side, since the two closest sides might be
> parallel.

I've made this change to the areas I could spot that needed it.

~TJ

[L. David Baron]

On Tuesday 2009-10-27 12:15 -0500, Tab Atkins Jr. wrote:
> That makes it more difficult to specify the starting-corner for
> gradients that have an <angle> argument.  Would it be sufficient to
> move the talk of normalization to that section of the spec, avoiding
> any possibility that an implementor accidentally normalizes early?

You can specify the starting corner as:
  bottom-left if sin(angle) >= 0 and cos(angle) >= 0
  bottom-right if sin(angle) < 0 and cos(angle) >= 0
  top-right if sin(angle) < 0 and cos(angle) < 0
  top-left if sin(angle) >= 0 and cos(angle) < 0
(Those work out slightly differently at the vertical/horizontal
cases, but it doesn't matter.)

That said, I think the formulation where the angle-only gradients
have a gradient line going through the center actually turns out
easier to implement (see
https://bugzilla.mozilla.org/show_bug.cgi?id=513395#c48 ).

> > # Between two color-stops, the colors are interpolated as SVG
> > # gradients.
> >
> > The spec ought to say explicitly whether this means that the
> > 'color-interpolation' property applies.  See
> > http://www.w3.org/TR/SVG11/painting.html#ColorInterpolationProperty
>
> Should it apply?  I'm not sure.  I don't have a good grasp of SVG.

I'm not sure whether people find the 'linearRGB' option useful.
Mozilla doesn't implement color-interpolation (though we do
implement color-interpolation-filters, I think).

> > In the description of radial gradients:
> >
> > # The image is constructed by creating an infinite canvas and
> > # painting it with concentric copies of the ending-shape, with the
> > # color of the painted shape being the color of the gradient-line
> > # where the two intersect.
> >
> > Saying that ellipses are concentric doesn't define what they are.  I
> > think what you want to say is that they are concentric *and* the
> > ratio of their major axis to minor axis is constant.  (You could,
> > for example, have concentric ellipses that are confocal, but I
> > really don't think that's what's desired here.)
>
> I have added the word "similar" to that sentence, which should address this.

Well, confocal ellipses are "similar".  It might work if you use
"scaled" instead of "similar" though.

-David

--
L. David Baron                                 http://dbaron.org/
Mozilla Corporation                       http://www.mozilla.com/

[Tab Atkins Jr.]

Listserv ate this the first time.


---------- Forwarded message ----------
From: Tab Atkins Jr. <jackalmage@...>
Date: Tue, Oct 27, 2009 at 10:54 AM
Subject: Re: Comments on gradient syntax proposal
To: "L. David Baron" <dbaron@...>
Cc: www-style@...


On Tue, Oct 27, 2009 at 12:40 PM, L. David Baron <dbaron@...> wrote:

> On Tuesday 2009-10-27 12:15 -0500, Tab Atkins Jr. wrote:
>> That makes it more difficult to specify the starting-corner for
>> gradients that have an <angle> argument.  Would it be sufficient to
>> move the talk of normalization to that section of the spec, avoiding
>> any possibility that an implementor accidentally normalizes early?
>
> You can specify the starting corner as:
>  bottom-left if sin(angle) >= 0 and cos(angle) >= 0
>  bottom-right if sin(angle) < 0 and cos(angle) >= 0
>  top-right if sin(angle) < 0 and cos(angle) < 0
>  top-left if sin(angle) >= 0 and cos(angle) < 0
> (Those work out slightly differently at the vertical/horizontal
> cases, but it doesn't matter.)
>
> That said, I think the formulation where the angle-only gradients
> have a gradient line going through the center actually turns out
> easier to implement (see
> https://bugzilla.mozilla.org/show_bug.cgi?id=513395#c48 ).

Hmm, you're right.  That does give an equivalent line.  It also seems
like it matches up better with the notions of revolving the
starting-point around that the no-<angle> case does.  I'll see how I
can revise this.

Preflight-edit:  How does this language sound?
If the `<bg-position>` is omitted in the first argument, then,
starting from the center of the box, extend the gradient-line in both
directions at the angle specified by `<angle>`.  The ending-point of
the gradient-line is where a line drawn perpendicular to the
gradient-line intersects the corner of the box in the direction of the
`<angle>`; the starting-point is figured identically, but the corner
used is the opposite of the one used to determine the ending-point.
For example, specifying an angle of "45deg" would make the
ending-point be determined by where a line perpendicular to the
gradient-line intersected the top-right corner when extended from the
center at a 45deg angle, and the starting-point would be the same but
using the bottom-left corner.

If both `<bg-position>` and `<angle>` are specified, the starting and
ending points of the gradient-line are determined as described in the
previous paragraph, except that the starting-point is where a line
drawn perpendicular to the gradient-line would intersect with the
point specified by the `<bg-position>`.  (In some cases this may cause
the gradient to 'reverse direction', for example if you specify "-10px
-10px 135deg" - the ending-point is to the right of the
starting-point, even though the `<angle>` points up and left.)

(Sorry for the formatting marks creeping in - I write those documents
in Markdown.)

>> > # Between two color-stops, the colors are interpolated as SVG
>> > # gradients.
>> >
>> > The spec ought to say explicitly whether this means that the
>> > 'color-interpolation' property applies.  See
>> > http://www.w3.org/TR/SVG11/painting.html#ColorInterpolationProperty
>>
>> Should it apply?  I'm not sure.  I don't have a good grasp of SVG.
>
> I'm not sure whether people find the 'linearRGB' option useful.
> Mozilla doesn't implement color-interpolation (though we do
> implement color-interpolation-filters, I think).

I wouldn't know if it's useful either - that's why I asked you.  ^_^
For now I'll leave it unspecified - implementors, please let me know
yay or nay on this issue.  (I suspect the answer will be "yes, it
should apply".)

>> > In the description of radial gradients:
>> >
>> > # The image is constructed by creating an infinite canvas and
>> > # painting it with concentric copies of the ending-shape, with the
>> > # color of the painted shape being the color of the gradient-line
>> > # where the two intersect.
>> >
>> > Saying that ellipses are concentric doesn't define what they are.  I
>> > think what you want to say is that they are concentric *and* the
>> > ratio of their major axis to minor axis is constant.  (You could,
>> > for example, have concentric ellipses that are confocal, but I
>> > really don't think that's what's desired here.)
>>
>> I have added the word "similar" to that sentence, which should address this.
>
> Well, confocal ellipses are "similar".  It might work if you use
> "scaled" instead of "similar" though.

They're not similar in the math sense that I know of, where the only
transformations allowed are scaling and translation (and the latter is
eliminated by the 'concentric' requirement).  But I can use 'scaled'
instead.

~TJ