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

On Thu, Dec 1, 2011 at 2:01 PM, Brian Manthos <brianman@microsoft.com> wrote:
>>Brian:
>>> # radial gradient is specified by first pinpointing the center
>>> # of the gradient (where the 0% ellipse will be) then specifying
>>> # the size and shape of the ending shape (the 100% ellipse).
>>>
>>> 1. The prose doesn't align with the grammar like it used to.
>>>
>>> In the previous grammars, this prose aligned with the ordering in the grammar...
>>>        ... (<position>, <size-shape>, <colors>)
>>>
>>> I think it's worth considering updating the prose to match the new grammar ordering.
>
> Tab:
>> Fixed.  "A radial gradient is specified by indicating the center of
>> the gradient (where the 0% ellipse will be) and the size and shape of
>> the <dfn>ending shape</dfn> (the 100% ellipse)."
>
> That doesn't address the issue.  Your new text has the form...
>        "A radial gradient .... [position information] .... and [size and shape information] ..."
> whereas the grammar has it in the opposite order.

Yes, but no ordering is expressed now.  I tried writing it with the
terms the other way, but I think it reads better this way, since it
lets me mention the 0% position before the 100% position.


>>> 2. Position can no longer be first.
>>>
>>> In the prior WD grammar, position was always first.  In the ED grammar prior to 12/28, position *could* be first.  With the current ED grammar it can never be first.
>>It could only be first if you omitted the shape, and only because the
>>shape and size weren't connected.
>
> Incorrect:
>
> WD 2011/09/08
> http://www.w3.org/TR/css3-images/
> <radial-gradient> = radial-gradient(
>        [<position>,]?
>        [[
>                [<shape> || <size>]
>                |
>                [<length> | <percentage>]{2}
>        ],]?
>        <color-stop>[, <color-stop>]+
> )
> radial-gradient(5px 6px, 7px 8px, red, blue)
>
> ED 2011/11/11
> http://dev.w3.org/cvsweb/~checkout~/csswg/css3-images/Overview.src.html?rev=1.219;content-type=text%2Fhtml
> <radial-gradient> = radial-gradient(
>  [ <shape> , |
>    <shape>? [ at <position> || to <extent> ] ,
>  ]?
>  <color-stop> [ , <color-stop> ]+
> )
> radial-gradient(at 5px 6px to 7px 8px, red, blue)
>
>
> Both old grammars allowed position to go first *with explicit sizing present*.  The new grammar does not.

That's what I said, fwiw.  Position could come first if the shape was
omitted in the November ED syntax.

> I would prefer either we allow full reordering (and we can, without ambiguity) or no reordering.  A partially flexible parser just confuses people rather than helps them.

In my head it's not partially flexible, any more than CSS normally is
with things like <position> in the bg shorthand.  There are now two
terms, same as in the old WD syntax, a position and a size/shape.
Like the old WD syntax, size/shape can appear in any order.  The only
difference, really, is that we've dropped the comma between the two
arguments, swapped their order, and required an "at" before the
position.

>>> 4. circle/ellipse keyword can now be repositioned
>>It's still prevented from coming after the "at <position>", though,
>>for the same reasoning as before.
>
> This is a better explanation for change #2 above.  I might be able to get on board with that but need to think about it some more.

Cool.


>>> 3. The meaning and rendering of "simple two length/percent" radial gradients has changed.
>>On the other hand, the November ED made just-a-size-keyword and
>>just-a-size-and-shape-keyword invalid, while the December ED returns
>>it to validity with the same meaning as the previous WD.  Kind of a
>>toss-up in terms of what different grammars allowed, I think.
>
> I think it's the wrong choice and found it worth calling out because it feels *just like the angle coordinate system* change where the same-syntax-means-something-different is a bad thing -- and I agreed with Brad on that concern then and now.

True, though since we're eating the pain of the l-g change, eating a
similar pain in r-g shouldn't be too bad.  radials aren't used as
commonly as linears anyway.


>>> 5. Editorial snafu with <position> prose regarding "defined".
>> I think you're misunderstanding that comment - it's not "the entire
>> syntax of background-position", but it *is* defined by the
>> background-position syntax, as that syntax has a <position>
>> non-terminal.
>
> Can we add "a single layer of" in front of 'background-position' to avoid the confusion?
>
> Current
> # The <position> notation is defined by the positioning syntax of ‘background-position’ and is resolved in the same way
>
> Proposed
> # The <position> notation is defined by the positioning syntax of a single layer of ‘background-position’ and is resolved in the same way

Sure.  I've made the change.


>> > # <extent-keyword> = closest-corner | closest-side | farthest-corner | farthest-side
>> > 10. To my recollection, we did not have consensus on the official demise of "cover" and "contain".  Did we resolve on that?  If not, it might be worth adding an issue near "<extent-keyword>" to call that out.
>> Are you asking for an issue because you disagree, or just for
>> completeness?  If the latter, I don't think we need to call it out
>> specially.
>
> Completeness and clarity for authors and implementers.
>
> For example, when adding/updating my implementation for the new grammar should I remove cover and contain under the assumption that they are gone OR should I leave them in place until we have are resolution?  For the moment, my gut is "do the least work" until I know more.
>
> I'm undecided on whether to keep them or not.  I see merit in both options.

Me too.  I advocate doing the least work until this hits CR, which is
in sight now.

~TJ

Received on Thursday, 1 December 2011 22:27:49 UTC