Re: remedy for click event

Hi, Krzysztof-

For reasons I've already stated, I respectfully disagree with your 
interpretation of "deprecated", and I don't intend to apply it in the 
case of DOM3 Events.  While I am writing the spec for both authors and 
implementers, the implications of deprecation most directly impact 
implementers.  I already use the term "deprecated" in what I see as a 
specific and pragmatic approach throughout the spec, and unless I hear 
from implementers that they disagree with that use, I'm not going to 
change it.

I don't really understand the specific problems that 'click' presents 
for you in the pragmatic case.  If you show me examples where it causes 
scripting or usability problems, that might help.

As editor (but not sole author) of the DOM3 Events spec, here's my 
suggestion to resolve issues in general:

1) Concisely describe the specific problems you see
2) Make a concrete suggestion on fixing those problems (preferably with 
spec prose I can use)
3) Convince the implementers that this is worth the investment in time.

I'm very open to adopting wording that improves the spec.  Please be 
very specific and very concrete.  Don't worry if it's not perfect... if 
the idea has merit, we can refine it through discussion.

As a caveat: right now, I'm not prepared to develop features based on 
general use cases (unless it's something I particularly want).  If you 
want that done, you have to do the legwork.  It might not make it into 
DOM3 Events, but we can always consider it for DOM4 Events.

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


Krzysztof Maczyński wrote (on 9/19/09 6:57 PM):
Doug Schepers wrote:
>> I am not convinced that this is a compelling enough use case to account
>> for... the 'click' event is a pretty crazy and krufty legacy feature,
>> but it's just not going to go away.  I have no intentions to deprecate
>> it (in any sense of the word), and I suspect the implementers would
> find
>> it laughable if I did anyway.
> As I argued, it being dispatched both at non-activating click and activating
> non-click makes it broken almost beyond repair. Deprecation (which, as
> Wikipedia says, may indicate a plan for removal in the future, but in this
> case it obviously wouldn't) and providing a brand new replacement (whatever
> the name) would be a reasonable and preferable course of action to me.
> But I anticipated some opposition (more or less in the form of browser
> developers considering it laughable), so I added a repair attempt as an
> alternative.
>
>> I find it hard to believe that the editor of HTML5 was being politically
>> correct. :)
> ;-)
> In WHATWG politics, not in general.
>
>>>>The Wikipedia article
>>>> says "Although deprecated features remain in the current version
> (…) deprecation
>>>> may indicate that the feature will be removed in the future. Features
> are
>>>> deprecated—rather than being removed—in order to provide backward
> compatibility",
>>>> so, as I understand it, it's exactly like I wrote - MUST implement,
> SHOULD
>>>> NOT use.
>>> I interpret it like this:
>> "Although deprecated features remain in the current version *of the
>> specification* (...) deprecation may indicate that the feature will
> be
>> removed in the future *versions of the specification*."
> The only thing on which I see we might disagree here is the "*of the specification*"
> part. What seems to be meant is that they remain in the specification as
> MUST, so support for them in implementations also remains (or is added,
> or included in case of a new implementation).
>
> Also wrote Travis Leithead:
>> You raise an interesting security consideration though not a new one.
> Script-dispatchable events have been the means of working around pop-up
> blockers and the likes for some time. It might be worth exploring how to
> guarantee that clicks are from "genuine" sources
I thought about this point as well, but it's only tangentially related
> (probably such a flag would be orthogonal (perhaps combined into an enumerated
> property, as just these make for 3 possibilities, not 4) to what I propose
> as a remedy for click's implemented oddities) and I didn't want to write
> about too much stuff at once. But since we're at that, also [1] has something
> similar.
>
>> By this argument, we'd also need a keydown2, keyup2, ..., etc. Why
> should a pointing device be considered more important than a keyboard?
> (Or any other input device?)
> Nope. Only click can be fake in this way, dispatched from DOMActivate's
> default action.

Received on Sunday, 20 September 2009 00:07:20 UTC