Search bar for posts

[dag7dev]

It would be nice to have a static search bar that doesn't involve an external service to search for text in our articles.

[tomfran]

Yes I agree, I briefly looked at some libraries but all of them had custom UI which didn't fit. What do you mean by not using external dependencies?

[tomfran]

Implementing some basic search by myself (using basic tokenization and keeping an inverted index loaded in memory) was an option but decided to put that aside for the moment. Maybe you have something in mind that I don't know.

[dag7dev]

Yep, I was exactly thinking about tokenization. By "no external services", I mean avoid using ElasticSearch or services like that.

[dag7dev]

I was thinking about lunr.js, is it feasible for our scopes?

[tomfran]

Oh okay, so an external dependency. I think anything would be okay honestly, given that it provides full text search over pages. The main concern would be about the UI.

Ideally, an implementation that allows to manually display search results would be perfect, this way the UI can be tailored to the theme.

[dag7dev]

Could be interesting to have a separate "search" page?

[tomfran]

Yes we can do that

[tomfran]

I am working on an implementation, the idea is to have a Spotlight-like search interface, entirely keyboard based, in the example here you press CMD + / to bring up the search, then use the arrows to navigate and enter to confirm.

The implementation is based on this: https://gist.github.com/cmod/5410eae147e4318164258742dd05393

Screen.Recording.2025-01-17.at.19.12.28.mov

Ideally, there will be a /search entry in the menu (configurable maybe) to bring up the search even on mobile.

[dag7dev]

That's so nice! Thanks for this!

[OleMussmann]

I like the look of it, but I am not a big fan of the user experience.

• Using keyboard shortcuts collides with certain navigation plugins like https://vimium.github.io/ or https://github.com/tridactyl/tridactyl . I'm not sure if screen readers would be affected, too.
• Websites do not use keyboard shortcuts consistently. This means that I would need to remember the specific way of navigation for each website. This is not going to happen.
• It is not discoverable. If you explain the shortcut in some text somewhere, people might miss it. If you put the explanation in a UI element, you could just as well put a search box there.

I'd rather have the search integrate with the existing UI. Maybe something along those lines:

Screencast.From.2025-01-25.09-59-15.webm

I like the selection interface @tomfran showed, maybe it could attach below the search box?

---

P.S.: Example code for the search box element.

<style>
  input[type="text"]::placeholder {
    color: var(--content-primary);
  }
  input[type="text"]:focus::placeholder {
    color: gray;
  }
</style>

<p class="small">
  <span style="text-decoration: underline;">/</span><input type="text" placeholder="search">
</p>

[tomfran]

• Using keyboard shortcuts collides with certain navigation plugins like https://vimium.github.io/ or https://github.com/tridactyl/tridactyl . I'm not sure if screen readers would be affected, too.

I agree with you, indeed this won't be the only way to access the search bar, a menu entry with search will be there, bringing up the search menu. The keyboard shortcuts will be configurable.

• Websites do not use keyboard shortcuts consistently. This means that I would need to remember the specific way of navigation for each website. This is not going to happen.
• It is not discoverable. If you explain the shortcut in some text somewhere, people might miss it. If you put the explanation in a UI element, you could just as well put a search box there.

I believe you're thinking too much about this, a menu entry will be more than enough for someone to discover the search bar (similar to what you shown, but "clickable"), and a hint about the keyboard shortcut will be placed somewhere yes (but this feature is intended as a nice to have shortcut, rather than the primary way of accessing it)

---

Those points aside, let's say we used your search bar proposal, where would you place results? Were you thinking about a separate page?

[OleMussmann]

Thanks @tomfran , I understand the idea better now. The way the search results are attached below the search bar in your example video looks really nice. I could imagine those being summoned below the (non-overlay) search bar in the same way, or something similar to it.

Examples of what that would look like are medium.com blogs (fixed search bar) github.com repos (expanding search bar) or discourse forums (overlay search bar, sometimes steals CTRL+F).

[runofthemillgeek]

@tomfran are you still looking into this?

I'm keen to get this added. I'm also in line with search being a command palette/modal UX but also having a search icon to toggle that somewhere in the header area.

I was able to get a quick implementation going on using Pagefind and <dialog> which was suggested in https://gohugo.io/tools/search/ but it'd mean the user would have to add a separate build step. But otherwise, it's fairly easy.

https://hugomods.com/search/modal/ also looks interesting and doesn't need the build steps. Not sure how easy it is to customize the looks and how good the search functionality is.