... load styles to show floating divs and their borders and such...
Number One exhibits the failure of mootools to cope with non-integer pixel sizes. Both Henry's are dimensioned to be 'pixel perfect', i.e. together, they occupy all the width' pixels available in the red container DIV.
Here I am, jiggle that CTRL+scroll-wheel of yours and here I am not... occasionally. Or rather, when you zoom out (i.e. when I become smaller) I'll be a goner for sure!
All I do is borderline!
Number Two exhibits the artifacts of mootools' integer processing - and hence accumulating rounddown losses - of said non-integer pixel sizes.
Since we assume you to be a crafty little bugger, you'll have seen the issue of Number One and 'fixed' it by allowing that extra spare pixel in between Henry's. When it is still a 'spare', it'll show in agony green.
Note, however, that -1px 'correction hack' isn't covering worst-case as you CTRL-scrollwheel / zoom out: Henry the First will still be pushed out at some zoom levels. This is due to the accumulation of rounddown errors in the getComputedSize()
method: it is not at fault per se, it's just that this call shows that you need to analyze the internals of your JS framework (moo, jq, whatever) to determine the correct rounddown 'error expression'; and thus 'worst-case error compensation value': we're better off with -2px correction here, as Number Three will prove, below.
Here I am, jiggle that CTRL+scroll-wheel of yours and here I am not... occasionally. Or rather, when you zoom out (i.e. when I become smaller) I'll be a goner for sure!
All I do is borderline!
Number Three comes with 2px spare agony green space between both Henry's.
The lesson to take away from all this is not that getComputedSize() is wrong, but that:
Here I am, jiggle that CTRL+scroll-wheel of yours and here I am not... occasionally. Or rather, when you zoom out (i.e. when I become smaller) I'll be a goner for sure!
All I do is borderline!