Re: Accesskeys for keyboard navigation

[Andrei Rybak <rybak.a.v@gmail.com>]

On 13/01/2023 01:57, Eric Wong wrote:
> Andrei Rybak <rybak.a.v@gmail.com> 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.