Re: Gradient syntax proposal

On Sat, Aug 15, 2009 at 11:02 AM, Brad Kemper<brad.kemper@gmail.com> wrote:
>
> On Aug 14, 2009, at 8:52 PM, Tab Atkins Jr. wrote:
>
>> On Fri, Aug 14, 2009 at 8:42 PM, Brad Kemper<brad.kemper@gmail.com> wrote:
>>>
>>>
>>> Sent from my iPhone
>>>
>>> On Aug 14, 2009, at 5:12 PM, "Tab Atkins Jr." <jackalmage@gmail.com>
>>> wrote:
>>>
>>>> would be equivalent
>>>> to linear-gradient(10px 10px to right 10px bottom 10px / white black)
>>>
>>> I have no idea what that would look like. What does 10px bottom 10px
>>> mean?
>>
>> "right 10px bottom 10px".  It's a background-position.  10px from the
>> right, 10px from the bottom.
>
> Oh yeah. I read "to right" as one thing. That is just too long of a string
> of numbers just to get to the first color. Its hard to read.

It is a bit long.  It's rare that you would ever need to do that,
though.  The shortest form is just "linear-gradient(10px 10px / white
black)" - the ending point is implied to be 10px from the bottom and
right edges.

The simple constructions, either in the form of a simple angle, a
single keyword, or a singe point, do address the vast majority of
cases.  But the engine to do more is already there - once you can
create a gradient at an arbitrary angle, you've pretty much done
*everything*.  The webkit and gecko versions currently in live code
have all this complexity built in already, too; what they're missing
is the simple forms!

Restricting yourself to *just* the simple forms doesn't gain you
anything.  It doesn't make it faster to implement, and it doesn't
somehow enable an even simpler syntax.  The simple forms are as
stripped-down as it is possible to be.  You now just have the ability,
when you need it, to specify things to a greater degree when
necessary.

>>>> which is equivalent to linear-gradient(10px 10px to calc(100% - 10px)
>>>> calc(100% - 10px) / white black)
>>>
>>> Holy Mackeral! My head is going to explode! Who needs that much
>>> complexity?
>>
>> Yeah, it's complex.  But it's no more complex than a background, since
>> it uses the same syntaxes.  That means that an author can apply the
>> knowledge they already have to this, or learn new details from this
>> and apply it back to backgrounds.
>
> It means that something that is supposed to be a short function within a
> background is the most complex part of the background property. It means you
> get long, hard to visualize strings of numbers, just to get to where the the
> gradation starts and what direction it goes and where it stops. This is al
> before even mentioning the positions of the 2 or more stops.

If and only if you need that level of complexity.  If you don't, you
can just say "left" and be done with it.

> Yet anyone who can figure out the distance from the left and top could just
> as easily figure out (or estimate) the single distance from that corner.
> Even if you can't get the gradation to start on the exact same pixel without
> a lot of trial and error, who cares? Who's going to be able to tell the
> difference on something the gradually blends from one color to another?
>
> There's no learning gain in putting 4 distance/percentage numbers into the
> beginning of the function, for people who are already learning to group and
> associate simpler distance/percentage numbers with the color stops
> (percentages that all refer to the same thing, instead of some to the width,
> some to the height, and some to the length of the gradation... or length
> distances that are all measured from the same point, instead of some that
> are from the left, some from the top, and some from the beginning of the
> gradation). You are just adding a second, longer way to do the same thing,
> one which will not make a positive difference for any but a tiny, tiny
> fraction of its actual use in practice (a "tiny minority of a tiny
> minority", to use your earlier language, might find some blending tasks that
> would benefit from the extra complexity).

Indeed the use-case served is a tiny minority of a tiny minority.  But
serving that use-case doesn't cost us any implementation time, nor
does it complexify the syntax for the simple cases.  If you don't ever
need it, it has literally no effect on you ever, direct or indirect.

> Speaking of applying previous knowledge, how about my PhotoShop experience?
> When I use the gradient tool in PhotoShop, I consider where how far in (or
> out) I want the starting color to start, what the angle it should be as I
> drag the mouse, and how far I should go along that angle before I let the
> mouse button up. I don't think, "hmm, this should start 10% of the way from
> a point that is 40 pixels from the top and 5% from the left, and end 900
> pixels from the left and 90% from the top." It's just absurd extra
> complexity to try to shoehorn in that kind of measurement, and for
> infinitesimal gain.

Um, no, you *are* doing that.  You're doing it with your eyeballs and
mouse rather than with text and numbers, but you really are doing the
exact same thing.  I'm sorry that it's impossible to translate tactile
Photoshop experience directly into CSS, but that's just one of the
limitations of the medium.

Anyway, you're purposely exaggerating the complexity of the syntax.
It would be more like "I want my gradient to start 40px from the top
and 5% from the left, and end 900px from the left and 90% from the
top.  My first color will start 10% in, and it'll go to the end."
Look at it when it's an actual rule, too:

linear-gradient(40px 5% to 900px 90% / white 10%, black)

Wow, not that complicated, huh?

>> That sort of knowledge-sharing is
>> pretty cool!
>
> Its almost totally redundant. If you like sharing knowledge, take the
> knowledge of how to measure a single distance to each stop, and share it
> with the need to specify where the first and last color-stops are
> positioned, instead of bringing in a second, different mechanism in a
> different place to do the same thing in addition to that.

That's precisely what the syntax does.  The first point sets where 0%
is for the color-stops, and the second point sets where 100% is.
That's it.  You can be real loose with the specifications, and just
say "left" to mean "start the gradient at the center of the left side,
and end it at the center of the right side", or you can be more
precise.

> I think there are vanishing few gradations you could create using this
> longer, more complex notation that I could not reasonably replicate without
> it in a much simpler, easier, shorter, and more consistent way without the
> extra four numbers and units at the beginning.

Then... do so?  Nothing's stopping you from using only the simple
forms of the syntax.  I like them better, too.  But allowing the
fuller point specificier doesn't add any implementation complexity,
and doesn't make the overall syntax more complex for the simple cases
either.

In other words, we can address *both* the common simple cases and hit
those vanishingly few complex cases at once without compromising!
This sort of situation is very rare and precious.

>>> If I stare at this long enough I see that it starts 10px from top, 10px
>>> from
>>> left, and ends the same distance from the bottom right, correct?so why
>>> not
>>> this instead:
>>>
>>> Gradient(top-left / white 14px, black calc(100% - 14px))
>>
>> Because the box may not be square, which would make your version not
>> equivalent to my versions.
>
> It would be pretty darn close. It's not like anyone would notice the
> difference on a blend that went mostly corner to corner on long vertical box
> if the gradation started a few pixels off horizontally from yours. It's not
> like I couldn't adjust it a few pixels one way for tall boxes or another way
> for wide boxes. The angle is changing on each different sized box anyway, so
> if you have two side by side they will already look different.

Sure, for that case.  I'm not willing to dismiss *all* such cases if I
can address them without compromising on the simple cases, though.

> Who needs that sort of precision for an effect that usually has no sharp
> edges that would need to align with anything else? Its up to 4 extra
> numbers, 2 extra directions, and up to 4 extra units, for a level of
> precision that vanishingly few would need. And that precision is replaced by
> ambiguity once you allow a mixture of percent, pixels, inches, ems, and so
> forth that <bg-position> does. With that, stops can trade position based on
> the width or height or font-size.

You... must be somewhat confused here.  I'm not sure how you can
possibly make a statement like that.  There is *no* possibility of
stops trading position based on *anything*.

<bg-position> is *only* used for specifying the starting-point and the
ending-point of the gradient line.  It just defines where 0% and 100%
are.  Worst case, you can use a strange combination of units that
makes the gradient change direction based on text-size or whatever, as
the start and end points move around, but the color-stops will always
stay in the same order.  They just have a percentage or length.

(Not quite true, actually - now that I've allowed lengths in
color-stops, it's possible for you to use "in" on one stop, "px" on
another, and "em" on a third, thus producing an ordering that can vary
wildly based on pixel size and text size.  At that point you're really
digging your own grave, though - you can screw up your design in a
million different ways by mixing different classes of lengths, and I
don't feel it important to protect you from doing so in this one
circumstance.  You still can't mix lengths and %, though, which would
be the primary cause of order-switching, so I'm content.)

~TJ

Received on Saturday, 15 August 2009 16:40:00 UTC