This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
http://dev.w3.org/csswg/cssom-view/#dom-element-getboundingclientrect [[ 1. Let list be the result of invoking getClientRects() on the same element this method was invoked on. ]] The "invoking getClientRects()" phrasing might be too vague. Is it supposed to mean simply: ``` getBoundingClientRect() { var list = this.getClientRects(); ... } ``` or instead something like: ``` magic uberprivate var _getClientRects = Element.prototype.getClientRects; getBoundingClientRect() { var list = _getClientRects.call(this); ... } ``` ? More concretely, is the following test expected to pass, or to fail?: http://jsfiddle.net/cvrebert/26kszjdz/ (See its console output)
*** Bug 29191 has been marked as a duplicate of this bug. ***
This is covered by a general provision stuffed in the Terminology section: https://drafts.csswg.org/cssom-view/#terminology [[ When a method or an attribute is said to call another method or attribute, the user agent must invoke its internal API for that attribute or method so that e.g. the author can’t change the behavior by overriding attributes or methods with custom properties or functions in ECMAScript. ]]
Yep but I should still fix this in a better way, where a better way is by using named algorithms and invoking those, instead of having one API invoke another, since the current setup keeps confusing people.