W3C home > Mailing lists > Public > www-dom@w3.org > July to September 2009

remedy for click event

From: Krzysztof Maczyński <1981km@gmail.com>
Date: Sun, 20 Sep 2009 00:57:44 +0200
Message-ID: <5E29231BAC0748E7A1BAEC859B96492D@kmPC>
To: "Doug Schepers" <schepers@w3.org>, "Travis Leithead" <travil@microsoft.com>
Cc: <www-dom@w3.org>
Dear All,

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.

Best regards,

Krzysztof
HTML WG

[1] http://www.w3.org/TR/xbl/#trusted0
Received on Saturday, 19 September 2009 22:58:37 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:14:03 GMT