Re: Gradient syntax proposal

On Sat, Aug 15, 2009 at 1:22 PM, Brad Kemper<brad.kemper@gmail.com> wrote:
> On Aug 15, 2009, at 9:38 AM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:
>> 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.
>
> So now the argument is "why not?" because the routines to handle complexity
> is already built into the programming code two software programs, so we
> might as well expose that much complexity to authors too?

No, I'm just heading off the argument that this extra complexity will
make it harder to implement.

> What I am against is adding complexity and confusion to the grammar just to
> serve some extreme edge cases.

It only adds complexity when you want it.  In the simple, common cases
it has no effect at all.

> There is no compelling reason for there to be more than one keyword or angle
> on the left part. 'top-left' is one such keyword. 'top left' is now two, and
> 'top left to bottom right' is five, all meaning the same thing with
> absolutely NO GAIN. It does not aid in learning to have to interpret that
> instead of a single keyword that means the same thing, or to have multiple
> ways to say the same thing. For instance:

"top-left" vs "top left" is a single character difference.  I doubt
that'll cause any confusion.

The literate form "top left to bottom right" does add *clarity*.  The
short form requires you to understand that the gradient *starts* at
the top left, and implicitly ends on the opposite corner.

> 1. linear-gradient(top / green 20% blue 40%)
>
> is the same as all of the following:
>
> 2. linear-gradient(0 20% / green, blue 40% )
> 3. linear-gradient(0 20% to 0 40% / green blue )
> 4. linear-gradient(0 20% to 0 40% / green 0, blue 0 )
> 5. linear-gradient(0 0 / green 20%, blue 40% )
> 6. linear-gradient(0 0 to 0 100% / green 20%, blue 40% )
> 7. linear-gradient(top left to 0 100% / green 20%, blue 40% )
> 8. linear-gradient(top left to bottom left / green 20%, blue 40% )
> 9. linear-gradient(top left to 0 40% / green 20%, blue 100% )
> 10. linear-gradient(0 0 to left 40% / green 20%, blue 100% )
> 11. linear-gradient(top to bottom / green 20%, blue 100% )
> 12. linear-gradient(top to 0 100% / green 20%, blue 40% )
> 13. linear-gradient(top to bottom left / green 20%, blue 40% )
> 14. linear-gradient(top to bottom / green 20%, blue 40% )
> 15. linear-gradient(top left to bottom / green 20%, blue 40% )
> 16. linear-gradient(top to 0 40% / green 20%, blue 100% )

Yes, there are lots of ways to specify the same thing in the
<bg-position> syntax.  It's that way for a reason, so that you have
lots of options and can specify something in the most reasonable way
possible.  Most of those varient will never be used, however.

(I'll note in passing, though, that several of these - 2, 4, 5, 11,
13, 15, and 16 - actually *don't* specify the same thing.  2 and 5
have the ending point defaulting to somewhere in the opposite corner
and will produce diagonal gradients, 4 will make an image that's
simply 20% green and 80% blue, 11 produces way too long of a fade
between green and blue, and the other three are all wrong because
using a side keyword by itself means the center of that side, and so
they'll produce a diagonal gradient.)

> I'm pretty sure I left some more ways to say the same thing out. And this is
> so far just for the commonest case of going in a direction that's a multiple
> of 90 degrees. It gets worse with other angles added to the mix.
> Now one can hope that people only use form #1, but they wont. Teaching CSS
> to students will require teaching what each of these means.

Hopefully they'll be taught "use these simple forms, but if you really
need to be exact, this stuff is exactly like background-position".  If
they can't get background-position right in a gradient, they're not
going to get it right in an actual background either.  Are you arguing
that we should cut out all of these options from background-position?

> And reading
> someone else's code means that you could come across any one of these forms.

While true, I honestly think that the vast majority of people would
just write "top" or "top to bottom".  Especially if the examples in
the final spec emphasize this.

I'm actually planning to rewrite my examples to make such an emphasis,
partially because of your prodding.  ^_^  I'll change it so that
there's only a single example at the end with the full <bg-position>
construction, emphasizing that it's usually not necessary, but exists
when you need it.

> And reading someone else's code gets even worse with diagonals, where people
> are using percentages on the left side of the slash to mean something
> different than what the mean on the right side of the slash. And adding all
> this complexity just to service the extreme few use cases, which can be
> achieved nearly the same without it? No, thank you. Keep It Simple, Sir.

Then just use the simple forms.  Is easy.

~TJ

Received on Saturday, 15 August 2009 18:50:23 UTC