This has never been the case. Custom elements are DOM Elements and so are just JavaScript objects. Just like you can do aEl.disabled = true, you can set any prop to any type of value.
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.
> For example, .js files are supported for loading locally
Technically yes, but last time i tried that it gives you CORS errors now. You can start your browser with CORS disabled, but that makes sharing your .html file impossible. So back we go to inlining stuff :)
Carp is great and I would love to include a mode of jank which is very much Carp-esque. If you're interested in working together on this, please let me know.
Yeah I like this layout and it seems to be available on all Linux distros.
I only use it occasionally to talk to friends back home though, not sure how it is for constant use.
Using a bool instead of empty struct also means that there is more way to use it wrong: check the bool instead of if the key exist, set the bool incorrectly, etc...
I would argue using bool hurts readability more.
Even better write/use a simple library that calls things that are sets `Set`.
Almost made it into 1.18 but looks like it doesn't add enough value and has some open questions like what to use for a backing data type and what complexity promises to make.
I feel the same. If someone would ask me for a recommendation I would point them toward Zellij but if you've been using tmux for years it's probably not worth it.
reply