On 13/01/2023 01:57, Eric Wong wrote:
Andrei Rybak <[email protected]> wrote:
I'm a frequent user of accesskeys [1] so I've written a user script [2]
to add them to some links on websites running public-inbox. The user
script is available via Greasy Fork, a website for hosting user scripts:
https://greasyfork.org/en/scripts/458141-accesskeys-for-public-inbox
Cool. I've long intended for the HTML output to be stable
enough something like that.
Please feel welcome post here if there's new developments or
discussion to be had about it.
Fwiw, there's also rel=prev / rel=next for paginated pages;
but I forgot how browsers use them :x
As far as I know, rel attribute has more to do with search engine
optimization.
However, having these attributes does make finding the links with
document.querySelector much easier for my script. I've added navigation
for next/prev pages to the script.
Any feedback, especially ideas for other uses of accesskey on
public-inbox websites would be appreciated.
Do you know if there's commonly-used accesskeys for normal git repo
viewers? (cgit/gitweb/etc...)
None that I know of, and I would guess that it isn't present in any of
them, really. Confluence (wiki from Atlassian) has them, but Bitbucket
(Git hosting from Atlassian) does not. (Side note: both of them also
implement their own custom shortcuts).
The /$INBOX/$OID/s/ endpoint (linked from @@ diff hunk headers)
is being extended to support "normal" git repositories meant for
code (WIP: https://80x24.org/lore/pub/scm/git/git.git/ ) and
I'd like to avoid conflicts.
Conflicts won't be a problem, because there wouldn't be a lot of users
of the user script. I'll just adjust my script, if needed.
P.S. I've looked at source code of public-inbox to try adding support for
accesskeys natively, but my Perl knowledge is very limited, so I
decided against trying to implement it on my own for a patch.
No worries. I will consider it if I find time (some other things
take priority atm).
Do you happen to know what happens if a page defines accesskeys
which conflict with userscripts? I prefer avoiding breakage for
existing userscript users if implemented in public-inbox itself.
When there is a conflict, Firefox, as an example, just shows the user
every link with the same accesskey, as if the user was navigating over
them using TAB key.
I am a bit hesitant to recommend browser extensions in the
documentation/help output itself since Stylish was found to be
spyware in the past. (that goes for downloading and running
anything from the Internet w/o auditing it, first, public-inbox
included)
Yeah, the Stylish debacle wasn't pleasant.
