We definitely need to have some kind of convenient UI for seeing dom node attributes
like "title" and "alt" text.  In fact, I have already written rudimentary support for
such, but there are several question of how the UI should work that need to be answered
before this feature can be added to Conkeror.  For the rudimentary version, go to
<http://jjfoerch.com/git/conkerorrc/node-info.js>.

I think that the Emacs "highlight" commands provide a good UI model to base our UI on.
This is because from a certain perspective, the highlight commands are very much like
the show-attribute commands that we want.  They add properties to the document to call
attention to certain things.  The highlight commands call attention to things that are
already visible by adding color.  The show-attribute commands call attention to invisible
things by creating colorful tooltip-like objects.

So for key bindings, modeling on Emacs, it seems very reasonable to use the prefix `C-x w'.

But which specific keys within this keymap should we use, and exactly how should these
commands behave?

Should they show the given attribute for the whole buffer, or just the viewport, or both,
depending on universal-argument?  Which way should be default?

Should the labels persist until explicitly removed, or should Conkeror wait for a keystroke
and auto-kill them?

Should there be one command to add the labels and a separate command to remove them, or just
one command that toggles them?  Perhaps universal-argument would be best used to disable
the labels, while calling that command without universal-argument would enable them.  The
Emacs command `set-goal-column' might be a good model here.  When you call `set-goal-column'
with universal-argument the goal-column is disabled.

The highlight commands use a two-command model.  You have, for example, `C-x w p' bound to
highlight-phrase, and `C-x w r' to unhighlight.  Honestly I have always found this asymmetry
a little annoying, even though it is appropriate given that there are multiple ways to
highlight things.

Finally, what should the command(s) be called?  show-attribute?  reveal-attribute?
attribute-show?  Welcome ladies and gentlemen, it's the Attribute Show, up next we have...

As primary investigator into this feature, I'll outline my own preferred answers to the
questions I posed:

  There would be one command, called, for example `show-attribute'.  When called, it
would prompt for an attribute to show, and generate labels for the entire web page
showing the value of that attribute for all the nodes that had it.  These labels would
persist.

  To remove the labels, you would call `show-attribute' with universal-argument.  It
would prompt you for which set of labels to remove---because perhaps you are displaying
several sets of attribute labels.  This prompt would use $require_match completion
on the attributes currently shown.

  In order to accomadate the display of multiple attribute sets, the labels would need
to be colored, or have their text include an identifier like "alt:", or even both.  If
labels for any given attribute had a unique class name, then CSS would be the cleanest
way to enable configuration.  For example, for colors, the CSS property "background",
and for textual id, the CSS pseudo-selector ":before" could be used.

  It would also be possible to use user-defined functions to retrieve colors and
text-formatting, but these decorations seem more properly the domain of CSS.

  We would want to be a little careful with choosing a binding, so that we don't use up
one that we might want to use later, for example, if we implemented a "highlight" module
patterned after the one that Emacs has.  `C-x w a' seems like a fair choice.  The `a'
would be a mnemonic for "attribute".

After further consideration, I have changed my mind about how the UI should work.  Having a
separate "remove" command will significantly increase the flexibility of the system.

The name for the system can be "annotate".  To create annotations for attribute tags like
alt and title, the command would be "annotate-attribute".  When annotate-attribute is called
without universal-argument, it creates transient annotations: annotations that are automatically
destroyed at the next keypress.  Transient annotations are only generated for the current
viewport, since it wouldn't make sense to generate annotations that could not be seen, if
hitting a scroll key causes their destruction.  However, when annotate-attribute is called
with universal-argument, then persistent annotations are created for the whole buffer.

Persistent annotations have to be removed explicitly with the command "unannotate", bound
on `C-x w r'.  Although for a start, we will only have attribute annotations, it is easy to
imagine that we will have other types of annotations in the future.  The unannotate command
will be able to destroy any of them, because each annotation-set will have a unique name.
For example, an annotation-set of "alt" attributes could be called "attribute:alt".  This
name could be completed on (or typed by the user) in a prompt of the unannotate command.

Any navigation action in the buffer automatically destroys all active annotations.

Latest version of this feature, implemented for a branch of conkeror I'm currently working on, is here:

http://retroj.net/git/conkeror-decoupling/modules/annotate.js

For the “title” attribute, you can see my minimalistic CSS workaround here
<https://github.com/erlehmann/dotfiles/blob/b4f48684005f8a579cc8b7b179eff15e1c3469fc/.conkerorrc#L40>.
Any ideas how to trigger :hover without a mouse?

@erlehmann: you can send a mouseover event