- From: Brad Kemper <brad.kemper@gmail.com>
- Date: Thu, 4 Mar 2010 09:13:04 -0800
- To: fantasai <fantasai.lists@inkedblade.net>
- Cc: Sylvain Galineau <sylvaing@microsoft.com>, "www-style@w3.org" <www-style@w3.org>, "fantasai (fantasai@inkedblade.net)" <fantasai@inkedblade.net>, Arron Eicholz <Arron.Eicholz@microsoft.com>, Brian Manthos <brianman@microsoft.com>
- Message-Id: <BBDF0D1B-15B4-4BC5-9DBC-AD2ABA2FDB79@gmail.com>
On Mar 4, 2010, at 12:06 AM, fantasai wrote: > On 03/03/2010 11:20 PM, Brad Kemper wrote: >> >> I can see these points. The way I'd like to see them addressed ... single slash ... > > That's overkill. There's no reason to involve a slash to address Sylvain's > concern about being able to set both. If a slash [or recently, a keyword that is a poor substitute for a slash] needs to be there for <bgsize>, then this lets us take advantage of that symbol in a way that is internally consistent, and easy to read and write, without sacrificing any of the power of the 'background' property to include any or all of the other background-* properties. I don't see how a single slash character, usable to address two similar problems, is overkill. > You just put > > [border-box|padding-box|content-box]{0,2} > > in the background shorthand. Zero occurrences sets both background-clip > and background-origin to their initial values. One occurrence sets both > to the given value. Two (immediately adjacent) occurrences sets the first > to origin and the second to clip (because you position before you clip). That's a step in the right direction, IMO, but means you can't set the bg-clip in the shorthand without also explicitly setting the bg-origin to a not-necessarily-initial value. My syntax didn't have that limitation. > This is much more consistent with CSS syntax elsewhere. The closest thing I can think of for that is something like overflow, in which you can set overflow-x and overflow-y in the shorthand (and the order is used for disambiguation), but not just one of those in the shorthand. But this is a more complex situation. With overflow, it is fairly obvious when you see 'overflow: none scroll' which value is for what (because when there are horizontal and vertical parts, but not 4 possible sides, then the horizontal always comes first). It is less obvious which property is represented when you see something like 'padding-box' and/or border-box' amongst 6 or 7 other subvalues in almost any order. You have to read the whole thing to see if there is another *-box value there on that layer, and then remember the somewhat arbitrary order. With the slash, the order is still a factor, but it is much easier to determine in a glance if the slash is present and what side it is on. Once you know the rule of what goes on which side of the slash, it becomes very obvious as to what sub-property the value part represents. I generally like consistency too, but don't think we should let it prevent us from making improvements. What I've suggested is not so different that it would hurt anything, but would offer improvements in ease of reading and writing a complex, multipart property ('background').
Attachments
- application/pkcs7-signature attachment: smime.p7s
Received on Thursday, 4 March 2010 17:13:43 UTC