This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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
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.
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?
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.
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?
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....
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.
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.
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