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

On Mon, Nov 8, 2010 at 2:05 PM, Lee Kowalkowski
<lee.kowalkowski@googlemail.com> wrote:
> 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 a hack because it has so many restrictions that a good
solution wouldn't have.  It only works for background-position (I
can't use it to deliver a bunch of small <img>s, frex).  It only works
for similarly-sized images (spriting differently-sized things is
pretty inefficient).  You can only use the 2d version of it if you're
not repeating the images at all, and the 1d version of it if you're
repeating in one direction only (a proper solution should allow you to
repeat in either or both directions).

These are the hallmark of something that only works accidentally.
That's what we call a "hack".  ^_^


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

Right; I'm not saying that the proper solution exists yet.  We're
still pushing on this space.  It will be solved *eventually*, though.

(Note that -x and -y, even if added to the draft today, would still
only be available in limited browsers for some time.  When some
feature isn't being added fast enough, adding a second feature doesn't
really buy you much.  ^_^)


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

You are not intrinsically serving a 2d array; that's just a detail of
your particular use-case.  Having a rule for each rank and a rule for
each suit isn't part of your requirements; your requirements are to
serve a different background-image for each of your 52 cards.  They
just happen to have a particular organization.

In most cases, there is no such "natural" organization.


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

It certainly does make sense to do 52 rules; there are 52 different
images you're trying to serve.  Again, the fact that in this
particular case you can organize the pictures logically into a 4x13
array is an implementation detail.

Using 17 rules rather than 52 isn't particularly natural or automatic.
 In a real programming language you'd be doing it with 4 rules and a
loop, most likely, or 1 rule and 2 loops.  Again, the fact that you
can possibly do it with 17 rules is basically an accident.


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

Because, outside of spriting, there's no real use for controlling the
x and y independently.  And using background-position to sprite is a
hack.


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

Um, you're not using this to position the background.  You are
selecting an image.  The fact that you do this by positioning a larger
image is irrelevant.  Again, it's an accident of history that you can
select an image in certain circumstances by positioning a larger
image.

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

It's only absurd if I really was inconsistent like you imply.  ^_^  I
*do* think that background-position shouldn't be used for spriting -
it's the wrong solution to the problem.  The correct solution is Media
Fragments, or more generally, making it cheap to make lots of small
requests.


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

-x and -y solve no new problems, nor do they introduce any new
capabilities.  The only thing they do is make stylesheets smaller in
certain limited circumstances that we really want to discourage
anyway.  So I object on the basis that they don't provide enough
benefit for us to bother with.

What is wrong with using 52 rules rather than 17?  This is easy to
generate, and the rules have a very regular structure, so they
compress very well too.  Last time this discussion came up I did some
tests that should have favored -x and -y pretty strongly (if I recall,
the -x/-y version of the stylesheet let you drop over 200 rules with
the set I was using), but after basic gzip compression the difference
was basically unnoticeable.  There's just so many common substrings
that almost all of the extra gets compressed away.

~TJ

Received on Monday, 8 November 2010 22:59:00 UTC