My beloved MacBook Pro 13" mid 2010 is nearing its end of life as Apple is preparing to halt any support for macOS 10.13 High Sierra and as much as I hate to, I will have to replace it by the end of 2020. It might seem odd it's still my main machine but having upgraded it with a fast SSD and 10 GB of RAM a few years ago, I still find it capable of handling my everyday web development needs.

So what is my dream replacement machine? Honestly, if Apple offered today the same laptop with up-to-date internals, it would be an instant purchase for me. Just give me the same enclosure, ports (I wouldn't mind if you swap the FireWire for USB-C), keyboard and I would be more than happy. I don't even care about the screen, I use an external monitor most of the time.

The keyboard alone deserves a separate paragraph. I have never used an external keyboard and you can imagine how much beating mine has seen in 10 years. And add to that a couple of times my little son forcefully disassemble many of the keys (the Space bar is hardest to reassemble BTW ) and still to this day not a single key has failed!

But no, Apple seems to have a different opinion. And I honestly have no clue why they chose to break and cripple something that was not broken. Not broken at all. Soldered RAM, even soldered SSD (is this a joke?), a single port type, no MagSafe (this thing has saved my laptop from dents at least a dozen times), stupid experiments with a rock-solid keyboard (hopefully, they got it right finally). I mean if this is some kind of smart phone-like consumer device, I could understand but you still dare to call this a professional laptop? Sorry, I'll pass.

I've already ordered a HP ProBook 430 G7 which offers practically the same upgradability like my MacBook Pro mid 2010 - 2 RAM slots, SSD slot + 2.5" HDD slot I will gladly use for a backup drive (I like keeping my private data "private" instead of storing it somewhere in the cloud). I don't need a beefy GPU so the integrated one will do just fine. It has a touchscreen and that's always handy for testing. Honestly, I just hope the keyboard is reliable enough, everything else is ideal for me.

Of course, the main thing I will miss initially is macOS but switching to a new platform was not a big issue last time. Ten years ago I went from Windows to Mac. I am certainly never getting back to Windows considering what a complete mess it is today. Honestly, in 10 years I feel like it's only gotten worse, I can't even stand looking at Windows 10's interface mess. UI consistency is arguably not great on any platform but to me it feels like in Windows 10 it's a whole new level of inconsistency.

So it's Linux for me this time and Pop!_OS is my initial choice. I've never used Linux for work but I've played with many different distros through the years and configuring a work station will not be a problem. What does a web dev need today anyway - a terminal, a text editor, a browser, some collaboration app?... It's all there.

Just install this small user script in your browser (Opera, Chrome, Firefox via Greasemonkey or Safari via GreaseKit):

https://raw.github.com/vadikom/facebook-nochat/master/facebook-nochat.user.js

and remove that chat floating box/sidebar for good! As a bonus, it will make sure you always appear unavailable for chat. Second bonus - when the sidebar is removed, the rest of the page will be perfectly centered in your browser window again. Yay!

* A special note for Firefox on Windows/Linux
Firefox 4 on Windows and Linux has this issue only when hardware accelerated rendering is enabled in the Options/Preferences (and, of course, supported on the machine). I always get the issue on Mac.

IE9 and FF4 introduced subpixel font rendering and now calculate and report width/height of page elements using float values even when a web page is viewed at 100% zoom level. This is something no other browser has ever done before. So, right now in IE9 and FF4 you can get computed width/height values for block elements reported like "100.34px", "11.65px", etc. I once heard from a colleague that a client asked him to move a page element by half a pixel because apparently one pixel seemed to much to him. Well, I've got good news for that guy, this is now possible!

But seriously, let's get back to the issue. As you already may be guessing, the problem with offsetWidth/offsetHeight in IE9 & FF4 is that these properties are integer values so in these browsers the values are computed by rounding the float values for width/height and adding the padding & border. And the rounding often leads to 1px inaccuracy depending on the calculations done in your scripts and on the exact fonts and font sizes used on the page. You may say 1px is nothing but there are cases when 1px could cause quite notable issues like, for example, text wrapping happening when it shouldn't, etc..

Demoing the Problem

Basically now you can easily stumble upon issues in IE9 and FF4 like on this demo page. In this example, offsetHeight is used to get the computed border-box height of the first DIV and the second DIV has negative top margin applied which is equal to the value returned. The end result should be perfectly overlapping DIVs, so that you could only see the second one. But in IE9 or FF4, you can see either the top or the bottom border of the first DIV sneaking beneath the second DIV for some of the iterations:

The Workaround

From the demo above we clearly see we can no longer use offsetWidth/offsetHeight if we want perfect results in these browsers. The workaround is to use the getComputedStyle() method instead which reports the width/height of block elements with float numbers. So basically, the workaround is to get the computed width/height and then add the computed top/bottom padding & border of the element to get the final value. The problem with getComputedStyle() on theory is that for width/height of inline elements it always reports 'auto'. But the good news is these browsers only seem to round the computed float values for block elements and so for inline elements we can still safely use offsetWidth/offsetHeight! Well, if you are still following me, here is a fully cross-browser workaround compatible with all other and older browsers:

function _getOffset(elm, height) {
	var cStyle = elm.ownerDocument && elm.ownerDocument.defaultView && elm.ownerDocument.defaultView.getComputedStyle
		&& elm.ownerDocument.defaultView.getComputedStyle(elm, null),
		ret = cStyle && cStyle.getPropertyValue(height ? 'height' : 'width') || '';
	if (ret && ret.indexOf('.') > -1) {
		ret = parseFloat(ret)
			+ parseInt(cStyle.getPropertyValue(height ? 'padding-top' : 'padding-left'))
			+ parseInt(cStyle.getPropertyValue(height ? 'padding-bottom' : 'padding-right'))
			+ parseInt(cStyle.getPropertyValue(height ? 'border-top-width' : 'border-left-width'))
			+ parseInt(cStyle.getPropertyValue(height ? 'border-bottom-width' : 'border-right-width'));
	} else {
		ret = height ? elm.offsetHeight : elm.offsetWidth;
	}
	return ret;
}
function getOffsetWidth(elm) {
	return _getOffset(elm);
}
function getOffsetHeight(elm) {
	return _getOffset(elm, true);
}

Usage is very simple:

var elmOffsetWidth = getOffsetWidth(elm);
var elmOffsetHeight = getOffsetHeight(elm);

And here is the fixed demo page that includes the workaround.

The Questions

Finally, here are the questions that come to my mind:

1. Is this the road all other major browsers (i.e. WebKit and Opera) plan to take in the future?
2. If not, why did IE and FF did it then and shouldn't they revert to the old behavior?
3. If yes, then shouldn't at least offsetWidth/offsetHeight be fixed to return the preciser float values?

I guess you'd agree it's nice to have these questions answered.

Update: Twitter have changed their design so this post covers a previous issue on their website and is no longer relevant.

First, a very quick demo of what I mean:

And the JavaScript/jQuery snippet which fixes the issue:

$('#page-container div.pane-components').live('mousewheel DOMMouseScroll', function(e) {
	var scrollTop = this.scrollTop,
		clientHeight = this.clientHeight,
		scrollHeight = this.scrollHeight,
		originalEvent = e.originalEvent,
		scrollingUp = (originalEvent.wheelDelta || -originalEvent.detail) > 0;
	if (scrollingUp && scrollTop == 0 || !scrollingUp && scrollTop + clientHeight == scrollHeight)
		e.preventDefault();
})

It just checks if the top or bottom of the details pane has been reached and when it has, the default action the mouse wheel event triggers (i.e. scrolling the whole page) is prevented.

If you would like to test the fix on your own, just load some Twitter page in your browser, then copy/paste the following code in your browser address bar and hit the "Enter" key:

javascript:$('#page-container div.pane-components').live('mousewheel DOMMouseScroll', function(e) {
	var scrollTop = this.scrollTop,
		clientHeight = this.clientHeight,
		scrollHeight = this.scrollHeight,
		originalEvent = e.originalEvent,
		scrollingUp = (originalEvent.wheelDelta || -originalEvent.detail) > 0;
	if (scrollingUp && scrollTop == 0 || !scrollingUp && scrollTop + clientHeight == scrollHeight)
		e.preventDefault();
});void(0)

And for a permanent fix, until eventually Twitter fixes the issue, you can install the following user script in your browser (Opera, Chrome, Firefox via Greasemonkey or Safari via GreaseKit):

https://github.com/vadikom/twitter-scroll-fix/raw/master/twitter-scroll-fix.user.js

Spread the Word

If you find this fix useful, tweet about it so that it can reach the guys at Twitter and they consider using it or a similar solution.

Well, that's all I can do about it.

It may seem a pretty insignificant addition to your browser's features at first sight but, at least for me, it has proven to be a really handy one and I have not stopped using it in my main browser (Opera) since I first wrote it. BTW, the original version of the script was featured in Mark Pilgrim's Greasemonkey Hacks book which means at least one other user found it useful.

Anyway, I am now publishing v2.0 which brings some nice improvements over the previous release.

What's new in v2.0

• you can now even easier zoom in/out the image by using the mouse wheel too - just hover the toolbar (any button) and use the mouse wheel (if you have one, that is :P)
• rewritten OO code allowing easily to add more custom buttons
• improved look (arguably) of the menu/buttons including light and dark style
• added optional show fade-in animation - disabled by default as it might become obtrusive over time (at least for me it does)

User Configuration

The script includes the following options which you could tweak to your liking:

zoomFactorClick = 1.5,		// zoom in/out by this factor each time
zoomFactorMouseWheel = 1.2,	// just hover the toolbar (any button) and use the wheel
showTimeout = 1.2,		// seconds
minimalImageWidth = 60,		// minimal width of the images the toolbar is activated for
minimalImageHeight = 50,	// minimal height of the images the toolbar is activated for
opacity = 0.80,			// opacity for the toolbar
fade = false,			// use fade animation when showing the toolbar
darkStyle = false,		// use dark style for the toolbar
zIndexFix = true;		// try to keep the zoomed image on top of other elements on the page

Adding More Custom Buttons

As mentioned, the script is now rewritten and allows more easily adding custom buttons to the toolbar. You can create a custom button like this:

var myButton = new Button(name, className, title, contentHTML, handlers);

And then append it to the toolbar like this:

zoomToolbar.addButton(myButton);

Example: Adding an "open" button

Here is a quick example how to add an "open" button which when clicked, loads the image in a new blank browser window:

var openButton = new Button('openButton', 'text-button', 'Open Image in New Window', 'open', {
	click: function() {
		window.open(image.src);
		zoomToolbar.hide();
	}
});
zoomToolbar.addButton(openButton);

I have added this button at the end of the Zoom Image code as well as another button "size" which when clicked reports the original dimensions of the image in a JavaScript alert popup. These buttons are disabled by default (the code is commented out) but you could enable them if you like.

Download / Install

Here is a direct link to the latest version available in the code repository:

http://github.com/vadikom/zoom-image/raw/master/zoom-image.user.js

The code is hosted on GitHub:

git clone git://github.com/vadikom/zoom-image.git

Demos

You might be eager to take a look at some examples so here is the demo page right away. And below you will find a short introduction.

Notable Features

OK, so apart from the awful name, is there anything interesting about this tooltip plugin?

A Single Background Image for Scalable Tooltips

Suppose you need to code a scalable tooltip that looks like this (i.e. a tooltip with auto width/height based on the content inside it):

The Usual Approach

To achieve this with most similar plugins out there you would need to slice the image into multiple separate images - for the corners of the box, for the sides, etc.:

The Poshy Tip Approach

But since the tooltips only work when JavaScript is enabled anyway, why not apply some JS magic which would make our life easier and save our server some additional requests? This is exactly what Poshy Tip was designed to do. With this plugin, you can create a scalable tooltip by just using a single background image for the tooltip body:

You need to create one big image for the tooltip body - e.g. something like 1024x768 pixels (which should be enough for anything you may want to display inside a tooltip in the browser viewport). You then have to set it as a background image for the tooltip container DIV in the most trivial way:

.tip-yellow {
	...
	background-image: url(tip-yellow.png);
}

Poshy Tip detects when a background image has been set for the tooltip container DIV and creates a scalable frame from it that wraps the inner contents of the tip. Finally, you just need to specify what should be the size of the background image frame around the inner content by setting the following option:

bgImageFrameSize: 10 // pixels

And the result:

You can, of course, tweak the margin/padding of the inner DIV if needed.

Advanced Positioning Options

With Poshy Tip you can position the tips relative to the mouse cursor or to the target element and align them in every possible way horizontally and vertically (note the alignTo, alignX and alignY options). In addition the script makes sure the tips are always displayed in the browser viewport and also automatically positions the arrow (if available) on the appropriate side of the tooltip body.

Asynchronous Loading of the Tooltip Content

Poshy Tip supports using a function for returning the tooltip content and the script also passes an update callback function as an argument to this function. By using this callback, you can easily update asynchronously the content of the tooltip after it has been displayed. You can see a quick example on the demo page.

Documentation

You can find usage examples and a list of the options and methods available on the demo page.

License

Like jQuery, Poshy Tip is dual licensed under the MIT and GPL licenses.

Git

The Poshy Tip source code is also available at GitHub:

git clone git://github.com/vadikom/poshytip.git

But who am I after all?

Ah, sorry for being impolite and not introducing myself right away! My name is Vasil Dinkov and I live and work in Plovdiv, Bulgaria. I am the guy behind the SmartMenus Website Menu and the FreshFavicon Favicon Gallery. If you would like to learn a bit more, you can check out the about page.

Well, I think that's it for now. I hope you find something useful here in the future and do not regret for just waisting your time when visiting Vadikom.com!