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

On Mon, Dec 5, 2011 at 11:27 AM, Brian Manthos <brianman@microsoft.com> wrote:
>>> 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?

It's the first part of the "Radial Gradients Readability" topic:

 fantasai: We worked with other WG members to come up with a syntax which
           we posted to the blog, per our action item.
 fantasai: We got some feedback, it was somewhat mixed.
 fantasai: One of the things we noted was that the proposed syntax used
           the "to" keyword to distinguish the size from the position,
           but that seemed confusing/awkward to people.
 fantasai: So we tweaked the proposed syntax a bit to remove that.
           The new version is up on the wiki.
 fantasai: It's simpler than before.
 fantasai: The only thing needed is to distinguish the size from the
            position, but only one of them needs a special marker to
            resolve the parsing/reading ambiguity.
 fantasai: So the proposal is
             radial-gradient( [<shape> || <size> ] [at <position>]?,
<color-stops> )
 fantasai: In the old syntax, you couldn't specify *just* an explicit size,
           because of the parsing ambiguity.  Now everything is optional.
           It's also clearer from the keyword that the values after "at"
           are a position.


In the above minutes, Fantasai explains why we removed the "to" from
in front of the size.


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

Will do.


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

You continue to ignore the reasoning given for removing "to".  It was
based on feedback in the blog post comments that authors often found
the "to" keyword confusing or awkward.  Fantasai gave this reasoning
in the minutes, just a few lines above the line you quote here.

You are attempting to elevate some other theoretical concern to
importance, based on your own opinion on what is consistent.  I
explained in my last email what our priorities are (readability,
CSS-ness, extensibility), and "reordering" is not one of them.
Allowing terms to be reordered is simply something that can help with
our other priorities, but it is not necessary for any of them.

Further, the current syntax more closely matches the older WD syntax
in design - it's essentially the old WD syntax, with the first and
second arguments swapped, and the comma replaced with "at".  This
wasn't an important consideration, but it's a nice accidental benefit.

~TJ

Received on Monday, 5 December 2011 22:22:21 UTC