Re: Gradient syntax proposal

On Fri, Aug 14, 2009 at 3:01 PM, Brad Kemper<brad.kemper@gmail.com> wrote:
> On Aug 14, 2009, at 11:03 AM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:
>> I don't see why the color *has* to come first, still.  Leaving it as
>> it is, where you can specify them in either order.
>
> If you keep the ability to specify the starting point as a coordinate that
> could contain percentages or lengths, then it can be very confusing to have
> the first thing after be a percentage (or a length). Making the color as the
> first item of the pair prevents that. If we get rid of the coordinate stops
> then it's not s problem.

Alternate idea: bring back the functional syntax for this.  ^_^
"point(<bg-position) point(bg-position)" would work.  That way we're
not introducing a sometimes-comma, and the complex lengths/percentages
are clearly separated from the color-stops.

I'm really not averse to requiring [<color> <percentage>?], I just
don't feel like restricting it unless necessary.

>> Also, leaving out <distance>.  Mixing percentages and distances brings
>> up the possibility (in fact, the certainty) of color-stops swapping
>> their order based on box size.  I don't think that's desirable.  The
>> only way around it would be to force the color-stops to be specified
>> in order, and say that out-of-order stops are treated the same as
>> same-position stops (they produce an instant transition from the first
>> specified to the last).  Would this be okay?
>
> I think it would be OK to have the starting and ending points as distances
> or percentages, and have either percentages-only or distances-only in
> between.

I thought about allowing distances for the start/end points, but this
produces an ambiguity.  Is 0%/100% defined by the first and last
color-stop, or by <direction>?  If the former, how does this work when
first/last color-stops have a %?

> Any distance that went beyond 100% would be clipped (unless we are
> seriously going to define "running into a side" as being 100%.

I can seriously see myself wanting to do "background:
linear-gradient(-45deg inner, silver, white)" on a long article, as a
little visual flourish that only affects the top of the block.

> If you have the starting point and/or ending point as a distance, then you
> don't need to use x/y coordinates for anything.

I already tried and discarded this while writing my draft.  Putting a
distance on the first color-stop is possible, but it then needs to
actually redefine the starting-point of the gradient-line, and thus
affect what % means in the other color-stops.  Putting a distance on
the last stop doesn't work at all, because distance on a color-stop
means how far away it is from the starting-point.  You're trying
instead indicate how far from the *original ending-point* the new
ending-point should be.

>>> Briefly, about "inner": I think it is very unusual. When I create an
>>> angled
>>> gradient box in PhotoShop, it fills the whole thing to all corners. It
>>> does
>>> not start in one corner and then just stop once it hits a side. That
>>> would
>>> be weird.
>>
>> In GIMP I have a choice.  I just click at the starting point, drag to
>> the ending point, and let go.  I can definitely see me wanting this
>> type of gradient, especially as a visual effect at the top of an
>> unpredictably tall box.
>
> You can do that in PhotoShop too, but it isn't the default for a gradient
> fill. Even so, what you're talking about is setting starting and ending
> points other than 0 and 100% (where it might also be handy to use distances
> instead of percent). You aren't talking about a gradient that automatically
> stops at a side.

As stated up above, linear-gradient(-45deg inner, silver, white) could
add an attractive flourish to the top of a long article.  Similarly,
linear-gradient(45deg inner, <color>, white) could be attractive at
the bottom of a box.

>> I agree, and that's how my proposal already handles it.  Before the
>> first color-stop the color is the same as the first color-stop, and
>> same with the last color-stop.
>>
>>> If you have named sides (like you do) and named corners (something like
>>> border-radius has in its 4 names), then you don't need to mention the
>>> opposite side at all. You also then don't need to use the bg-position
>>> coordinate system with its possibility of 4 lengths separated by another
>>> comma.
>>
>> Agreed; I've already changed to named corners based on your email.
>>
>> You do still need bg-position coordinates if you want anything more
>> controlled than the angle or side-side/corner-corner gradients.
>
> No you don't.  You can do that by setting the distance from the
> defined/implied corner/side for the start, and a distance from it's opposite
> for the end. One number is simpler than two.

How would you integrate this into the syntax?  I've hopefully
explained up above why just putting these distances on the first/last
color-stop doesn't work.

~TJ

Received on Friday, 14 August 2009 20:34:50 UTC