For example, id, class and attribute names should be in lowercase-with-dashes in HTML/CSS; JavaScript names should be in camelCase (better defined here); and anything in URLs (including file names) should be in lowercase not only because of conventions, but for cross-platform compatibility as well.

Please, avoid crazy shit like ab_someName and keep things consistent!

F.lux adjusts the color temperature of your screen to match your lighting and time of the day.

Measuring Javascript Parse and Load

While studies like this are fascinating to observe and to learn from, be very careful — unless you’re doing something like distributing JS libraries, these optimizations probably do not apply to you.

Keep in mind that the parse-and-load test runs 1000 iterations; in the first table, the actual average parse time is really only 0.125ms at worst and 0.003ms at best. Compare that to the average HTTP request — you might see sub-30ms responses just for a HTTP 304 on a good day, but 1000ms+ responses are not unheard of on unprimed caches (even more with DNS lookups). To put this into perspective, a snappy HTTP request at 30ms is more than 200 times slower than the slowest parse time of 0.125ms.

In other words, the net improvement you might gain from such parse-and-load optimizations is insignificant compared to the improvement from removing just one HTTP request.

So before you go adding more lines of code to accomplish yet another new trick, profile your code to see where the actual bottlenecks are. Otherwise, this smells like a lot like premature optimization.

Update: I’ve wrongly interpreted the results table and Carlos has corrected me. This means that the cost of script parsing and loading is significant, and optimizing this should help reduce CPU load which is hard to benchmark in real world conditions but could certainly be perceptible to users.

Note to self — Apache (stock on Leopard, which runs as _www) cannot read the preset directories in my home directory (like Desktop, Documents, Downloads, Library etc) because these directories only allow owner access by default (drwx------).

So that is why PHP won’t include files on my desktop. D’oh.

Ever wonder how the wheel group in /etc/group came to be?

“The guy who wrote the group functionality was both a buddhist and a Journey fan. He was listening to “Wheel in the Sky” while trying to figure out a way to give more people administrative rights without giving too much access. In a fit of enlightment, he came up with a special group for administrators. Since they were the ones who kept things turning, it only seemed appropriate that “wheel” be immortalized in the /etc/group file.”

Modern browsers for modern applications

“We’re also going to begin phasing out our support, starting with Google Docs and Google Sites. As a result you may find that from March 1 key functionality within these products — as well as new Docs and Sites features — won’t work properly in older browsers.”

A couple of choice quotes I found on “A message to the Internets regarding the iPad”:

“You can’t just ask customers what they want and then try to give that to them. By the time you get it built, they’ll want something new.”
— Steve Jobs

Subsequently spotted in the comments:

“If I had asked people what they wanted, they would have said faster horses.”
— Henry Ford

I’ve learned to prefer * and _ hacks over conditional comments to target IE for two reasons—users won’t need to make yet another HTTP request, and perhaps more importantly, code in one file is much easier to maintain than the same code in two or more files (DRY).

Recently, it occurred to me that this can also be used as a more granular way to target IE instead of browser sniffing. Similar to testing for the existence of a JS property/method before using it, I can basically check if a certain CSS rule value is supported. Note that this is different from checking CSS rules like -moz-border-radius, which can be directly accomplished in JS.

For example, IE6 does not support position: fixed, but other property values like absolute and relative are fine. So if I want to run some JS code only in IE6 to emulate fixed positioning (lots of existing workarounds use CSS expressions which I’d rather avoid), I can do the following:

#foo {
    position: fixed;
    _position: absolute;
}

var isPositionFixed = (fooEl.style.position == 'fixed');
if (!isPositionFixed) {
    // Special sauce for IE6
}

Here, isPositionFixed will always evaluate to false in IE6 since all other browser will ignore it, which I think is much more reliable and cleaner than user agent sniffing. Admittedly, this does blur the line between presentation and behavior, but it is not a terrible compromise that I’m willing to take.

Till shitty browsers drop off the face of the planet, here’s yet another hack to live with.

Given a date format like “Thursday, January 21, 2010” and limited space to drop in this string on a page, what is the maximum width of this string as rendered in Georgia or Helvetica/Arial?

Longest day of the week: Wednesday
Longest day of the month: 22–30 (30 is a hair wider in Georgia)
Longest month of the year: September
Longest years: 2002–2009, 2020 (Yay for a “short” next decade?)

Therefore, the hypothetical longest date string is “Wednesday, September 30, 2009”. Then I discovered that September 30, 2009 is actually a Wednesday. Neat.