russellbeattie/hypertext-editor

Feature Request: Self Contained Single Page HTML

trholding opened this issue · 3 comments

Dear Russell

Would it be possible for builds that output a single output HTML with all dependencies inlined?

This has several benefits, fewer requests, better http compression, easy to put the editor on IPFS etc.

I agree this is worth looking into and perhaps preferable to the work required to solve the encapsulation issue.

How many items cannot be inlined these days?

SVG icons
Fonts
CSS
JS

That's a lot!

I guess multimedia is the main standout? But we want a document format, not a media consumption app, don't we? Perhaps media could be handled with the usual screenshot placeholder that simply links to a corresponding online resource? At least until some sort of encapsulation (ever) manifests?

Could even potentially supplant many PDF offline functions such as fill-print-scribble (signature) forms.

Sorry, I’ve been moving house so I haven’t had time to finish this up, but I’m working on it.

Here’s a prototype of how the document would look:

https://www.hypertext.plus/demo/htmldoc-test1.html

It has a small bit of JS at the top of the page and all the assets are included are the bottom of the page in an organized JSON blob containing the base64 encoded files, leaving the rest of the page untouched. The JS simply intercepts the elements as they are parsed and swaps out the src/hrefs for the appropriate data urls below. By adding in a super restrictive CSP to the top of the page, it's guaranteed to be safe and private to open.

That’s the prototype of the file format, then once that’s settled, I’ll add it into the editor.

Here’s a prototype of how the document would look:

https://www.hypertext.plus/demo/htmldoc-test1.html

There is only one catch, the inlining of videos and big stuff can slow down a browser like hell. Inlining of video could be optional or lets say there should be something that checks files size and anything bigger than X MB should give warning like "Inlining a file larger than X MB can make loading slow or hang the browser on low end devices" . Maybe we should keep track of file sizes X and cummulative file sizes Y, and if X>=Y>= maybe 50-100MB then warn the user.

You could experiment with filesizes by doing this:

Use a high end computer and a low end computer / phone.

Download a tiddly/feather wiki https://codeberg.org/Alamantus/FeatherWiki / https://tiddlywiki.com/ and add big files to it and save each time.

Make it such that you get the single file wikis of following file sizes: ~10MB, ~50MB, ~100MB, ~500MB

Then load that document on the above mentioned devices. And note how sluggish each file is relatively.

The file size of the wiki that loads without problems or much sluggishness on devices can be marked as the safe size Y.