I have never understood why footnotes are added to the bottom when we have an interactive medium available at hand? Why not leverage <details> and <summary> to show them in-place without breaking the flow and without listing them all at bottom?
See your comment as an example. Why list all links at the bottom rather than in-place?
On HN it makes sense to me, because a long link would interrupt the flow of text. So you do a footnote to make them go out of the way. Otherwise Wikipedia has a happy medium I think; footnotes are on the bottom where you'd expect, but they show on hover so you don't have to jump there and then back.
I find inline links incredibly disruptive to my reading flow, the change in color makes my eyes start jumping around in the text. Wikipedia especially is absolutely hopeless, to the point where I've built a mirror that removes all inline links. (A page looks like this: https://encyclopedia.marginalia.nu/wiki/Hyperlink )
Just make it the same color. For me links on HN are underlined but the same color as regular text or a slightly dimmer gray if already visited. It's one of the first things I do when I install a new browser and if it's hard that browser doesn't stay installed long.
Just found this FF add-on [1], yesterday, which removes all links from a page. Works reasonably well. Can also invoke reader view after removing links and get the benefits there.
There must be other reasons, if it doesn't make sense technologically, no? Instagram also has the tech to show more than 3 images in a row, and Twitter could allow longer texts if they wanted so.
I think endnotes are typically an awful idea, and the web can’t do footnotes. What you want is generally side notes. I think what I do on my website is a fairly good compromise for JavaScript-free operation, with a side column for notes on large enough screens, and the notes inlined on small screens. That wouldn’t be suitable for very long notes; such are often more suitable as appendixes, a variant on endnotes.
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.
On my website, I ise margin notes for the desktop and "footnotes" for mobile, however said footnotes are displayed just below the paragraph in which they appear.
This avoids requiring both long scrolling and interactivity.
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.
You gotta dance with the browser that brought you though. Unless you plan to never publish you’ve gotta design the best interface you can with the constraints of your real users.
Ah, <details> and <summary>. The most glorious HTML5 elements of them all. Use and abuse these for all sorts of custom yet native capabilities, like <select>s with custom styles and proper keyboard/native controls.
This honestly looks like a huge PITA compared to even the worst static site generator’s syntax. Is this actually supposed to be used as end-developer templates?
True, but keeping to the spirit of the comment I replied to, I’d prefer it to be HTML only. Something like <template src=“header.html”> and it just uses a relative or absolute path.
Building a website in raw HTML/CSS is much easier than the equivalent in javascript-framework-du-jour. It's also much lighter on resources both on server and client. It's a win-win situation for everyone, especially for clients with less powerful computers.
In "modern" stacks it is preferable to do things like layouting of formulas millions of times on the clients, instead of once on the server. I guess that sort of thing needs JS.
As you have pointed out, but formulated more explicitly: client-side rendering should deal only with HTML/CSS because that's what the browser is built and optimized for. Every line of script changing the DOM (html structure) may trigger a redraw of the page, which means wasting considerable amount of resources! But even if your script outputs HTML only once, you still have O(n) HTML templating instead of O(1) for n clients. Such a waste!
~~With progressive enhancement, you could arrange to display only the current subpage. When Javascript is off, the whole page would render as a long-ish HTML document. Which is indeed no issue at all with the sitemap in a sidebar.~~
One suggestion, set the overflow to "scroll" so the scrollbar is always visible. When I open a section it appears, adding like 10px on the right and all the content moves left.
I still remember the first time I used google maps. It was the first example I ever saw of what was then called AJAX, and it blew my mind. Without javascript, google maps would have been the same as mapquest (or any other mapping sites from that era): a full page refresh to move or zoom on the map. Javascript was the differentiator that made google maps the winner.
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.
+ 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...