Re: [css-images] conic-gradient and 'at'

On Tue, Apr 9, 2013 at 3:02 PM, Rik Cabanier <cabanier@gmail.com> wrote:
> On Tue, Apr 9, 2013 at 2:37 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>> On Tue, Apr 9, 2013 at 1:36 PM, Rik Cabanier <cabanier@gmail.com> wrote:
>> > Isn't it needed so you can place the 'middle' of the conic gradient?
>>
>> Dirk's question and Simon's answer aren't about whether the argument
>> is needed at all, but rather about the 'at' keyword used to introduce
>> the argument.
>
> I see. Since a colorstop requires a color, I agree that the 'at' is not
> really needed.

It's not needed for syntax disambiguation *yet*, and within the single function.

However, as I argued previously, I put it there because it's the exact
same argument as radial-gradient(), and having consistency there is
nice for authors.

Further, if we ever make conic-gradient more complex, such as by
allowing it to take an ending-shape (which seems like a very
reasonable future expansion), we'll run into the exact same ambiguity
issues that plagued radial-gradient().  It seems silly to not plan for
that, and the best way to plan seems to be to just copy
radial-gradient().

>> > From the spec, it's unclear how you can rotate the gradient. Why is the
>> > start angle always as 0 degrees?
>>
>> Because it's a reasonable choice.  To "rotate" it, just change the
>> color-stop positions, exactly like you would to get a linear-gradient
>> to move.
>
> Wouldn't that be hard to author? For instance, to emulate the attached
> gradient the user would have to calculate the color that's at 0 and 360
> degrees himself.

Oh, hm, that's true.  I was assuming in my head that you could just
write "90deg black, 450deg white", but that doesn't actually work.
Hmm, I'll either need to rejigger the drawing algorithm or add a
rotation angle to the syntax.

~TJ

Received on Tuesday, 9 April 2013 22:09:07 UTC