Re: [css3-background] background-shorthand and also border-radius

One more thing about how this is not diverging that much from existing practice or expectations, or from what is already in the spec. The spec already has this notion of "one thing must occur before another, but other things can go in between." The background shorthand already has this:

	where ‘<bg-position>’ must occur before ‘/ <bg-size>’ if both are present

And I am doing something similar, with the addition of a slash mark as part of the order requirement, which can be written like this:

	where ‘/ ’ must occur before ‘<bg-size>’ or '<bg-clip>' when '<bg-position>' or '<bg-origin>' (respectively) are present.

Or it can be broken into two parts, if that is more clear:

	where ‘/ ’ must occur before ‘<bg-size>’ when '<bg-position>' is present.
	where ‘/ ’ must occur before '<bg-clip>' when '<bg-origin>' is present.

You see? It is not that different. But it makes the rule easier to write (because it is more permissive and more internally consistent), and easier to read (because a slash mark is very easy to notice, and the position relative to the slash is easier to quickly recognize than to try to pick out the order of 4 values and remember the relative order rules for all 4), and easier to learn (because there are fewer restrictions on where you can put the slash, and the slash disambiguates values in the same way for both sets of values).

By the way, the way the slash is used in border-radius is similar in that "one thing must occur before another, but other things can go in between" way. It separates the horizontal from the vertical parts of a corner's curve, but there can be up to three other corners in between, on either side of the slash (depending on which corner, and how many of them have separate h and v parts). 

On border-radius, I actually think it would have been clearer to go the other way: have either a single value of '<horizontal-and-vertical>'  or a '<horizontal>/<vertical>' combo-value for each of the four sides. Keeping the horizontal and vertical values together (with nothing in between, aside from a slash in this case) is much more in keeping with existing practice and expectations than insisting that the much less-related <bg-origin> and <bg-clip> have nothing but space between them, or that the slash (or "as" keyword) occurs IMMEDIATELY BEFORE <bg-size> but ANYWHERE AFTER <bg-position>. 

So, in addition to my other comments, I would propose the following change for 'border-radius':

[[ <length> | <percentage> ][ / [ <length> | <percentage> ]?]{1,4}

 and for border-top-right-radius, border-bottom-right-radius, border-bottom-left-radius, border-top-left-radius:

[ <length> | <percentage> ][ / <length> | <percentage> ]?

This would be less like the properties that only have a space between horizontal and vertical (like overflow), but more like the properties that only have spaces between the 4 parts (like margin, border, padding, etc.). And the pairing of '<horizontal>/<vertical>' for each corner would be more like the pairing of '<font-size>/<line-height>' in the font shorthand (in that--if they are both included--there can only be a slash between them, so that they are read as a single group of related values within the shorthand).


On Mar 5, 2010, at 10:17 AM, Brad Kemper wrote:

> 4) All I am suggesting is a simple way to combine #2 and #3, above, in a way that adds consistency to the shorthand, while also aiding in the quick recognition of parts of the shorthand (because of their order relationship to a very simple, common, and easily spotted mark). Instead of having more than one slash (as with border-image), the same slash can be used for 2 different disambiguations, or (as with border-image) be left out if the author is willing to accept the relevant initial values (or automatic value of <bg-clip> if <bg-origin> is set without also explicitly setting <bg-clip>). 
> 
> 5) I do not consider #4 above to be a big change. Combining 2 good ideas into a new better way of doing things is part of the essence of creative problem solving, and I see no downside of this simple extension/combining of existing practice that is not more than made up for by the upside. On the other hand, using "as" instead of a slash IS a big change (AFAIK, "as" is not used anywhere else), which reduces the readability of the declaration in a much more unusual way. I can't think of any other shorthand where another keyword is added just for disambiguation; the shorthand is already filled with keywords that have much more direct meaning.