[whatwg] Zip archives as first-class citizens

[Thaddee Tyl]

The idea of making zip content (and hopefully XZ content) available
feels right, but adding complexity doesn't.

On Wed, Aug 28, 2013 at 1:32 PM, Anne van Kesteren <annevk at annevk.nl> wrote:
> We have thought of three approaches for zip URL design thus far:
>
> * Using a sub-scheme (zip) with a zip-path (after !):
> zip:http://www.example.org/zip!image.gif
> * Introducing a zip-path (after %!): http://www.example.org/zip%!image.gif
> * Using media fragments: http://www.example.org/zip#path=image.gif

W.r.t. the sub-scheme, KDE kioslaves have something highly similar
(available for instance on their file explorers). The syntax is the following

    zip: <absolute path to zip> / <path to content>

For instance,

    zip:/home/tyl/vault.zip/js/simplex.js

Sure, a "real" directory can have a .zip extension, but spread across
all KDE users since kioslave's inception, more than 10 years ago, that
hasn't been raised as an issue (at least, I couldn't find one through
their bug tracker).

As a result, may I suggest this?

    zip:http://www.example.org/js.zip/simplex.js

W.r.t. using fragments, which I agree is the cleanest approach,
can we change the URL parsing algorithm
to authorize reading any number of fragments?
It would require adding # to the simple encode set, which
can have consequences I didn't think of.

    http://example.org/assets.zip#html/frame.html#editor

(Is there a reason we should have a path=, then?)

That would also take care of nested zips.