- From: Christian Sciberras <uuf6429@gmail.com>
- Date: Mon, 15 Aug 2011 10:33:41 +0200
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: www-style@w3.org
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