So everyone is raving about this new CSS3 feature for cropping images.
|example from the W3C specification (working draft 12)|
However, the reason we put multiple images in single image-files in the first place, is not because we think that's practical or fun. It's a work-around, enabling us to deliver many small images more efficiently, packaged in a single file.
In other words, the real problem is this: delivering many small files efficiently.
But what you get with image-fragments, is something very specific - an image-specific solution that makes one particular image-specific work-around a bit more workable.
It's too short-sighted.
Since this problem is important enough to warrant another HTML/CSS extension, why we can't we have a solution that addresses the root of the problem?
Both servers and clients have support for gzip already, so the technology is already there - it just needs a bit of adaptation. For example, a URL-notation for addressing files in archives. Since we don't use the "#" sign in resource URLs, we could apply it like so:
http://site.com/awesome-design.gz#images/button-hover.pngThis is a much simpler solution, more general-purpose, and probably a whole lot easier to implement (for browser vendors) than futzing around with images.
In my opinion, the internet needs more general-purpose tools - not more problem-specific solutions, which complicate the medium and lead to more browser-incompatibilities, and more work-arounds.
On a related note, you already gave us the power to futz around with images - rather than forcing us to hack that, why not integrate canvas with background capabilities?
Semantically, cropping doesn't even make any sense for "backgrounds", and that's not what developers are going to use it for - note the close semantic relationships between the words "canvas" and "background"? as opposed to the non-relationship between "button" and "background"...
My verdict: This solution is not elegant.