Reminder: You Can Stitch Together Lots of Little HTML Pages With Navigations For Interactions
94 points by LesleyLai
94 points by LesleyLai
I'm generally a fan of always responding with HTML, however I'm not so sure about things like menus. I'd be interested to hear an accessibility expert's input on what's better between a toggleable element and a full page transition to open up a menu.
The Popover API feels like it would be the better solution here, since you can ship a JS-free menu without invoking a full round trip. As for most other things, I agree that we shouldn't fear the page transition. SPA-like navigation is now nearly always accessible to SSR and static sites with little difficulty.
I'd be interested to hear an accessibility expert's input on what's better between a toggleable element and a full page transition to open up a menu.
Barging in as someone who isn't an "accessibility expert" by any means, but does have NVDA installed specifically for web development - in terms of user experience I don't notice any difference. Page navigation resets where you are on the page, but as long as I intend to open a menu, and end up in a menu, they are pretty equivalent.
The biggest thing is that, just like for a non-screen reader user, it's pretty weird to navigate to a new page when you open a menu.
Reminder: You Can Stitch Together Lots of Little HTML Pages With Navigations For Interactions
Key word: 'can' (not 'should'). Use HTML pages for interactions when appropriate. Use other things when more appropriate. Eg would you use two different HTML pages for the expanded/collapsed versions of a component, or would you use the <details> tag? Obviously the latter, right? In the same way, it's perfectly fine to use the Popover API.
The point is to '[a]void in-page interactions that require JavaScript', not to insist on the use of multi-page HTML navigations.
The presented method uses JavaScript and onclick to dynamically load a menu. This introduces latency and an extra datapoint on the user journey.
Instead, the menu could be added to each page and shown and hidden with the <details> element or with the :focus-within CSS selector. This is how https://nlnet.nl does it.
Nice post! However, the approach described doesn't actually work at all: If you open the blog post with JS disabled, then open+close the menu, you will land on the home page (/), not on the blog post. The described approach will only work if you dynamically render the menu on the backend, in order to have a correct link for the close button.
Personally I would also prefer using the Popover API if possible, since then everything can be statically rendered without a backend.
The X icon's link in the menu points at https://blog.jim-nielsen.com/, but if you run JS the navigation appears to gets hijacked by the onclick handler with:
document.referrer
? history.back()
: window.location.href = '/';
return false;
This is poor UX as the link takes you into a different page than what's stated in href. I frequently hover links to see where they direct me to and I don't appreciate being misled.
Not only that, but one of the central points of the OP is that it works without JS:
Have an older device, or an older browser, or JS disabled, Et al.? It’ll still work.
But it doesn't actually work without JS, it takes you to a completely different site.
It could be easily improved by just not having a close button. Browsers have standard back buttons that do the job!
Hell, if you really absolutely positively want to ape mobile application for some weird reason you could inject the close button in javascript, that way if it's present it's doing the right thing, and if it's not present it's not doing the wrong thing.
This code also does the wrong thing on right-click, as well as clicks when a modifier key is held down.
On the one hand, I love this! HTML can do a whole lot, more smoothly and simply than in JavaScript.
On the other hand, this seems to work well mostly on mobile. On a desktop page we would expect the menu to be constantly present, or pop out or something, not require a page navigation.
So do we now need to have 2 sets of pages for different browsers?
Counter point. On mobile, when connection is spotty, you have to navigate to the menu and then to your destination. Double the friction. :/
Maybe so.
Maybe on average the page loads are smaller so that the pages are smaller and easier to load.
I'm not sure this is easy to generalize one way or the other.
No, generalization from my part. I just wrote it from my own personal experience, using a shitty Wifi while traveling. :)
But to play devil's advocate where does this stop?
Loading the menu may be slow, so bundle it into the page. But they might go to the homepage next, and that would be slow, maybe we should bundle that too? What about the next post? the previous post? all the pages on the archive?
There is sort of a fundamental tradeoff here between loading less and having snappy navigation. In this example maybe a preload hint for the menu would be optimal. It would load after the main content (as opposed to usually loading before the actual content for top menus) but should still be snappy to load (assuming the user clicks after the prefetch succeeds).
I mean, that's exactly why web development is hard - there's no one single good answer about where state should live in a distributed system. Put more state on the server and you have a simpler client, but more network calls, leading to more chances for failures and delays. Put more state in the client, and you get rid of network calls, but you have a more complicated and bloated client. Added to that that the initial loading of the client requires at least one network call, and it's clear that's it's going to be a case of juggling trade-offs and understanding the specific needs of each case.
That said, menus are very easy to implement with very little JavaScript (possibly none at all with a combination of some of the newest html features?) and add basically nothing to a page load, so I don't see a lot of value in trying to put them behind a network call.
I am guessing you are relatively young. Not sure which percentage of readers are aware of this.. but this is how every website worked 20-30 years ago. And kind of how html was intended to be used. JavaScript was accidental.
I am puzzled that people this this is more difficult/complicated than any JavaScript solution. It certainly is the simplest and easiest way to build a website.
20 years ago we had frames and framesets, so you could still have navigation and content at the same time
A more complex variant is Server Side Includes or Edge Side Includes. The latter is supported by Vinyl Cache/Varnish Cache: https://vinyl-cache.org/docs/9.0/users-guide/esi.html
They are simple enough that you could later decide to build a static site based on the <esi> tags (could do it in a shell script if pressed), if you only do simple file includes.
Today we also have htmx and similar libraries, which can do client-side includes quite effectively.
I am also not a fan of that menu design. Putting the menu on a separate page looks alright on mobile, but it is not how "old school" websites do things. Even if you visit a 90s website, you can see a lot of sites with nav bars. On the other hand, using a toggle for a menu is a trend popularized by mobile.
And menus can be put on the same page without JS. If you want a different menu style depending on screen size, CSS has you covered. And if you want to have fancy interaction to hide it by default, you can use the invisible checkbox trick or HTML popover attribute.
That said. I like the author's idea in general, and that's why I shared this.
Frames/iframes never reached more than 10% of all websites. And that was at their peak. Early versions of IE didn't support them. And when they finally got widespread. Browser support. It was already clear they were a bad idea. Virtually no serious comercial site had frames.
this is how every website worked 20-30 years ago.
Nonsense, having a separate menu view / page is entirely an artefact of mobile applications and websites. "Normal" website would show navbars on every page, possibly using includes, framesets, or flash to make maintenance easier.
I am puzzled that people this this is more difficult/complicated than any JavaScript solution.
It's literally a javascript solution, the "close menu" link requires javascript to work otherwise it sends you fucking off to the site root without warning.
Nonsense, having a separate menu view / page is entirely an artefact of mobile applications
I am guessing you're very young, or else you are talking about some parallel reality I am unaware of. Having a bunch of html links absolutely was the way 90%+ of websites worked even before JavaScript or flash plugins. I have no idea what "close menu" refers to. I am talking about a bunch of links includes in a page template layout used I a collection of documents. This worked for one and a half decade before the iphone was launched. Mind you. By the time frames were supported in all browsers, they were already being phased out as they were an horrible idea. And never really caught up with Google cold bloodly sending any website that used them out of any first SERP.
I am guessing you're very young
I'm sorry to report you need to work on your guessing game as much as you do your recollection of reality, because you're way off on both.
Having a bunch of html links absolutely was the way 90%+ of websites worked even before JavaScript or flash plugins.
Navigating sites by having a separate page with no content and only links was absolutely not how any website worked.
I have no idea what "close menu" refers to.
Have you looked at TFA? At all?
I am talking about a bunch of links includes in a page template layout used I a collection of documents.
So... absolutely not in any way what the article is about? Well that might explain why you come across as completely unglued, and why literally every reply to your comment is telling you that you're wrong.
By the time frames were supported in all browsers, they were already being phased out as they were an horrible idea.
I really have to question your experience with any of the internet back then.
this is how every website worked 20-30 years ago.
one of the oldest examples of hypertext that I am aware of, the Common Lisp HyperSpec, has ample navigation. Granted, the styling of that navigation is terrible, but they haven't figured that out yet https://www.lispworks.com/documentation/HyperSpec/Body/t_smp_st.htm
Not a fan of the nav, but loved the transitions -- wasn't aware you could do that, Applied them to my website (bespoke C++ static generator + template library): https://vittorioromeo.com/
I think it's especially nice for the dark/light theme switcher
Clicking "menu" and navigating to a different page feels bad on on desktop because it triggers a full page reload, which is jarring compared to what I expect. Personally, it interrupts my flow of reading and of thought. When I click a link that takes me to another site, it's like I am leaving a room, so I discard the prior room and move on. When this happens with a menu, it feels uncomfortable: like I walked up to a doorway and found myself in a different room entirely.
I like the idea, frankly, but it does not feel good to use.
Also, I am not sure what transitions they're talking about, but there's no transition to speak of for me: when I click the Menu button it just loads the Menu page as I'd normally expect.
Cross-document view transition doesn't work on Firefox yet. Maybe it also doesn't work on other browsers but I use Librewolf (a Firefox fork) as my primary browser. I can see the transition effect on Chromium.
It seems to be targeted for 151? https://bugzilla.mozilla.org/show_bug.cgi?id=2020327. But no trace of this on Can I Use.
This is a really fun idea but I wonder how it would work on desktop? Probably makes less sense to fully change the page since a full page menu is a little much, imo.
Doesn’t mention preload to reduce latency of the menu page load. How well would that work?
Make sure you put out the right cache headers too (a pretty simple expires one would prolly be good enough here) so it doesn't even have to validate against the server before showing and it would be very snappy.
I came across a text game by @misty some years ago based on simple links as interactions giving me an illusion of choice. It touched me deeply. Simple HTML, strong story.
The menu thing is kinda brilliant, really, because being pretty much a full screen menu is exactly what everyone does now to support mobile browsers anyway. If it hadn't been pointed out, I'm not sure I would have realized I was being navigated to another page!