W3C home > Mailing lists > Public > public-webapi@w3.org > May 2008

Event handler attributes (Was: Dependencies in XHR)

From: Ian Hickson <ian@hixie.ch>
Date: Wed, 28 May 2008 06:56:31 +0000 (UTC)
To: Doug Schepers <schepers@w3.org>
Cc: Web API public <public-webapi@w3.org>
Message-ID: <Pine.LNX.4.62.0805280648280.12907@hixie.dreamhostps.com>

On Tue, 27 May 2008, Doug Schepers wrote:
> > > 
> > > We have discussed adding consideration for "event handler DOM 
> > > attribute" in the DOM3 Events spec, such that a host language can 
> > > define what that means in its context
> > 
> > That would be great, I'd love to offload this part of HTML5. Do you 
> > have a plan for how to resolve the dependency between event handler 
> > DOM attribute processing and the designMode DOM attribute? Also, 
> > please remember to deal with the mouseover event's quirk when doing 
> > this.
> (This seems like a sarcastic and combative reply, for no good reason.)

Sorry, that was not the intent.

> Perhaps I misunderstood the issue.  My impression was that Anne was 
> referring to the definition for the "onfoo" event handlers, as stated in 
> the HTML 5.0 spec:
> "Event handler DOM attributes, on setting, must set the corresponding 
> event handler attribute to their new value, and on getting, must return 
> whatever the current value of the corresponding event handler attribute 
> is (possibly null)."

Right, that is indeed what I'm talking about (that and the event handler 
content attributes).

I really would like this to be taken out of HTML5 and turned into a 
generic mechanism. 

> A host language, such as HTML or SVG, would define the specific event 
> handler attributes appropriate to that language, and provide details 
> about the event.  The host language would also cover the particulars of 
> the quirks you mention (so, sorry, but you're stuck with that task).

designMode's quirks aren't HTML-specific, they apply equally to SVG event 
handlers. I expect (but haven't tested) that the same applies to 
onmouseover's quirks. I certainly would rather all the behaviour was 
defined in one place than requiring implementors to have to 
cross-reference multiple specs to get this done right.

(In particular, I think we really need to get over the concept of "but 
that's a host language issue" or "that doesn't belong in my spec" and so 
on -- we're defining a single platform here, it isn't useful for us to be 
declining responsibility over the more complicated parts. While the theory 
of orthogonal technologies would have been nice, the Web is at a point 
where all the technologies are embedded in each other to some extent, and 
we should embrace that, not try to deny it. We will have a healthier 
technology stack if we consider the HTML and SVG specs, say, to be 
different chapters of the same language spec, rather than if we consider 
them to be separate languages.)

Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 28 May 2008 06:59:46 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:27 UTC