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

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.

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

This is not a reason to deny background-position-x or -y.  This
problem already exists with background-position, if it actually
exists, I've not played with background-size, but it looks like I
should be able to make my image bigger or smaller if I really wanted
to, regardless of whether or not its a sprite-image.

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

> But you are asking for new
> capabilities.

I am NOT, background-position already exists.

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

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

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

> 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 cannot think of another CSS property that lacks this
>> granularity.
>
> I can.

Which is?  And why not?

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

So why do you insist on a new use case for doing so for background-position?

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

Not really, the supersize is just a matter of <body
class="supersized"> for example, I may wish to style a lot more than
just background-position-y when the game is in this state, my game
code is going to just switch the class name of the body element, and I
wish to look after the look&feel of the game using as much declarative
CSS as possible, because programmatic == problematic from a
maintenance point of view.

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

-- 
Lee
www.webdeavour.co.uk

Received on Wednesday, 10 November 2010 10:07:49 UTC