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 11016 - Give the TimedTrackCueList getter operation an identifier
Summary: Give the TimedTrackCueList getter operation an identifier
Status: RESOLVED WONTFIX
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: Unsorted
Assignee: Ian 'Hixie' Hickson
QA Contact: contributor
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-10-12 23:34 UTC by Cameron McCormack
Modified: 2012-07-18 18:48 UTC (History)
6 users (show)

See Also:

Attachments

Description Cameron McCormack 2010-10-12 23:34:30 UTC 
The getter on TimedTrackCueList should have an identifier.  This would make it consistent with other interfaces such as HTMLCollection, DOMTokenList, HTMLFormElement, HTMLSelectElement and UndoManager that have indexed properties as well as a method to get an item at a particular index.
Comment 1 Ms2ger 2010-11-22 10:27:57 UTC 
What's the use case?
Comment 2 Cameron McCormack 2010-11-24 04:03:29 UTC 
Obviously, you can get at the elements of the TimedTrackCueList with the index properties, so whatever the use case is that TimedTrackCueList serves is solved by that.  I would ask why TimedTrackCueList isn't being made consistent with the other collection/array-like interfaces in the spec.  Surely consistency benefits authors, and we should strive to be consistent unless there are good reasons not to be?
Comment 3 Ian 'Hixie' Hickson 2011-01-01 06:36:50 UTC 
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: It's unclear to me why consistency would be especially useful here. It's not like someone using track.cues[0] is going to wonder why he can't do track.cues.item(0) instead. Arrays don't support that, right? If we should be pursuing convergence, it's with Array, not with a random smattering of DOM interfaces that have a variety of additional ways of obtaining the array items in addition to the regular getter syntax.