24662 2014-02-14 16:52:34 +0000 Spec for indexed access on Window doesn't match most browsers 2014-02-27 22:16:37 +0000 1 1 1 Unclassified WHATWG HTML unspecified Other other RESOLVED FIXED http://www.whatwg.org/specs/web-apps/current-work/#accessing-other-browsing-contexts P3 normal Unsorted 1 contributor ian adamk adrianba annevk bzbarsky dburns eric ian mike travil w3c zcorpan contributor oldest_to_newest 100593 0 contributor 2014-02-14 16:52:34 +0000 Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html Multipage: http://www.whatwg.org/C#accessing-other-browsing-contexts Complete: http://www.whatwg.org/c#accessing-other-browsing-contexts Referrer: Comment: Spec for indexed access on Window doesn't match most browsers Posted from: 98.110.194.132 by bzbarsky@mit.edu User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:30.0) Gecko/20100101 Firefox/30.0 100594 1 bzbarsky 2014-02-14 16:53:31 +0000 See http://jsfiddle.net/vJ3PX/ IE is the only browser that maps [0] to the first frame in DOM order here. Gecko, Blink, WebKit, and Presto all map it to the first frame in insertion order. 100619 2 ian 2014-02-14 21:09:44 +0000 Yeah, this was intentional because matching insertion order seems highly unhelpful and since IE did the other one I presumed there was only a low risk of compat problems. Are there actual compat problems here, or do you think it's better for authors to do the insertion order? 100640 3 bzbarsky 2014-02-14 22:26:19 +0000 I don't know. I'm a bit worried about compat problems, yes, but have no hard data. Insertion order is also a lot easier to implement in a performant way. 101022 4 ian 2014-02-20 21:05:05 +0000 The three implementations using insertion order is a compelling argument, but it does seem quite inferior for authors, which seems more important than implementation complexity. Anyone else have an opinion here? 101094 5 bzbarsky 2014-02-21 04:59:46 +0000 This API is pretty useless for authors in practice, I suspect, given ad scripts and like buttons and the like which may or may not insert iframes, more or less randomly from the author's point of view.... 101303 6 eric 2014-02-25 01:21:13 +0000 Depending on frames[x] would be an extremely brittle way to code your page. I suspect (but don't have any data!) that authors use window.frames just for iterating over all frames and not for depending on a specific frame ordering (which might change every time they redesign their page). Maybe the first frame, frames[0] is stable enough that sites depend on that? We could use-counter and possibly remove this accessor all together. 101376 7 ian 2014-02-25 19:22:38 +0000 I doubt we can remove the accessor. In static pages, regardless of whether the order is tree order or insertion order, the order is predictable and stable (since the frames would be inserted in tree order). Even in dynamic pages, most of the time it'll be close to tree order. Anyway, I'm happy to change the spec if we don't think tree order is actually that useful or if there's a compat need or if you're just not willing to change or something. IE using tree order seems like a sign that maybe we could use tree order if we agree it's better for authors. But if we don't, and you won't change, then three vs one seems like a slam dunk for the insertion order side. 101538 8 contributor 2014-02-27 22:16:37 +0000 Checked in as WHATWG revision r8515. Check-in comment: Make the spec match more UAs (frames[] is in insertion order, not tree order) http://html5.org/tools/web-apps-tracker?from=8514&to=8515