Re: [css3-images] 2011/12/01 ED section 4.2 review notes

On Dec 6, 2011, at 12:27 PM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:

> On Mon, Dec 5, 2011 at 4:02 PM, Brian Manthos <brianman@microsoft.com> wrote:
>> The quoted section doesn't even mention reordering.  It talks about why "to" was removed and, on its face, suggests that the discussion didn't even involve awareness of the loss of reordering capabilities that resulted.
>> 
>> I find it troubling that after such protracted discussions about the grammar of this property, that you're so cavalier in asserting that it was addressed in previous discussion when clearly it was not.
>> 
>> 
>> Whether you think that reordering capability is a desirable or not, the loss of functionality was *not* addressed.  That reordering capability was part of why I was somewhat supportive proposed ED grammar.
>> 
>> As it stands, I think we're better off reverting to the 09/08 grammar than moving forward with the lesser version of the grammar that is now in the ED.
> 
> Given that Fantasai and I edited the grammar, I'm pretty certain that
> we were both aware of the "loss".  The change was intentional.
> 
> The WG resolved on the grammar, and Fantasai, Brad, and I are happy
> with it.  It's extremely unlikely to change again unless someone finds
> actual problems with it.

I did have a suggested change during our discussions, that would make me happier. I don't think I ever got a reply. So the agreement is not quite as resounding as you imply (though I think that I could live with it). My comment included a preference for <size><shape> in that order, which you can see below, and which Brian also seems to prefer, if anything is ordered (his option F). I would have said so, if I could have made it to that telecon that day. I go further, to say that the shape keyword is actually pretty redundant when lengths are given for size. Here is that thread (unquoted part below is me from November 25, during Thanksgiving weekend, then the next telecon was the one I missed):

On Nov 25, 2011, at 11:51 AM, fantasai <fantasai@inkedblade.net> wrote:

> So I've been thinking about the feedback there, and one of the main issues
> with the proposed syntax is that 'to 5em' doesn't make much sense, it would
> make more sense grouped with 'circle' or 'ellipse'.
> 
> If we have 'at' disambiguating the <position>, we don't need a keyword
> specifically to disambiguate the size. So here's a suggestion to address
> that feedback:
> - specify circle/ellipse keyword || explicit size OR
> - specify circle/ellipse keyword with "to <keyword>"
> 
> radial-gradient(
> [  [ circle || <length> ] | [ ellipse || <length>{2} ] |
>  [ circle | ellipse ] to <closest/farthest-corner-side> ]?
> [ at <position ]?
> , <color-stops>)
> 
> You get:
> 
> radial-gradient(5em circle at 25% 25%, yellow, blue)
> radial-gradient(ellipse 50% 2em at center, yellow, blue)
> radial-gradient(circle to closest-corner, yellow, blue)
> 
> Thoughts?

It seems like an improvement, except that I prefer to be able to leave out the 'ellipse' keyword, so that 'circle' is more of a special case of the normal (normal = no circle constraint). I also think '2in circle' is a lot more meaningful and readable than 'circle 2em' in the first part, but the shape keywords are not actually necessary there at all, since one length = circle, and two lengths = ellipse. So I think it could be readable still (better, even) and still work  as: 

radial-gradient(
[  [ <length> circle? ] | [ <length>{2} ellipse? ] |
 [ circle | ellipse ]? [to <closest/farthest-corner-side>]? ]?
[ at <position ]?
, <color-stops>)

I think I wrote that right, but won't swear to it. Thus, it should allow this, in addition to your samples:

radial-gradient(5em at 25% 25%, yellow, blue)
radial-gradient(50% 2em at center, yellow, blue)
radial-gradient(closest-corner, yellow, blue)