enyo.Control.getBounds() vs. Element.clientWidth & Element.clientHeight

Over the past few months I have ran into a few layout bugs across multiple devices which were caused by working with incorrect dimensions for some DOM Elements. This is not something browser specific, I have ran into situations like this on Chrome on Desktop and IE on Windows Phone 8.1, possibly other browsers as well.

Basically these layout bugs were usually solved by replacing something like:
var width = control.hasNode().clientWidth; // returns wrong width
With something like:
var width = control.getBounds().width; // returns correct width

Now I know the getBounds method does a lot more than simply looking at a clientWidth property, so its not entirely unexpected to see different results.

The fascinating thing though, is that Element.clientWidth & Element.clientHeight apparently do not trigger enough layout calculations in the browser to ensure the correct dimensions are returned, while getBounds does.

getBounds is significantly slower though, and retrieves metrics that are not always needed. For the sake of making my reflows as speedy as possible I'd like to simply find the shortest route towards retrieving an accurate width and/or height of an elements.

So, I was wondering, what is it exactly that makes getBounds more accurate? Which part of enyo.Control.getBounds or it's super enyo.dom.getBounds does the trick?

Comments

  • Nevermind, just figured out I shold not have been using Element.clientWidth & Element.clientHeight, but Element.offsetWidth & Element.offsetHeight...

    That's what I get for being lazy and using libraries when vanilla-js is just as easy...
Sign In or Register to comment.