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.

If only the Web had a way to make text clickable withtout showing the whole target URL.

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.

[1] https://addons.mozilla.org/en-GB/firefox/addon/nolinks/

Wouldn't a user script work just as well for this purpose? `document.querySelectorAll('a').for each(a=>{a.outerHTML=a.innerHTML});`

Sure, that works too. You still get the megabyte pageloads though, and you need to carry the script with you every where you go.

Looks good. A bit out of date though

Yeah, I think the there is a new data dump available, will rebuild the html files from that soon.

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.

Sarcasm acknowledged

Hiding in the URL is a favorite feature for scams and pranks

The technology just isn't there yet.

The reason is that trolls like to post links to shock sites or a google search for something terrible. Even worse, you could get rickrolled.

Some day we will have native browser support for the full URL showing in the status field.

Oh no cried the scammers, how will we ever again trick people into clicking a link

window.status to the rescue! We must override the long scam URL there!

Just wanted to say, the best part was acknowledging the worst was being rickrolled. xD

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.

Do you think you could elaborate on how this works? It seems like a very ergonomic alternative to traditional footnotes.

Good question.

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.

I like how the site being discussed implements footnotes with a hidden checkbox followed by <small> tag: https://john-doe.neocities.org/

> Why not leverage <details> and <summary> to show them in-place

Searchability. You want footnote content to be Ctrl+F-able.

A smart browser could understand footnotes and show them in searches.

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.

I’d want templating if I’m going to make more than two pages on a site.

HTML has that built in: https://developer.mozilla.org/en-US/docs/Web/Web_Components/...

You'd need some JS to make use of them though.

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.

Static site generators like Jekyll and Hugo are perfect for this :)

You can run React (and everything else) off a CDN.

React runs in the browser. You probably mean serve the files off a CDN

Yeah that's what I meant.

It can also run in the server with Server Side Rendering[0]. I believe some CDN's also offer support for this, too.

[0]: https://reactjs.org/docs/react-dom-server.html

> HTML and CSS alone are really powerful

https://html.energy/

> Written in pure, raw HTML. Can you feel the energy?

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.

The Patreon page isn't HTML. Guess there are limits.

getting zombocom vibes

You like to live in hard mode. I like that.

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.

Building a website without JS is not hard.

Depends of what a website is for you.

The same it is for everyone since the beginning of WWW: a static page with images. The web is uniquely unsuitable for anything else.

So forget e-commerce? Amazon didn't do too badly and CGI was hot on the heels of HTML so I think "everyone" is a little exaggerated.

> So forget e-commerce?

Says (s)he and immediately follows up with

> Amazon didn't do too badly

My point is that the WWW was a lot more than static HTML and CSS pretty soon after its inception.

You're confusing displaying different information at different URLs with being "more than static HTML and CSS".

This is a very old fashioned point of view I’m afraid, things have moved on.

I know enough to don't feel the need to demonstrate a random guy in a forum that I know more about a topic.

May I ask how to create a Mathematics Stack Exchange clone without JS?

PHP and cocaine.

In the past Latex symbols were rendered on server as an image.

It was not pretty but it works virtually anywhere.

What part of a Mathematics Stack Exchange clone would require JS?

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!

The MathJax part.

MathJax is somewhat convenient but doesn't seem necessary at all.

Completely agree

How old are you?

~~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.~~

Edit: I obviously didn't read the article...

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.

Thanks for sharing, beautiful site. Great typography.

Can you filter some of the content based on say selected keywords? #physics on physics and … not sure even one can two keywords.

#physics:target #section-1, #physics:target #section-2{display:block}

then wrap the sections in <div id="physics">

nice. most sites that use javascript don't need to... https://i.imgur.com/qaJYWit.png

I’m not sure that Google Maps is the best example of something that should work well without JS.

True, but even Google Maps could work without Javascript... It may not be as easy to use without it though.

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.

I'm not saying the experience is as good, but sometimes you need or want to browse without Javascript (at least some people).

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.

We did, yes.

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.