Clearer thoughts on accesskey handling (long)
3 views
Skip to first unread message
Derek Peschel
Oct 30, 2009, 1:22:43 AM10/30/09
to TiddlyWikiDev
Greetings to everyone.
At FND's suggestion, this is a followup to recent threads:
Accesskeys for per-tiddler buttons?
http://groups.google.com/group/tiddlywikidev/browse_thread/thread/4cde060751595fc3
Patch to allow "close all" toolbar button
http://groups.google.com/group/tiddlywikidev/browse_thread/thread/48983fc48549b81b
Patch to add accessKey for "close all" sidebar button
http://groups.google.com/group/tiddlywikidev/browse_thread/thread/8859ce042ee603b3
on the subject of how TiddlyWiki handles keys and how to improve TW.
There are some patches in those threads, and one of the patches is
attached to ticket #452 in Trac.
Also see http://tiddlywiki.org/wiki/Dev:Accesskeys_vs._events
A few people have been working on the problem, all with different
goals. Until they get hammered by peer review, my goals are:
- Extend TW's letter-key shortcuts to work reliably on sidebar
macros (always) and toolbar commands (for a tiddler, when that
tiddler has the focus). Shortcuts may set focus or click buttons
or follow links. Nothing else is needed right now.
- Ideally, run as a plugin, but will that make _other_ _typical_
plugins work automatically with my code?
- Run in phases:
1. The core code defines the shortcuts it wants.
2. Plugins load and define the shortcuts they want.
3. User preferences load and make changes to the definitions.
Somewhere above here, my code loads.
4. Conflicts are detected. (Two different commands/macros want
to use the same key. Thinking about this feature, it's not as
easy as it seemed at first.)
Now HTML rendering begins.
5. Conflicts are displayed.
6. As sidebar elements are created, shortcuts are assigned to
them in a predictable documented way. Multiple copies of the
same macro in the sidebar are handled. Sidebar elements may
be hidden. I'm not sure if they can be destroyed.
7. As toolbars are created and get focus, shortcuts are assigned
to buttons in a predictable documented way. Sidebar macros in
toolbars are handled. Multiple copies of the same command in
toolbars are handled. As toolbars lose focus or are destroyed,
shortcuts are removed.
My goals are NOT:
- Work with every plugin that has been written or could be written.
- Support multikey sequences or non-ASCII key events. The
implementation of letter shortcuts using HTML's "accesskey"
property works for me now and will handle the number of keys
I want.
- Support changing definitions without a restart.
The questions of compatibility with old core code, compatibility with
current plugins, and demands on future plugins are too difficult to
deal with yet.
With all the macros I've looked at, all instances behave the same way,
so it doesn't matter which one gets a shortcut. And with all the
commands I've looked at, all instances behave the same way except for
which tiddler they act on, so it doesn't matter which instance in a
particular toolbar gets a shortcut. The point is to be predictable.
Rather than macro vs. command, the user probably cares about sidebar
vs. toolbar, or taking-a-tiddler vs. not.
If the data supported it, it would be possible for a macro/command to
ask for two keys. It _might_ also be possible for a given key to do
different things at different times. The point is to predictably map
keys _to_ macros or commands or nothing, when the code currently sees
macros/commands as _having_ keys.
Considering the boring life of a sidebar element, it might be easier
to create a good design by looking at those first. The current code
that assigns the key "F" to find fields is broken in two ways.
It assigns a key twice if the sidebar contains two find fields.
It also assigns a key if you open the SidebarOptions shadow tiddler.
As one solution, if each macro knew how many instances existed,
it would know whether to assign a key to the next-created instance.
For detecting conflicts, a JavaScript map from keys to commands/macros
is necessary.
One question is whether to detect conflicts in the shortcut data that
code sets, or conflicts caused by parsing templates? A plugin may ask
for shortcuts for toolbar buttons, but a user may choose not to
display those buttons. Parsing the templates ahead of time, to figure
out what they will do later, sounds more like an undecidable problem
the more I think about it.
For handling multiple copies of a macro/command, a hash can record
which macros/commands have been handled. The sidebar needs one of
those hashes and the current toolbar needs another.
My code doesn't try to solve the sidebar problem at all. It isn't
nearly robust enough at solving the toolbar problem. It does,
however, try to search the toolbar of a tiddler as the tiddler gets
focus and to assign accesskeys, and removes accesskeys when the
tiddler loses focus. "Try" because I don't have a clear idea of what
should be searched, either in terms of HTML child nodes or JavaScript
command and macro objects. The view and edit templates are good
places to start looking, though.
My code reacts to mouse-over and mouse-out events, but I've already
seen it not work as I expect. Reacting to focus and blur events might
solve that problem. As long as the main contents of tiddlers aren't
searched, opening toolbar contents as tiddlers isn't a problem.
There's a lot I don't know yet about TW's code and existing plugins.
Comments are welcome.
-- Derek
At FND's suggestion, this is a followup to recent threads:
Accesskeys for per-tiddler buttons?
http://groups.google.com/group/tiddlywikidev/browse_thread/thread/4cde060751595fc3
Patch to allow "close all" toolbar button
http://groups.google.com/group/tiddlywikidev/browse_thread/thread/48983fc48549b81b
Patch to add accessKey for "close all" sidebar button
http://groups.google.com/group/tiddlywikidev/browse_thread/thread/8859ce042ee603b3
on the subject of how TiddlyWiki handles keys and how to improve TW.
There are some patches in those threads, and one of the patches is
attached to ticket #452 in Trac.
Also see http://tiddlywiki.org/wiki/Dev:Accesskeys_vs._events
A few people have been working on the problem, all with different
goals. Until they get hammered by peer review, my goals are:
- Extend TW's letter-key shortcuts to work reliably on sidebar
macros (always) and toolbar commands (for a tiddler, when that
tiddler has the focus). Shortcuts may set focus or click buttons
or follow links. Nothing else is needed right now.
- Ideally, run as a plugin, but will that make _other_ _typical_
plugins work automatically with my code?
- Run in phases:
1. The core code defines the shortcuts it wants.
2. Plugins load and define the shortcuts they want.
3. User preferences load and make changes to the definitions.
Somewhere above here, my code loads.
4. Conflicts are detected. (Two different commands/macros want
to use the same key. Thinking about this feature, it's not as
easy as it seemed at first.)
Now HTML rendering begins.
5. Conflicts are displayed.
6. As sidebar elements are created, shortcuts are assigned to
them in a predictable documented way. Multiple copies of the
same macro in the sidebar are handled. Sidebar elements may
be hidden. I'm not sure if they can be destroyed.
7. As toolbars are created and get focus, shortcuts are assigned
to buttons in a predictable documented way. Sidebar macros in
toolbars are handled. Multiple copies of the same command in
toolbars are handled. As toolbars lose focus or are destroyed,
shortcuts are removed.
My goals are NOT:
- Work with every plugin that has been written or could be written.
- Support multikey sequences or non-ASCII key events. The
implementation of letter shortcuts using HTML's "accesskey"
property works for me now and will handle the number of keys
I want.
- Support changing definitions without a restart.
The questions of compatibility with old core code, compatibility with
current plugins, and demands on future plugins are too difficult to
deal with yet.
With all the macros I've looked at, all instances behave the same way,
so it doesn't matter which one gets a shortcut. And with all the
commands I've looked at, all instances behave the same way except for
which tiddler they act on, so it doesn't matter which instance in a
particular toolbar gets a shortcut. The point is to be predictable.
Rather than macro vs. command, the user probably cares about sidebar
vs. toolbar, or taking-a-tiddler vs. not.
If the data supported it, it would be possible for a macro/command to
ask for two keys. It _might_ also be possible for a given key to do
different things at different times. The point is to predictably map
keys _to_ macros or commands or nothing, when the code currently sees
macros/commands as _having_ keys.
Considering the boring life of a sidebar element, it might be easier
to create a good design by looking at those first. The current code
that assigns the key "F" to find fields is broken in two ways.
It assigns a key twice if the sidebar contains two find fields.
It also assigns a key if you open the SidebarOptions shadow tiddler.
As one solution, if each macro knew how many instances existed,
it would know whether to assign a key to the next-created instance.
For detecting conflicts, a JavaScript map from keys to commands/macros
is necessary.
One question is whether to detect conflicts in the shortcut data that
code sets, or conflicts caused by parsing templates? A plugin may ask
for shortcuts for toolbar buttons, but a user may choose not to
display those buttons. Parsing the templates ahead of time, to figure
out what they will do later, sounds more like an undecidable problem
the more I think about it.
For handling multiple copies of a macro/command, a hash can record
which macros/commands have been handled. The sidebar needs one of
those hashes and the current toolbar needs another.
My code doesn't try to solve the sidebar problem at all. It isn't
nearly robust enough at solving the toolbar problem. It does,
however, try to search the toolbar of a tiddler as the tiddler gets
focus and to assign accesskeys, and removes accesskeys when the
tiddler loses focus. "Try" because I don't have a clear idea of what
should be searched, either in terms of HTML child nodes or JavaScript
command and macro objects. The view and edit templates are good
places to start looking, though.
My code reacts to mouse-over and mouse-out events, but I've already
seen it not work as I expect. Reacting to focus and blur events might
solve that problem. As long as the main contents of tiddlers aren't
searched, opening toolbar contents as tiddlers isn't a problem.
There's a lot I don't know yet about TW's code and existing plugins.
Comments are welcome.
-- Derek
Eric Shulman
Oct 30, 2009, 2:33:05 AM10/30/09
to TiddlyWikiDev
It's important to avoid making assumptions about the expected layout
and usage of macros and commands. TiddlyWiki documents can be
extensively customized, so there is no single keystroke use-model for
macros and toolbar commands.
For example, frequently used commands are often embedded in several
places within the document's PageTemplate content to provide context-
specific access to selected features. In addition, custom
ViewTemplate and/or EditTemplate definitions can include multiple
toolbar elements, each containing different toolbar items.
Conversely, there is no *requirement* for TW templates to even define
'sidebar' or 'toolbar' elements at all, so the assumption that
specific macros or commands are present in the document is not a
reliable one.
Regardless of any custom layout concerns, an even more fundamental
problem exists: access key handling is inconsistently-implemented on
different browsers. For example, if an access key is defined on an
element that is currently hidden (i.e., element.style.display='none'),
FireFox will not trigger the associated event handler, but IE will
(though it may also throw an error if the access key attempts to move
focus to the hidden element).
Instead of using browser-based access keys, I suggest you take a look
at this plugin:
http://tiddlyspot.com/BradleyMeck/#CaptureKeysMacro
which provides an API for easily binding keystrokes (with optional
ctrl/alt/shift modifiers) to any desired JS function.
With this plugin, you may be able define all your desired access key
assignments simply by creating a custom CaptureKeysMacroConfig with
the appropriate calls to the CaptureKeysMacro API. See Bradley's site
for an example of such a config tiddler... (note: ignore the 'expired
graphics' on his site)
enjoy,
-e
and usage of macros and commands. TiddlyWiki documents can be
extensively customized, so there is no single keystroke use-model for
macros and toolbar commands.
For example, frequently used commands are often embedded in several
places within the document's PageTemplate content to provide context-
specific access to selected features. In addition, custom
ViewTemplate and/or EditTemplate definitions can include multiple
toolbar elements, each containing different toolbar items.
Conversely, there is no *requirement* for TW templates to even define
'sidebar' or 'toolbar' elements at all, so the assumption that
specific macros or commands are present in the document is not a
reliable one.
Regardless of any custom layout concerns, an even more fundamental
problem exists: access key handling is inconsistently-implemented on
different browsers. For example, if an access key is defined on an
element that is currently hidden (i.e., element.style.display='none'),
FireFox will not trigger the associated event handler, but IE will
(though it may also throw an error if the access key attempts to move
focus to the hidden element).
Instead of using browser-based access keys, I suggest you take a look
at this plugin:
http://tiddlyspot.com/BradleyMeck/#CaptureKeysMacro
which provides an API for easily binding keystrokes (with optional
ctrl/alt/shift modifiers) to any desired JS function.
With this plugin, you may be able define all your desired access key
assignments simply by creating a custom CaptureKeysMacroConfig with
the appropriate calls to the CaptureKeysMacro API. See Bradley's site
for an example of such a config tiddler... (note: ignore the 'expired
graphics' on his site)
enjoy,
-e
Derek Peschel
Oct 30, 2009, 8:04:27 PM10/30/09
to TiddlyWikiDev, dpes...@eskimo.com
On Oct 29, 11:33 pm, Eric Shulman <elsdes...@gmail.com> wrote:
> It's important to avoid making assumptions about the expected layout
> and usage of macros and commands.
You're right. That thought has been bothering me all along. Can you
> It's important to avoid making assumptions about the expected layout
> and usage of macros and commands.
give more concrete examples of the layouts you mentioned, which I cut?
Your point about context sensitivity is especially interesting because
context sensitivity invalidates some of my assumptions.
Also, I mentioned a list of things accesskeys can do: follow links,
push buttons, and set focus. Do your example layouts require that
shortcuts do things accesskeys can't? In other words, does the
difficulty lie with associating accesskeys with the right HTML, or the
abilities of accesskeys once associated?
I can imagine useful things to do, which is not the same as a
requirement. For example, it might be nice to move the mouse over a
link to a tiddler, and use a keyboard or mouse command to act on the
target, such as "close" or "open in edit mode". TiddlyWiki remains
usable even without those features, though.
> Regardless of any custom layout concerns, an even more fundamental
> problem exists: access key handling is inconsistently-implemented on
> different browsers.
solution is impossible, or difficult, or something else?
-- Derek
Reply all
Reply to author
Forward
0 new messages