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@suse.cz , l.lunak@kde.org Drahobejlova 27 tel: +420 2 9654 2373 190 00 Praha 9 fax: +420 2 9654 2374 Czech Republic http://www.suse.cz/