Re: Gradient syntax proposal

On Fri, Aug 14, 2009 at 6:13 PM, fantasai<fantasai.lists@inkedblade.net> wrote:
> Tab Atkins Jr. wrote:
>>
>> On Fri, Aug 14, 2009 at 5:16 PM, Tab Atkins Jr.<jackalmage@gmail.com>
>> wrote:
>>>
>>> Yeah, but allowing the literate form (in addition to the short "left"
>>> form) makes a *wonderful* parallel to the full <bg-position>
>>> construction, so it's easy to learn and understand.  This suggestion
>>> from Elika was a definite win in my mind.
>>
>> After some thought, I think I'd rather make that parallel explicit.  I
>> want to change the second construction back to only taking a single
>> keyword, but then add those keywords to the possible values in the
>> second construction, and define what they translate to in terms of
>> <bg-position>.  "left", frex, would translate to "left center" as a
>> <bg-position>.
>>
>> The syntax would then look like:
>>
>> [
>>  <angle> [ inside | outside ]?
>> |
>>  <point>
>> |
>>  [ <bg-position> | <point> ] to [ <bg-position> | <point> ]
>> ]
>>
>> with <point> being [ left | right | top | bottom | top-left |
>> top-right | bottom-left | bottom-right ].
>>
>> Sound good?
>
> I'd drop the combination keywords, because you can write them
> as <bg-position>. (top-left vs top left is not an improvement,
> just makes things more confusing). Also <bg-position> already
> allows single keywords:
>  http://www.w3.org/TR/CSS21/colors.html#background-properties
>
> So like this:
>
> [
>  <angle> [ inside | outside ]?
> |
>  <bg-position> [ to <bg-position> ]?
> ]

Hmm, okay.  That would simplify the construction even more, which I
like.  We just need to address the case when a complex <bg-position>
(not on the edge of the box) is given but the second part is omitted.
I'm inclined to just say that in all cases, an omitted second position
defaults to a point obtained by rotating the starting-point 180deg
around the center of the box.

That way linear-gradient(10px 10px / white black) would be equivalent
to linear-gradient(10px 10px to right 10px bottom 10px / white black)
which is equivalent to linear-gradient(10px 10px to calc(100% - 10px)
calc(100% - 10px) / white black).  It also makes the definitions of
the simple cases (like just "left") fall out naturally as we intend.

Change accepted.

> Also, I would like to see the ability to combine lengths and
> start positions with the angle, as in
>  http://lists.w3.org/Archives/Public/www-style/2009Aug/0142.html
> because I think in many cases it will be simpler than picking two
> sets of coordinates.
>
> So
>
> [
>  <bg-position>? <angle> <length>?
> |
>  <angle> [ inside | outside ]
> |
>  <bg-position> [ to <bg-position> ]?
> ]
>
> or simply
>
> [
>  <bg-position>? <angle> <length>?
> |
>  <bg-position> [ to <bg-position> ]?
> ]
>
> if we drop the 'inside' option.

<bg-position> added to the angle, defaulting to one of the corners as
before.  There's no need for <length> - it can be specified implicitly
through the color-stops if we allow <length>s there alongside
<percentage>s, which I've now done in my draft.

The only complication I had to deal with was a case like
linear-gradient(left / white, red 200px, black).  What should the
black default to?  What if the box is only 100px wide?  I resolved it
by first explicitly stating that color-stops may come before
starting-point and after the ending-point, and then saying that if
you're using lengths and the stops already exceed the ending-point,
the color is ignored, otherwise it's treated as 100%.  If you're using
percentages, the last one always defaults to 100%, because then it
can't change order based on the box-size.

So if the box is at least 200px wide, it's equivalent to
linear-gradient(left / white, red 200px, black 100%).  Othrwise, it's
equivalent to linear-gradient(left / white, red 200px).

Does this seem like a reasonable solution?

~TJ

Received on Saturday, 15 August 2009 00:13:37 UTC