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

Re: Gradient syntax proposal -- Problems

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 27 Aug 2009 19:08:05 -0500
Message-ID: <dd0fbad0908271708q1080dbafrb5c322fc78f16e4f@mail.gmail.com>
To: James Elmore <James.Elmore@cox.net>
Cc: CSS <www-style@w3.org>
On Thu, Aug 27, 2009 at 6:57 PM, James Elmore<James.Elmore@cox.net> wrote:
>> Edits have been made to the master proposal, located at
>> http://www.xanthir.com/:4bhipd.  I also added a line with the syntax
>> to the first example.
>> I'm not happy with how I phrased the comma thing, or with the fact
>> that I had to say it at all.  I think it's confusing.  I suspect that
>> it would be better to handle that in the grammar, but I'm not sure of
>> how to write it.  Ideas?
>> ~TJ
> Thanks for the updated proposal. I am working my way through it and hope to
> find few problems -- many have already been pointed out in the discussion.
> However, in the following paragraph, I believe the corners are misstated.
> <<If the <bg-position> is omitted in the first argument, the starting-point
> is in one of the box's corners, based on the <angle>. If the angle is
> between [0deg,90deg], the starting point is the bottom-left corner. If the
> angle is between [90deg,180deg], the starting point is the bottom-right
> corner. If the angle is between [180deg,270deg], the starting point is the
> top-left corner. If the angle is between [270deg,360deg], the starting point
> is the top-right corner. The ending-point is determined in the manner
> described by the previous paragraph.>>
> Odeg to 90deg is the lower left corner. [correct]
> 90 to 180 is the lower right corner. [correct]
> 180 to 270 should be the upper right corner. [states top-right]
> and 270deg to 360deg then has to be the top left corner.

Ah, you're correct.  Fixed now.

> Also -- what about overlaps? Can we safely ignore 0/360, 90, 180, and 270
> degrees simply because they align with one side of the box? Would the
> gradient not still be visible, but be drawn in opposite directions,
> depending on which direction the gradient line is drawn?

Can you elaborate?  I suppose I can be exact with the ranges, but the
overlap scenarios are unimportant because, for example, a 90deg
gradient (pointing up) produces an identical display if the
starting-point is *anywhere* along the bottom edge.

I've gone ahead and made the ranges half-open, though, to forestall
any confusion.

> For example, suppose the user specifies 90 degrees. The gradient line would
> be parallel to the bottom of the box. If there are no offsets from the
> bg-position, it will be on top (underneath?) the bottom of the box. However,
> if the UA selects 90 degrees to start at the bottom left corner, the
> gradient line would be oriented left-to-right. Or, if the UA selects 90
> degrees as the bottom right corner, the gradient line would be oriented
> right-to-left. The specification needs to make clear which behavior is
> correct, or allow some way for users / designers to specify the direction of
> the gradient line. Clearly, the users can reverse the order of their
> color-stops, PROVIDED they know in advance which direction the UA will pick.
> Otherwise, the gradient might be reversed and the users will not be able to
> know the correct direction.

You're slightly confused about the direction - 0deg is East, 90deg is
North.  This aligns with standard mathematical usage - it's what I've
been taught in every math course since Algebra 2 (10th grade math).
At first blush this feels like it goes against the definition of
angles used elsewhere, but not really - every use of <angle> I've seen
uses it to define a rotation rather than a direction.  The only
unfortunate part is that positive angles seem to produce a clockwise
rotation, while making the angle more positive when it's a direction
moves it CCW.

So far I've though that it was worthwhile to stick with familiar
mathematical notation, but if it causes too much confusion we can
switch to a "0deg is North, 90deg is East" model.

Thanks for the feedback, James!

Received on Friday, 28 August 2009 00:09:10 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:28 UTC