Determining when an element is scrollable in Gecko

As a web developer, there are often times where it’s necessary to know if an element on a page is scrollable. One way of checking this would be to find the difference of element.scrollWidth and element.clientWidth. If the difference between these two properties is non-zero, then the element is scrollable. However, this doesn’t work for all cases.

In particular, element.scrollWidth and element.clientWidth clamp their values to integers. If the difference between the scrollWidth and clientWidth is less than zero, then the computed difference between the two will result in zero. This is less than good.

Starting in Firefox 16 [1], there is a new property element.scrollLeftMax which returns the difference of scrollWidth and clientWidth, including the fractional component. Also introduced is the companion element.scrollTopMax for use in determining vertical scrolling availability.

Hopefully these properties will find their way in to the other layout engines.

[1] These properties were implemented in bug 766937.

Unnecessary Regular Expressions

Regular expressions are powerful. They are the jackhammer for all chiseling purposes. In some situations they work great, but often they are either overkill or computationally unreasonable.

Regular expressions introduce a state-machine that is hard to optimize for each case.

Here are a couple regular expressions that I’ve seen within code that was replaced with easier-to-read and faster code.

s.replace(/[^.]*/g, “”).length

This regular expression removes all non-period characters in a string. It then queries for the length of the new string. This effectively just gets the number of periods in the string.

A much simpler approach, and also faster, would be to walk through the string and just count each instance of the period character.

var i, l = s.length, count = 0;
for (i = 0; i < l; i++) {
  if (s[i] == '.')
    count++;
}

s.replace(/\s+$/, “”)

This regular expression removes all whitespace at the end of the string. A much simpler approach would be to use the trim() function. There also exists non-standard functions trimRight() and trimLeft() that can be used to only remove whitespace from a specified side of the string.

Testing it out

If you’d like to see the performance differences for yourself, you can run the character counting and string trimming benchmarks on JSPerf.

Performance Improvements of Screencast.com

The latest Screencast.com release included a couple speed improvements that were quietly included.

URL improvements

The first improvement was one requested by Kyle Mulka, of Twilk, during a visit to TechSmith. Kyle mentioned that he wished the Screencast.com short URLs would stay short after the web page was accessed. He mentioned that a lot of users like to copy and paste the URL from the address bar and use it in tweets.

I spent a bit of time researching what we would have to change to fix this issue, and in a couple of days we had the changes implemented.

This change also brings about a nice speed improvement to the loading of pages on Screencast.com. Previously, when a piece of content was visited, the server would reply with an HTTP Status Code 302 - Found. This causes the browser to then load the page at the redirected location. This little bit of communication takes time, and with our new change we have removed this initial hurdle.

Here is a graphic showing the change in loading times:

With this improvement, we have increased the speed of viewing your Screencast.com content by 4.1% on average. If you are viewing your content from outside of North America, you can expect an even larger speedup.

Reduced page size

The second improvement that was added to Screencast.com was a new library layout. Much care has been taken to reduce the filesize of the webpages, to the point where loading up my library using the Library (beta) only uses 1/4 of the bytes yet sends more data. The Library (beta) also makes 11 less network requests than the current library. This means that your Screencast.com library is now more accessible under tighter network conditions such as 3G.

A response to “Comments: A Dissenting Opinion”

This past Thursday, our second post of the new Dev Corner was published and featured thoughts on code comments from Matt Mercieca.

The post is really well written and generated a lot of conversations within our internal development blog at TechSmith. Code comments are one of my bike-shed problems (I prefer green by the way), but I do feel inclined to respond.

Much of the post pits “how-comments” versus “why-comments”. I believe that it is well understood that “how-comments” are little cared for. For example, the comment in the following code offers no value to the reader:

//print out array
for(var i in objects) {
  document.write(objects[i]);
}

However, the “why-comments” is where the real discussion is. Respectfully, I stand on a different side of the fence when it comes to “why-comments”. I believe that what can be written as a comment can also be written as a function or variable name. Consider the following two code samples:

var printOrders1 = function()  {
  // this query is a hack due to weird SQL Server Query Optimizer bug
  var orders = sqlConnection.execute('SELECT TOP 1000 FROM tblOrders WHERE ...');
  print(orders);
};

var printOrders2 = function()  {
  var executeQueryForOrdersWithHackForQueryOptimizer = function () {
    return sqlConnection.execute('SELECT TOP 1000 FROM tblOrders WHERE ...');
  };
  var orders = executeQueryForOrdersWithHackForQueryOptimizer();
  print(orders);
}

I feel that the second version contains the same information as the first version, but will be read more often. As code gets duplicated (unfortunately), sometimes comments get stripped. It is less likely that a function like this will get renamed to a more innocent name.

Where do you stand?

Code Jam programming competition

I found out about the Google Code Jam programming competition this past week through Reddit and registered for it. It’s my first programming competition so I’m pretty excited to see how it turns out.

I’ve started to go through the practice problems listed on the site and completing them as though they are part of the competition. As I compete them, I’ll upload my solutions to the problem. Since these solutions are written in haste and I don’t plan on making the code maintainable, for your own benefit please don’t copy the code and use it in an actual production scenario.

The first problem that I have solved is the Alien Numbers problem from April, 2008.

The decimal numeral system is composed of ten digits, which we represent as “0123456789” (the digits in a system are written from lowest to highest). Imagine you have discovered an alien numeral system composed of some number of digits, which may or may not be the same as those used in decimal. For example, if the alien numeral system were represented as “oF8”, then the numbers one through ten would be (F, 8, Fo, FF, F8, 8o, 8F, 88, Foo, FoF). We would like to be able to work with numbers in arbitrary alien systems. More generally, we want to be able to convert an arbitrary number that’s written in one alien system into a second alien system.

See if you can solve this problem. Then continue reading to see my solution.