Entire website in a single HTML file
css-tricks.com
css-tricks.com
+ 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 deploys and page loads. Single KBs (with brotli compression) for long blog posts. Just `scp` and Nginx keeps serving.
I can't think of anything else I want. And when I think of it, I can probably build it on top.
[0]: https://maddo.xxx
[1]: https://maddo.xxx/thoughts/an-introduction-to-product-strate...
Has several CSS files (one 2.5 Kb) and a 13Kb minified js file (https://www.statcounter.com/counter/counter.js) that does... something related to user tracking.
I don't get it.
Says (s)he and immediately follows up with
> Amazon didn't do too badly
It was not pretty but it works virtually anywhere.
You'd need some JS to make use of them though.
then wrap the sections in <div id="physics">
See your comment as an example. Why list all links at the bottom rather than in-place?
For my site, there are other options that I'd like to explore. Tooltips for smaller things (like definitions) maybe sidebar notes for large screen sizes, and inline notes (like show/hide inserting it between that line and the next) for mobile.
I'll look into those.
This avoids requiring both long scrolling and interactivity.
Hiding in the URL is a favorite feature for scams and pranks
Searchability. You want footnote content to be Ctrl+F-able.
As for <details>, you run into the problem that it’s a block-level element; it’s dubious using it as an inline-level element, though it’ll probably work well enough (I say probably due to uncertainty about screen readers) despite being nominally invalid, given that it’s not an element that will automatically close a paragraph tag like <div> does.
I think links at the bottom is generally foolish, taking more effort for both reader and writer, and never do it that way, interspersing them in the text, usually surrounded by angle brackets as has historically been the way of delimiting URLs in plain text.
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.
Edit: I obviously didn't read the article...
* Yes, I know, PDF doesn't -always- do this, but a well designed PDF generally does.
HTML can be styled in a fixed layout if desired, and reflowed by a reader mode if needed. PDF can't be styled in a responsive way, and there's no (easily accessible) reader mode equivalent for PDFs.
HTML is a far better document format than PDF.
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.
The dimensioning problem isn't PDFs. The dimensioning problem is computer displays.
Get yourself an e-ink display of 10" or 13" (standard dimensions offered by the patent-monopoly vendor across multiple OEMs), and discover that online reading of PDFs is 1) quite pleasant (so long as the underlying PDF formatting itself is sane) and 2) vastly preferable to either HTML or "fluid" ePub or Mobi file formats.
Book formats developed over about 500 years largely guided by the capabilities and limitations of human eyes and hands. Typical mass-market books range in size from roughly 6" to 12" diagonal measure. Yes, there are smaller and larger formats, these are deviations from the norm and impose compromises for other concerns (portability for smaller formats, resolution for larger ones, typically pictoral or graphical in nature).
A 5" or 6" mobile device presents less display area than an index card. Laptop displays are too short to display a portrait-mode document one page at a time, and in almost all cases too small to present a 2-page up display.
(You can verify this yourself trivially at the Internet Archive using its BookReader, e.g., https://archive.org/details/UnderstandingPhotoTypesetting/pa...)
When wedding PDFs with an appropriate display technology, the frustrations fixed-proportion PDF display disappear.
This does rely on the PDF being dimensioned for a typical book size, though there's considerable flexibility here, and any dimensions from ~6" to well over 12" will tend to be readable, there's no need for precisely matching device to document size.
I'm saying this as someone who's long railed against PDFs for documentation. My mind's been changed.
Notably this is not the standard size for most e-ink devices though, on which pdfs are a pain to read. Mobi/epub files, in contrast, are fantastic on my kindle (and on my phone, and on desktop).
If your argument has to boil down to "this file format is great if you just buy a specific device for viewing them, and eschew viewing them on any of the other devices you already own and use more frequently", I'd say your argument provides more evidence for the counterpoint than for the one you're arguing.
I'm happy you found a good way to consume a fundamentally outdated format, but PDFs are a bad format for the majority of use cases.
Again: at 8", e-ink is pretty broadly useful. If you're frequently reading scanned-in journal articles, the 10" or 13" devices shine, though these can be accessed on smaller screens using in-page zoom-and-scroll. (Onyx BOOX has several settings for this in its NeoReader app.)
Note-taking, which was not a use I anticipated using, also happens to be really well-suited.
Yes, you can read on a smaller device if you must. However you're making the same sacrifices for mobility that are present in pocket-sized printed books, and the format is best suited to largely unformatted text (e.g., prose). Diagrams, tables, and other layout translate quite poorly, and this is intrinsic to the display itself.
The one task to which the tablet format seems best suited is precisely e-book reading. So I've ditched the "smartphone" (a pocket snoop) and settled on laptop / desktop (productivity) + tablet (ebooks), and dedicated devices for specific other applications, most especially capture (audio, images, video).
"The Case Against Tablets"
https://joindiaspora.com/posts/880e5c403edb013918e1002590d8e...
There have always been other tools for producing PDF (E.g. TeX) and there are also tons of free converters, print-to-PDF drivers, etc.
Also worth noting that the PDF preview on the Mac has very nice simple editing capabilities to combine pages, delete pages, crop etc.
Yes, they did. (Non-Adobe readers often don't support JS, though some do, but Adobe definitely built the support for interactivity.)
Also 3D content and a lot of other things most people probably aren't aware of, because they are peripheral to the common use cases of PDF.
HTML can be responsive, like an electronic document should.
PDF was designed to faithfully represent paper, and it has all the fluidity and customizability of a stack of printed paper. It's also completely anti-semantic: it has no document structure beside pages, and each page just describes how to put ink onto paper.
I think that the principal application area of PDF is just that: to represent paper, for printing purposes. For everything else, it's not exactly great.
yes they did. JavaScript, though I have no idea if there is a DOM or anything like it. pdf is kinda messed up in ways like that.
A lot of the issues "solved" in modern frameworks could have been addressed by using this, but instead things went a different path.
This method even works well with the back/forward browser buttons, something that a naive show/hide JavaScript solution wouldn’t.
If you want to consider that single or multiple files ... quickly veers into semantics.
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.
It's in the interest of publishers not to offer them, however.
A chief example that comes to mind is the Feynman Lectures in Physics series, which are available online but only in a chapter-by-chapter basis in HTML format. (Quite beautifully formatted, FWIW.) If you want to glue those together into a single integrated whole, you'll have to do that yourself.
PDFs and ePubs afford the single-file format.
Copyright status means that anyone who glues together the set will find themselves pursued for infringement.
In practice, the question's moot as the Feynman Lectures are available via LibGen, ZLib, and similar resources.
Surely this exists already? It's good and obvious an idea to not be taken already.
You can add some JS here and there for the few really interactive elements of the document but my browser already has all the features to render documents and links perfectly fine. People have been able to "click around" since 1991 and we never needed to download, parse and execute 2MB of JS for this.
Your book is probably big, and I'm probably not reading it in one go, so if it includes images and videos, downloading it all is probably unnecessary and the book is probably best split in several HTML pages. If you want to allow me to consult it offline, that's very kind and noble. Just put a zip file somewhere I can download.
Sorry for the rant, but I'm a bit fed up by having to download run megabytes of Javascript I can't control (and even read, because yay, bundles!!) to browse the web, just because.
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).
Chrome: File > Save Page As... > Webpage, Complete
Safari: File > Safe As... > Web Archive
My god, it's just text files and images, you don't need JavaScript.
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 directory instead of embedding them; so you might need to do some work to download that page (I think File -> Save as.. can give you a readable static version on some browsers).
Anyway, somewhat surprising that people are stumbling into how much you can do with just one well-crafted .html file. Look ma, no node.js, no (no)SQL database, no nothing except for one file for one website (and that file isn't even that large, given what TiddlyWiki allows you to do).
TiddlyWiki can be run on node.js, but I don't see much reason to. If I want to make changes, I use the built-in editor, and then the "Save..." button generates me the .html of the updated version. Save it over the old one, upload over ftp, done. No deployment process to speak of.
And, at that, the feature set rivals (and, at times, exceeds) that of, say, Wikipedia.
(And for math nerds: it supports LaTeX via a KaTeX plugin. Maybe you can't copy-paste your entire thesis, but it's pretty damn close to real-time full-featured LaTeX).
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...
I've found having it all in a single html file tends to makes it easy to survive on a lot of different kinds of networks, and I like that the larger context of the site is automatically attached to any particular part of it (which is invaluable for my work). To my eyes, it's what a PDF dreams it could be.
Never have to worry about the editing environment when porting from one machine to another. Never have to worry about version compatibility and stuff like that.
HTML+JS are mature enough that we can reliably expect the software required to open and edit your notes (i.e., a web browser) to reliably exist in the future. Can't say the same about most other formats.
Even LaTeX, with its version-control-friendly text file format, very quickly runs into portability issues with package management. Someone gives you a .tex file - good luck trying to compile it without Internet connection.
PS: awesome website and art, thanks for sharing!
But:
- No, the entire website isn't a single HTML file (it's also images and a CSS file)
- So no, you can't download a single file and have it work offline
- And no, this won't work well with screenreaders and other non-standard clients
- And no, this doesn't scale well to larger sites
- And no, this won't be indexed well by search engines
- And no, you don't need this to avoid Javascript navigation (just use multiple HTML files)
But if you just want to be able to save the entire website with Ctrl + S, then it works fine.
As an aside, loading="lazy" is the way in which images are embedded in the website from TFA https://i.imgur.com/wIkaE5g.png which was the reason why I mentioned it, although it certainly does not fit all possible use cases.
If you get hung up scaling a single page, you have other problems
And how is 20MB js SPA with 20 wss connections more scalable?
I've see too many react/vue projects bundling everything into a single main.js file even pages I never click. e.g. some crazy map or graph module. Is there some magic in webpack to make sure the needed functions gets executed in "eagerly" fashion?
Or does json provide streamable parsing capabilities?
Edit: I just read tyingq's explanation. Is there anything else?
1. You can embed CSS easily, and images using data: URIs...
2. ... so you can download the whole thing as a single and work offline.²
3. Non-standard clients are not my problem, file under “you can't please everyone, especially those who chose to be difficult to please!”. Accessibility is a concern though, I'd need to look into that before using such techniques without a reliable fallback.
4. This isn't practical for sites/pages needing large resources like high-res images, or that are large generally¹, but not all sites/pages need large resources or are large in general.
5. Not everything needs to be indexed well by search engines, I have things out there that are only relevant to those I refer to them, though I agree this could be a significant issue for many.
6. True. Though that breaks your second point, so you need to choose.
----
[1] you wouldn't want wikipedia done this way!
[2] also with external resources almost all browsers will happily save then when you do file|save, and to be pedantic the description given is “in a single html file” not “in a single file”
This is all classic and supported HTML, so those should work perfectly for this.
A site is a collection of those.
But you know this doesn't use JS, right? (joking)
You're maybe parallelizing things. As the client is downloading and interpreting the css and JavaScript, the server is doing database calls and rendering the HTML.
So you actually are doing things on the server side when you're "blocking"on the client. You didn't get this for free. You had to worry about buffers, flushing, and plenty of testing.
I don't know if you can still squeak an actual speed up with this technique (there's many attributes you can use to customize things these days) but I used to use it all the time back in the days of platter drives.
This is a web site as a single file, using CSS only.
It's a CSS equivalent to a single-page application (SPA), except that this is a single-page site. SPS, perhaps, or maybe a multi-paged file (MPF).
Strictly, it requires CSS features which weren't originally present in HTML, though the concept's likely been possible since the early 2000s, if not late 1990s.
It does rely on CSS support within the browser, and some simple browsers (mostly terminal-mode clients) won't present the multi-page aspect. The site / page itself remains useful.
> the whole website is contained within a single HTML file.
Because, it's not. An HTML file, a CSS file, and some PNGs. What's interesting is there is no JavaScript.
Having no JS or having everything in a single HTML file, and the title suggests the latter.
Also, you can embed the JavaScript too.
Then in practice the issue becomes a bloated file that isn't able to reuse internal components, at least not without introducing a layer of complexity such as a scripting language and browser APIs to go with it.
Perhaps if HTML had been designed with more component re-usability in mind, the landscape of the internet would look very different today. Then again, what sense would there be in having a single HTML file for a site like Wikipedia or Altavista? And imagining the web evolving without a scripting language would be naive.
Single file websites that could be served up on blob or network storage certainly appeal to me, especially today.
what would make it different from DAT's Beaker Browser?
The article is not another pointless potshot at frameworks, it's showing a clever use of a new standard to allow multiple pages in the same HTML document without using Javascript.
At one point we were able to create "interactive" content entirely in our heavily customized BBCode without a single line of JS, and this #target is one of the more used tricks.
But people made big “clubs” and then created these really cool semi-interactive posts using just CSS. It was really awesome what people can do.
Has made tens of millions in revenue.
Just assumed every developer or template seller in south asia was using this - or their clients. Probably more common than you think.
If you already knew about this, the post seems like a joke, you've made millions off this for years now--that's really special, but that is also pretty subjective and doesn't mean it's not meaningful that one of the top CSS sites shared this article out this year.
I heavily encourage people constantly demonstrating how to competently do things using conventional systems.
I've gotten into many arguments over this stuff. Not that these simpler approaches don't work, but they lack the formality and theater.
Some people need to see stuff like this every day until they stop creating giant towers of spaghetti that don't do anything
There are no^W^W is one external dependency (the stylesheet https://john-doe.neocities.org/style.css). This could also be inlined, and is required for the concept to work. There are 75 directives and/or media queries.
The site can be browsed entirely offline once accessed.
On the other hand, there have been solutions for this case for ages (like using radio buttons), so using :target is just a somewhat cleaner approach from my point of view.
I think a major issue with this approach is just practicability - I'd want to write my content in something like markdown and we will anyway need JS to convert the markdown to HTML.
I have also been interested in making SPAs, my my way is more traditional. Using javascript for the stitching. But only Vanillajs. I don't use any frameworks and bundlers for my SPAs. In fact right now I am working on a simple blog: http://rishav-sharan.com using just HTML, Vanilla js and Tailwindcss.
If anyone is interested in my approach, I have an article detailing things there, or you can just read through the source. Its un-minified and fairly readable.
And as it doesn't have any server for the markdown (they are just CDN files), I have to use JS to do the translation to HTML.
That's the entire problem with JS: i can't browse a page without a complex rendering engine (arguably full of security vulnerabilities) or even scrape it. Something like webmention/microformats (indieweb) federation becomes almost impossible with you due to your setup.
Also worth noting, rendering the Markdown on the client is super inefficient. First, because client-side JS will always be far slower than native code server-side: i first need to download the entire JS then run it in a super slow sandbox. Second, because there's economies of scale to be had: it may take a few milliseconds to build the markup, but every client has to do it. For n client, that's O(n) complexity vs O(1) for server-side rendering. So many CPU cycles wasted :)
You could compile the markdown to HTML server-side …
I’m also more in favor for compiling the MD to HTML once and then serving pure HTML via the CDN. You could still keep it to the two steps you outlined in your blog post by running the build step and deployment using github actions.
site:john-doe.neocities.org in a google search only finds the main page and dist page.
Google likely haven't designed their indexer to handle pages like this because not many people do it.
Many people don't do it, because Google won't index it properly.
https://developers.google.com/search/blog/2009/10/proposal-f...
No idea if that still works.
Sometimes you want as much information as possible on a page. Sometimes you want one and only one portion presented. Which you choose depends very much on the application, user community, and objectives.
But there is definitely a trend that our collective cost models are downshifting from “ah fuck it’ll be faster by the time this ships” to “well right this minute we’re not zero-effort scaling on the backs of the deep-infrastructure people”.
Maybe this perspective is perverse, but I personally find it cool that there’s both money and hacker cred in counting bytes, even megabytes, after a long time of “well the hardware will be better in 6 months so why bother”.
1. https://github.com/cadars/portable-php 2. https://news.ycombinator.com/item?id=25770516
https://www.gnu.org/software/texinfo/manual/texinfo/html_nod...
The difference is that Info requires a dedicates reader (the info or pinfo command-line utilities, or of course, Emacs), whilst this format will work with any graphical Web client.
It doesn't quite work as planned with a terminal-based browser. I've opened https://css-tricks.com/a-whole-website-in-a-single-html-file... with w3m, and rather than seeing only one of the intended "pages" at a time, the entire "site" is presented. That said, degredation is graceful, and navigation works.
I'm quite impressed.
"Show HN: A simple way to make HTML websites": https://news.ycombinator.com/item?id=25170078
It's also available as a library / on the command line: https://github.com/leoncvlt/imml
[1] http://futureasapresent.org/trinkwasser.html
[2] https://cleantechnica.com/2021/12/18/climate-change-impacts-...
It's a bit of a weird flex but was fun to do.
im obsessed with offline-first/offline-only (optional) and have been trying to build all my products with the underlying philosophy of single-file tooling and “infra-less” in-mind; meaning it doesn’t care where it lives and highly portable by default.
here’s a note taking app that is all in a single html file. images are base64’d and data is kept in indexdb. https://github.com/bkeating/nakedNV
Here's a todo app with no javascript (not my work:
https://www.mattzeunert.com/2017/10/30/javascript-free-todo-...
Still static though. I built my blog with hugo (static site generator) and it is hardly noticable, that it is completely static.
See https://pilabor.com/blog/2021/05/building-a-blog-with-hugo/ for details.
0: https://css-tricks.com/video-screencasts/84-site-walkthrough...
Further, the no-js portion isn’t even the main idea. “Entire website in a single file” is.
The whole point here is you can do instant navigation to multiple pages that are contained within a single file without using JavaScript.
[0] https://addons.mozilla.org/en-US/firefox/addon/single-file/
Update: maybe element.scrollIntoView()? I'll investigate sometime later
I also created a forked SSG based off of https://portable.fyi/ [1]
More recently I discovered that you can just use `scroll-margin-top: 100vh`, as seen here: https://cadars.github.io/portable-php/
Got a ton of saved pages and articles from HN in my dropbox that I can read where I want later without worrying about dead links, ghost edits and other live annoying things.
https://en.m.wikipedia.org/wiki/Wireless_Application_Protoco...
What's being shown off here is not having a single page of a website in just HTML/CSS, but having all pages.
[1] https://www.w3.org/TR/REC-CSS1/#pseudo-classes-and-pseudo-el...
In fact I was very specific about what concepts were not possible twenty years ago: "What's being shown off here is not having a single page of a website in just HTML/CSS, but having all pages."
You're the one who proceeded to ignore that and make an unrelated claim about something different that was possible twenty years ago.
They're artificial limitations exercised in pursuit of demonstrating that, with new CSS tools, something surprising can be done. Something which, as I stated in my original comment, could not be done twenty years ago: putting multiple pages in the same HTML file without Javascript.
https://twitter.com/rafalpast/status/1316836397903474688?s=2...
If people (like me) want to offer resources requiring none of that, why not encourage them, insofar as it makes the internet more efficient, a more helpful resource, and just way cooler in terms of chilling with all the crazy wasteful and annoying JS activity.
It's valid, relevant, and worthwhile. There's really no need to talk about being scared, as if this is some issue that requires a good talking to from dad.
Your original reply was really uncalled for. Now you're back to some combination of hand-waves and missing the details (which self and others have shared up and down the thread already).
Really, a more respectful, thoughtful approach is merited.
The hell happened? Did I get cryogenically frozen and just woke up?
It would be like telling someone who has been using an IDE: did you know you can compile your code from the command line? And having that person genuinely be blown away.
You can click on a comment directly to reply to it immediately. Use this knowledge with care.
I'm picturing way to many people viewing this today and thinking "Wow! Websites can be made without React? I will upvote!"
Are we at a point where university Web101 classes just jump straight into SPAs?
The trending topic on front-end twitter last week was if you should even bother learning CSS or is only knowing Tailwind fine.
It's madness.
Though almost no one is able to do it.
Which is weird, as it's objectively easier than writing enterprise react crap.
There is a concept of a single file app (SFA). You can share an html file, and that is the application.
It can have inlined micro js/css frameworks, or hand-rolled everything. An SFA should be human readable though- viewing the page source is useful.
I think it’s a concept worth exploring.
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.
The example URL is a complete website within a single HTML document with no external dependencies and no further round-trip requests. It is a single-page site (SPS) or perhaps a multi-page file (MPF).
https://john-doe.neocities.org/
You can open that URL, disable networking, and browse the entire site to your heart's content in any browser supporting CSS.
If you open the file in a terminal browser (lynx, w3m, elinks[2], etc.), you'll see the full site presented at once, as a single page, without needing to specifically navigate between them (you can scroll the full site). Though the intra-site navigation itself still works --- it just doesn't reveal or hide sections.
BTW, the discussed page is not at all a single-page site; it makes separate network requests for CSS and PNG files.
The concept of an "SPA" refers to the appearance rather than provisioning of the app, and inherently relies on Javascript (or an equivalent scripting capability) to interactively rewrite the display. It's possible to single-file an SPA. The characteristic isn't central to the SPA concept, and in practice implementation is typically anything but.
SPAs are not accessible without Javascript, and don't render at all from a terminnal / console-mode browser. (Ask me how I know this...)
This is not an app. It's a website, or at least, multiple web pages, provisioned from a single HTML file.
Yes, this instance has several external references. I've noted CSS in an earlier comment, you mention image assets. The concept could be further optimised for portability by incorporating those inline.
Note that optimisations are also trade-offs. Inlined assets would mean duplication for a larger site. Which of those trade-offs are preferable or unwanted really depends on the specific goals.
But as a demonstration of an idea, this really is pretty elegant.