[PATCH] konqueror keyboard link navigation

[Lubos Lunak]

On Thursday 02 of December 2004 23:21, Robert Ewald wrote:
> On Thursday 02 December 2004 15:06, Lubos Lunak wrote:
> > On Thursday 02 of December 2004 12:08, Robert Ewald wrote:
> > > After thinking a bit more, the seperate function is not such a good
> > > idea, it should really be merged with accesskeys. It would confuse all
> > > users that want to interact with a form and links via the keyboard.
> > > Also form elements should be accessible, even if no accesskeys are
> > > defined. The collision remains though. We could choose to ignore the
> > > accesskey definition in the webpage altogether. Thats a quick and dirty
> > > sollution to the problem, but I am not sure if it is a good idea.
> >
> >  Accesskeys are created manually, and as such should usually fit better.
> > You probably can't write an algorithm that'd give better assignments than
> > the one implemented in human brain. I think your code should be rather
> > seen as a fallback when accesskeys are missing (either completely, or for
> > some elements). Moreover I think pages with more than 26 links would be
> > cumbersome with it anyway - search as you type for links would be
> > probably better in such cases.
>
> Let me respond to your second point first. I developed this patch
> especially for pages with more than 26 _visible_ links, esp. if the link
> caption is duplicated. On many blogs like slashdot, you have multiple "read
> more" on the same page. You would have to search multiple times with the
> type ahead method. Also images are hard to access. I wanted to change that
> and navigate to a link as quick as possible.
>
> I have investigated access keys a little more. I think it is a pretty
> flawed concept. For example in firefox, you alt+access key. now alt+1
> switches to the first tab as well, so every time you switch the tab you
> also call the access key on the current page, leading to strange effects.
> Since all browsers define their own set of hotkeys, the web author can only
> choose from a very small set of possible access keys. The access key
> approach taken by konqureror is much better, having it visible.

 I think it is a pretty flawed concept to consider something is a flawed 
concept just because the implementation is wrong. That's simply a Firefox 
bug, and that's all.

> So since type ahead is sometimes cumbersome

 I guess it's mostly because of #87372 . With it you could simply scroll to 
the "read more" you want and it'd be the first hit for searching. Mozilla 
does it that way.

> and my approach collides with 
> accesskeys, but otherwise provides the same functionality, I would suggest
> to treat access keys in the webpage at most as hints if not abandon this
> concept altogether. If we would abandon it, only minor changes to the patch
> are needed. If we would treat the accesskeys as hint integration is much
> more difficult, so I'd like to avoid that.

 Well, if you manage to create code which is at least as good in assigning 
keys to elements as people handwritting accesskeys are, then indeed 
accesskeys won't be very useful. But I doubt you could do that (note that I 
said elements, not links - accesskeys work also for checkboxes etc.), and 
therefore I think your code should be an addition to accesskeys and not the 
other way around. Manually selected shortcuts should always be better than 
guessed shortcuts, and they're also stable. However having at least guessed 
shortcuts is definitely a welcome addition.

 And I also think that these two things should not be separated - what would 
be the difference from the user's point of view? Also from the technical 
point of view it'd be IMHO simpler that way.

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l.lunak at suse.cz , l.lunak at kde.org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/