W3C home > Mailing lists > Public > www-style@w3.org > March 2010

Re: [css3-background] background-shorthand and its background-clip side-effect

From: Brad Kemper <brad.kemper@gmail.com>
Date: Fri, 5 Mar 2010 10:17:47 -0800
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, Sylvain Galineau <sylvaing@microsoft.com>, fantasai <fantasai.lists@inkedblade.net>, "www-style@w3.org" <www-style@w3.org>, Arron Eicholz <Arron.Eicholz@microsoft.com>, Brian Manthos <brianman@microsoft.com>
Message-Id: <65DAFD3F-E381-4FEA-B33D-7898AA953F49@gmail.com>
To: Brad Kemper <brad.kemper@gmail.com>

On Mar 5, 2010, at 8:25 AM, Brad Kemper wrote:

>>> You can if you use the slash the way I was suggesting, which would also be consistent between disambiguating BOTH the <bg-position>/<bg-size> combinations AND the <bg-origin>/<bg-clip> combinations in the same ways. Thus, the position/size disambiguation does NOT need to be more complex than the origin/clip disambiguation. They can both be simple, with a single slash providing a reference point for disambiguation.
>> 
>> What I meant is that you don't *need* a slash in the origin/clip
>> situation, since you can rely on a simple ordering.  That's not
>> sufficient for position/size.  Ordering-based disambiguation is used
>> much more commonly throughout CSS, and so should be relied on when
>> possible.
> 
> Right, but the part you quoted me on was about how the two situations are not consistent with each other, but could be (very simply). My way is still ordering-based; the order is in relation to the slash.

Another way of looking at this is that:

1) It is not uncommon to use ordering to disambiguate (not exactly as I am suggesting, but I am doing that generally with the order of the slash). More often than not, it is with a pair of more closely related values, such as horizontal and vertical offsets. 

2) It has been suggested to use order to disambiguate for <bg-origin>/<bg-clip>, but not for  <bg-position>/<bg-size> in the same shorthand. I don't think that is a good idea, and I have suggested a way to be more consistent (and more readable).

3) The slash has also been used to disambiguate, such as with <font-size>/<line-height> in the 'font' shorthand. It is also used for that purpose in border-image. With border-image there can be either <‘border-image-width’> between the two slashes, or nothing at all between the two slashes, and both slashes are optional if you are willing to accept the initial values for <‘border-image-width’> and/or <‘border-image-outset’>. This works well, is perfectly clear, and still fits into the precedent of #1, above.

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. 
Received on Friday, 5 March 2010 18:18:22 GMT

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