You've got a way with words! I believe that this isn't the first time we've heard that rounding errors cause well.. errors -- at least unexpected designs/results.
Best step in the right direction is to report this issue at Github: http://github.com/mootools/mootools-core/issues and mention the rounding error in a jsfiddle. We'll go from there. On Thu, Feb 9, 2012 at 8:38 PM, Ger Hobbelt <[email protected]> wrote: > See bottom. > > Bottom line: > FireFox is perfectly capable of reporting floating point widths, such as > 'border-left-size: 0.9999916px' and mootools will treat that one as 0 > (zero) in getComputedSize() et al: .toInt()-ing CSS pixel values will give > you some nasty surprises, at least, thanks to unpredictable rounddown > losses, so simple calculus transforms into calculus with error margins. ... > Fun! > (In my experience, only Mech. Engineers remain sometimes able to cope with > this 'error expression' sort of thing beyond graduation; IT folks simply go > <core dumped; insert boot disk> at the mere mention. >;-) ) > > Fix for now: > don't try to precisely (pixel-perfect) dimension and/or position your > <div>s and whatnot, but consider the amount of rounddown error accumulation > along the way and compensate for the worst-case scenario by taking off a > couple of pixels at judicious spots. Be a crafty bugger. > > If mootools would be made to produce these non-integer values as reported > by the browser, e.g. by migrating a bundle of .toInt()s to .toFloat()s, > then a much-less-than-1px 'error correction term' in user code will > suffice, but until then you'll have to analyze the internals and track the > error term / accumulation yourself: 1px won't always be enough. > (And in case you expect jQuery and others are smarter than this, then I'm > sure I can sell you this amazing deal in Greek bonds too...) > > > Posting/forwarding this here, because I think it's a mootools issue and: > > - somebody else might be saved a toupee purchase thanks to a lucky google > hit here, > > - I'd like to hear whether this is: > > - known issue, bloody tough to fix and really you can't fix it > completely (once you enter the floating point arena, there's always the > error expression in any math-turned-computation to consider, if only > theoretically ;-) ). > > - Jeez Louise, why on earth did your user jiggle that bloody > CTRL+scrollwheel?! > > - me being blind and dumb once again > > > Cheers! > > > > Met vriendelijke groeten / Best regards, > > Ger Hobbelt > > -------------------------------------------------- > web: http://www.hobbelt.com/ > http://www.hebbut.net/ > mail: [email protected] > mobile: +31-6-11 120 978 > -------------------------------------------------- > > > > ---------- Forwarded message ---------- > From: Ger Hobbelt <[email protected]> > Date: Fri, Feb 10, 2012 at 2:50 AM > Subject: milkbox 3.0.x issue in FireFox at zoomlevels != 100% + fix -- > really a mootools issue with non-integer CSS values reported by browser. > To: Luca Reghellin - Milkbox <[email protected]> > > > FYI. Ran into this one this evening while working on someone's site. FF > rendered milkbox wrong while Chrome did fine; turned out the zoomlevel was > the cause (in this case, the user / test machine had a FF zoomlevel of > /nearly/ 100% but not exactly that. ... Let's just say that it was an > interesting test of my stamina. :-) ) > > See > https://github.com/GerHobbelt/milkbox/commit/a43076b1be5623666d56be9a7b1393bfa7599348, > particularly the comment block in there (the links listed in there provide > further info). > > > Way to reproduce: > > - start FF, open a page, either view a milkbox item with a caption > already, or do this later. > > - Use CTRL+mousewheel to zoom in/out a couple of times; see the caption > disappear at various zoomlevels, particularly at zoomlevels < 100%. > > This is due to the following: when you inspect element in FF/FireBug, > you'll note that the left-border of the controls section will show a > FLOATING POINT number such as 0.916px instead of 1px. > Milkbox uses mootools to getComputedSize(), etc. and in there, 0.916 and > such numbers are, thanks to .toInt(), converted to 0 (zero), which means > that the caption div width will be calculated such that it's essentially > 1..2 px too wide (these rounddown errors accumulate in there!), resulting > in that div ending up BELOW the float:right controls div, and > overflow:hidden, etc. make the caption 'disappear' that way. > > The problem is really with mootools core/more which doesn't cope with > non-integer sizes (widths, etc.) delivered by the browser (everything is > .toInt() instead of .toFloat() in there, for starters!), but fixing it at > mootools level is a serious undertaking, so I 'hacked' a workaround into > milkbox itself -- it's basically a situation-specific 'compensation' error > correction assuming-close-to-worst-case, thus tolerating a cluster of > unpredictable round-down (floor) numeric value losses while widths are > calculated / derived. > >
