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

Fwd: Comments on gradient syntax proposal

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 3 Nov 2009 09:05:45 -0800
Message-ID: <dd0fbad0911030905x60257315kc5202ec77117a237@mail.gmail.com>
To: www-style list <www-style@w3.org>
Listserv ate this the first time.

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

On Tue, Oct 27, 2009 at 12:40 PM, L. David Baron <dbaron@dbaron.org> 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'

Received on Tuesday, 3 November 2009 17:06:34 UTC

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