- From: Lee Kowalkowski <lee.kowalkowski@googlemail.com>
- Date: Wed, 10 Nov 2010 23:29:03 +0000
- To: Brad Kemper <brad.kemper@gmail.com>
- Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, "www-style@w3.org" <www-style@w3.org>
On 10 November 2010 18:12, Brad Kemper <brad.kemper@gmail.com> wrote: >>> But you are asking for new capabilities. >> I am NOT, background-position already exists. > background-position-y and background-position-x do not (not in the spec > anyway), so yes you are. Clearly you are, or we wouldn't be having this > conversation. Wrong again, I'm asking for new properties, not capabilities, the distinction is utterly important. > Well it must be comforting for you to tell yourself you know the intentions > of the spec writers more than the spec writers themselves do. I don't tell myself this, quite the opposite, I'm actually wondering where such intentions are documented, specifically for background-position. So I might be able to humour you and present a use case in alignment with these intentions, I'm convinced one exists. Because what is actually bugging me is that it never makes sense to withhold individual properties. > Just because certain things are possible, doesn't mean they were considered > by the spec writers as meaningful considerations for what properties and > values we should have for this module But we already have a background-position property, therefore such meaningful consideration has surely already taken place. > No, different shoe sizes already exist. background-position-y > and background-position-x do not exist in any W3.org spec. Bizarre, besides, long handles might be beneficial to people who have difficulty reaching their feet. We really ought to cut the anecdotes, they're not helping. > No, you are free to use the existing properties and values however you wish. > If the shoe-maker makes a suitable shoe, or the browser-maker makes a > suitable property, then of course you are free to use it. I've said so > several times, and still you seek to twist my words. Honestly I don't seek to twist words, that is probably accidental. You may have assumed you're responses are complete enough to be understood unambiguously, such as below: > You are proposing new properties, which also lack official support. > > They're only unsupported by Firefox and Opera - Chrome, Safari & IE > support it. Do you mean something else by official support? > > I meant support by the Working Group. I cannot say we will never support > them, but so far I agree with fantasai that we lack sufficient non-hack use > cases to justify adding them to the spec. Use cases communicate expected behaviour, I'm actually not suggesting the introduction of a new behaviour, the ability to position a background already exists. The use cases for my request presumably already exist and have already been accepted. For *ALL* such CSS properties, an author may wish to specify different parameters of a behaviour using different CSS selectors. If this means it makes more sense to have -left -top -right- and -bottom instead (or even all six), that's completely acceptable to me. To insist on new use cases for more fine-grained properties is seemingly hypocritical. > Just off the top of my head: > Text-shadow, box-shadow, border-image-slice... It is not that unusual to > have component values that can't be addressed individually with their own > separate properties. Any old ones? It might not be unusual, but I'll bet somebody will find these new compound properties limiting in exactly the same way. Good API design should allow control of individual aspects without interfering with others. You can never tell who might find that useful. I haven't yet been told where to find the Guiding Principles that were used in the creation of the specification, but I think allowing fine-grained control ought to be one of them, in the interest of API best practice and inherent versatility. 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? > 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. 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). But the real shortcoming is with background-position, not sprites. 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. -- Lee www.webdeavour.co.uk
Received on Wednesday, 10 November 2010 23:29:41 UTC