I previously wrote of a fairly straightforward workaround to get "proper" dark theming for Zeal (AUR/zeal), which as far as I know still remains the easiest workaround available. However, as it depends on the invert-color-include functionality of picom, something that is not available for sway/wayland users, I went back to square one and figured out what turned out to be an arguably better, albeit somewhat more complicated, approach.

Officially Supported Dark Theming

As mentioned earlier, Zeal (aur/zeal, or aur/zeal-git for the VCS version) does in fact support dark theming, but it is in fact still garbage, so enough about that - moving on.

Introducing dasht

I recently learned of a CLI dash implementation called dasht (aur/dasht, or aur/dasht-git for the VCS version), which in itself is a reasonable documentation browser, one that works without a graphical interface even. It is generally as simple as dasht <search_term>, producing a TUI with results that then allows you browse the docs.

However, as many docs are originally web pages, browsing them from CLI is arguably less comfortable than it could be.

Adding qutebrowser to the mix

dasht also ships with the dasht-query-html executable that instead produces straight html to your stdout. We can add the following qutebrowser userscript (for instance to ~/.config/qutebrowser/data/userscripts):

#!/bin/bash

dasht-query-html "$@" > /tmp/dasht.html
echo "open file:///tmp/dasht.html" >> "${QUTE_FIFO}"

Now we have access to the dasht search results (that then produce more html) from qutebrowser, we just have to add some handy binding to our qutebrowser config (~/.config/qutebrowser/config.py), for instance:

c.aliases['d'] = 'spawn --userscript dasht'

This in and of itself already works, but personally I consider part of the advantage of using a dedicated documentation browser is that your documentation doesn't get lost somewhere in your tab tree, rather it's always available with a single key press - much like how Zeal works.

Putting it together

The hard way - sway(land)

Unlike X11, sway(land) doesn't support convenient window matching rules like class or instance, just an app_id, which as of now cannot be set for qutebrowser via a flag, so unfortunately some creativity is needed here.

Fortunately, qutebrowser can run both wayland native and under xwayland, which results in its app_id being either org.qutebrowser.qutebrowser or null, respectively. This in turn means that we can, for instance, start our "documentation browser" instance of qutebrowser prepending with the QT_QPA_PLATFORM=wayland environment variable (assuming we normally start it with xcb), and then add something in this vein to our sway config:

exec "QT_QPA_PLATFORM=wayland qutebrowser -B ~/.config/qutebrowser/profile-dasht/"
for_window [app_id="org.qutebrowser.qutebrowser"] move to scratchpad
for_window [app_id="org.qutebrowser.qutebrowser"] floating enable
for_window [app_id="org.qutebrowser.qutebrowser"] resize set 980 1240
bindsym $mod3+k [app_id="org.qutebrowser.qutebrowser"] scratchpad
show

Note: you need start qutebrowser with a separate base directory for it to start in a separate instance, else you will not have two qutebrowsers running under different platform instances and what we're trying to do here will not work.

And voilà! We now have an automatically starting documentation browser instance of qutebrowser that can be summoned and hidden with mod3+k (or any hotkey of your choice) and where we can quickly make searches with :d keyword (or again, an alias of your choice). And most importantly, the theming and navigation will work no worse than in your favorite browser!

Most importantly for me, qutebrowser loads my global dark css properly without flashbanging me with a solid white background and then sloading (sic) the css color inversion on top of it each page load, but the other benefits shouldn't be understated either.