Re: Gradient syntax proposal

Sent from my iPhone

On Aug 14, 2009, at 2:54 PM, "Tab Atkins Jr." <jackalmage@gmail.com>  
wrote:

> On Fri, Aug 14, 2009 at 4:27 PM, Brad Kemper<brad.kemper@gmail.com>  
> wrote:
>>
>>
>> On Aug 14, 2009, at 1:33 PM, "Tab Atkins Jr."  
>> <jackalmage@gmail.com> wrote:
>>
>>> 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.
>>
>> Using xy points is really not neccesary when 0% is always a corner  
>> or side,
>> and 100% is always it's opposite corner.
>
> Indeed, but the whole purpose of the <bg-position> construction is to
> allow gradients that start/end at points *not* on a corner or
> side-center.  (Example 7 in my draft.)

Given that each color of the gradient is a 2 diminsuonal line,  
perpendicular to the angle, the need to start somewhere other than  
some distance or percentage from a corner or side seems like an  
extreme edge case, and not worth the extra complexity and readability  
problems.


>
>>> I'm really not averse to requiring [<color> <percentage>?], I just
>>> don't feel like restricting it unless necessary.
>>
>> It's not neccesary if we get rid of the measurements before the  
>> first stop,
>> as I've suggested.
>
> Not convinced yet that that's desirable.  The additional comma has
> been removed at this point, though, and I've changed the separator
> between the direction and color-stops to be / rather than a comma.
> That should completely disambiguate things.

I'm OK with that.

>
>>>>> 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 %?
>>
>> Usually, 0% would always be a corner or side, and 100% would always  
>> be it's
>> opposite. But... I think that maybe if the first and last are both  
>> fixed
>> lengths with percentages between them, then they could become the  
>> new 0% and
>> 100%. But only in that case and no others. If that's too  
>> complicated then
>> just don't mix at all.
>
> Hmm...
>
>>>> 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.
>>
>> It seems kind of unpredictable or difficult to imagine where that  
>> would
>> stop. I think you'd want more control. Like this:
>>
>> background: linear-gradient(-45deg, silver 0, white 200px)
>>> [snip]
>>> You're trying
>>> instead indicate how far from the *original ending-point* the new
>>> ending-point should be.
>>
>> No I'm not. I'm measuring from the starting point to say where the  
>> ending
>> point should be.
>
> I'm not sure that it's useful to be able to say "push the starting
> point this many pixels from the original location", but then "set the
> ending-point to this new distance from the starting point".

I meant from the original starting point.

> The two
> things aren't symmetrical now.  Better if we can specify someway that
> the start should be x distance from the edge/corner, and the end
> should be y distance from the edge/corner.

That's what I meant, if you are talking about the same corner or edge.  
Except I wouldn't use x and y, since they tend to equate to horizontal  
and vertical positions.  A and B.

> In other words, I want a gradient that goes left-to-right, but leaving
> 100px free on each edge.

linear-gradient(left, silver 100px, black calc(100% - 200px)

> I'm not sure how wide the box would be.  I
> can't do this in your proposal - something like "linear-gradient(left
> / white 100px, silver 50%, white 100px)" would instead either do
> nothing, or make an image with 100px of white, then 50px of
> white->silver and 50px of silver->white, with white filling the rest.
>
> I can do this with the <bg-position> construction, as
> "linear-gradient(100px top to calc(100% - 100px) top / white, silver,
> white)".

I like mine better.

Received on Friday, 14 August 2009 23:17:38 UTC