Re: DOM3 Events last call comment

Hi, Garrett-

Garrett Smith wrote (on 10/21/10 6:09 PM):
>
> The comments there show that DOMActivate is not interoperable.
>
> But they don't show why it failed. Is it worth taking a look at that,
> as a failed feature postmortem? Seems DOMActivate had merits but with
> no way to feature test it, poor interop, and an alternative "click",
> it was dead in the water.

I think that's a good idea.  I agree with your points, and I'll add a few:
* there were no other abstract events at the same level, making 
DOMActivate an ugly duckling
* there wasn't a clear way to test and fall back (as you mention), or to 
reliably cancel "competing" related events
* mobile Web wasn't really here yet, and Web developers were focused 
only on the traditional desktop WIMP
* webapps were not yet as common or sophisticated, and 'click' seemed 
good enough, especially as it was adapted to cover the activation case
* the timing was bad for implementations... Netscape had pretty much 
closed up shop, and IE was not really following standards before it too 
stopped development


> New features should be feature testable and events should be, too.

Yes.

> About Steve Pemberton's other point:
>
> "Another problem is that if true hardware events, like click, get
> mixed up with the abstract events like DOMActivate, then it will be
> harder to differentiate between hardware events when you need them,
> and abstract events when you don't."
>
> If the program cares about activation then it should listen for
> "click". But for touchscreen hardware, does a "touch" cause a "click"
> event to fire in all browsers?

This is where the abstracted layer on top of the new TouchEvents 
interface will come in, which is why I think your postmortem idea is useful.

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Received on Thursday, 21 October 2010 22:53:52 UTC