W3C home > Mailing lists > Public > www-style@w3.org > August 2011

Re: Splitting background-position in two different attributes

From: Christian Sciberras <uuf6429@gmail.com>
Date: Tue, 9 Aug 2011 11:31:48 +0200
Message-ID: <CAD6s_XuWTdW6uCSXHGsnpx+hw65xoiPfiB7iOTZByX2kN_Lf2g@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: www-style@w3.org
Hello TJ,

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.

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.
The rest of the sprites which do not apply can as well not use it.
I don't have to explicitly set background-repeat if the item in
question is the same size of the background. Same thing with
background-position*.

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

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.

Best regards,
Christian Sciberras.
Received on Tuesday, 9 August 2011 09:32:14 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:43 GMT