Hi'all, I'm currently adding keyboard navigation to Dillo. A quick search on the web produces loads of opinions on which keys to use for what purpose, how to navigate using the keyboard, etc. The w3c has produced some guidelines for 'accessibility' (http://www.w3.org/WAI/UA/sect508-UAAG.html#keyboard) which I will take into account for this feature, and the Mozilla project has done quite a bit of brainstorming on the subject. This is a request for some comments from current Dillo users/developers on what you would like Dillo to be like in this respect. My plan is to implement basic keyboard navigation for links and other content which can be activated (input fields, checkboxes, buttons, etc). For this I already have a working implementation. I will probably add accesskey support as well. Currently I use the cursor keys plus a modifier (now CTRL, will probably switch to ALT/META) to navigate to the nearest link (up/down/left/right), while the TAB key navigates sequentially through all 'activatable' content. Shift-TAB should do the same in reverse, but this is currently not working as it should. Enter activates the current link (embedded GTK+ widgets have their own conventions for this, eg. radiobuttons can *also* be selected using the spacebar, etc...). The find feature will be able to set the current focused link (not implemented yet). If you have any suggestions on this subject, send them to the list. Should this feature be optional? On devices without a keyboard (many PDA's) keyboard navigation does not help much after all... On the other hand, the generalised 'focus' mechanism I've added to the viewport can be used for other purposes as well. Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank@unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]
* Frank de Lange <frank@unternet.org> [10-07-03 08:45]: [snip ...]
Should this feature be optional? On devices without a keyboard (many PDA's) keyboard navigation does not help much after all... On the other hand, the generalised 'focus' mechanism I've added to the viewport can be used for other purposes as well.
Possibly selectable via .dillorc. -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org
Patrick Shanahan wrote:
* Frank de Lange <frank@unternet.org> [10-07-03 08:45]: [snip ...]
Should this feature be optional? On devices without a keyboard (many PDA's) keyboard navigation does not help much after all... On the other hand, the generalised 'focus' mechanism I've added to the viewport can be used for other purposes as well.
Possibly selectable via .dillorc.
Possible... But that would not lead to any space savings, which are important for exactly those devices which do not benefit from keyboard navigation... Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank@unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]
At 09:09 AM 10/7/2003, Patrick Shanahan wrote:
* Frank de Lange <frank@unternet.org> [10-07-03 08:45]: [snip ...]
Should this feature be optional? On devices without a keyboard (many PDA's) keyboard navigation does not help much after all... On the other hand, the generalised 'focus' mechanism I've added to the viewport can be used for other purposes as well.
Possibly selectable via .dillorc.
Of course if there's no keyboard, the keyboard navigation shouldn't cause any problems even when enabled. Like being able to display GIF on a site that only uses PNG. I don't see a reason to make it optional. The only keyboard functionality that's caused me frequent headaches in any other browser is type-ahead find, and that only when focus isn't where I think it is. Maybe the actual keybindings, or a choice of navigation styles (cursor keys vs. vi-keys, for instance) should be configurable, but I don't see a reason to make the feature itself optional unless it adds a lot of unused code to space-starved PDAs. Kelson Vibber www.hyperborea.org
* Kelson Vibber <kelson@pobox.com> [10-07-03 15:30]:
At 09:09 AM 10/7/2003, Patrick Shanahan wrote:
* Frank de Lange <frank@unternet.org> [10-07-03 08:45]: [snip ...]
Should this feature be optional? On devices without a keyboard (many PDA's) keyboard navigation does not help much after all... On the other hand, the generalised 'focus' mechanism I've added to the viewport can be used for other purposes as well.
Possibly selectable via .dillorc. [more snip ...] Maybe the actual keybindings, or a choice of navigation styles (cursor keys vs. vi-keys, for instance) should be configurable, but I don't see a reason to make the feature itself optional unless it adds a lot of unused code to space-starved PDAs.
I agree with this. I will be very happy with the added functionality. -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org
Frank de Lange wrote:
I'm currently adding keyboard navigation to Dillo.
Fantastic! Keyboard navigation is the main reason why I still do most of my browsing in lynx, so if it becomes available in dillo, I'd probably use it a lot more, and get involved in the development. I did have a look at how I might go about implementing it, about a week ago, but I got put off when I realised that it would require considerably more than a 10-line hack, just to indicate which link was currently `selected'. The more I have to change, the more I fear I can mess it up.
If you have any suggestions on this subject, send them to the list.
Well, here's some rambling thoughts: I'm very fond of lynx's "vi-keys" setting, and find that hjkl (with b and space for pageup/down) make for much faster navigation than cursor keys and PgUp/PgDown keys, especially as those may be missing, or poorly placed, on anything other than a full-size keyboard. However, the precise choice of keys should be easily configurable, and setting the defaults to be like any one text editor would be asking for trouble... Comparison with lynx also brings up the issue of whether to navigate in one or two dimensions. That is, either to go through all links in order (which will take a lot more key presses, especially in tables), or to be able to move left and right as well as up and down - this is far more intuitive, but requires another two keys, which could easily have been used for "Follow Link" and "Back" under the first method. Glyn
participants (4)
-
Frank de Lange -
Glyn Kennington -
Kelson Vibber -
Patrick Shanahan