1.0.0-beta.1
Pre-release
Pre-release
niklasramo
released this
15 Oct 20:15
·
11 commits
to master
since this release
Breaking changes
- Update the document width/height computation logic:
- Previously we allowed getting the document width/height with or without the viewport scrollbar, which isn't really logical as the viewport scrollbar is not part of the document exactly. So, to amend that, you will now get the same result from
getWidth(document)
andgetHeight(document)
no matter which box edge value you provide as the second argument, and that result is the width/height without the viewport scrollbar. - Previously we also included the
body
element'sscrollWidth
/scrollHeight
in the calculations when deciding the max width/height for the document. This stemmed from the fact that while in quirks mode the main scrollbar (queryable via document.scrollingElement) could've been either thebody
's scrollbar or thedocumentElement
's scrollbar. However, in standards mode, the main scrolling element is always thedocumentElement
, which is why we don't include thebody
'sscrollWidth
/scrollHeight
anymore when trying to compute the max width and height for the document. - The document's width/height can be fractional, but the current method's for querying it (
scrollWidth
,scrollHeight
,clientWidth
,clientHeight
) only return rounded integers. To make the document width a bit more accurate in some scenarios we now also inlcude thedocumentElement
'sgetBoundingClientRect().width/height
in the calculations, which returns fractional pixel values.
- Previously we allowed getting the document width/height with or without the viewport scrollbar, which isn't really logical as the viewport scrollbar is not part of the document exactly. So, to amend that, you will now get the same result from
- Update the logic for computing
documentElement
scrollbar width/height:- Previously we computed the viewport scrollbar height/width for
documentElement
, but in realitydocumentElement
can't actually have a scrollbar. Check it yourself, the scrollbar of thedocumentElement
is always outside the bounds ofdocumentElement
because it's actually thewindow
's scrollbar , so we always return0
from now on.
- Previously we computed the viewport scrollbar height/width for
- Change box edge argument name: "scroll" -> "scrollbar":
- This change affects all methods that accept box edge as an argument. The change was made to prevent any confusion with getting element's scroll width/height vs scrollbar width/height. Now it should be very explicitly conveyed that "scrollbar" width and height includes the element's dimensions up until the end of scrollbar edge, but not including the actual scroll area of the element.
- Performance optimization for element width/height calculation:
- In case the element is using "content-box" box sizing we can make the width/height computation a bit faster for the "content" and "padding" box edge cases while sacrificing a bit of precision. In these cases we can just start with
window.getComputedStyle(elem).width/height
, which's precision varies per browser, but still always returns values with at least 2 decimal precision. In practice you probably won't notice the difference compared to the original approach where we started peeling the layers off ofelem.getBoundingClientRect().width/height
, but it's still a breaking change compared to the previous behavior.
- In case the element is using "content-box" box sizing we can make the width/height computation a bit faster for the "content" and "padding" box edge cases while sacrificing a bit of precision. In these cases we can just start with
The PR: #23