- From: Brad Kemper <brad.kemper@gmail.com>
- Date: Wed, 10 Nov 2010 18:57:02 -0800
- To: Lee Kowalkowski <lee.kowalkowski@googlemail.com>
- Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, "www-style@w3.org" <www-style@w3.org>
On Nov 10, 2010, at 3:29 PM, Lee Kowalkowski <lee.kowalkowski@googlemail.com> wrote: > This should happen without the need for additional use cases, it > should just fall under a "you never know" category, after all, you > already have use cases for the compound properties, you've already > justified the existence of a capability or behaviour. It's just > quicker and easier to add them instead of debating every last one. > Who cares if one is redundant, and could that ever be proven? I think that the majority of the Working Group would probably disagree with that. There are implementation costs for every new property and/or value, and a lot of time spent considering how these might all interact with other properties in unexpected ways. > >> Don't you think they would be useful for foreground images too? > > Sprites would be useful for foreground images, absolutely, but > background-position would be useless for foreground images. You may > think this is twisting words, but I'm trying to stay on topic, which > is background-position, not sprites. > > I only gave sprites as an example to demonstrate a genuine shortcoming > of this specification. No, most of your objections were to the fact that we didn't consider spriting to be a worthy use case for the backgrounds spec, and our use of words like "unintended" to mean that it is not our intension to write a backgrounds spec in order to enable sprite use, and that we considered such use to be a hack. I think we are all willing to listen to non-sprite reasons for splitting the property into two X/Y properties. > If you don't like my example, I'll try to find > a better one (but it will be an example, not a use case - you > presumably already have a use case), but I'll need the original use > cases for background-position (the ones that were instrumental in the > acceptance of background-position originally). I think it is fairly obvious that the main idea behind image-based backgrounds is to take a single image and position and/or tile it in different ways. Using it to seemingly show different images when there is really just one, by selectively hiding the majority of the (actually single) image is really a very different use that was not and is not a consideration of the design of the "show an image in the background and maybe tile it" properties and how they were expected/intended to be used. > The insistence of a use case for this is a real faux pas, because I > feel you'd rather spend time 'bickering' about it, than providing a > complete API. Naw. Bickering has wasted chunks of my day, but specs and implementations take much longer. The working group always needs use cases.
Received on Thursday, 11 November 2010 02:58:09 UTC