LWS March: JavaScript – The events that get left behind & Pro-bunfighting (live blog)

by Jeff Van Campen. 1 Comment

Warning: This is a live blog post.  I’ll be typing as it happens.  Expect typos, mistakes and my own distinctive interpretation of the night’s events.


Frances Berriman will be discussing testing, and group hugs.

She works on the BBC Glow JavaScript Library, which is Open Source.

Small team, with various issues.


3 people on the team. 2/3rds live in london.

Quite a lot for the three of them to do, but not a lot of face-to-face time.

Problem 1: Communicating what to make

Miscommunication is the source of most project woes. Issues arise when a specification has been misunderstood. Someone does work, but the response is, “That’s nice, but it’s not what I wanted.”

Need to communicate accurately over email.

The unwrap() method

People skim prose.

All communication of requirements is done in code in JSDoc.

Empty source files are created in their repository with JSDoc, then they commit them. Makes it easier to follow than email.

The bun-fight

Locking themselves in a room and have a fight. Go through the docs line-by-line.

Everyone has to read it. Everyone has to understand it.

Bits get removed. Bits that aren’t really needed, so no one wastes time coding it.

Then someone goes away and codes it.

Because they are using JSDoc, they get free documentation.

Problem 2: Checking what we’ve made actually works

Unit testing. The first thing you should think about doing is turing examples from you docs into unit tests.

They use Qunit. setup and teardown are really useful, but don’t seem to be documented.

Sanity checking & code reviews

Notorious at the BBC. Some people may have cried.

Somebody stands over you shoulder and tells you what is wrong.

They make sure it doesn’t read like a W3C standard because nobody can read a W3C standards.

Also check punctuation and make sure it’s understandable by an external user.

Conflict resolution

We fall out, and there is no resolution.

But debate is good. No one holds a grudge.

Problem 3: checking what we’ve made is fast

How do we know what is we made is fast? We benchmark in Woosh.

Live demo of Woosh, comparing Glow to other libraries.

The headlines

  • Treat writing documentation like writing code
  • There’s no such thing as too many unit tests
  • Benchmark regularly if you want to go fast

Events left behind

Jake Archibald

Used Photoshop CS5 content fill to generate his notes.

He likes cycling. He doesn’t do it too often, but when he does it he thinks, I should do that more often. And he notices improvements, i.e. disk brakes are better than whatever went before. One thing hasn’t changed — the chain & gear system still clunks and breaks. Browser events are the chains and gears of the JavaScript world.

Making an application work off of the keyboard is more complicated than you’d think it was.

We need to be abele to be able to track more than one event (polyphony).

Key actions. Key repeating – this differs between operating systems and depending on user settings.

Key actions are monophonic.

Mouse events are pretty well documented in the W3C DOM 2 specs.

What about keyboard events? No a lot.

What do the browsers do?

keypress – The exceptions in Internet Explorer and Webkit actually make more sense. Only keys that generate characters generate a keypress event. Exceptions are more random in Opera and Firefox.

Should keydown really repeat?

Is there a way we can normalise the event order?

The plan for for Glow 2:

  • Event order is keydown, keypress, keyup
  • keypress is the only event that repeats
  • keypress always fires
  • (missed it)

Problem with fixin keypress: it isn’t always fired. We need to fake a keypress event when needed. Need to decide this. And to do this, we need browser detection. 🙁

Keycodes on various television remotes aren’t the same. There’s no spec to tell them what the keycodes should be.

Opera doesn’t distinguish number pad number keys from other number keys, so this behaviour is repeated in Glow (lowest common denominator).

Great photo of the messy cupboard in the search to find an American keyboard.

Unfortunate closeup of a keyboard found in the messy cupboard.

keys x keyboards x browsers x operating systems = Archibald’s constant of misery

The good news: Erm, no good news, but there will be soon. DOM Level 3 Events covers keyboard events in detail (though the spec is volatile).

IE uses key instead of keyIdentifier and location instead of keyLocation.

Wrapping up:

  • Keyboard events are awful
  • They’re going to get less awful

Leave a Reply

Your email address will not be published. Required fields are marked *


HTML tags are not allowed.