7 ms·
Potential use case: instead of using CSS sprite maps (putting all of your images into one image to reduce the number of http requests generated by your page, th
by nanidin 13y ago
Potential use case: instead of using CSS sprite maps (putting all of your images into one image to reduce the number of http requests generated by your page, then using css magic to select regions inside of that image), image files could be zipped into an image package that is delivered to the client, who unzips it and uses the images inside.
This would cut down on the number of requests made, but allow the images to be used as normal images instead of as images within a sprite sheet.
- chadscira 13y agoi'm surprised we don't have a cross-browser webarchive concept yet... especially with the emphasis on mobile.
- dsl 13y agoWe have a fantastic one based on MIME that is usable by everything except Firefox (however you need to enable some experimental stuff in Chrome). http://en.wikipedia.org/wiki/MHTML http://en.wikipedia.org/wiki/MHTML
- chadscira 13y agoi wasn't aware of this, very cool
- TazeTSchnitzel 13y agoUntil now I always thought the M stood for Microsoft. Now I know.
- stu_k 13y agoThere is definitely work towards this. This spec was recently released and has some potential: https://github.com/w3ctag/packaging-on-the-web https://github.com/w3ctag/packaging-on-the-web
- jahitr 13y agoSome images formats already come with compression. Also, zip doesn't work with well with binary data. Using CSS to "subscript" into the sprite is a better solution.
- TheZenPsycho 13y agoExcept that the primary utility of zip is usually not its compression. It's the combining of multiple files into one "file". Basically what tar was invented for, but with actual universal support on every OS.
- chadscira 13y agoseems like multipart http responses may be pretty close to what we want
- TheZenPsycho 13y agoa multipart http response saves what kind of file?
- nanidin 13y agoIt's not about saving bandwidth or space by compressing the images - it's about removing the step of combining your images into one big image then using coordinates inside of that image to find your original images. Sure, you can build the spriting into your build process, but I don't know how to do that (I'm sure there are tools) and you can't exactly use normal css since the coordinates of your images may change within the sprite sheet. Using the zip method saves you some of that headache/overhead with the tradeoff of having to package your images into a zip and unzip them on the client side.
- MatmaRex 13y agoYou can embed the images in the CSS as data: URIs, preferably automatically as part of the build process, and get the best of both worlds.
- 13y ago
- moron4hire 13y agoThe crazy thing: in this thread, you are all right. The state of sending multiple files sucks. ZIP is the closest thing we have to a universal standard, if only because Windows refuses to ship with support for anything that is meaningful.
- zo1 13y agoI seem to recall them getting a big fat law suit when they tried to bundle things with their OS. Perhaps they don't bundle things anymore for a reason?
- TazeTSchnitzel 13y agoWell, is there anything better for Windows, aside from maybe cabinet files?
- csomar 13y agoSo is the point to simplify the process or something else? CSS Sprites are very easy to make and use. You just need to set the right coordinates for the background-image. On the other hand, running a complicated JS library and building an infrastructure to extract these images seems like an overkill for something that CSS sprites can do so easily.
- TazeTSchnitzel 13y agoCSS Sprites have numerous disadvantages that normal image files lack.
- magicalist 13y agoI'm surprised that no one has brought up that this is also solved at the protocol level with SPDY and eventually HTTP 2 (and by HTTP pipelining, which is sadly never going to happen). Not a silver bullet, but a bit more sane than unzipping a set of images in JS.