Web compatibility story of scrollTop and scrollLeft

How do you account for scroll position on the Web?  You use document.body.scrollTop/scrollLeft on WebKit/Blink and document.documentElement.scrollTop/scrollLeft on non-WebKit/non-Blink browsers.

A couple of months ago, one WebKit contributor tired to fix this discrepancy between browsers by flipping WebKit’s behavior to match other browsers in http://trac.webkit.org/changeset/154614.  This, of course, broke a bunch of websites including Facebook that did UA string sniffing.  In particular, if you clicked on an image after scrolling on the News Feed page on Facebook, the scroll position reset to the top of the page.

While I was initially considering to roll out the whole patch, I realized that we could make scrollLeft and scrollTop of both body and documentElement return the scrolled positions of the viewport.  So I landed a partial revert of the original patch in http://trac.webkit.org/changeset/158254 to preserve the old behavior in HTMLBodyElement.

While I was uploading the patch, I told another WebKit contributor that my partial rollout would break any websites that takes the advantage of the fact scrollTop and scrollLeft on body and documentElement are currently mutually exclusive. e.g.

var scrollLeft = document.body.scrollLeft + document.documentElement.scrollLeft;

As it turns out, I immediately found such code on Facebook along with at least 17,527 results on github.

Live NodeList and HTMLCollection in WebKit

There are many DOM APIs that return a live NodeList or HTMLCollection such as childNodes and getElementsByTagName. However, the fact they reflect the live view of the DOM tree introduces a significant code complexity and runtime cost. Consider the following code:

var headers = document.getElementsByTagName('h1');
for (var i = 1; i <= headers.length; i++) {
    var prefix = document.createTextNode(i + '. ');
    var wrapper = document.createElement('span');
    headers[i].insertBefore(wrapper, headers[i].firstChild);

This code prefixes all h1 elements with “1. “, “2. “, etc… Of course, you can use CSS instead but let’s say we wrote this code. Somewhat surprisingly, the runtime complexity of this code is Θ(n^2) where n is the number of nodes in the document in WebKit. Let us see why that’s the case. Continue reading

I don’t know why people have such a hard…

I don't know why people have such a hard time understanding that I'm not interested in engaging in discussions or debates at all. The only reason I use SNS is because there are things I want to say but don't necessarily want to broadcast them to the entire world. In most cases, I'm not interested in justifying or supporting my positions or hearing opposing opinions.