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'.
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
Whiteboard: API_Compatibility
Depends on: 27740
  Show dependency treegraph
Reported: 2015-01-03 23:33 UTC by Glenn Adams
Modified: 2015-01-21 02:15 UTC (History)
5 users (show)

See Also:


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

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.

[3] Above
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: