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

On Nov 9, 2010, at 2:51 PM, Lee Kowalkowski <lee.kowalkowski@googlemail.com> wrote:

> On 9 November 2010 15:36, Brad Kemper <brad.kemper@gmail.com> wrote:
>> I am talking about using sprite images, as were you.
> 
> The fact that I was talking about sprite images is largely irrelevant,
> that's just my example. You were talking about things that you can't
> use backgrounds for, a bit like talking about smoking by talking about
> not smoking.

I was talking about how using background-position for spriting imposes strict limitations on the usefulness of other background properties, limitations that mostly don't exist otherwise. 

> The main point is there are situations where an author would like to
> specify -x without -y, for whatever reason, exactly like when
> specifying margin-top without interfering with margin-left defined in
> another rule.

And as fantasai told you, those situation all seem to be associated with using background-position for showing sprites as fragments of the image, and there is a more appropriate spec for that. 

> 
>> By using background-position in a way that is different from what the spec authors intended, as you do when you use it for spriting, you give up the ability to use these other background properties as they were intended.
> 
> Really I don't, I can still use them on other elements where they are
> required (I have used background-repeat:repeat-x on sprite images in
> the past, for styling navigation tabs - so you *can* have
> flexibly-sized boxes : http://tinyurl.com/268tkkx).
> 
> If I'm using backround-image for spriting, I'm not going to be very
> interested in the other background properties am I?  How are they
> relevant?  Authors will rarely specify every available background
> property on an element, so I don't really see any argument there.

You should, for instance, be able to use 'background-size" to make you playing card image fit the object, whatever it's dimensions. With your method of spriting, you can't. That is an artificial limitation that is directly due to using background-position this way, and only having a portion of the whole image that is usable for a single element. 

>> Thus, the spec is not going to change just to suit that unintended use, but you are free to use it as is, if that is good enough.
> 
> 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. But you are asking for new capabilities. 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. 

> How can you possibly criticise image sprites when
> you break it down:
> 
> backround-image:url(whatever.png); /* nothing wrong with this, allowed
> by spec */
> background-repeat:no-repeat; /* a perfectly legitimate thing to do */
> background-position:-20px 0; /* spec says you can do this too,
> although it's a pity I have to explicitly provide both values, I'm
> only interested in specifying the 'x' value */
> 
> Its ridiculous to criticise intentions

I'm not criticizing your intension. I'm just saying you're looking for the solution in the wrong place.  

> when technically, nothing has
> been done wrong, according to what the specification allows.  How dare
> anyone sneer upon the use of image sprites!  What's not as per the
> specification?

I never sneered. I never suggested that the thing you are twisting this background property to do is not allowed. More power to you, if you can make it work. 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. I use my shoes for that purpose pretty often, but I don't expect the shoe manufactures to improve the shoes for that reason. 

> 
>> If it is not good enough, then look towards the upcoming image fragments spec,
> 
> Each fragment of my image has to be served separately?  

Who said that? Being able to use fragments of a single image as though they are individual clipped pieces is one of the goals of the media fragments working group. You should really be directing feedback to them to help them get it right. 

> No thanks, how
> is that viable?  What on earth would I write all that code for?  52
> uris?  I only need 1, and 17 rules.  How can you recommend an
> alternative approach that 1/ lacks support and 2/ doesn't really make
> coding easier, or more right - whilst keeping a straight face?

You are proposing new properties, which also lack official support. I'd rather see the support for well thought out solutions to the problems, rather than just codifying some experimental versions of what you are asking for. 

I can't say for certain that the final media fragments solution will be harder. Perhaps they will have some shorthands or wildcats characters that will allow what you want. You should ask them for something like that, if you feel it is important. 

> 
>> rather than waiting for the backgrounds spec to conform to your unintended use.
> 
> Pardon?  *My* use *is* intended, by myself, and many others who
> promote this technique.  

It was not an intended use by those that wrote the spec (and you've been told that by two of the authors of the current spec, and another member of the working group that votes on such things). Nobody is abridging your freedom to use it as you wish, but that was not a use that had much, if anything, to do with how the current spec was drafted, or how it is likely to be evolved. The purpose of the spec is to provide ways to have images as backgrounds, either singly or tiled. It is not to figure out ways of showing pieces of images instead of the while thing, in as few rules as possible. There is another working group that is working on that sort of thing. 

> None of which say "oh by the way, this is
> wrong, you really ought to wait for image fragments".
> 
>> We recognize the need, but it is not a background-* problem; it is an image fragment problem.
> 
> I really doubt the image fragment specification will provide
> background-position-x & -y.  

I don't see why not. Except that they don't really care if the image is for a background, foreground, border-image, bullet marker, or what have you. 

> It's nothing to do with them.

Sure it does. They've already begun to design a syntax that let's you determine x/y coordinates to grab just a piece of an image. 

> It's also not an image fragment problem, the image fragment problem is
> for when the author does *not* wish to download the entire resource.

I don't know where you got that idea. 

> Image sprite users *do* wish to download the entire resource.
> 
> background-position does have a problem, it forces you to specify both
> x & y every time, when that's not always convenient (for whatever
> intention).  I cannot think of another CSS property that lacks this
> granularity.

I can. 

>  Are you saying in each of these cases you were provided
> with appropriate use cases, and all you need is one for
> background-position, and we're good to go?

No. 

> I could understand if doing image sprites using background-position
> had some serious consequences.  If they do, they've yet to be
> successfully communicated.
> 
> What if the use case was a background to a simple scrolling platform
> game's background?  The game automatically scrolls in one direction
> (suppose horizontally) - at a slower rate than what's in the
> foreground to simulate perspective, but the character can "supersize"
> and when it does, the background is offset (vertically) to simulate an
> altered perspective?

Well, it's different. I don't know if it is that important of a use case. It seems like any game that could do that could also write out the y coordinate too pretty easily. 

> What would the objection be then?  Or is this working group just
> generally averse to imaginative uses of CSS?

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. 

> Are you seriously suggestion having a shorthand property that doesn't
> have individual counterparts is what you intended?  I don't buy it,
> neither do the majority of major browser vendors that have gone ahead
> and implemented this already (it was in IE4 - IE4!).

Received on Wednesday, 10 November 2010 01:59:47 UTC