Re: DOM3 Events last call comment

On 10/20/10, T.V Raman <> wrote:
[opinions on ISSUE-170]

(see also:

> DOMActivate  is interaction agnostic

Where does "click" fails to notify the program of a UI activation-type event?

Do activation events belongs in D3E or should they be defined by a
separate specification?

Activation events aren't interoperable. They can't easily be feature
tested to know where they're supported. Author's can't make unrelated
execution inferences about them (just assume they works) because the
majority of clients don't support them; the app would never get past
QA testing (because it would not work in IE and other browsers). Pages
don't rely on them leaving browser vendors not much incentive for
implementing them.

Feature testing was reraised in issue #123, though the issue was
discussed previously.

Time and effort spent on spec'ing activation events took away from
issue #1. Now issue #1 is about finishing D3E and it seems that the
scope of the spec is too large to just get the entire thing done (the
current spec takes 1-2 trees to print ;-))

And so issues #148, issue #86 are about modularizing D3E, though to be
fair, that came up over a year ago on list via Sergey Ilinsky (that
seemed to have been ignored), was re-raised by Ian Hickson (issue
#86). The spec scope seems to be causing it to take too long. Perhaps
activation events are a good thing and if so, then do they belong in
D3E or a separate document?

If the reason nobody uses activation events is that they can't be
detected, then detecting events should be looked into. That was raised
in issue #123, and also mentioned in Doug's "Can Dispatch
canDispatch()?" thread. To me, that seems to belong more in D3E
because it is very generalized concept of "detect if object has a
predefined 'slot' for such event type being dispatched.


Received on Thursday, 21 October 2010 01:14:14 UTC