>> I'm still curious to here the rationale for killing this reordering support, as it haven't found anywhere where that discussion was documented:
>> http://dev.w3.org/cvsweb/csswg/css3-images/Overview.src.html.diff?r1=1.230;r2=1.231;f=h
>>
>> The reordering *was* supported before the "rushed edit and publish" at the last TelCon.
>
>This was explained both in the telcon (the minutes for which have been
I don't see in the minutes, or in the k... log. Could you provide a link to the relevant quote?
>published) *and* in the private email fantasai sent to you (and I
>pinged you about).
I don't see it in the mail from fantasai. Perhaps the junk mail filter ate it (it gets confused by w3c mail periodically). Can you privately forward the mail you're referring to?
>The blog comments were inconclusive with regards
>to the overall decision of "commas or keywords", but there was a
>fairly persistent theme that the "to" keyword was confusing, and
>people liked having the size and shape together like the old grammar
>had.
>
>Thus, the simplest and most reasonable solution is to do exactly that
>- put the size and shape together. The shape previously was
>restricted to always come first, even though it wasn't strictly
>ambiguous from a grammar perspective, because it was easier to read
>that way. So, we've kept that restriction.
From the minutes...
# fantasai: So the proposal is
# radial-gradient( [<shape> || <size> ] [at <position>]?, <color-stops> )
I don't have an issue with "put the size and shape together". What I'm uncomfortable with is not allowing position move to the front.
I'd prefer...
radial-gradient( [<shape> || <size>] || [at <position>]?, <color-stops>)
As she points out, this introduces ambiguity. As you point out, having such ambiguity is undesirable.
Again, I argue that the removal of "to" is what is causing the ambiguity with this reordering-friendly proposed syntax. I think reordering trumps "uncomfortableness" of having the size-preceding keyword. I think it also trumps your "unhappiness" with having to address the ambiguity in the prose.
If reordering is really NOT important compared to that, then I would argue that we should remove the || between shape and size.
A. radial-gradient( [<shape> || <size>] [at <position>]?, <color-stops>)
B. radial-gradient( [<shape> || <size>] || [at <position>]?, <color-stops>)
C. radial-gradient( [<shape> <size>] || [at <position>]?, <color-stops>)
D. radial-gradient( [<size> <shape>] || [at <position>]?, <color-stops>)
E. radial-gradient( [<shape> <size>] [at <position>]?, <color-stops>)
F. radial-gradient( [<size> <shape>] [at <position>]?, <color-stops>)
My preferences are as follows...
E,F > B >> C,D >>>> A
B, E, F are consistent in either allowing reordering or not allowing reordering. I slightly prefer E,F because they keep the parsing simple and avoid serialization pain for JS authors consuming via the OM.
C, D are inconsistent in that they only allow reordering of {position, {size-shape} } but you could argue that's reasonable because size-shape is intended to be treated as connected.
A is a mistake that all of us will regret, IMO.
>> Again, another valuable reason for doing the grammar change in the first
>> place was so that the grammar is extensible in the future. It's clear that the
>> removal of "to" has already hampered reordering support in the grammar
>> of today, and thus will likely present extensibility problems in the future.
> Can you elaborate on what extensibility problems you see? As far as
> we can tell, it still works perfectly fine for the extensions that we
> plan in Images 4. Unless you have a concrete example of problems, I
> don't think we should attempt to adjust the grammar any further.
I've removed the ?s because it keeps the grammar simple...
CSS3:
radial-gradient( [<shape> || <size>] [at <position>], <color-stops>)
CSS4:
G. radial-gradient( [<shape> || <size>] [ [at <position>] || [from <position> | from offset <length>{1,2}] ], <color-stops>)
The CSS4 syntax allows reordering of shape and focal position (relative to each other). But it furthers the confusion about "why can I reorder within chunk 1 and chunk 2, but I can't reorder chunks 1 and 2 relative to each other?"
Chunk 1 = [<shape> || <size>]
Chunk 2 = [ [at <position>] || [from <position> | from offset <length>{1,2}] ]
There are two clean ways of addressing that:
Be consistent in allowing reordering OR consistent in rejecting reordering.
H. radial-gradient( [<shape> || <size>] || [ [at <position>] || [from <position> | from offset <length>{1,2}] ], <color-stops>)
I. radial-gradient( [<size> <shape>] [ [at <position>] [from <position> | from offset <length>{1,2}] ], <color-stops>)
J. radial-gradient( [<shape> <size>] [ [at <position>] [from <position> | from offset <length>{1,2}] ], <color-stops>)
My preferences are as follows...
I,J > H >>>> G
Similar rationale to the previous preference list.