On Friday 23 January 2004 17:04, Lubos Lunak wrote:

>  If I understood it the way that all attributes should be explicitly
> handled, otherwise the unsupported attribute case in
> HTMLElementImpl::parseAttribute() will be hit.

Thats not a problem, its just a debug statement. 

>  So in other words, KHTMLView::focusNextPrevNode() has this broken as well.

Yes. 

>  Is it documented somewhere how this should work? The best docs I could
> find only explained what the event is, but not when it's generated and so
> on. I e.g. noticed that if I do <form ...><input type="submit"
> onclick="alert('kuk')" accesskey=s></form> , clicking or pressing Space on
> the button shows the alert, by my implementation of accesskey doesn't
> trigger it (it's triggered in Mozilla).

Well, normally when you click on an element, and it receives the event during 
the capturing phase, it will decide if it can handle the event. that means, 
the element can handle it, is not disabled or anything that would prevent 
event handling. 

When the click activates the element, a domactivate event is emitted. event 
listeners can react to that event, and can even block it. if the element 
receives its domactivate event, it does its default action (in case of a 
link, go to the url). 

so its a slight mistake for an anchor to react on a click event. instead it 
should produce a activation event, and then react on that one. Feel free to 
fix. 

See the form handling stuff for inspiration.