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

>> 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.

Received on Monday, 5 December 2011 19:28:53 UTC