Last modified: 2010-05-15 15:37:55 UTC
I was going to add accesskeys to next and previous links in the history browsing modes, but run problems with akeytt. Looks like it tries to find a element, which child is a a-element. That's ok because almost all those links are in format li > a. If the else-clause was meant to be fallback, which I think it was meant to be, it didn't work. So i rewrote the function so it tries to find a a-element directly or in the first child element. Ask for clarification if you don't understand my poor explanation. Nevertheless i'll add a patch for it.
Created attachment 452 [details] A patch for akeytt
It's a little unclear what problem this patch is solving. :) Can you clarify what breaks with the current code, and how this fixes it?
Well... The original basically changed <xxx id="b"><a> construct to <xxx id="b"><a title="xy" acceskey="x">. The problem was that it didn't work if the id was put directly to anchor element, like <a id="c">. In other words you have to encapsulate the link with another element with id in it. My version first checks if the given tag is an anchor element (<a id="c">) and if it isn't, it falls back to the original behaviour. In other words it tries to assign accesskey parameter to anchor element, not only to the first child of element which has the id we searched for. I think this is also how the original version was meant to behave. This problem came up as i was adding accesskeys to next/previous diff links which were not encapsulated by another element. Original: <xxx id="b"><a> to <xxx id="b"><a title="xy" acceskey="x"> New: <xxx id="b"><a> to <xxx id="b"><a title="xy" acceskey="x"> or <a id="c"> to <a id="c" title="xy" acceskey="x">
I've committed this to HEAD, no problems reported so far.
