This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 27739 - Change event name 'keyschange' to 'keychange'.
Summary: Change event name 'keyschange' to 'keychange'.
Status: RESOLVED FIXED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: Encrypted Media Extensions (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: David Dorwin
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard: API_Compatibility
Keywords:
Depends on: 27740
Blocks:
  Show dependency tree / graph
 
Reported: 2015-01-03 23:33 UTC by Glenn Adams
Modified: 2015-01-21 02:15 UTC (History)
5 users (show)

See Also:

Attachments

Description Glenn Adams 2015-01-03 23:33:54 UTC 
Since one doesn't know whether the key(s) changed are one or many, it would be better to rename 'keyschange' to 'keychange'. This would also be more consistent with changing 'message' to 'keymessage' (see bug 27738 [1]).

[1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=27738
Comment 1 David Dorwin 2015-01-07 21:19:51 UTC 
'keychange' might be ambiguous (i.e. key rotation). Perhaps 'keystatuschange', though it's also possible for this event to be fired when a key is added or removed. I suppose that could be a change in status. Since this is fired when the keyStatuses attribute changes, perhaps it should be 'keystatuseschange' (or a similar name based on the discussion in bug 27740).
Comment 2 David Dorwin 2015-01-13 22:59:29 UTC 
The HTML5 media element spec has the following "change" events [1]:
1. durationchange: The duration attribute has just been updated.
2. ratechange: Either the defaultPlaybackRate or the playbackRate attribute has just been updated.
3. volumechange: Either the volume attribute or the muted attribute has changed. Fired after the relevant attribute's setter has returned.

The Timed text tracks section defines change and cuechange [2], which do not appear to be related to any specific attributes.

Document's readystatechange event is fired when the readystate attribute changes [3].

In general, the pattern appears to be "<attribute-name>change" (or "attribute-category-name"). In that case, assuming we keep the attribute name "keyStatuses" as currently proposed in bug 27740, the event name should be "keystatuseschange". It's not easy to say, but it is easy to understand.

[1] http://www.w3.org/TR/html5/embedded-content-0.html#mediaevents
[2] http://www.w3.org/TR/html5/embedded-content-0.html#cue-events
[3] Above http://www.w3.org/TR/html5/dom.html#dom-document-readystate
Comment 3 Henri Sivonen 2015-01-15 10:19:10 UTC 
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.
Comment 4 David Dorwin 2015-01-21 00:34:50 UTC 
In the telecon this morning, we agreed on "keystatuseschange" as proposed in comment 2. I will implement this.
Comment 5 David Dorwin 2015-01-21 00:36:54 UTC 
Telecon minutes: http://www.w3.org/2015/01/20-html-media-minutes.html#item02