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

Re: Marked addEventListenerNS and removeEventListenerNS At Risk

From: Krzysztof Maczyński <1981km@gmail.com>
Date: Sun, 20 Sep 2009 00:27:00 +0200
Message-ID: <CF3AD6ED14FE4EA18ED89FD7FA0FF9EE@kmPC>
To: "Doug Schepers" <schepers@w3.org>
Cc: <www-dom@w3.org>
Doug,

> Events don't tend to be as tightly coupled 
> with one another (at least on the same scale), and this smaller set of 
> names allows for easier clash-proofing via naming conventions.
I don't understand what tight coupling has to do with the risk of clashing. The more events defined (regardles of the degree of their coupling), the more likely they're to clash.

> That said, if we do introduce a generic event initializer with writable 
> attributes prior to dispatch (as has been discussed), the namespaceURI 
> could simply be another optional attribute, which should be relatively 
> minor for implementers to support (though it would require keeping the 
> NS-aware event listeners), and no burden to authors.
I don't care about init* (both with NS and without) if there's a good alternative. Deprecate (preferably) or even obsolete.
<dreaming-up>
By the way, isn't there likely to be a W3C-internal endorsement at TPAC of some facade upon Names in XML, usable both from XML and HTML? Could APIs get a piece of that cake either? Skimming over requirements and proposals I expect there to be more robust defaults, falling back from one namespace to another (including no namespace) if nothing is found. Those defaults could be specified by the author or by a spec (potentially overridable by author). Some specs could mandate some initial defaults for methods without NS in their names related to events (or larger portions of APIs, though this would preferably be defined more precisely with adequate hooks) for scripts running within a document handled by a user agent in conformance with such spec.
</>
<rant>
I'm a strong believer in hiding complexity, even moderate, in ways not making it impossible or impractical to do more advanced stuff for people who want to. That consistently benefits everybody. If we "make simple things simple" based on the formidable assumption that normal users (in this case of specs, i.e. authors) are dumb and incapable of dealing with things like binding namespaces ([1]) (and if at least one in 10000 isn't, remember that it's those individuals who contribute most towards progress, of technologies and other human achievements), we risk blindfoldedly missing the rest of this adage: "and complex things possible". That motivates me to oppose dumbing down anything already specified in a Rec or Note, unless I can clearly see it's much worse that something else readily available and completed or in progress as a standard.
</>

Best regards,

Krzysztof
HTML WG

[1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=7670
Received on Saturday, 19 September 2009 22:27:55 GMT

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