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
_______________________________________________
calendarserver-users mailing list
calendarserver-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/calendarserver-users
