Re: [css3-background] New use case for background-position-x (&y!)

On Nov 10, 2010, at 2:07 AM, Lee Kowalkowski <lee.kowalkowski@googlemail.com> wrote:

> On 10/11/2010, Brad Kemper <brad.kemper@gmail.com> wrote:
>> You should, for instance, be able to use 'background-size" to make you
>> playing card image fit the object, whatever it's dimensions.
> 
> I don't understand why I couldn't use background-size in this context.

Values like "contain", "cover", and "100%" assume that it is the entire image you want to size, not just a piece of it. 

I suppose you could do some math to determine what percentage would fit the segment to the box, and also apply that percentage to the position offsets, but that seems like a lot more work than what you're already having to do to squeeze sprites out of the older background properties. 

>> .Just because the use was unintended doesn't make it automatically bad
>>> - or wrong even.
>> 
>> I didn't say it was. I use them too. But it's still a hack. I use lots of
>> hacks, actually, since I gave to support IE6.
> 
> No doubt, but I don't think this is really a hack, as it doesn't
> deviate from what is permitted by the specification.

Neither does "HTML > BODY", yet that is a hack to hide a rule from IE quirks mode. The people like me who are telling you it is a hack are not denying that it is permitted. We are defining "hack" as meaning something like "taking advantage of a side effect of something that was not considered as a meaningful or important or relevant use case by the authors of the specification, nor by those other working group members who agreed to it." In this case, we did not consider it important or relevant to adapt background-position to serve the need of showing a individual pieces of an image as though each one could substitute as an image in it's entirety (spriting). Thus we have a property called 'background-image", not 'background-images". 

> 
>> 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. 

> 
>> That's just not likely to happen here, if the only use case is
>> one that just takes advantage of a side effect to do something unintended.
> 
> It was never intended to have background graphics larger than its
> element, or to position the backgrounds?

It was never intended to be a substitute for a full-fledged spriting method, where a piece of an image can be used in places that otherwise use complete images. You are free to adapt it to do that if you can, but that is not what it was designed to do. 

>  I haven't asked for either
> of those capabilities.  The specification says the background will be
> clipped, therefore it is not unintended.  The specification says you
> can specify negative values in pixels, therefore it is not unintended.

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. 

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, especially since there is a more appropriate spec that is better suited to address the needs of spriting, and THOSE spec writers are intent on doing just that in that spec. 

>> But insisting that it be extended to fit your off-label need is
>> like insisting that shoes come with long handles on them, so that they can
>> be more effective at whacking at mosquitos.
> 
> To me, it's more like asking for one shoe to be a different size than
> the other.  Not common but also not unreasonable.  

No, different shoe sizes already exist. background-position-y and background-position-x do not exist in any W3.org spec. 

> That is why I
> cannot see any reason to refuse the request.  And if you're saying we
> shouldn't be allowed to buy shoes if we intend on swatting flies with
> them, well, people will use whatever's at hand.

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. 

>> 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. 

Sometimes things are added in order to reflect what all or most of the browsers are doing anyway, so it is possible that might eventually happen anyway. 

> 
>> It is not to figure out ways of showing
>> pieces of images instead of the while thing, in as few rules as possible.
> 
> I'm not asking anybody to figure that out.  I'm just asking to be able
> to specify x&y independently.

I understand what you are asking, and the reason you are asking. 

> 
>>> I cannot think of another CSS property that lacks this
>>> granularity.
>> 
>> I can.
> 
> Which is?  And why not?

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. 

>>>  [...]
> 
>> Oh, please. I'm all for imaginative uses. But the specs are written for the
>> common use cases first and foremost. Other cases should be able to still use
>> it, but it is optimized for the common cases.
> 
> Now you're saying sprites are not a common case?

No. I'm saying that they are not one of the common use cases that _this_ spec was designed to address, and still isn't. There is another spec for that. 


>  How on earth does
> adding -x and -y conflict with the common cases?  If anything, it will
> enhance the common cases too.
> 
> You're saying in all common cases, it will be unfeasible to want to
> use one selector to specify -x and another to specify -y?  That's
> rather closed-minded, don't you think?

I am not saying that. I am saying that the use cases for doing so are all about sprites, which are more appropriately addressed by another spec. Thus. There is not a strong case for adding them to the backgrounds spec. Don't you think they would be useful for foreground images too?

At this point, I think you are purposely misconstruing my words, since I believe I've been very clear about what I'm saying, and you just keep twisting my words and taking them out of context. So it is pointless to keep bickering with you.