The Problem with Learning by Doing: DOM events

Sometimes you learn wrong.

I’ve built myself a little music player that loops sections of songs pretty much as long as one could want. I’m asking the user to pick a minimum duration from 0 seconds to 1 day. This creates an interesting UI problem: the user probably wants to pick something in the realm of 5 minutes, but 5 minutes is only 1 pixel away from 10 minutes on this scale. So I wrote a script that will get and set the value of a range input logarithmically, so that the left 1/3 covers 10 minutes, the middle 1/3 covers 5 hours, and the right 1/3 covers 1 day. This works great, and the user has fine control within each unit scale.

This creates a further problem, though: the user needs real-time feedback of how I’m converting their input. To do this, I used the change event, which I’ve been using since I was born into JavaScript. It worked like a charm.

Then 4 days ago, it broke. Chrome broke it by fixing this bug. The behavior described in the bug report (from 2012!) was the behavior I had come to accept as correct. Fixing this bug meant breaking my code, to conform to spec! I had no idea, because I learned this by using it, not by reading the spec.

Should I read the spec of every new tag in HTML5?

Yes.

I’ve learned a lot by doing, but especially in a distributed development field such as the web, the standards do need to be read. A lot of people have broken up the spec into shiny chunks that are easily digested. However, in this case, I can’t find a single mention of the expected behavior of the change event for [type=range]. The spec draft at W3.org describes the change event for inputs, generally, as firing “when the value is committed, if that makes sense for the control, or else when the control loses focus. In all cases, the input event comes before the corresponding change event (if any).”

I had never even heard of the input event. This is the event that I should have been using in the first place, since I’m reacting to someone’s input, not their decision (which would be the change event).

I will continue to learn by doing; I can’t help it, and I can’t do without it. But, the next time I’m aware that I’m doing something new, I’m going to jog over to W3.org to check that I’m leveraging stuff that’s going to be around for a while.

Christopher Lovejoy

The Problem with Learning by Doing: DOM events

Should I read the spec of every new tag in HTML5?

0 thoughts on “The Problem with Learning by Doing: DOM events”

Leave a Reply Cancel reply

works-in-progress, and the occasional hello