- From: Stefan Haustein <sh@kobjects.org>
- Date: Mon, 16 Apr 2007 23:38:42 +0200
Hi Tyler, I like the idea very much, for instance for having a copy of the CSS spec on my laptop without the need of an Internet connection while commuting.... - When I save a page with Safari, Firefox cannot read it. - When saving stuff with Firefox, I have to deal with both, the HTML file and the resource folder - It would be easy to write a nice wget-like utility that creates a single file. - A zip based format is still usable for browsers that do not support it, one would just needs to unpack the file. Best regards, Stefan Haustein Tyler Keating wrote: > 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. >
Received on Monday, 16 April 2007 14:38:42 UTC