I was on board until I saw that those can't easily be opened from a local file. Seems like local access is one of the main use case for archival formats.
Html is already a good single-file html format. Images can be inlined with data-uri. CSS and javascript have been inlineable since the very beginning. What more is needed? Fonts? Data-uri, once more.
Hell, html is probably what word processor apps should be saving everything as. You can get pixel-level placement of any element if you want that.
They explicitely contrast it with single file html, giving an example that is much more performant than waiting for the single 280Mb html file to load.
Yes, they're both approximately the same in terms of size on disk and even network traffic for a fully loaded page, one is a much better browser experience.
> You can get pixel-level placement of any element if you want that.
You may well be able to, but it is largely anathema to the goals of html.
Agreed, I was thinking it's like asm.js where it can "backdoor pilot" [1] an interesting use case into the browser by making it already supported by default.
But not being able to "just" load the file into a browser locally seems to defeat a lot of the point.
Any static HTML server. Also if you try to load the page directly it suggests just untarring the contents back into a folder structure and provides a perl command line as a suggestion for how to do that.
It sounds like it would be pretty easy to write a super simple app with a browser in it that you could associate with the file type to spin these up. IMO.
I mean `claude -p "spin up a python webserver in this directory please"` or alternately `python -m http.server 8080 --bind 127.0.0.1 --directory .` is not hard
Sure, but opening ports tends to be a headache when all you want to do is view the contents.
On this case I wonder if the format can be further optimized. For example, .js files are supported for loading locally and albeit a very inefficient way to load assets, it could overcome this local disk limitation and nobody reads the HTML source code in either way so it won't need to win any code beauty contests. I'll later look into this theory and ping the author in case it works.
NoMoreNicksLeft|14 days ago
Hell, html is probably what word processor apps should be saving everything as. You can get pixel-level placement of any element if you want that.
Quarrel|14 days ago
Yes, they're both approximately the same in terms of size on disk and even network traffic for a fully loaded page, one is a much better browser experience.
> You can get pixel-level placement of any element if you want that.
You may well be able to, but it is largely anathema to the goals of html.
avaer|14 days ago
But not being able to "just" load the file into a browser locally seems to defeat a lot of the point.
[1] https://en.wikipedia.org/wiki/Television_pilot#Backdoor_pilo...
deevus|14 days ago
WorldMaker|13 days ago
qingcharles|13 days ago
vessenes|14 days ago
nunobrito|14 days ago
On this case I wonder if the format can be further optimized. For example, .js files are supported for loading locally and albeit a very inefficient way to load assets, it could overcome this local disk limitation and nobody reads the HTML source code in either way so it won't need to win any code beauty contests. I'll later look into this theory and ping the author in case it works.
WorldMaker|13 days ago
chungy|14 days ago