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

On 08/11/2010, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> 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).

That's fine, we are talking about background-position afterall, I
*expect* it to work only for background-position.

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

Not following, I'm not repeating any images, unless I have a multi-deck game.

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

It's *not* working accidentally though, is it?  The usage of
background-position is working in a predicatble and expected way, and
in accordance with the specification.

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

I'm not proposing a new feature or defining new behaviours at all.
You can already specify and use background-position, the behaviour
(and presumably use cases, whether considered valid or otherwise) is
already implemented.

The only thing that is missing is two additional setters, which are
already supported by the majority of major browsers.  I only wish for
a complete API.

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

Hmm, how I wish to organize my images though is my choice and no
business of anyone elses.

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

It's pretty common to have a tiles-based sprite images in computer
games, for whatever reason.  I'd personally find it easier to work on
a single image than on 52 separate image files.  Less loading and
saving of files for example.

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

It's the most convenient way to work with graphics for a game.  It's
pretty much accepted practice (easier to modify the pallete if all
artwork is in one file for example).  There's no rule that there are
52 different visible images therefore they must be 52 different files.

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

I'm not generating my CSS on the fly or programatically.  If for some
reason I wanted to change the aspect ratio of my cards (e.g. a
poker-deck), I'd prefer to modify 4 or 13 CSS rules, than all 52.

> Again, the fact that you
> can possibly do it with 17 rules is basically an accident.

No, that's the desired design, no accident.

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

I'm going to disagree with that, that's a almost like saying using a
mobile phone for anything other than making calls is a hack (but not
quite).  I think you can legitimately use background-position to
sprite, because it's within the constraints of the specification.

Even if I could have a package download and address resources
independantly, I don't think I would, because I actually want to work
with a single image, not multiple ones.  And I definitely want my
images to go behind my text, not replace it.

> Um, you're not using this to position the background.  You are
> selecting an image.

Yes, a *background* 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.

I'm pretty sure it was no accident to handle background images that
are larger than the area that requires a background.

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

Yeah, I don't like that.  I don't want to make lots of small requests,
I don't want to maintain separate resources for this.

> -x and -y solve no new problems, nor do they introduce any new
> capabilities.

It solves a maintenance problem, my code would be easier to maintain.

I'm also pretty sure this particular request doesn't have to solve a
new problems or introduce new capabilities, because
background-position itself *already* *exists*, it already solves a
problem and provides a capability.  I shouldn't have to justify that.

All I'm saying that it would be nice to be able to specify them
independantly, from a maintenance perspective, not a performance one.

> The only thing they do is make stylesheets smaller in
> certain limited circumstances that we really want to discourage
> anyway.

You can't discourage something by encouraging something that doesn't
exist.  Well you can, but you shouldn't, it's annoying.

> So I object on the basis that they don't provide enough
> benefit for us to bother with.

Really, you don't have to justify the benefits in this case, the two
properties would be practically self-explanatory, they only expose
finer-grained control for existing aspects of background-position: and
it already has support in most of the major web browsers.

Seriously, a couple of setters is no big deal compared to an entire
new spriting framework.

> What is wrong with using 52 rules rather than 17?

Maintenance really.

> This is easy to
> generate,

Yes, but more time-consuming by hand.

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

Yeah, but I'm not concerned with the transport performance of my CSS,
that's going to be cached client-side anyway, it's just a manual
maintenance issue.  Am I the last one left editing CSS by hand?  Did I
miss somethiing whilst I was away on holiday?!

-- 
Lee
www.webdeavour.co.uk

Received on Tuesday, 9 November 2010 10:51:36 UTC