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

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.

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.

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

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

> If it is not good enough, then look towards the upcoming image fragments spec,

Each fragment of my image has to be served separately?  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?

> 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.  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.  It's nothing to do with them.

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

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?

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

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 Tuesday, 9 November 2010 22:51:52 UTC