This is a revision of https://gist.github.com/annevk/6174119 focusing on putting the semantics in the fragment identifier instead. The fragment identifier would follow http://www.w3.org/TR/media-frags/ (media-frags) and we'd introduce a new keyword http://www.w3.org/TR/media-frags/#processing-name-value-lists "path":
The general structure would be:
{URL-to-zip}#{media-frags}
http://fetch.spec.whatwg.org/ would be modified to support sub-responses for zip resources. First the resource would be fetched and then if it's a zip resource (signature sniffing) the fragment identifier would be processed per media-frags. The "path" keyword would be used to locate the sub-resource.
/package.zip#path=image.jpg
/package.zip#path=image.jpg&xywh=160,120,320,240
Because navigating to such zip resources would create more complicated processing for inline links (e.g. what would #test do?) that is not supported for now.
We should make sure that the various contexts that allow for manipulation of the URL do the same thing for updating the fragment as they would do for updating the path.
Previous comment was from me on a borrowed computer :)