WHOOPS!! Emailed this to the wrong mailing list... Silly me. On 16-Apr-07, at 1:36 PM, 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. _______________________________________________ calendarserver-users mailing list calendarserver-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/calendarserver-users