1.1.0

#26

1.0.0

Measuring the DOM in the modern browser landscape

Measuring DOM elements just got a lot better. A complete refactoring of the old (v0.6.2) codebase with all the calculations revised for modern browsers and made more accurate.

• It's all 100% TypeScript now with strong typings.
• All methods can be imported individually via subpath exports.
• Distributed as ES modules, CommonJS modules and UMD - pick your poison.
• Tests refactored and CI set up to run them on a wide variety of devices/browsers.

This release is the culmination of three beta releases:

• https://github.com/niklasramo/mezr/releases/tag/1.0.0-beta.0
• https://github.com/niklasramo/mezr/releases/tag/1.0.0-beta.1
• https://github.com/niklasramo/mezr/releases/tag/1.0.0-beta.2

Enjoy!

1.0.0-beta.2

Bug fixes:

• In the 1.0.0-beta.1 version we introduced a performance optimization to element width/height calculcation, but the optimization mistakenly included the scrollbar size for content and padding widths/heights. Additionally, the optimization produces a bit less accurate values than getBoundingClientRect(), which is otherwise okay, but it also causes the getRect() method to return data where the offsets are not fully in sync with the dimensions. And that is not okay. So I decided to drop it for now and think about it a bit more.
• Fixed an issue with getHeight() method where it would not always subtract the scrollbar correctly.
• You could consider this a feature instead of a bug fix, but let's call it what it really is. Previously, if the element had a scrollbar with a subpixel width/height (possible in Chromium-based browsers) the final width/height calculation for padding and content sizes would be incorrect. Now that's fixed. I think we got this done in nicely performant way without needing to resolve to adding test elements in the DOM (which would have sucked big time). It turns out that subpixel scrollbars vary in behaviour between devices/browsers, which means that we can't use the same assumption for all cases, which also means we have to test the behaviour in the DOM to get accurate results :( I built a cache system to store the corresponding real values for the values that window.getComputedStyle() reports. This way we can keep the DOM testing at minimum and only test when there actually is a custom subpixel scrollbar value defined.

The PR: #24

1.0.0-beta.1

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) and getHeight(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's scrollWidth/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 the body's scrollbar or the documentElement's scrollbar. However, in standards mode, the main scrolling element is always the documentElement, which is why we don't include the body's scrollWidth/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 the documentElement's getBoundingClientRect().width/height in the calculations, which returns fractional pixel values.
• Update the logic for computing documentElement scrollbar width/height:
  • Previously we computed the viewport scrollbar height/width for documentElement, but in reality documentElement can't actually have a scrollbar. Check it yourself, the scrollbar of the documentElement is always outside the bounds of documentElement because it's actually the window's scrollbar , so we always return 0 from now on.
• 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 of elem.getBoundingClientRect().width/height, but it's still a breaking change compared to the previous behavior.

The PR: #23

1.0.0-beta.0

A massive refactoring that makes Mezr modern and modular:

• Full rewrite with TypeScript which also means the API was completely rewritten (hopefully for the better).
• Fix a lot of bugs.
• Support only modern browsers.
• Offer the library as ES Module, CommonJS module and UMD module.
• Offer each individual public method as a an independent subpath export.
• Rebuild even more extensive unit tests with Mocha.
• Proper CI pipeline.

The PR: #21.

v0.6.2

• Generic cleanup and reorganisation.
• Sticky element handling: #17
• Bug fix: #18

v0.6.1

• Fixed this: #16
• .width(), .height() and .rect().width, .rect().height could earlier return negative values, which is now fixed. Those methods are now guaranteed to return 0 or greater values.

v0.6.0

• New method: mezr.overflow(container, elem). Related ticked: #14.
• New option for mezr.place() method's options: adjust. Related ticket: #10
• Renamed mezr.place() method's contain.onCollision option to contain.onOverflow. Related ticket: #15

v0.5.0

This is a major update to the v0.4.0 and has some breaking changes. Here's the list of related tickets.

Changes

• .offsetParent() method was renamed to .containingBlock(). The reason for this was that the method was refactored thoroughly and as a result it does not match the description of elem.offsetParent anymore. However, it does match the description of the containing block. This method is pretty neat because it't smart enough to recognize if the browser leaks fixed elements from within transformed elements (against the spec) and returns correct results in all modern browsers (IE9+).
• .intersection() method now accepts two or more elements.
• .place() method's options were refactored quite a lot, so you might want to check that out.
• "core" edge layer was renamed to "content". Affects all methods which allow defining the element's edge layer. This is now more in line with W3C spec.
• .offset() method learned a new trick: you can now use an alternative syntax and define which element the offset is measured from. Use it like this: mezr.offset([elem, 'content'], [otherElem, 'padding']). The old syntax is still supported and not going anywhere.
• .rect() was introduced and it's meant to mimic the behaviour of the elem.getBoundingClientRect(), but with a bit more options =)
• Unit tests were overhauled and updated.

Generally speaking, things are looking good and this should be a pretty solid release. This could have easily been granted v1.0.0 status, but I want to add a few more features before bumping the version all the way up there.

Happy _mezr_ing!

0.4.0

• Major API overhaul and a lot of bug fixes.
• Contains breaking changes to all previous versions.
• Tested successfully with SauceLab in the following browsers:
  • Chrome 45 (all platforms)
  • Firefox 41 (all platforms)
  • Safari 6/7/8/8.1
  • Microsoft Edge 20.10240
  • IE 9/10/11
  • iOS emulator 7.1/8.4/9.0
  • Android emulator 4.4/5.1
    • Note: unit tests fail on 4.0/4.1/4.2/4.3