281–290 of 333 posts
Earlier quoted context omitted.
But what is the benefit?
Showing the capabilities of the web browser as an application target, directly. You have HTML, CSS, and JS available. No build tools required. Take this file and open it with a web browser. Then modify it, and refresh the browser. Distribution and Development for applications is about as straightforward and accessible as it gets.
Earlier quoted context omitted.
> there's no (easily accessible) reader mode equivalent for PDFs. It’s called Liquid Mode in Reader, and it is, in fact, easily accessible. > HTML is a far better document format than PDF. HTML is better for some things, PDF for others. That's why PDF is widely used on the web when HTML is available.
Liquid mode only works we for a subset of PDF files. And sometimes it doesn't work at all.
HTML and CSS alone are really powerful. I decided not to use any JS on my personal site, but you can still have: + collapsible sections with `details` and `summary`[0] + footnotes, with navigation to/from with anchor tags. You can even apply CSS on the currently selected footnote.[1] + Semantic web that is compatible with everything and has sensible defaults so you can focus on what you're actually doing! + Tiny depl…
Did you manage to sell Romulus to any gov customers? I built and sold a similar solution on top of SAP Hybris which we sold to several government departments around the world. It’s a very hard sell even with the worlds largest software sales organisation behind you.
The start was in political offices, which need CRMs and are motivated to move or they're fired. Constituent service satisfaction is one of the top indicators of being re-elected.
Moving into permanent government departments is more of a pain but we did see some success there.
Ultimately, though, the trough between early-adopters and getting mainstream is dishearteningly deep and there aren't enough ealry-adopters to build momentum. Not for us anyway.
Is this a joke? Why is this a revelation?
Earlier quoted context omitted.
I think you've just described an EPUB?
I thought epub files were basically zip archives of all the required files
I'd argue that that's not meaningfully different to OP's suggestion of a HTML file with all the content inlined, though. It's still a single file grouping everything required together and can be easily edited and read practically anywhere. It has a few advantages over the inlined-content HTML file, too:
- You can read the compressed file directly, an epub being typically half the size of the uncompressed files (going by a quick test of 30 randomly-selected files I had on hand).
- Storing the actual JPEG, PNG, OTF, etc files inside the zip is more efficient than inlining them as base64 and then making the browser decode them, in terms of both speed and filesize.
- While reading an epub, different sections can be a different HTML files, and only one needs to be loaded into memory at a time. This can be irrelevant for smaller things but it can make a big difference sometimes--with pages that include many charts and tables, documentation for graphics libraries that include images and animations for each documented function, etc.
- Epub files have native support for highlighting and bookmarking, to keep your place in long documents and share the file with your highlights attached.
Earlier quoted context omitted.
That could easily be made into a PWA that people could save and view offline. I've been doing this with create-react-app and markdown files (muuuch bulkier solution) but it's an offline docs-like SPA people can click around with interactive examples and shareable links etc. Seems like offline availability was not a priority for other docs-making tools like docosaurus etc (last time I checked)
Please, don't make me run React to read your document, and don't make my device parse Markdown and generate HTML on each visit. This is wasteful. I and the planet should not suffer because you decided to author your book using Markdown (which is a fine format, but my browser does not understand it natively). A virtual book is best served as plain old static HTML pages. Shareable links is indeed an impressive feature,…
To play devil's advocate: a majority of web traffic is on phones and tablets now, especially for long-form content where you will frequently see people request a page on a desktop, then request it two minutes later from a phone or tablet where they can read it more comfortably. 99% of mobile users will be happier when a text-heavy site is a PWA that caches itself, rather than a static HTML site that asks them to download a zip file, install an app to work with zip files on their device, unzip it to a folder of hopefully-relevantly-named HTML files, and then browse those, in the process breaking link sharing, link navigation (depending on OS), cross-device reading and referencing of highlights/notes, site search, and so on. Not to mention the limitations imposed on file:/// URIs, like browser extensions not working on them by default, which is a real problem for users relying on them for accessibility (e.g. dyslexia compensation, screen reader integration, stylesheet overrides). A lot of times that won't even be possible on a dedicated reading devices; my ereader will cache PWAs but will not download arbitrary files, if you make your site a PWA I can read it during my commute, if you make it static HTML with a zip file I can't. These are features most users appreciate a lot more than not having to load a 60k JS bundle (current size of React gzipped).
Well, TiddlyWiki[1] has been going it for 17(!) years. It's a very mature, polished, and extensible engine for wikis, blogs, and personal knwledge bases. The entire thing (including the editor!) is a single .html file. By default, even images are embedded. For my ADHD Wiki[2], a resource that talks about ADHD with a copious amounts of relatable memes intertwined with the text, I chose to just use images in the same d…
Yes, TiddlyWiki is great, but isn't it full of JS? I mean, the somewhat special thing here, is that the page is built without JS.
The author seems to be fascinated by the concept of single-HTML website which uses anchor links for internal navigation to reveal or hide content instantly without page reload.
That's exactly what TiddlyWiki does.
If you are JS-averse, you can generate a static HTML version of the wiki as well without JS in it [1]. It doesn't use CSS tricks though to show/hide parts.
[1] https://tiddlywiki.com/static/Generating%2520Static%2520Site...