Re: Splitting background-position in two different attributes

On Tue, Aug 9, 2011 at 2:31 AM, Christian Sciberras <uuf6429@gmail.com> wrote:
> With regards to compression, you have to see this from a developer's
> perspective.
> Line noise indeed, but to a developer it matters a lot. Even the fact
> of having to copy around values makes a deal of a difference.

I'm a webdev too, don't worry.  (I don't do it professionally any
longer, but I still do personal webdev projects regularly.)

I understand the appeal of being able to compress things somewhat, but
I also know that in common situations the difference is very little,
since it's just the difference between the product and the sum of the
number of states in each axis.  Since most of the time one axis will
be 2 or 3 at most, the difference stays relatively small.


> You mentioned that it is limited to work nicely on two state axis
> alone. I disagree.
>
> They can be used with multiple state axis visually similar to a stair;
> moving the sprite horizontally depending on a root state and
> vertically on a sub-state.
> I can't think of a practical example, but in theory, it plays nice.

I'm not sure you understand my objection here.  Say you base the
display of a checkbox icon on three axises: active, disabled,
irrelevant; checked, unchecked, indeterminate; and normal, hover,
hover+active, active.

This is 3x3x4 = 36 states.  Because the image is two-dimensional,
you'll have to arrange it either as 3x12 or 9x4 images.  Rather than a
theoretical 10 distinct rules, you have to specify 13 or 15.  Both of
these are still better than 36 rules, but they have a similar
redundancy.  (And either way, they should really be script-generated
at this point.)


> With regards to being a hack, I really, really disagree with this one.
> In practice, I see MF as a standardized hack.
> You see, when you mention "sprites" in the programming world, people
> instantly know it's about position, grids and viewports - not URIs.

Yes, because that's what "sprites" typically means.  My argument is
that the notion of "sprites" itself is a hack, in an attempt to reduce
the number of http requests.  A better solution would fix the problem
directly, so you could use it for many other things, like scripts (no
need for a server-side script concatenator!), etc.

And as well, sprites are simply not as good as real images.  For
example, you can't repeat a sprite.  (Well, if your spritesheet is 1d,
you can repeat either horizontally or vertically, depending on the
orientation.  A 2d spritesheet, like what you want to optimize, can't
be used for repeating at all.)


> And then there's the honesty part; how much do people use MF? And how
> much are we expecting them to?
> Historically, there are a LOT of *dead* specs. I wouldn't be surprised
> MF end up as such.

Nobody uses them yet because they're not implemented yet.  I expect
people to use them when they are able to.

> Other than my reasoning regarding this being practical, I've also
> highlighted several other reasons why it should be implemented,
> including for the sake of completeness.
> Then there's the other reason Jonathan mentioned; since many browsers
> support it, it is by definition "standard".
> I think W3 should rectify this confusion by giving it it's due merit
> and actually standardize it.

Completeness is never a reason to add something to the platform by
itself; it has to justify itself with actual benefit.  (Now,
completeness is sometimes useful in the name of *consistency*, or
simplicity.  Both of these bring benefits by making it easier to
learn.)

That said, since so many browsers already support it (and I think they
do so unprefixed), I've changed my mind and believe we should go ahead
and put it in a spec.

~TJ

Received on Thursday, 11 August 2011 23:52:47 UTC