Hi,
I'm bringing this up again with a different tact, because the more
that I think about it, the more I believe it has the ability to
significantly change the perception and application of HTML and I
would really like to keep the discussion alive. In the previous
thread, I proposed a standard for archiving web sites into a single
ZIP archive with a unique file extension and although it didn't get
any outright negative feedback, it didn't drum up too much excitement
either. If you can bear with me, I'd like to describe the idea again
in a slightly different light.
Take for example, web-based presentations vs. PowerPoint from an
average user's point-of-view. I can create an incredibly dynamic
presentation based on HTML, JavaScript, CSS, SVG, etc., but I can't
easily share it with anyone unless it is served (I can't easily send
it to them). On the other hand, I can create an incredibly dynamic
presentation using PowerPoint, but I can't easily share it with
anyone unless I send them the file and they also have PowerPoint (I
can't easily serve it).*
For another example, which relates to my modest experience, I've
created a simple Quotes/Sales/Invoices web app for a friend and have
come across similar issues trying to resolve the served file model
with the local file model. Without going into too much detail,
assume that there is sufficient reason why a file copy of the web
page is needed (in this case because my friend's customers can't use
the app directly). How should the user get copies of web documents
to be sent or saved to disk? Instead of describing all of the
various options of saving it to some kind of browser proprietary
archive, sending HTML email, creating an HTML-to-PDF converter or
some other time-consuming non-user friendly method, let's look at an
ideal solution.
Imagine this: An HTML based document ZIP compressed into a single
file could be uploaded as is to the server. Clicking on a link to
the file would probably download, decompress and open the file in the
browser seamlessly and, even better, right-clicking on the link
instead and choosing "Download Linked File" would download the same
nice small single file.** Double clicking that file would open it in
any browser identically as to the served version. The identical
format and behaviour of the web document and the file document
presents the best user experience. Instead of saving a
representation of the web document, you are saving THE web document.
The question is, why do we only think of HTML with respect to the web
and why are HTML-based documents constrained to being served? This
is the meat of my argument. Browsers have no issue opening a file
URI, but humans have an issue dealing with a directory of .html files
versus, say, a single .ppt file. Humans will soon also have issues
viewing and serving ODF and OOXML files, I might add, but still won't
have issues viewing and serving HTML files. After the little bit of
discussion from the first thread, I believe that the solution is
indeed a near clone and more complete version of the Widgets 1.0
specification ( http://www.w3.org/TR/WAPF-REQ/ ) as something
different and as part of HTML, specifying how to package entire web
documents as zip compressed archives using a unique file extension.
In reality, compared to all of the other work being done on HTML, I
believe this would be very simple to specify and should be very
simple to implement.
Please give this some thought. I appreciate your comments.
Tyler Keating
CEO Concept Digital Inc. -- don't be impressed, it's just me
* I could export an HTML version to be served, but I can't share both
ways with the same file and this means I have two versions of the
same presentation to work with. Again, the average user (my mom)
isn't going to be serving files created on their desktop any time too
soon, since she has just barely grasped email attachments.
** Containing any number of HTML, XHTML, CSS, image or other files
inside of it invisible to the average user.
