Widget.connect onclick should register some key based triggers.

[davidb]

onclick fires for most elements via mouse, but for many of them it can not be triggered via keyboard.

We should have Widget.connect provide key based triggers as/when necessary. Most likely the best keys to use are the space-key and possibly the enter-key. Probably safest to trigger on keyup.

(filed as per dojo-meeting today)

[davidb]

thinking about something like this...

[davidb]

The danger with this patch is perhaps if the dijit in question already has a keyboard actionable onclick handler. (e.g. has an html button node that captures the click). One way around this is to make sure e._dijitKeyboardGenerated is checked and the event ignored in those cases. This might be hard to diagnose though ... if folks encounter two clicks and don't know why.

Maybe output a warning console.debug message?

[davidb]

or this (a new keyclick event) to add in templates as/when necessary

[davidb]

Update: preparing patch that will affect (slightly): ColorPalette?, TitlePane?, Widget, Button, ComboBox?, InlineEditBox?, popup .js files.

Will need to test before posting/commiting.

(Note, in some places code could be quite simplified if enter also fires click... not sure about enter though).

[bill]

I thought you would check the type of the DOM node and add the special keyboard handler only if necessary.

Also, this.disconnect needs to be able to undo whatever this.connect did, so this needs some more work. Probably easier with a new name for the synthetic event like in your second patch. (I'd like to think of a better name than onkeyclick but nothing comes to mind. "activate" seems wrong as "active" typically refers to a button while it's being pressed.)

[davidb]

OK. I'll proceed with the second patch. Perhaps naming the event "trigger" or something similar.

[davidb]

update of work so far. (possible solution)

[davidb]

a better fix

[davidb]

Two solutions have been attempted:

In _Widget.connect...

1. Add key listening to fire the onclick handler.

in pseudocode:

if (event == "onclick" && node-needs-kb-click) {
 // auto-add keyboard listener that calls
 // click handler when space key up happens.
}

2. Add new event "onklick".

in pseudocode:

if (event == "onklick" && node-needs-kb-click()) { 
 // auto-add keyboard listener that calls
 // click handler when space key up happens.
}

Conclusion: Avoiding conflict with existing keyboard based "click" triggers is problematic.

1. node-needs-kb-click is impossible to get right in all cases, since clicks can bubble. It is not just a matter of checking for the current, or for a child node that has kb based click already, but we need to know what the handler does with the event. Does it bubble? What does the author want?

2. onklick has grown on me and I think it offers several advantages:

• clarity. "onklick" should tell an author that this does something different, and we are doing something different. We are adding a side-effect (a very handy one) of space/enter key-up connection to the onklick handler.
• it allows us to preserve onclick as it is currently implemented.
• it still allows us to simplify our templates and handler implementation.
• node-needs-kb-click can be removed or left very simplistic as long as we know in the templates when onklick should be used, and when it shouldn't.
• it is a baby step. changing onclick is disruptive and it is very hard to test how disruptive a change it is.

[davidb]

I think this is a decent baby step towards consistent kb based click.

[davidb]

Bill, I'd like your nod before I commit this dijit core work. (If you can find the time)

[davidb]

(In [9299]) Fixes #3461: added new event type 'onklick'.

[davidb]

(Approval from Bill via email)

[bill]

(In [12159]) slight optimization from cougar; "w" var is not necessary since dojo.connect's third arguments make "this" valid. refs #3461. !strict