Re: Splitting background-position in two different attributes

Great!

How many more people to convince before we get it into the spec?

;-P

Cheerio,
Chris.


On Fri, Aug 12, 2011 at 1:51 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> 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 Monday, 15 August 2011 08:34:09 UTC