In the process of implementing a "follow mode" for [lariza].
This is really messy. There is no C API to access the DOM, so this has
to be done in JavaScript. This means that there are two ways to
implement it:
- Everything in JS. This is what the user scripts for [surf] do.
- Call a JS snippet just to grab DOM info and then do the rest in C.
The first option requires less code, but it's a total mess. Web "pages"
grab keys all the time these days and I don't see a way to prevent that.
So, my "follow.js" fights with the "page" over who gets which key
events. Even duckduckgo.com is broken. All "pages" try to be clever
these days ... I write "pages" in quotes, because "web pages" are no
longer passive pages, these days are looooong gone. Virtually all of
them are _applications_ that run code. A disaster.
Plus, a pure JS implementation has to _change_ the DOM in order to
create the hint labels. This means creating new nodes, okay, but also
removing them when you're done. How do you find your nodes? Use some
attribute and hope that nobody else uses the same? Hopefully, I can find
a way to avoid deleting nodes ...
The second option looks like this: You grab all keys in C, so there is
no conflict. Great. You still have to access the DOM to find out which
links there are (and where), so you run a little JS against the
document. And then ... you have to draw the hinting labels. This is easy
in JS, but a PITA in GTK.
And of course, the concept of these "follow modes" is fundamentally
broken. It cannot work reliably, ever. Web pages can randomly decide
what they want to do -- you cannot reliably catch all links or
"activateable" elements. You can only hope to catch most of them.
Long story short, a "follow mode" can get really complicated. Maybe it's
best to live with it. It's ugly, it's messy, it doesn't work all the
time, but it's better than nothing. Ugh.
[lariza]:
https://uninformativ.de/git/lariza
[surf]:
http://surf.suckless.org/
