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

(Just a small comment, I'll talk about the rest later.)

Border-radius demonstrates a good use of the slash, in that it only appears
when there is something for it to separate. It's not just an ordering
indicator.

On Mar 9, 2010 10:36 AM, "Brad Kemper" <brad.kemper@gmail.com> wrote:

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.