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:
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.
Non-support in browsing contexts
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.
Updating fragment identifiers
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.
This will pose some challenges to implement since fragment resolution is at least in Gecko completely separate from the network stack. And we really want the network stack to deal with the zip support since otherwise we'll never get it consistently working.
But hopefully we can ensure that the fragment reaches the network stack, even though in most cases it doesn't use it.
But it's a bummer to not supporting putting the HTML file in the zip bundle. Obviously a lot better than status quo though.
Is there really no character that's not allowed (i.e. used rarely enough) in URLs that we could steal for "bundle support". I.e. something like
If we had something like that then relative URLs could even be defined to work within the bundle. So if the base URL is
then something lie like would resolve to
If we can't find a character like that then I agree that using fragments is a big step forward.