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 28918 - getClientRects() and getBoundingClientRect() need to be clearer about when the returned DOMRect might contain -0 anywhere
Summary: getClientRects() and getBoundingClientRect() need to be clearer about when th...
Status: NEW
Alias: None
Product: CSS
Classification: Unclassified
Component: CSSOM View (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: Simon Pieters
QA Contact: public-css-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-07-06 19:17 UTC by Jeff Walden (remove +w3 to email)
Modified: 2015-07-07 09:42 UTC (History)
1 user (show)

See Also:

Attachments

Description Jeff Walden (remove +w3 to email) 2015-07-06 19:17:53 UTC 
The CSSOM spec is unclear about what the sign of getBoundingClientRect().top is, when that value is zero.  Is -0 a possibility, or is +0 the only permitted value?  Could it be either, and if so, when should the different signs be observed?

This issue applies to all the other fields of DOMRect, as well.  The DOMRect spec is clear that width/height can be negative, but that could just as easily be because |new DOMRect| lets you create a rect with arbitrary numeric components, as because of any real-world reason.  And one could imagine that "negative" observation to be motivated by "real" negative numbers, not -0.

This issue is pretty nitpickery, of course.  But I raise it because I stumbled across a Gecko test that inadvertently compared gBCR().top with -0.  It passes because it ignores the sign on zero, but I'm changing the (general) comparison mechanism to only equate same-signed zeroes, and it's not clear that the test's comparison is exactly right or wrong.