More explanation:
http://lists.w3.org/Archives/Public/www-style/2012Jan/0933.html
roundup(<modulus>)
(automatically applied to width/height only) also rounddown()
and round()
roundup(<css-value>, <modulus>)
matrix(<number>, <number>, <number>, <number>, <number>, <number>)
matrix(<number>{2}, <number>{2}, <number>{2})
—
translate(<x>, <y>)
translate(<x> <y>)
scale()
.
steps(<number> [, [start | end]]? )
steps(<number> && [start | end]?)
—
cubic-bezier(<number>, <number>, <number>, <number>)
cubic-bezier(<number>{2}, <number>{2})
matrix()
, the value here is two pairs of numbers, not four numbers, and so the grouping should reflect that. Positions are space-separated in CSS (though this is obviously a restricted form of “position”).
No change to Color as part of this effort. (We believe that percentages should be usable for opacity, and angles for hue, but those will be pursued as part of Colors 4.)
rectangle(<length>, <length>, <length>, <length> [, [<length>,] <length>])
rectangle(<length>{4} [<'border-corner-shape'> <length>{1,2}]? )
rect()
in CSS already allows space separation. The addition of border-corner-shape allows greater flexibility in the future and serves to make it clearer what the trailing 1 or 2 lengths mean.
rect()
, and unifying with the 'clip' value.
—
circle(<length>, <length>, <length>)
circle(<length>{3})
rectangle()
.
—
ellipse(<length>, <length>, <length>, <length>)
ellipse(<length>{4})
circle()
—
polygon([<fill-rule>,]? [<length>, <length>]# )
polygon([<fill-rule>,]? <length>{2}# )
cubic-bezier()
, but moreso - a list of points should be indicated with different separators between the components and the points, or else a long list becomes unreadable without writing conventions or manual counting. <fill-rule>
doesn't need a comma for disambuation, but we left it in due to Principle 3 and to match the gradient functions.
No change suggested to any functions in Fonts - they all accept either a single argument, or a comma-separated list of parallel items.
We would recommend removing the commas from target-text()
, as they're not necessary for disambiguation or grouping, but we think it is more valuable to match the syntax of target-counter()
(which is constrained by the syntax of counter()
) for consistency.
No change suggested to any functions in Grid. We would suggest removing the comma from minmax()
, as it's not necessary for disambiguation or grouping, but we feel this is a math-like function and, like round()
, may be more natural to see with commas.
No change suggested to any functions in Image Values. (image()
takes a comma-separated list of parallel arguments, element()
takes a single argument, and the gradient functions already follow the principles above)
Same as Grid.
No change suggested to Lists. We would suggest removing the commas from counter()
and counters()
, but back-compat dictates they stay the same unless there's a good reason to change them. Given that, we don't feel this change is significantly helpful enough to justify itself. (symbols()
already follows the principles above.)
We suggest that rect()
be defined such that space separation MUST be accepted. We believe this matches all major UAs. Also, maybe align with the suggestions for rectangle()
from Exclusions.
attr(<name>[, <type> [, <default>]?]?)
attr(<name> <type>? [, <default>]?)