Re: Marked addEventListenerNS and removeEventListenerNS At Risk

Hi, Krzysztof-

Krzysztof Maczyński wrote (on 9/19/09 6:27 PM):
>> 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.

It's an indirect connection.  The larger the number of names needing 
correlation, the more risk that one of the names will conflict with 
another use.


> I don't care about init* (both with NS and without) if there's a good alternative.
> Deprecate (preferably) or even obsolete.

The choices for DOM3 Events are deprecate or remove.


> <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?

None that I'm aware of.  As with any organization, different people 
within W3C have different opinions and preferences regarding namespaces 
(and pretty much everything else).  Some Team members hate them, some 
can't do without them... I'm in favor of using them where they make 
pragmatic sense.  Liam Quinn has a proposal for "unobtrusive namespaces" 
that he might bring forward.

As a whole, the W3C Team does strongly favor distributed extensibility 
and fallback capability, but it's not clear that Namespaces in XML is 
always the best way to accomplish that.  As I said, the case for markup 
is clearer than for events.


>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".

I'd prefer not to speak in general terms here, but rather to discuss the 
relative merits of event namespaces.  Not to sound like a broken record, 
but if you can produce more solid use cases where event namespaces are 
critical (not just "avoid clashes"), and/or point to content that 
requires them, that will help the case much more.

Right now, browsers don't want to implement them; the burden of proof is 
now on the event-namespace advocates to demonstrate rationales that 
override that sentiment, unfortunately.  What complex things are made 
possible by event namespaces, specifically?

I have seen clashes in markup names, but I've never seen clashes in 
event names (which wasn't resolved by simple prefixing).  Sometimes I've 
seen unfortunate names as a result, but I can deal with that.


> 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.

Here's the "worse", then: if I keep event namespaces (in their current 
form) in the spec, I sincerely doubt that browsers will implement them, 
undermining the strength of the argument that the non-deprecated parts 
of the spec must be implemented interoperably in all browsers.  Authors 
will be faced with a spec that does not reflect the reality of the 
functionality they can depend on, making it a poor resource.

Looking at it from the author perspective, it's a matter of resources: 
browsers can spend a some number of hours implementing the namespace 
support (which has questionable practical use), or that same amount of 
time implementing the new wheel event, or key identifiers, or 
composition events, or any number of features in DOM3 Events that *I 
really, really want to be able to use*, and which solve very real 
problems authors are facing today.

If I had my druthers, we'd keep them.  I agree with the principles of 
the general use case.  But other things are worth more to me.

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

Received on Saturday, 19 September 2009 23:44:02 UTC