blog.smarmy.space

L5 Navigation Updates!

smh June 16, 2026

This is the third week check-in on my work with L5 this summer. This week implemented a bunch of the design with focus on bandwidth constraints!

Recap

If you missed the last post:

Based on the schedule outline

TLDR;

On Self-Hosting

I've been on the self-hosting bandwagon this summer and during this last week we had a low-key permacomputing hacking session.

I set up Coolify on a Raspberry Pi and will have an Obsidian, Calibre, and my own Bluesky PDS soon! Coolify is a self-hosted PaaS that allows quick installation of different Docker images*.

https://coolify.io/ External Link • coolify.io

I went through the Raspberry Pi setup guide which was pretty straightforward, although they did not mention any specific firewall settings. They did mention using ufw-docker which......is fine.

We will likely be using Yakforms going forward and I will probably add this to my self-hosted installation!

https://yakforms.org/en/ External Link • yakforms.org

Alternative Browsers

There are a couple of alternative browsers that we are testing on to ensure that L5 is accessible on a variety of devices.

Browsers with GUI

The first I tested was Dillo:

https://dillo-browser.org/release/3.3.0/ External Link • dillo-browser.org

Fortunately they have a homebrew package, but I didn't know this and tried to build from source which was much more difficult. It also requires using fltk!

brew install fltk@1.3
brew install dillo

Next up was NetSurf, which I actually had a lot of difficulty installing and wasn't successful.

https://www.netsurf-browser.org/ External Link • netsurf-browser.org

Their installation documentation is goofy. They say it works for MacOS, but nowhere is there instructions on the compile page on how to actually compile from source*.

Browsers without GUI

There are a few of these CLI browsers that Lee suggested I test:

I only was able to install Links (fortunately with a homebrew install).

https://links.twibright.com/ External Link • links.twibright.com

Huge Website Navigation Overhaul

Check it out!

https://l5lua.org/ External Link • l5lua.org

Right now it is built using Mkdocs

https://www.mkdocs.org/ External Link • mkdocs.org

And the Material theme

https://squidfunk.github.io/mkdocs-material/ External Link • squidfunk.github.io

Which has some weird limitations around customizing navigation. A big point of feedback was the navigation on the left vs. the table of contents on the right was confusing for users in understanding the flow of the webpage. You can pretty easily integrate the table-of-contents into the navigation, but we had some pages that we didn't want that integration. I also enabled a couple of navigation features, which we were worried if it blew up the website size.

  features:
    - navigation.tracking # URL address bar
    - navigation.prune # Render only visible navigation
    - navigation.path # Breadcrumbs for beginning of filename
    - toc.follow # Follow navigation
    - toc.integrate # rendering nav bar to the left

It basically distilled down to some very specific CSS for the pages we did or did not want to display the table-of-contents.

#__nav_5_label + nav.md-nav > 
.md-nav__list > 
.md-nav__item > 
.md-nav.md-nav--secondary {
	display: none;
}

There were also pages that were "orphaned", or after clicking a link within a page you would lose where you were in the navigation. So this required to hide / show the page in the navigation only when it was the active page.

#__nav_4_2_1_label + nav.md-nav 
> ul.md-nav__list 
> .md-nav__item:not(:first-child){
  display: none;
}

#__nav_4_2_1_label + nav.md-nav 
> ul.md-nav__list 
> .md-nav__item.md-nav__item--active{
  display: block;
}

Which looks like this:

Upon clicking "Shape Primitives":

Resource Bandwidth

There were a few issues testing the bandwidth of a site. The first was reading the Inspector wrong.

https://stackoverflow.com/questions/56043151/what-is-the-difference-between-transferred-and-resources-in-chrome-devtools External Link • stackoverflow.com

When looking at the Network tab in Firefox, you can see the actual consumption of a page.

On the bottom there are two numbers: 1.63MB and 803.73 kb. The left is the total size of the page whereas the right is transferred bytes over the network. We are focusing on keeping the transferred bytes number as low as possible. This is a screenshot of the largest page currently on the site.

Okay so first problem was looking at the wrong number.

The second and larger issue was that the navigation features implementation appeared like it blew up the page size.

We had already enabled lazy-loading and weren't sure if it was somehow disabling or if enabling different features in mkdocs was actually way bigger than we thought.

1.15MB transferred was way bigger than the live site at the time; however I also checked out the main branch and tested the size locally.

Which was...the same.

Basically there is no compression that ends up happening on local development, because it will always be the fastest on the machine that is serving the files.

But, if we look at the live site now:

Woohoo! Compression is working and the site is actually small!

So go look at the site and tell me your thoughts via DM or make an issue on Github!