W3C home > Mailing lists > Public > www-style@w3.org > December 2011

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

From: Brian Manthos <brianman@microsoft.com>
Date: Thu, 1 Dec 2011 18:21:43 +0000
To: Tab Atkins Jr. <jackalmage@gmail.com>, fantasai <fantasai.lists@inkedblade.net>, "www-style@w3.org" <www-style@w3.org>
Message-ID: <9710FCC2E88860489239BE0308AC5D170450BF85@TK5EX14MBXC264.redmond.corp.microsoft.com>
Quick review of the new ED included below.

IMO, issues 12, 6, and perhaps 10 should be addressed quickly before the WD publication.  It would be bad to publish a WD that introduces a new grammar without updating any of the associated examples to match.



http://dev.w3.org/csswg/css3-images/#radial-gradients

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


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.


3. The meaning and rendering of "simple two length/percent" radial gradients has changed.

WD 09/08
radial-gradient(25% 25%, red, blue)
= radial-gradient(25% 25%, ellipse cover, red, blue)
~= radial-gradient(25% 25%, ellipse farthest-corner, red, blue)

# ED 11/06
radial-gradient(25% 25%, red, blue) is invalid
radial-gradient(at 25% 25%, red, blue)
= radial-gradient(ellipse at 25% 25% to farthest-corner, red, blue)

ED 12/01
radial-gradient(25% 25%, red, blue)
= radial-gradient(ellipse farthest-corner 25% 25%, red, blue)
radial-gradient(at 25% 25%, red, blue)
= radial-gradient(ellipse at 25% 25% to farthest-corner, red, blue)

In short, the November ED made the not-keyword-preceded invalid and thus avoided confusing with existing content and conversion while the December ED now makes it valid again but have a completely different meaning from previous WD grammars.

This isn't a catastrophe but introduces pain for little gain, IMO.



# <shape> || <size>

4. circle/ellipse keyword can now be repositioned

This isn't so much an issue as just a notation.  Was this intentional?  I thought there were reasons we tried to avoid that in the November ED grammar.



# The <position> notation is defined by the positioning syntax of 'background-position'

5. Editorial snafu with <position> prose regarding "defined".

We ran into this issue before:  <position> or <bg-position> should be referred to rather than background-position.  Referencing background-position has the problem that it has layers whereas the <position> parameter of <radial-gradient> does not have layers.



# and the content box as the positioning area.

6. Editorial snafu with <position> prose regarding "box".

The reference to "content box" is at best confusing here.  I think what you mean is "image positioning area" which maps to "background positioning area" for background-image, and something different for list-style-image and generated content.

The reference to "content box" suggests that radial-gradients used with background-image both ignore the background-clip property AND use a different default (content-box instead of padding-box) when the background-clip property isn't specified.



# Same as

7. "Similar to" is the proper phrasing for the prose within 'farthest-side' and 'farthest-corner'.

Absurd: "Blue is the same as purple except it doesn't have any red."

I already raised this during our November discussions; just broadening the audience.



# <length>
# Gives the radius of the circle explicitly. Negative values are invalid.

8. We should add a note for authors that speaks to why <percentage> is not included.

It should serve at least three purposes:
(a) explicitly call out in the prose the invalidity to aid those that consume "simple grammar + prose" instead of "full grammar"
(b) briefly explain why the it was excluded from the CSS3 module
(c) give a perhaps vague hint that it is expected to be supported in a later level of the module, but the meaning/rendering isn't decided upon yet

Both (a) and (c) are simple courtesy to web authors so they avoid wasting their time trying to debug "why doesn't it work?!" with such attempted syntax and builds awareness that this is "undefined space" that might "behave interestingly" in prefixed implementations.

Purpose (b) serves to capture some of the history of the CSS3 grammar both for larger community awareness and as a step towards the CSS4+ grammar discussions.



# [ ellipse              || [ <length> | <percentage> ]{2} ] [ at <position> ]? , |

9. Editorial nit:  please fix the 3 space alignment of the position portions for readability.



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



# though negative locations are never directly consulted for rendering

11. This is incorrect for repeating-radial-gradient.  At least, it is for the way I'm interpreting it.



# Example 18
# Example 19
# Example 20
...

12. All radial-gradient examples that contain non-color parameters need to be updated for the new grammar.



# &lt;foo>
# &lt;foo&gt;

13. Editorial nit:  Can the two Editors tweak their editors so that they agree on what to do with the > character?  The CVSWeb log is a lot more difficult to read than it needs to be.  Real edits are often difficult to find amidst the opposite-direction "fixups" regarding the '>' character.
Received on Thursday, 1 December 2011 18:22:23 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:47 GMT