Re: Splitting background-position in two different attributes

On Thu, Aug 4, 2011 at 1:40 AM, Christian Sciberras <uuf6429@gmail.com> wrote:
> ========= Introduction =========
>
> This issue has been previously covered here:
>
> http://www.w3.org/Style/CSS/Tracker/issues/9
>
> I believe the example used does not highlight the importance of such a feature.
[snip]
> ========= Conclusion =========
>
> - Without background-position-[x|y], there is a lot more code and more
> room for error.
> - State positions cannot be separated from type/subject positions.
> - Code is significantly larger to replace this feature.

Hi!  Thanks for emailing the list!

As you indicated, this has been discussed before, and rejected.  I
believe the reasoning for it being rejected is still valid.

The amount of extra rules required is relatively low.  In your example
case, you go from 6 rules to 9 rules.  That's nearly line noise, and
it compresses well.  (Last time this discussion came up, I explicitly
tested the difference between background-position and using Media
Fragments, which are even more verbose, and found the difference in
gzipped file size to be basically meaningless even for large sets of
rules.)

The compression you do see only occurs when you have two state axises,
and have arranged your sprites accordingly.  If you have only one, or
more than two, or just have more-or-less randomly-arranged sprites,
the split property doesn't help you nearly as much.

Finally, using background-position for spriting is a hack.  It's an
extremely useful hack that has served me and many authors very well,
but it's a hack nonetheless, and has several annoying limitations.
Spriting should instead be solved by a dedicated solution (like the
Media Fragments spec) or by a more general fix to our network
architecture that makes many small requests not as expensive (resource
packages, SPDY, etc.)

So, though I understand your reasoning, I still don't believe it's
worthwhile to add this to the language.

~TJ

Received on Thursday, 4 August 2011 16:22:38 UTC