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

On 8 November 2010 17:49, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> All image spriting techniques used today are hacks, yes.  They're a
> workaround for the fact that network requests have a significant
> constant cost, so it's more efficient to make a single large request
> rather than multiple small requests.

Hmm, hacks are supposed to be bad/unfavourable though, I don't see
this approach as a bad way of doing it - currently.  And I haven't
used an image sprite only for network optimisation (see below).

It would be a hack if I was relying on some side-effect of the
background-position in order to achieve what I want.  I am not doing
that, I am using the background-position property in a predictable
way, the *effect* may be a hack, but the *usage* is perfectly valid.

> This is something that should be fixed on the network level, and
> people have been working for a while on fixing this.  For example,
> some Moz people introduced the idea of resource packages (putting lots
> of resources into a single zip, which can then be conveniently linked
> into), while Google is working on its SPDY networking protocol (if I
> understand correctly, basically an improved version of request
> pipelining).

OK, that explains why you consider image sprites to be a hack, but the
alternative non-hack approaches are not viable at the moment.  I'm not
interested in anything that is only possible in limited browsers.

> The specific spriting technique of using background-position is an
> extra hack on top of the basic hack.

In some cases but not in mine, I have <a>10 &diams;</a> (nice for tiny
displays, e.g. mobile, Nintendo DS), my cards are not images, that's
semantically false, and using <a> is an accessibility boon, I only use
background images when the user elects to play with "big cards", the
elements are resized and the elements' textual content makes the
top-corner of the 'big' card (which is missing from the
background-image), it's definitely background-image I want to set.  I
could have a different URL per background-image, but that's 52 rules.
I just want a single image URL, a rule for each rank, and a rule for
each suit, not a rule for each card.  You know, like a 2D array, my
image is a 2D array of cards.  So optimal network performance is not
my only reason for choosing this approach.

> This doesn't make sense - the word "hack" is in no way applicable to
> this point.  You are trying to assign 52 different backgrounds to 52
> different types of elements.  Thus, it makes sense that this requires
> 52 different rules.

No, 13 ranks and 4 suits, not 52 elements.  I want to address the
backgrounds as a 2D array, not as a 1D array.  It does not make sense
to have 52 different rules (only because it's not currently possible
to do as 17 rules).

> The fact that you can organize the images in such a way that they can
> potentially be referenced with a combination of 17 rules doesn't make
> the 52-rule version a hack.

No, it makes it a compromise.  Because for some reason,
background-position was never implemented as its individual
properties, unlike margin with -top -right -bottom -left, etc, etc...

> For example, if you had images for each
> of the old web-safe colors, these could potentially be organized into
> a 6x6x6 cube and referenced with only 18 rules.  Does this make
> background-position a hack, since its 2-dimensional nature means you'd
> have to use 42 rules?

No, background-position is only a hack if you use it to do something
*other* than position the background.  I only want to use
background-position to position the background.  Therefore it's not a
hack.

Your argument is actually absurd, because it's arguing against
background-position too, saying one must not use it for image sprites,
I'm not wishing to debate that.  Only the omission of
background-position-x and -y.

Do you actually have an objection against -x and -y?  I haven't seen
one.  These "image-sprites are hacks" objections apply to
background-position itself also, I'd like to see a specific objection
to -x and -y.

--
Lee
www.webdeavour.co.uk



-- 
Lee
www.webdeavour.co.uk

Received on Monday, 8 November 2010 22:06:07 UTC