W3C home > Mailing lists > Public > public-audio@w3.org > October to December 2012

[Bug 20502] MIDIEvent should have a port attribute

From: <bugzilla@jessica.w3.org>
Date: Mon, 24 Dec 2012 10:27:05 +0000
To: public-audio@w3.org
Message-ID: <bug-20502-5429-6zcIJH5SIv@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=20502

--- Comment #1 from Marcos Caceres <w3c@marcosc.com> ---
On Monday, 24 December 2012 at 07:42, Jussi Kalliokoski wrote:
>Yes, actually I thought that for events on an EventTarget, both "this" and
>".target" would automatically be the port, but now that I checked, it seems that >only the former is true.

But then you still have two objects that are disjoint ("this" and the MIDIEvent
instance). It would be nicer, IMO, to have them combined (specially because
there can be multiple sources for an event, and a single listener).

There is precedence for knowing the "source" of the event. For instance, Web
Messaging has a "source" attribute.   

There is also GamepadEvent, which has:
readonly attribute Gamepad gamepad; 
http://dvcs.w3.org/hg/gamepad/raw-file/tip/gamepad.html#gamepadevent-interface

> But that being the case, I think we should use 
>".target", rather than introduce a new way of reporting the target.

According to DOM4, the event.target "Returns the object event is dispatched
to." Not the object it was dispatched *from*.

For example, in Web Messaging. If I postMessage some data from document A to
iframe "Document B", I get:

e.source.document.title === "Document A"; 
e.target.document.title === "Document B"; 

In any case, I find .target confusing. It's also more confusing because you
also have the sourceElement attribute, which will probably have to also be set.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
Received on Monday, 24 December 2012 10:27:07 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:50:04 UTC