Monday, August 24, 2009

Beyond Sprites - The New WAR

I was just looking at a set of image files which are used to decorate custom form elements. I was analyzing how best to turn them into sprites1. One particular set of 3 images caused me to dream up a 'new' web standard: a resource tar.

The set was a left end-cap, a right end-cap, and a repeatable middle section to accommodate a control of fixed height but variable width. The end caps were say, 20px wide, but the repeatable middle section image was - and only needed to be - 1px wide. Now, if I were to combine the 3 in a stacked sprite, the 1px wide middle section would have to be stretched to the 20px width to match the end-caps. True, widening the middle section would compress well in PNG or GIF format - as it was destined to become -- but these were just 3 of the 20 or so images. I could make the tiny sacrifices along the way and probably create 7 sprites out of the 20 images .. but that's still 7 http requests.

Maybe right now you're thinking what I was - there should be a way to send all 7 at once. And if there was a way to do *that* - then why muss about with all this sprite nonsense at all2? Just leave the images alone in their 20 separate files, but send them all in one jar. It would be the browser's responsibility to interpret a jar file that came from "http://site.com/path/to/jars/jarfile.jar" and had an internal directory structure of
/.
/img/
/img/1.gif
/img/2.gif
...
so that the images could be referenced in CSS as "http://site.com/path/to/jars/img/1.gif", "http://site.com/path/to/jars/img/2.gif"...

So what's with the title phrase "the new WAR"? Sending along the image assets for custom controls is just one application of this new "jar" or "war" file concept. Another is to send a packet that has the base images for a site: the logo and primary site decoration elements. Other people may conceive of other sets of resources that it make sense to combine and send along together in one packet.

1 For an excellent description of sprites, including some fantastic examples, see The Mystery Of CSS Sprites: Techniques, Tools And Tutorials.

2 Ok, the reason to still create the sprites is so that 'older' browsers - you know, the ones that don't have this as-yet unproposed feature - will still have 7 http requests instead of 20 (instead of the 1 they could have with this!)

7 comments:

  1. Good idea, but possibly limited to:

    Browsers have built in java support (hasn't this already been squashed?)

    User has to download the java plugin (required plugins are always a risk)

    Best to suggest a archive like format in your case (stick with jar for clarity), but let the W3C decide which is format is best.

    ReplyDelete
  2. This is a great idea! I think using a platform neutral terminology (rather than java centric) can make a big difference in its acceptance with different browser providers.

    ReplyDelete
  3. Its an interesting idea. I'm wondering what you feel is the logical breakpoint at which you *wouldn't* jar things up? In other words, at the extreme you could put every static asset a page needed into a single jar (all images, css, js). Would that be advisable? Where would one draw the line in your opinion?

    ReplyDelete
  4. @babaskate: good point. I wasn't explicit enough that my concept was only analogous to to a jar, but not actually a real jar file. It should only be limited by browsers that would understand the "resource packet" which is described by this post.

    ReplyDelete
  5. @kaiwen: Thank you for your feedback! I was envisioning the use of gzip or similar.

    ReplyDelete
  6. @aidrian: Perfect! I hadn't even considered including anything but images, but there's no reason to stop there. As for deciding where to stop - it would be a similar question for already-existing css- and js- combining techniques, or for that matter, deciding what style definitions warrant inclusion in 'global.css' vs. template.css. Much as it is now for existing combinatory systems (if they even support configurable combinations), the question of whether to include would be on a per-file basis, using your best judgment.

    ReplyDelete
  7. How about automating this?

    Instead of extending html to permit manual aggregation by developers via a war-like file, browsers could instead issue a single HTTP "MULTI-GET" request that lists all desired URLs with a single set of shared HTTP header fields? This would then be backwards-compatible with existing web content, would allow them to dynamically omit items already present in the browser cache from prior pages, and would revert by default for older browsers (which would just issue traditional GETs). It would also imply no new work for web developers.

    I'm sympathetic to your search for the motivation and cure for web sprites, and I hope you succeed!

    ReplyDelete