GerHobbelt/.gitignore

## .gitignore
# Editor backup files
*.bak
*~

## README.md

      
    Raw
  

              README.md
            
          
    The issue & showcase

...
Test #1

...
Test #2

...
Test #3


## index.html
<html>
<head>
  <script src="http://mootools.net/download/get/mootools-core-1.4.4-full-nocompat.js" type="text/javascript"></script>

... load styles to show floating divs and their borders and such...
</head>
<body style="overflow: auto;">
  <h1>Test #1</h1>
  <p>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.
  </p>
  <div id="container-1">

    <div class="first">
      <h1>Henry The First</h1>
      <p>Here I am, jiggle that CTRL+scroll-wheel of yours and here I am not... <strong>occasionally</strong>. Or rather, when you zoom out (i.e. when I become smaller) I'll be a goner for sure!</p>
    </div>
    <div class="right">
      <h2>Right-Wing Henry</h2>
      <p>All I do is borderline!</p>
    </div>
  </div>
  <hr />
  <h1>Test #2</h1>
  <p>Number Two exhibits the artifacts of mootools' integer processing - and hence accumulating rounddown losses - of said non-integer pixel sizes.</p>
  <p>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.</p>
  <p>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 <code>getComputedSize()</code> 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.
  </p>
  <div id="container-2">
    <div class="first">
      <h1>Henry The First</h1>
      <p>Here I am, jiggle that CTRL+scroll-wheel of yours and here I am not... <strong>occasionally</strong>. Or rather, when you zoom out (i.e. when I become smaller) I'll be a goner for sure!</p>
    </div>
    <div class="right">
      <h2>Right-Wing Henry</h2>
      <p>All I do is borderline!</p>
    </div>
  </div>
  <hr />
  <h1>Test #3</h1>
  <p>Number Three comes with 2px spare agony green space between both Henry's.
  </p>
  <p>The lesson to take away from all this is not that getComputedSize() is wrong, but that:</p>
  <ul>
    <li>don't blame getComputedSize(); when you look into the mootools code, you'll see a plethora of .toInt() invocations in there, it's just that I picked out getComputedSize() as that was the one that led me to this. Blame (most of) the .toInt() calls in there instead.</li>
    <li>CSS dimensions should be treated as float values, rather than integers, to make sure that the error component in any subsequent calculations will, with extremely high probability, remain 1px or less - I won't ever say it'll be (0)zero as that is plain wrong, given that floating point calculations are implicitly inaccurate all by themselves.</li>
  <div id="container-3">
    <div class="first">
      <h1>Henry The First</h1>
      <p>Here I am, jiggle that CTRL+scroll-wheel of yours and here I am not... <strong>occasionally</strong>. Or rather, when you zoom out (i.e. when I become smaller) I'll be a goner for sure!</p>
    </div>
    <div class="right">
      <h2>Right-Wing Henry</h2>
      <p>All I do is borderline!</p>
    </div>
  </div>
  <hr />
  <h1>Values as reported by our mootools test code</h1>
  <div id="js-report">
  ... display measured values here...
  </div>
</body>
</html>
	<html>
	<head>
	<script src="http://mootools.net/download/get/mootools-core-1.4.4-full-nocompat.js" type="text/javascript"></script>

	... load styles to show floating divs and their borders and such...
	</head>
	<body style="overflow: auto;">
	<h1>Test #1</h1>
	<p>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.
	</p>
	<div id="container-1">

	<div class="first">
	<h1>Henry The First</h1>
	<p>Here I am, jiggle that CTRL+scroll-wheel of yours and here I am not... <strong>occasionally</strong>. Or rather, when you zoom out (i.e. when I become smaller) I'll be a goner for sure!</p>
	</div>
	<div class="right">
	<h2>Right-Wing Henry</h2>
	<p>All I do is borderline!</p>
	</div>
	</div>
	<hr />
	<h1>Test #2</h1>
	<p>Number Two exhibits the artifacts of mootools' integer processing - and hence accumulating rounddown losses - of said non-integer pixel sizes.</p>
	<p>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.</p>
	<p>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 <code>getComputedSize()</code> 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.
	</p>
	<div id="container-2">
	<div class="first">
	<h1>Henry The First</h1>
	<p>Here I am, jiggle that CTRL+scroll-wheel of yours and here I am not... <strong>occasionally</strong>. Or rather, when you zoom out (i.e. when I become smaller) I'll be a goner for sure!</p>
	</div>
	<div class="right">
	<h2>Right-Wing Henry</h2>
	<p>All I do is borderline!</p>
	</div>
	</div>
	<hr />
	<h1>Test #3</h1>
	<p>Number Three comes with 2px spare agony green space between both Henry's.
	</p>
	<p>The lesson to take away from all this is not that getComputedSize() is wrong, but that:</p>
	<ul>
	<li>don't blame getComputedSize(); when you look into the mootools code, you'll see a plethora of .toInt() invocations in there, it's just that I picked out getComputedSize() as that was the one that led me to this. Blame (most of) the .toInt() calls in there instead.</li>
	<li>CSS dimensions should be treated as float values, rather than integers, to make sure that the error component in any subsequent calculations will, with extremely high probability, remain 1px or less - I won't ever say it'll be (0)zero as that is plain wrong, given that floating point calculations are implicitly inaccurate all by themselves.</li>
	<div id="container-3">
	<div class="first">
	<h1>Henry The First</h1>
	<p>Here I am, jiggle that CTRL+scroll-wheel of yours and here I am not... <strong>occasionally</strong>. Or rather, when you zoom out (i.e. when I become smaller) I'll be a goner for sure!</p>
	</div>
	<div class="right">
	<h2>Right-Wing Henry</h2>
	<p>All I do is borderline!</p>
	</div>
	</div>
	<hr />
	<h1>Values as reported by our mootools test code</h1>
	<div id="js-report">
	... display measured values here...
	</div>
	</body>
	</html>