27738 2015-01-03 23:22:39 +0000 Need to change name of 'message' event to avoid confusion. 2015-01-21 00:36:26 +0000 1 1 1 Unclassified HTML WG Encrypted Media Extensions unspecified All All RESOLVED WONTFIX API_Compatibility P2 normal --- 1 glenn adrianba annevk cpearce ddorwin hsivonen mike public-html-media slightlyoff public-html-bugzilla oldest_to_newest 116766 0 glenn 2015-01-03 23:22:39 +0000 HTML5, Server Socket Events (SSE), Web Messages, and WebSockets API all employ a "message" event, with MessageEvent interface type, as defined by [1]. It is bad form, confusing, and potentially ambiguous for EME to redefine "message" as being an entirely different event bound to a MediaKeyMessageEvent. Please change the name to something specific to EME, e.g, "keymessage". [1] http://www.w3.org/TR/webmessaging/#event-definitions 116900 1 ddorwin 2015-01-07 21:16:51 +0000 Is this really a problem for someone that wants to handle the "message" event on a MediaKeySession? As for potential alternative names, "keymessage" is misleading since it is unlikely to relate to a key. It's really a session message (redundant because it's fired at a session object) or message from the CDM ("CDM" is not an app-visible concept). 117102 2 ddorwin 2015-01-13 22:34:17 +0000 Web MIDI fires [1]: * Events named "connect" and "disconnect" using the type MIDIConnectionEvent at MIDIAccess objects. * An event named "disconnect" using the type MIDIConnectionEvent at MIDIPort. * An event named "midimessage" using the type MIDIMessageEvent at MIDIInput. The first two are "common" event names with custom event types. The last is a specific event name for a custom event type. Perhaps this is specifically to avoid the issue with MessageEvent, but it seems odd to special case this name and type rather than "scope" all event names using custom types. [1] Search for "fire " in http://webaudio.github.io/web-midi-api/ 117202 3 hsivonen 2015-01-15 10:18:39 +0000 Can we please get edits that are about naming things done (or rejected) ASAP so that the names won't keep changing after implementations have adopted the names? There's more value in not having vendor prefixes and not having naming churn after shipping than in ending up with perfect names some time in the future. 117243 4 ddorwin 2015-01-15 21:39:45 +0000 +Anne and Alex for general platform comments (see comment 2). I agree with comment 3 - let's determine whether a change is necessary and move forward. I'll send an email to the list. 117268 5 annevk 2015-01-16 08:27:27 +0000 Event types (commonly referred to as the name of an event) are not required to be globally unique. This only goes for event interfaces (nay classes) and even those can be reused by events that signify something else as long as the objects they are dispatched on are different. (And I would argue, as long as those objects have no relationship. E.g. we wouldn't want Text and Element nodes to use a "foo" event with a "FooEvent" interface for completely different reasons.) So I don't really see a problem here. 117364 6 ddorwin 2015-01-21 00:34:03 +0000 Per comment 5, this is not a problem. As agreed in the telecon today, we will keep the name 'message'. 117366 7 ddorwin 2015-01-21 00:36:26 +0000 Telecon minutes: http://www.w3.org/2015/01/20-html-media-minutes.html#item01