3 ms·
Truth be told, you're the first person I've seen ever argue that HTML is a broken file format, particularly because it doesn't contain everything it links to. I
by itafroma 13y ago
Truth be told, you're the first person I've seen ever argue that HTML is a broken file format, particularly because it doesn't contain everything it links to. Imagine what it would mean if HTML was an encapsulated file format: you couldn't pre-fetch or cache static assets at all, because you'd have to get everything any time the structure of the document (the HTML part proper) changes. That's not a 0.001% problem.
As I and others have mentioned throughout the comments here, the single index file—be it XML like FXG, HTML, or otherwise—and linking to assets within it is pretty common and standard approach to complex documents. Combining them by zipping them up is a trivial addition and, again, common way to solve the "but I don't like having multiple files to transfer" problem.
- tjoff 13y ago"Combining them by zipping them up is a trivial addition..." That, seriously, 99% of the population will never, ever, accomplish in their entire lifetime. Instead, you get files without the resources. Instead, you get files with hard coded local links to C:\xxx. This of course works for HTML since most "regular people" never ever has to deal with either html files or its resources (but every time they do, it is sure to be a disaster). Images on the other hand is something that most people deal with in some way or another. It must be something that you can easily share or it will be pointless. It would be nice if you could actually add a caption to an image - without having to "destroy" the original by converting it to a png just so that you'd be sure that the recipient could handle it. Everything has its place. Resources work fine for html files if you are the creator, if you want to store a page for later use it is a disaster. I love the fact that the resources are separate from the document when I write use InDesign or LateX - such a relief from having to deal with word documents etc. At the same time those solutions make it completely inaccessible to most people I know, they are great for their isolated environment but disastrous for anything else. So, an image with resources... Might work well, terrific even, in your studio but if it is ever going to be used by the masses it is a dealbreaker. What if PDF only used linked resources, no one would even know what PDF was by now if that were the case. "Imagine what it would mean if HTML was an encapsulated file format: you couldn't pre-fetch or cache static assets at all, because you'd have to get everything any time the structure of the document (the HTML part proper) changes. That's not a 0.001% problem." You could of course do all that with single encapsulated file as well...
- itafroma 13y ago> That, seriously, 99% of the population will never, ever, accomplish in their entire lifetime. Yes, they do. All the Microsoft Office formats (DOCX, XLSX, etc.), all the OpenOffice formats, all the iWork formats, ePub, Safari extensions, Chrome extensions, JAR files, and countless other general public-facing formats are exactly that: loose collections of files that contain an index file (or multiple index files) and are combined using zip. People by and large don't seem to have a problem dealing with them: transfers, edits, and other operations are seamless to regular users. > What if PDF only used linked resources, no one would even know what PDF was by now if that were the case. Many PDFs do, in fact, rely on this capability.[1] It's generally transparent to the user. > You could of course do all that with single encapsulated file as well... No, you couldn't. You'd have to transfer the entire file to determine what's changed. That's the the definition and principle benefit of encapsulation: one file gets transferred at once instead of many in piecemeal. [1]: http://en.wikipedia.org/wiki/Portable_Document_Format#Content http://en.wikipedia.org/wiki/Portable_Document_Format#Conten...
- tjoff 13y ago"Yes, they do. All the Microsoft Office formats (DOCX, XLSX, etc.), all the OpenOffice formats, all the iWork formats, ePub, Safari extensions, Chrome extensions, JAR files, and countless other general public-facing formats are exactly that: loose collections of files that contain an index file (or multiple index files) and are combined using zip. " In other words, a single encapsulating file... Which was my point? The exact implementation is hardly relevant is it? "No, you couldn't." Of course you can. Just include hashes of the different resources within the file and only the parts of the file that contain changes needs to be downloaded. Or implement something more general along the lines of the rsync algorithm. Taking html as an example you could also do everything transparently on the server if you wanted to. Or do everything transparently on the client instead if you wanted to keep a snapshot of each visit as a single file. But no, I'm not arguing that we should encapsulate all web pages. But on the client side, if the user chose to save a webpage, the result should in most cases be a single encapsulating file. "Many PDFs do, in fact, rely on this capability.[1] It's generally transparent to the user." The keyword was only used linked resources. I think my point was, and is, rather obvious. PDF would never be where it is today if it weren't for its ability to encapsulate resources. EDIT: My point isn't that all files should be encapsulating all the linked content. There must be a point to it. Web pages on a server, hardly beneficial... Image files? Absolutely.