The Web APIs WG is charted to do a new version of DOM Level 3 Events. In doing so we are planning to do some changes on which public feedback would be welcome. One of the changes is to no longer mention DOMFocusIn and DOMFocusOut in favor of general focus and blur events. Probably the most signicant difference between the two is that the former two are bubbling events and the latter are not. You can still capture them of course which covers every use case. One of the reasons for making the two HTML specific events generic is that authors are used to them and that they are widely recognized. Another reason was that having multiple events for focus does not make much sense, especially not when you would only be able to use focus and blur for HTML (or XHTML) and the other two events for the rest.
I'm a stranger to mailinglists so I'm hesitant to send in feedback that way, but I'm missing properties that define the offset relative to the source-element for mouse-events. Most browsers do support offsetX/offsetY (or simular - actually it's a jungle but at least most browsers have something), but I noticed the other day that Opera's SVG-implementation has nothing of such kind...
Excellent! It certainly makes more sense to use the already implemented focus and blur events.
I'd really like to see the keyboard events in Appendix A of that DOM 3 events spec get significantly improved and, most importantly, interoperably implemented. From experience, it's so difficult to reliably capture keboard events for much other than the the alphanumeric keys, and even then it requires different code for different browsers.
Tino, are implementations buggy or the specification? Opera accepts bug reports. ;-)
Lachlan, feel free to point out the current problems to the list. All input is taken into consideration.
Anne, what I meant was that I feel that the specification is lacking on that point. Sure you can get the offset of the mousecursor relative to the source element of the event by using clientX/Y and taking into account the offset from that element itself, but that means iterating through all it's offset parents untill you get to the root element meanwhile adding up all the offsetLeft/Top values. Needless to say that that is quite bothersome (and slow).
Most implementations therefor have their own properties for that; even in (X)HTML Opera provides offsetX/Y but not in their SVG-implementation (where f.i. Firefox does).
So it's not a matter of a bug, but something I feel should be covered in the specification, or at least Opera's SVG implementation should provide the same propriety extensions when it comes to events as in their (X)HTML implementation ;)
Well, it seems likely that we are going to be stuck with the events after all. People squeal every time you break something they were using, no matter how intelligent or otherwise it was, so you get stuck with extra garbage in the browser to implement the same thing in 5 ways.
Tino, Opera's SVG support is in development, and follows the relevant specifications pretty closely. You have to deal with the idea of providing feedback to the people doing the work (the public mailing list) if you want to promote a change, but it isn't impossible. I have seen Microsoft change implemented behaviour before now based on public contributions.
Lachlan, one of the problems with keyboard events is that, for example on a phone, or a stylus-based input device, it is not clear how to decide when to generate which events if they are keyboard based. This is an open issue (issue 33 for the Web API group) and feedback is, as Anne says, very very welcome.