How setTimeout’s timer clamping works

This is a fantastic post on the blink-dev discussion list by Chrome dev James Robinson describing how setTimeout’s timer clamping works. James argues that setTimeout(fn, 0) behaves exactly as setImmediate(fn) would except in excessively-nested timers.

Nearly everything I’ve read starts off with an incorrect idea about how timer clamping works or why it’s in place.  The way timer clamping works [1] is every task has an associated timer nesting level.  If the task originates from a setTimeout() or setInterval() call, the nesting level is one greater than the nesting level of the task that invoked setTimeout() or the task of the most recent iteration of that setInterval(), otherwise it’s zero.  The 4ms clamp only applies once the nesting level is 4 or higher.  Timers set within the context of an event handler, animation callback, or a timer that isn’t deeply nested are not subject to the clamping.  This detail hasn’t been reflected in the HTML spec until recently (and there’s an off-by-one error in it right now), but has been true in WebKit/Blink since 2006 [2] and in Gecko since 2009 [3].  The practical effect of this is that setTimeout(…, x) means exactly what you think it would even for x in [0, 4) so long as the nesting level isn’t too high.

With a better understanding of timer clamping, let’s consider the possible use cases for scheduling asynchronous work.  One is to time work relative to display updates.  Obviously requestAnimationFrame() is the right API to use for animations, but it’s also the right choice for one-off uses.  To perform work immediately before the next display – for example to batch up graphical updates as data is streamed in off the network – just make a one-off requestAnimationFrame() call.  To perform work immediately -after- a display, just call setTimeout() from inside the requestAnimationFrame() handler.  The nesting level is zero within a rAF() callback so the timeout parameter will not be clamped to 4.

The difference between smart quote and apostrophe

Improper use of “smart quotes” (aka “slanty quotes”, “curly quotes”) came up in a code review. Get Smart with Smart Quotes was a great resource.  Here are some quick take-aways:

  • Smart quotes consist of an open and a closed version (also referred to as left and right quotes).
  • Don’t confuse apostrophe () with a single quotation mark ().
  • Contractions should use the apostrophe character.
  • There are named HTML entities for smart quotes: ‘ (‘) ’ (’) “ (“) ” (”)

contractions

 

Of small fonts, blink rates, and eye strain


eye strain
tl;dr:
A low blink rate can cause irritated eyes (“eye strain”). Small fonts, poor type contrast, and poor typography all contribute to low blink rates. Eye strain is not permanent.

Several people, after seeing the small fonts on my laptop (2560 x 1600 on a 13″ screen), have told me that I’m “hurting” or “damaging” my eyes my using such small type. I haven’t ever had eye strain symptoms and wasn’t sure whether to be worried.

First, and most importantly, eye strain doesn’t appear to be permanent.

“Despite popular belief, sitting too close to the television, or in this case the computer, won’t cause blindness or other permanent damage,” said Dr. Kimberly Yen, assistant professor of ophthalmology at BCM. “What it can do is cause eye strain symptoms.”

When eyes are focused on one item for a long period of time, whether it’s a computer screen, television or even a book, the blink rate slows. That could lead to eyes feeling dry or uncomfortable. Vision could even begin to blur or double. One common side effect of eye strain is headache.

source: Baylor College of Medicine

A great article at Eye Magazine (a graphic design magazine) breaks down specific stressful conditions:

  • reading small text sizes
  • reading low-contrast gray text
  • reading with a light source behind the reading material to cause glare
  • reading from too close a distance, which causes the eyes to point inward towards each other (convergence stress)
  • reading from variable focal distances (accommodative stress)
  • reading while wearing glasses that simulate an astigmatism (refractive stress)

Small text sizes, low contrast, glare and refractive stress all resulted in increased activity in the orbicularis oculi, while convergence stress and accommodative stress did not, though after reading in these two conditions, readers are more likely to report headaches and pain coming from behind the eye. Stressors such as small text size and glare are reported as irritation on the front of the eye.

Blink rate is a key factor in eye stress. Difficult-to-read text (e.g. small text) causes a lower blink rate.

Light grey text on a white background and small text size both lead to an increased orbicularis oculi activity and decreased blinking. These two conditions are related to text quality, and we would expect to find similar indicators of eye fatigue with poor font quality or condensed letter spacing. To reduce this type of eye strain, we need text of the highest possible quality.

…other studies found that we blink far more often under relaxed conditions than while reading: 22 blinks per minute while relaxed, versus ten blinks per minute while reading a book. A recent study at Pacific University illuminated why blinking is suppressed during reading. Tai and Sheedy found that the eye movement following a blink was far more likely to be a regressive or backward corrective eye movement than one that did not follow a blink.

I’ll be sticking with small fonts for now.  If I experience eye strain though, it’s good to know that cranking up the font size can offer some relief.

Essential JavaScript links

This is a continuously updated list of JavaScript articles and resources that I recommend to other Amazon developers.

Essential CSS links

This is a continuously updated list of CSS articles that I recommend to other Amazon developers.

Getting started with Ruby on Rails

These are some of the tutorials and guides I’ve found most helpful while picking up Ruby on Rails 3.

Ruby language:

Installing Rails on Windows:

Best “my first app” walk-through:

Using “remote” to ajaxify links and forms:

“Unobtrusive JS” library that ships with Rails 3:

Use Twitter Bootstrap with Rails:

iCatcher! podcatcher app for iOS – mini review

I recently found a new favorite podcatching app called iCatcher! (the exclamation is theirs, but I share their enthusiasm).  The selling points for me are:

  • over-the-air downloads aren’t subject to the 50MB iTunes Store OTA download limit
  • 30 second skip button for video (not just audio), and a 30 second rewind button
  • plays video in portrait orientation
  • a sleep timer
  • if you’re playing a video and you lock the device, the video’s audio will continue to play
  • play video files back at 2x speed (a feature that iTunes Mobile supports only for audio files)

I can’t express how excited I am about that last feature.  The app has been working as advertised so far – no crashes or bugs.  iCatcher is $2 in the App Store.

Get Chrome “Side Tabs” back (kind of)

Thousands of people, including myself, cried out in terror when Google removed the “Side Tabs” from Chrome. I tried for one month to settle into Firefox + Firebug + Tree Style Tabs as my main browser, but that combination is nowhere near is snappy as Chrome for my workload.

My workaround has been to use the most recent build of Chromium (Chrome’s open-source alter ego) that still contained the Side Tabs feature. Because there are no security updates available for this version, I use NoScript and whitelist scripting on sites as needed.

Chromium 15.0.862.0 – Windows: chrome-win32.zip, Mac: chrome-mac.zip

A major advantage of using Chromium instead of an old version of Chrome that has Side Tabs is that Chromium can be run side-by-side with the latest version of Chrome.