frontendstuff

From 31st of March until 17th of April I’ll be once again touring the US. I’ll start and end with conferences, but I’m not quite sure yet what I’m going to do in between and I’m looking for suggestions.

I’ll arrive in Seattle for An Event Apart, on 2 and 3 April, where I’ll pontificate on the touch events and how they’re not the same as mouse events. It’s been a while since I’ve been exposed to so much Apartness, and it’ll be a nice start of my tour.

My tour will end in Orlando on 16 and 17 April, where I’ll speak at the third Breaking Development conference, Mobilism’s American sister conference. The good Breaking Developers have given me the code ORPPK12 for a $100 discount on tickets, and if you register before end of next week you’ll save another $200. Not a bad discount for a top-notch conference.

That leaves me with almost two weeks in-between conferences. I’m fairly certain I’ll be in Toronto on the 10th, and I plan to visit San Francisco and the Valley at some time (duh), but other than that my itinerary is still unclear.

If you’d like me to swing past your city, let me know. Unfortunately I’m not super-wealthy, so I do expect you to pick up my hotel bill, as well as help me out a bit with domestic flights.

Last year I ended up going to San José, Austin, New York, and Albany. I have no idea what this year will bring, but that’s what makes this kind of touring so exciting.

Anyway, I’ll post an update when I have more news.

I have retested the support for the new input types (<input type="number"> and such) in the desktop and mobile browsers.

All in all support has increased slightly since the last time I tested them, although Safari desktop, Chrome, and BlackBerry have seen some decline. Safari and Chrome have mainly done away with badly or buggily implemented types — it’s clear they’re rewriting significant parts of this module.

As to BlackBerry, its decline was a nasty shock to me. Previously it vied with Opera for Best Implementation, but the PlayBook 2 default browser has dropped support for quite a few types and attributes, such as required and pattern.

Quiz

To understand how complicated these new features can be, consider the following quiz question:

I add an <input type="number" step="3"> to the page, and the user enters 11. What should the browser do?

You can try it for yourself at the test page. Don’t forget to submit the form. My Twitter followers gave they following replies:

step poll outcome

Answer	Number	Browser support
The browser rejects the 11	17*	IE, Chrome, Opera
The browser automagically rounds it to the closest proper value, 12	13	none
The browser shows an error message	9	none
The browser submits 11 to the server	8	Safari
The number 11 should be impossible to enter	3	none
The browser accepts the value if the min attribute is absent	2	Safari, sort of
Mathematics should be changed so that 11/3 is an integer	1	none

* This total includes the votes for an error message.

So the desired outcome is unclear. The browsers’ behaviours have been documented on the desktop page.

Purpose

A quick repeat of the underlying purpose of the input types seems in order. In the end, the idea is to not send incorrect values to the server. Thus we can see three purposes:

1. The browser could perform a validation and show an error message and refuse to submit the form when an incorrect value is found.
2. The browser could also restrict the accepted input — for instance by not allowing letters in an <input type="number">.
3. Finally, the browser could also give the user a nice interface — for instance the various date pickers in Opera, BlackBerry, and Safari iOS.

The last purpose is a nice extra. If the browser offers an interface but doesn’t support either validation or input restriction, I judge its support Minimal. It misses the actual point, after all.

Findings

With that said, my findings were the following:

• readonly is still the only universally supported attribute or type.
• IE10’s support is decent, though not great.
• Opera and BlackBerry added support for color.
• Firefox on desktop has added datalists, but its interface is an autosuggest, and not a complete list of options, as IE and Opera show.
• Firefox Mobile, however, has a very nice interface (see screenshot) that I hope other mobile browsers will pick up.
• Firefox Mobile does not show any error messages, though, while Firefox desktop does.
• Chrome dropped support for the date types. That’s curious, because Chrome 10 supported them reasonably well. I can only assume a major re-factoring is going on.
• Safari desktop dropped support for dates, datalist, email, and url. Since they were hideously buggy previously, this makes sense. I assume they’ll reappear.
• Safari on iOS added support for dates, numbers, and ranges. The interface for the range slider is a bit confusing, though.
• Android 3.2, MeeGo and UC support autofocus, but they cleverly don’t pop up the software keyboard, which would be very annoying. As far as I’m concerned this should become a mobile standard.
• Still, poor Android can’t do anything right. Android 3.2 tried to add support for number and range, but the range slider is invisible, while the number type restricts user input only to actual numbers. No negative numbers; no exponents.
• And then BlackBerry, which in my previous round of testing was the best browser. The PlayBook 2 default browser dropped support for required, pattern, email, url, step, and month (though not the other date types). The old BlackBerry Torch (OS6) supported them all fine. I’m not sure what’s going on here, and I hope the PB 2 final version will restore these types.

We’ve already had a glimpse at Server-Sent Events (also known as EventSource^†, and I’ll switch between the two to keep you on your toes) in my Methods of Communication article from last year. In this article, I want to delve in to more detail about the SSE API, demonstrate its features, and even show you how to polyfill browsers that lack EventSource support.

Server-Sent Events are real-time events emitted by the server and received by the browser. They’re similar to WebSockets in that they happen in real time, but they’re very much a one-way communication method from the server.

These events are similar to ordinary JavaScript events that occur in the browser — like click events — except we can control the name of the event and the data associated with it.

All the code for this article is available on github, and a live demo is available online.

† Is it Server-Sent Events or EventSource? Well, they both work. Server-Sent Events is the name of the API and specification. EventSource is the name of the JavaScript object you’re instantiating. It’s a bit like Ajax and XHR, where XHR refers to the XMLHttpRequest object…kinda.

Two notes: a) the uptime for this example is, I’m afraid, usually rather low — good for my server, bad for you. If you test the demo locally it will give you more interesting figures. b) IE6 isn’t supported in any of this article.

Possible Applications #

A few simple examples of applications that could make use of Server-Sent Events:

• A real-time chart of streaming stock prices
• Real-time news coverage of an important event (posting links, tweets, and images)
• A live Twitter wall fed by Twitter’s streaming API
• A monitor for server statistics like uptime, health, and running processes

We’ll use the server monitor for this article’s examples. If this application were to be used in the wild, we could also check the EventSource‘s connection state to indicate when there’s a potential problem connecting to the server.

Overview of the API #

The client-side API is rather simple, and it hands-down beats the insane hacks required to get real-time events to the browser back in the bad old days.

The main points of interest:

• new EventSource(url) — this creates our EventSource object, which immediately starts listening for events on the given URL.
• readyState — as with XHR, we have a readyState for the EventSource that tells us if we’re connecting (0), open (1), or closed (2).
• onopen, onmessage — two events that we can listen for on the new EventSource object. By default, the message event will fire when new messages are received, unless the server explicitly sets the event type.
• addEventListener — not only can we listen for the default message event, but we can also listen for custom messages using the addEventListener on the EventSource object, just as if we were listening for a click event.
• event.data — as with most messaging APIs, the contents of the message reside in the data property of the event object. This is a string, so if we want to pass around an object, we need to encode and decode it with JSON.
• close — closes the connection from the client side.

In the future, EventSource will also support CORS using an options argument to the EventSource object: { withCredentials: true }. But at the time of writing, no stable release includes this property.

Simple Example #

Our simple web app will notify us of server status messages — things like the load average, number of currently connected users, and most CPU-intensive processes. If I were using this application in anger, I’d probably build server modules that emit specific event types when they cross specific thresholds, so that I’m only notified when something gets to warning level.

This snippet of JavaScript connects to our server, listens for messages, and handles the data that comes with the messages:

var source = new EventSource('/stats');
source.onopen = function () {
  connectionOpen(true);
};

source.onerror = function () {
  connectionOpen(false);
};

source.addEventListener('connections', updateConnections, false);
source.addEventListener('requests', updateRequests, false);
source.addEventListener('uptime', updateUptime, false);

source.onmessage = function (event) {
  // a message without a type was fired
};

Properties of Server-Sent Events #

Server-Sent Events are more than just a one-way web socket. They have some unique features:

• The connection stream is from the server and read-only. This suits lots of applications, some examples of which I listed above.
• They use regular HTTP requests for the persistent connection, not a special protocol, which means we can polyfill using vanilla JavaScript.
• If the connection drops, the EventSource fires an error event and automatically tries to reconnect. The server can also control the timeout before the client tries to reconnect.
• Clients can send a unique ID with messages. When a client tries to reconnect after a dropped connection, it will send the last known ID. Then the server can see that the client missed n messages and send the backlog of missed messages on reconnect.

Message Format #

A simple message doesn’t require much:

data: this is a simple message
<blank line>

Note that the end of a message is indicated by a blank line (obviously not the literal characters <blank line>).

For a message with multiple lines:

data: this is line one
data: and this is line two

You can send message IDs to be used if the connection is dropped:

id: 33
data: this is line one
data: this is line two

You can even send multiple messages in a single response so long as you separate the messages by blank lines:

id: 34
data: Remy is awesome

id: 35
data: Bruce is stinky

And you can specify your own event types (the above messages will all trigger the message event):

id: 36
event: price
data: 103.34

id: 37
event: news
data: Bruce sells his collection of replica bananas

You don’t have to worry about this structure on the client side. It only applies to the server, which I’ll touch on next.

Typical Server #

I’m not going to give a full walkthrough of the server-side code, since this is an HTML5 web site But there are a few important and simple features that you need to know to build the server (you’ll need this part anyway if you’re going to use EventSource).

I’ve included all the files for this demo on GitHub for you to peruse at your own leisure, and I’ve also deployed a live example of this code.

Ideally, you should use a server that has an event loop. This means you should not use Apache, but instead use a platform such as Node.js (which I’ve used) or Twisted for Python.

Key properties:

1. You can only accept EventSource requests if the HTTP request says it can accept the event-stream MIME type.
2. You need to maintain a list of all the connected users in order to emit new events.
3. You should listen for dropped connections and remove them from the list of connected users.
4. You should optionally maintain a history of messages so that reconnecting clients can catch up on missed messages.

Here’s a sample of my Node.js based server. It’s using Connect (a simple webby framework for Node). When it receives a request for /stats, it calls the following function. I’ve commented the code so you can follow along:

function stats(request, response) {
  // only response to an event-stream if the request 
  // actually accepts an event-stream
  if (request.headers.accept == 'text/event-stream') {

    // send the header to tell the client that we're going
    // to be streaming content down the connection
    response.writeHead(200, {
      'content-type': 'text/event-stream',
      'cache-control': 'no-cache',
      'connection': 'keep-alive'
    });

    // support the polyfill - we'll come on to this later
    if (request.headers['x-requested-with'] == 'XMLHttpRequest') {
      response.xhr = null;
    }

    // if there was a lastEventId sent in the header, send
    // the history of messages we've already stored up
    if (request.headers['last-event-id']) {
      var id = parseInt(request.headers['last-event-id']);
      for (var i = 0; i < history.length; i++) {
        if (history[i].id >= id) {
          sendSSE(response, history[i].id, history[i].event, history[i].message);
        }
      }
    } else {
      // if the client didn't send a lastEventId, it's the
      // first time they've come to our service, so send an
      // initial empty message with no id - this will reset
      // their id counter too.
      response.write('idnn');
    }

    // cache their connection - the response is where we write
    // to send messages
    connections.push(response);

    // send a broadcast message to all connected clients with
    // the total number of connections we have.
    broadcast('connections', connections.length);

    // if the connection closes to the client, remove them
    // from the connections array.
    request.on('close', function () {
      removeConnection(response);
    });
  } else {
    // if the client doesn't accept event-stream mime type,
    // send them the regular index.html page - you could do
    // anything here, including sending the client an error.
    response.writeHead(302, { location: "/index.html" });
    response.end();
  }
}

The important trick on the server is to ensure you don’t close the connection to the EventSource object. If you do, it will of course handle the closed connection, fire an error event, and try to reconnect. So you’ll just want to maintain the persistent connection.

Polyfills and Tweaks to the Server #

There are two good polyfills I know of, and though I prefer the one I wrote, I’ll still lay them both out for you.

Yaffle’s Polyfill #

The first is one by Yaffle (on github), available on github/Yaffle/eventsource.

The cons:

• It doesn’t send the accepts header, and
• It completely replaces the EventSource object, so even if your browser supports EventSource natively, this script will replace it. But there’s a good reason for that.

The pros:

• It maintains a persistent connection (whereas the one we’re using doesn’t), and
• More interestingly, it supports CORS (which I imagine is why it replaces the native EventSource).

These two pros are quite compelling. But when I was testing, I couldn’t get it working in IE7 (which was my minimum browser target), so that might be a blocker for you…or not.

Remy’s Polyfill #

The second is my own, available on github.com/remy/polyfills.

The cons:

• It uses polling, so once a small group of messages come down, it re-establishes the connection, which could lead to significant overhead (though less so on a Node-based server). You have to add about 4 extra lines to your server code.

The pros:

• It doesn’t replace the native EventSource object (but that also implies that, for now, it won’t support CORS), and
• It supports IE7.

Retrospectively, I might choose Yaffle’s polyfill over mine in the future if I wasn’t bothered about IE7 support.

Using the Polyfill #

By including the EventSource.js JavaScript library before my client-side code, I just need a couple of small changes to my server-side code. Other than that, everything on the client side works without any changes (as a polyfill should work).

When posting the server’s reply to the client, instead of keeping the connection open, I include the following in my server when it’s finished writing the response:

// send the data (event type, id, message, etc)
response.write(data);

// if our response contains our custom xhr property, then...
if (response.hasOwnProperty('xhr')) {
  // clear any previous timers using the xhr prop as the value
  clearTimeout(response.xhr);

  // now set a timer for 1/4 second (abritrary number) that
  // then closes the connection and removes itself from the
  // connection array.
  // The delay is in place so that a burst of messages can 
  // go out on the same connection *before* it's closed.
  response.xhr = setTimeout(function () {
    response.end();
    removeConnection(response);
  }, 250);
}

Bugs? #

The error event should always fire when the readyState changes, assuming you didn’t explicitly call the close method. This works nearly all the time, but in writing this article, I found a few edge cases where it doesn’t fire. In Chrome, if I put my machine to sleep and then woke it back up, it would close the connection but not fire the event, therefore never triggering a reconnection. As I said, this is an edge case and I’ll file a bug against it, so I don’t expect it to hang around for long.

Why Not Use WebSockets? #

There are two reasons I’d advocate using EventSource over WebSockets, as they’re currently the two contenders for sending real-time events to the browser.

The first is that EventSource (as we saw earlier) works over regular HTTP and can therefore be replicated entirely using JavaScript if it’s not available natively. That means that we can polyfill browsers without support, like IE9.

The second is probably more important: you should always use the right technology for the job. If your real-time data is sourced from your web site, and the user doesn’t interact in real-time, it’s likely you need Server-Sent Events.

I recently saw a cool demo of snowflakes drifting down a web site. Each snowflake is a tweet based around the Christmas theme — like if someone mentions a particular Christmas-y term, it’s sucked in to the snowflake. Don’t get me wrong, I know this is a demo, and it’s very cool (if you wrote it, this is me sending you hugs), but it’s based on WebSockets. I’d suggest this demo should be based on EventSource since all the data is read-only and the user doesn’t interact with it at all.

The point: evaluate the technology against your problem, and aim to get good fit.

Server-Sent Events originally appeared on HTML5 Doctor on January 24, 2012.

On 10th and 11th of May the second edition of Mobilism will take place in Amsterdam. Like last year, it will concentrate on all aspects of the mobile web. For an idea what we’re going to do, see last year’s coverage, or watch Stephanie Rieger’s session.

For this edition we’re happy to welcome Lyza Danger Gardner, who started as a web developer and moved to mobile back in 2007, co-founding Cloud Four with Jason Grigsby, who’ll also speak at Mobilism.

Take a look at the programme page yourself: our line-up is progressing quite nicely; thanks so much. And we’ll also get a Fast Track with some quite interesting speakers, a mobile browser panel with Jeremy Keith, and no less than Mr. Responsive Design Ethan Marcotte will take us to the next level of responsiveness (and designiness).

And it’s in May in Amsterdam, when the city is at its most beautiful. So what’s not to like? Buy your ticket now!

The pixel has long been the atomic particle of screen based design: a knowable, concrete unit of measurement. But layouts based on the hardware pixel are fast becoming an endangered species. Even the introduction of a new, W3C standard reference pixel, although it promises stability in the long-term, can't help us navigate the current chaos. Consider the two "standard" pixel definitions and 500 "standard" viewports your user's Android device may support. To create designs that transcend platform differences—the promise of the web and standards—you must normalize pixels across devices. Scott Kellum shows how math and media queries can keep you sane and help you design consistently across platforms.

Bootstrap is an open-source front-end toolkit created to help designers and developers quickly and efficiently build great stuff online. Its goal is to provide a refined, well-documented, and extensive library of flexible design components created with HTML, CSS, and JavaScript for others to build and innovate on. Today, it has grown to include dozens of components and has become the most popular project on GitHub, with more than 13,000 watchers and 2,000 forks. Mark Otto, the co-creator of Bootstrap, sheds light on how and why Bootstrap was made, the processes used to create it, and how it has grown as a design system.

Design is on a roll. Client services are experiencing a major uptick in demand, seasoned design professionals are abandoning client work in favor of entrepreneurship, and designer-co-founded startups such as Kickstarter and Airbnb are taking center stage. It’s becoming increasingly difficult to ignore the fact that design has a massive role to play in the evolution of the web and the next generation of web products. The result, says Cameron Koczon, is that designers have now been given a blank check—one that lets web designers band together as a community to change the way design is perceived; change the way products are built; and quite possibly change the world.

In December I held a QuirksMode reader survey on Urtak. It had 69 questions, and about 55,000 answers were given by about 1,100 respondents. Here’s a partial summary of the findings.

About one quarter of the total number of questions was submitted by readers — and some of them are very interesting ones. Even better, I had to reject only a quarter or so of the submitted reader questions. So the collaborative aspect of Urtak is a resounding success.

This entry gives some information about the respondents themselves, about how they deal with IE6 and 7, and whether and how they test mobile and tablet devices.

Urtak allows you to create cross-tabs of two questions (and no more than two). For this entry my primary interest was to see whether my European and US respondents differed.

There’s one restriction on the cross-tabs: at least 100 people must have replied Yes to the first question in order to get a more-or-less representative response.

Incidentally, you can create cross-tabs yourself at the site. Play with the data if you feel like it.

About you

Here are the findings about you. The most interesting one is your gender: 95% of you is male. Weirdly 98% of my European respondents is male, against only 86% of my US respondents. That’s a large gap.

Overall, slightly more than one-third of the respondents works as a freelancer, and slightly more than one-third in a medium- to large-size web company. I assume the others work either in companies of 2-4 people. or in the web department of a non-website company.

Nearly half uses Chrome as their default browser (this fits the browser stat data from my site, though the fit is not perfect). About three out of four have their own, private projects next to their jobs. Four out of five consider themselves autodidact.

Differences between Europe and the US: Chrome is used more in the US, US respondents are more likely to have five years of experience under their belt, but Europeans are more likely to be autodidact.

About you

Question	All	Europe	US
Do you live in Europe?	58%	-	-
Do you live in the US?	30%	-	-
Are you male?	95%	98%	86%
Do you consider yourself autodidact in web development and/or design?	82%	83%	78%
Have you been working as a web developer for over five years?	74%	72%	83%
Is your primary browser Chrome?	49%	45%	54%
Do you work as a freelancer?	36%	36%	34%
Do you have your own site/project that you run independently of your primary job?	73%	74%	73%
Do you visit web design or development conferences?	49%	52%	49%
Do you work in a company whose core business is the creation of websites for others and that has at least 5 employees?	38%	37%	38%
Are you a member of Fronteers?	4%	7%	1%

About IE6 and IE7

How many of you still care for IE6 and IE7? Six out of ten of you still test your sites in IE6 and IE7, and about half of you charge your clients extra if you must support these browsers.

However, less than one out of five of you report that IE6 and IE7 together account for at least 1/3 of the traffic to your sites. This percentage is much lower among people who charge their clients extra.

Europeans are more likely to refuse to make their sites work with these older browsers.

About IE6 and IE7

Question	All	Europe	US	Charge
Do you charge your clients extra for making their sites work in IE6 and IE7?	52%	53%	50%	-
Do you test your sites in IE6 and IE7?	61%	63%	62%	60%
Do you purposefully make your web site _not_ work on IE6 or IE7?	18%	20%	12%	27%
Do IE6 and IE7 together account for at least 1/3 of the traffic to your sites?	17%	13%	21%	8%

About testing on mobile phones

Then we come to the questions that interest me most personally: on what kind of mobile phones and tablets do you test? I split up the replies according to geography, but also among iPhone- and Android users.

In general Europe has slightly fewer iPhone users than the US, but slightly more Android users.

Very generally speaking iPhone users are more attuned to the mobile Web, although in most cases the difference is slight. Only when it comes to testing on two different Android devices do Android users significantly outpace iPhone users — perhaps not surprisingly. Also, Android users use WAY more QR tags than others (23% vs 11% for iPhone).

iPhone users have more experience with Windows Phone 7 and the BlackBerry PlayBook. For some reason this surprised me, but it’s clear now that, at least among my readers, iPhone users are more mobile-savvy than Android users.

The difference between Europeans and Americans is larger. In general, Americans are more of the opinion that only iOS and Android will remain important (56% vs 42% in Europe), care less about testing OSs that are neither iOS nor Android (18% vs 28% in Europe), and test less in Opera Mini (14% vs 25% in Europe). Still, Americans test their sites more on mobile/tablet devices in general (77% vs 72% in Europe) and use more jQuery Mobile (17% vs 12% in Europe).

In any case it’s clear that geography is more important than OS preference for deciding what to test on. This makes sense — the European and US mobile browser market shares are quite different.

About testing on mobile phones

Question	All	Europe	US	iPhone	Android
Is your primary phone an iPhone?	42%	41%	49%	-	-
Is your primary phone an Android?	35%	37%	33%	-	-
Do you think that of the myriad mobile OSs, only iPhone and Android will remain important?	47%	42%	56%	51%	50%
Do you test your sites on at least two tablets?	17%	16%	18%	22%	16%
Do you test your sites on at least two mobile phones? (Not tablets, phones)	48%	51%	46%	55%	52%
Do you test your sites on a tablet or mobile device that runs neither iOS nor Android?	25%	28%	18%	24%	22%
Have you done any site testing on Windows Phone 7?	15%	16%	13%	18%	12%
Have you tested your site on the BlackBerry PlayBook?	5%	4%	5%	9%	3%
Do you hope that WebKit will become the only rendering engine, and that the others will gradually disappear?	32%	28%	36%	39%	27%
Do you set up different landscape and portrait layouts for your mobile web sites?	30%	31%	27%	35%	28%
Do you test on at least two Android devices from different vendors?	21%	20%	21%	18%	33%
Do you test your sites in Opera Mini?	21%	25%	14%	19%	25%
Do you test your sites on any device that's not a classic desktop or laptop?	72%	72%	77%	82%	70%
Have you used PhoneGap, WebWorks, Titanium or any other HTML5 wrapper to create native mobile/tablet apps?	21%	21%	22%	26%	21%
Do you publish QR Code tags as quick links to your App / Site?	16%	16%	15%	11%	23%
Do you use jQuery Mobile to develop mobile websites?	17%	12%	17%	19%	16%
Do you practice the "mobile first" philosophy when approaching a new web project?	25%	-	-	-	-

The Mobile First question came in late in the survey and too few people answered Yes, so I will not publish the cross-tabs.

To be continued

There are plenty more fun facts to be gleaned from the reader survey. In a future post I’ll give some more numbers and cross-tabs.

Shim was developed within the Boston Globe’s media lab as a way to study how Web sites look on various devices and browsers. A laptop intercepts all wifi traffic – this is redirected to a custom node.js server – which inserts a javascript, or “shim,” at the head of each web page that is visited.

The shim, once loaded in a device’s browser, opens and maintains a socket connection to the server, according to to Shim’s developers. Shim was written in 2011 by Chris Marstall, Creative Technologist at the Boston Globe. The software has been open sourced. Write the Shim originators on git.hub:

Whenever a new page is requested, the page’s URL is broadcast to all connected browsers, which then redirect themselves to that URL, keeping all devices in sync. Shim info is available on git.hub.

For some time now, we’ve been using various technologies to edit and store text within a web browser. Now with the contenteditable attribute, things have got a whole lot easier. In this article, I’ll tell you what this attribute is for, how it works, and how we can take things further.

The Basics #

First, let’s check out the spec:

The contenteditable attribute is an enumerated attribute whose keywords are the empty string, true, and false. The empty string and the true keyword map to the true state. The false keyword maps to the false state. In addition, there is a third state, the inherit state, which is the missing value default (and the invalid value default).

— WHATWG

The contenteditable attribute was mainly intended for providing an in-browser rich-text or WYSIWYG experience. You’ve likely seen this sort of thing in blog-based authoring tools like Symphony or sites like Flickr where you can begin editing page content simply by clicking in a given area.

As mentioned above, contenteditable has three possible states:

contenteditable="" or contenteditable="true"

Indicates that the element is editable.

contenteditable="false"

Indicates that the element is not editable.

contenteditable="inherit"

Indicates that the element is editable if its immediate parent element is editable. This is the default value.

When you add contenteditable to an element, the browser will make that element editable. In addition, any children of that element will also become editable unless the child elements are explicitly contenteditable="false".

Code Example #

Here’s some example code to get us started:

<div id="example-one" contenteditable="true">
<style scoped>
  #example-one { margin-bottom: 10px; }
  [contenteditable="true"] { padding: 10px; outline: 2px dashed #CCC; }
  [contenteditable="true"]:hover { outline: 2px dashed #0090D2; }
</style>
<p>Everything contained within this div is editable in browsers that support <code>HTML5</code>. Go on, give it a try: click it and start typing.</p>
</div>
    

Putting it together

Live examples #

Here are two basic-but-live examples showing what you can do with contenteditable.

Example One #

I’ve used CSS to create an obvious visual cue that this area of text is different from the rest. Note that I’ve future-proofed this with <style scoped>, which I covered in my previous article.

Example Two #

Chris Coyier of CSS-Tricks pointed out that you can let your users edit the CSS in real-time. Because the <style> element is set to display: none by the user agent, we need to set it to block for this code to work.

Try editing the CSS below:

Browser Support #

Browser support for contenteditable is surprisingly good:

Browser Support for contenteditable

Browser	Version
Chrome	4.0+
Safari	3.1+
Mobile Safari	5.0+
Firefox	3.5+
Opera	9.0+
Opera Mini/Mobile	N/A
Internet Explorer	5.5+
Android	3.0+

We have to give credit where it’s due and point out that Internet Explorer has supported this attribute since IE5.5. In fact, a very early iteration of contenteditable was designed and implemented by Microsoft in July 2000.

For a more in-depth compatibility table, visit When Can I Use….

Storing the Changes #

For this section, I went straight to Doctor Remy for help, as he is much more knowledgeable than me when it comes to storing your data everything.

Depending on the complexity of your editable block, your code could be listening for the enter key (keyCode 13) to save the changes, and the escape key (keyCode 27) to undo the changes.

When the user hits enter (assuming it’s a single line of editable content), it would grab the innerHTML of the editable field and send an Ajax post to your server with the change.

A simple example of this can be seen on JS Bin: contenteditable saving to Ajax

— Remy Sharp

Conclusion #

We’ve repeated the phrase “paving the cowpaths” all over this site, and I’m mentioning it again with the introduction of the contenteditable attribute. The spec finally makes official something that’s been implemented by browser makers for years.

Although this is one of the lesser-known new attributes, I bet you’ll find yourself using it more often than you would think.

Imagine being able to simply click a block of content and start making changes instantly: making quick corrections to an article in-place, allowing users to edit their comments, or even building spreadsheets within company applications that aren’t hooked up to any sort of back-end user interface.

If you can think of other uses for this attribute, then head on down to the comments section and tell us where else you think this could be implemented.

Related Reading #

• What is contenteditable?
• Expanding Images Using HTML5’s contenteditable

The contenteditable attribute originally appeared on HTML5 Doctor on January 10, 2012.

I’ve been thinking a lot about device classes recently, and decided on a provisional four-class scheme. I have no idea if the scheme is going to survive, but we have to at least try to order the bewildering variety of devices somewhat.

While I was at it I also gathered data from StatCounter about the browsing shares of these device classes.

Your donation for keeping this research up and running would be much appreciated.

The four device classes are:

• Desktop: traditional computers with a hardware keyboard and a non-touch screen. This includes laptops.
• Mobile: devices that fit in your pocket and have mobile connectivity.
• Tablet: devices that do not (easily) fit in your pocket and have a touchscreen but no hardware keyboard.
• Other: other devices. I admit that this is a bit of a cop-out. Right now it consists of the iPod Touch and Internet-enabled PlayStation and Nintendo devices. None of these fall in any of the other categories.

These four categories fall into three markets:

1. Mobile market: mobile. These devices are bought for their mobile connectivity. Devices on this market are subsidised by the mobile operators. Everybody needs a mobile device, even if they’re not interested in other kinds of devices or already own several of them.
2. Computing device market: desktop and tablet. These devices are bought for productivity and/or media consumption. It’s clear that tablets are becoming competitors to desktop computers. One purpose of this new line of research is figuring out how rapidly tablets are going to replace desktops for browsing purposes.
3. Other markets: other. These are devices that are bought primarily for a goal other than productivity or mobile connections. Examples include gaming consoles or music players. (OK, OK, this remains vague. People can easily buy both a gaming console and a music player.)

In general people buy a mobile device first, then a computing device, then one or more other devices. In the developing world, that usually means people only have a mobile device. Hence the immense change in browsing we’re witnessing.

The stats

With that said, here are the general browsing stats. I use hundredths of percentage points here because some shares are very low. I don’t really like doing that, because it suggests a precisions that StatCounter’s figures do not have, and I’m going to change my methodology later on.

Interestingly, it turns out that the growth of mobile browsing has collapsed in Q4. Where earlier mobile browsing grew with over a percentage point per quarter, in Q4 it grew very little. Let’s see if this is a trend or an outlier before we comment on it.

As to tablets, its rate of growth is itself growing. That’s nothing surprising: the tablet market is growing vigorously, and that is reflected in its browsing shares.

Quarterly market shares of the four device classes

Device class	Q4	ch	Q3	ch	Q2	ch	Q1
Desktop	91.35%	-0.61	91.96%	-1.46	93.42%	-1.51	94.93%
Mobile	6.82%	+0.18	6.64%	+1.14	5.50%	+1.31	4.19%
Tablet	1.32%	+0.41	0.91%	+0.30	0.61%	+0.18	0.43%
Other	0.51%	+0.02	0.49%	+0.02	0.47%	+0.02	0.45%

bla

Tablet browsers

Which browsers do tablet users use? Nobody will be particularly surprised to hear that Safari for iPad leads with an immense percentage. Its share is going down, but that’s only because it has very little room to go up.

Keep in mind that we’re using very small numbers here, especially for BlackBerry. If the total share of tablet grows, I expect these numbers to starts to fluctuate.

StatCounter reports slightly less Android browsers than Android OSs. I assume most of these non-default Android browsers to be Opera. The Safari/iOS numbers match perfectly, so very, very few iPad users use a non-default browser.

Quarterly market shares for tablet browsers

Browser	Q4	ch	Q3	ch	Q2	ch	Q1
Safari	88%	-5	93%	-1	94%	-4	98%
Android	10%	+4	6%	+1	5%	+3	2%
BlackBerry	1%	+1	0	0	0	0	0
Opera and others	1%	0	1%	0	1%	+1	0

Classes in 12 countries

Here are the four device classes in my twelve countries. The table clearly shows rather large differences between these countries. Unsurprisingly, developing countries have a high mobile share and a low share of the other three classes.

Four device classes in Q3 2011 in twelve countries

Country	Desktop	Mobile	Tablet	Other
Nigeria	53.17%	45.38%	0.97%	0.02%
India	66.39%	33.44%	0.15%	0.02%
South Korea	83.16%	16.06%	0.18%	0.13%
Indonesia	88.83%	10.80%	0.34%	0.03%
US	90.03%	6.87%	1.84%	1.27%
UK	90.10%	7.10%	1.59%	1.22%
Mexico	92.73%	5.82%	0.81%	0.64%
Netherlands	94.07%	3.29%	2.04%	0.60%
China	95.51%	3.73%	0.70%	0.06%
Brazil	95.62%	4.17%	0.17%	0.04%
Egypt	97.81%	1.99%	0.17%	0.03%
Poland	98.46%	1.35%	0.12%	0.06%
Worldwide	91.96%	6.64%	0.91%	0.49%

Findings:

• The highest-scoring country when it comes to tablets is the Netherlands. Yay!
• Tablets score surprisingly well in Nigeria: close to 1% of all devices. That’s a lot for a developing country.
• Tablets score surprisingly lousy in South Korea: it seems Koreans are not taken with the concept.
• Of course the iPad takes 75-95% of the tablet market. I expected this to be different in South Korea due to the Samsung Galaxy being a local product, but that doesn’t really seem to be the case.
• The bulk of the Other category is made up of the iPod Touch, as one would expect. The only exception is the UK, where the iPod Touch takes only about 40% of the Other category.
• Mexico scores very well in Other. That’s mainly due to the iPod Touch, which is used as much as the iPhone. In other countries iPod use is well below iPhone use.

Methodology

• StatCounter gives desktop and mobile stats, and also states the share of these two classes.
• Other: desktop PlayStation or Nintendo browsers, as well as mobile iPod Touch and Sony PSP browsers. I took this data from the desktop and mobile browser stats.
• Tablet: “desktop” devices running on iOS, Android, or BlackBerry. I took this data from the desktop OS stats.
• Mobile: all mobile devices that are not Other.
• Desktop: all desktop devices that ar not Tablet or Other.
• For the tablet browsers I compared the desktop OS (iOS, Android, BB) to the desktop browsers (Safari iPad, Android, BB). Any difference between the two was assigned to Opera (and other).

Earlier this week Net Market Share released numbers that allegedly show the Java ME operating system is gaining ground to the expense of iOS and especially Android.

Unfortunately the story isn’t true, and I suspect it’s a good example of headline grabbing aimed at those who don’t have deep knowledge of mobile browser statistics; a group that seems to include the entire tech blogging caste.

There’s rather a lot wrong with Net Market Share’s assertion. The most egregious error of all is the contention that Java ME is an operating system. It’s not.

Java ME is a middleware layer that’s supposed to make creating a Java-based app for all OSs supporting it easier. Java ME’s big problem is that it’s not a case of write once, run anywhere, but more like write once, and make it marginally easier to write it elsewhere, too. Still, the relative ease of writing apps for Java ME is not the issue here.

Java ME (or rather, an OS- and device-specific version of Java ME) comes pre-installed with Symbian, BlackBerry, Windows Mobile (and, I think, bada), as well as a host of proprietary feature phone operating systems from Nokia, Samsung, Sony Ericsson and the like.

So it could mean that the combined market share of these operating systems is growing. Unfortunately Net Market Share does not mean that: it counts Symbian and BlackBerry separately.

Besides, the combined tech press completely overlooks the fact that Net Market Share’s own numbers clearly show Java ME has lost market share this year. Java ME had 26.80% market share in February, and 21.27% in December. A complex calculation based on my secret and proprietary formulae shows that it lost 5.53% market share this year. Hardly a winner.

Finally, what Net Market Share measures are browser impressions on its member sites. So which browsers do all these Java ME users use? If you compare the OS stats to December’s browser stats it clearly emerges that the Java ME share coincides fairly exactly with the Opera Mini market share.

What is going on is that Opera Mini is slightly on the rise (a trend confirmed by the latest StatCounter numbers), and that Net Market Share counts most of these Opera Minis as running on Java ME.

Now it is notoriously difficult to read out the operating system from Opera Mini’s browser string, and it is true that Java ME is often mentioned. Clearly, Net Market Share has decided to cut some corners, forget about detecting the true OS underlying these Opera Minis, and call them all Java ME. (Compare this to StatCounter, which at least tries to get the true OS right, and says “Unknown” if that’s impossible.)

So all that Net Market Share’s numbers tell us is that Opera Mini is on the rise again. Good news for Opera, but it isn’t that much of a story. Java ME replacing Android sounds much better, and will grab headlines all over the world.

I wish tech reporters would actually study the numbers they report on instead of copying press releases.

It’s time for the browser stats for December; as always according to StatCounter. Since it’s the last month of the year, I can also give the aggregate stats for Q4 and for 2011 as a whole.

Your donation for keeping this series up and running would be much appreciated.

December

Mobile

Opera once more overtakes Safari. It’s clear now that Android’s untrammeled growth has ended, and that the race for first position will continue to be between Opera and Safari.

Global mobile browser stats, December 2011

Browser	December	ch	November	ch	October	Remarks
Opera	24%	+2	22%	0	22%	Mini and Mobile combined
Safari	23%	-1	24%	+1	23%	iPhone and iPod Touch
Android	20%	0	20%	-1	21%
Nokia	13%	+1	12%	0	12%
BlackBerry	8%	0	8%	-1	9%
UC	5%	0	5%	0	5%	Chinese proxy browser
NetFront	3%	0	3%	0	3%
Dolfin	1%	0	1%	0	1%	Samsung bada
Samsung	1%	0	1%	0	1%	Samsung’s non-Android, non-Jasmine, non-Dolfin browsers
Obigo	1%	0	1%	0	1%	For LG phones as well as Brew MP. Version 10 is WebKit-based
Jasmine	0	-1	1%	0	1%	Samsung NetFront-based and early WebKit-based
Other	1%	-1	2%	+1	1%
Volatility		3%		2%
WebKit	57%	-1	58%	0	58%	Safari, Nokia, Android, Dolfin, 10% of BlackBerry
Mobile	8%	+1	7%	0	7%	Mobile browsing as percentage of all browsing

Desktop

As was already known, Chrome has passed Firefox as the second browser. This change seems to be permanent: Firefox loses terrain every month, and Chrome wins it. Meanwhile IE is still going down, too.

Global desktop browser stats, December 2011

Browser	December	ch	November	ch	October	ch	September
IE	39%	-1	40%	-2	42%	0	42%
Chrome	27%	+2	25%	+1	24%	+1	23%
Firefox	25%	-1	26%	-1	27%	0	27%
Safari	6%	0	6%	+1	5%	0	5%
Opera	2%	0	2%	0	2%	0	2%
Others	1%	0	1%	+1	0	-1	1%
Volatility		2%		3%		1%

Q4

Mobile

In the quarterly overview we can see the most important changes in the mobile browser market. The top two are still Safari and Opera, with now the one then the other leading.

Just below the top two there has been a change. Where at the start of the year it was a very close race between Android, Nokia, and BlackBerry, the three have drifted apart decisively, with rather large differences between them. I expect that this won’t change any time soon.

StatCounter’s detect was changed in two important ways during this year:

1. In early Q2 it introduced the Dolfin, Obigo, and Jasmine browsers as separate entries. I documented this change.
2. In early Q4 it changed its detection for UC, the Chinese proxy browser. Turns out roughly 4% of the entire browser market was counted as Nokia, but should have been counted as UC. This accounts for a large part of Nokia’s drop.

Global mobile browser stats, Q4 2011

Browser	Q4	ch	Q3	ch	Q2	ch	Q1
Opera	23%	+1	22%	0	22%	+1	21%
Safari	23%	+3	20%	-2	22%	-3	25%
Android	20%	+1	19%	+2	17%	+2	15%
Nokia	12%	-5	17%	0	17%	+1	16%
BlackBerry	8%	-4	12%	-1	13%	-1	14%
UC	5%	+4	1%	0	1%	+1	0
NetFront	3%	-1	4%	+1	3%	-1	4%
Dolfin	1%	0	1%	0	1%	+1	-
Obigo	1%	0	1%	0	1%	+1	-
Samsung	1%	0	1%	0	1%	-1	2%
Jasmine	1%	0	1%	0	1%	+1	-
Other	2%	+1	1%	0	1%	-2	3%
Volatility		10%		3%		8%
WebKit	56%	-2	58%	0	58%	0	58%
Mobile	7%	0	7%	+1	6%	+1	5%

Desktop

The quarterly desktop table shows that the trends we already noticed have been going on for the entire year. IE reliably loses 2 points per quarter; Firefox rather less, but it also loses. Chrome is surging.

Global desktop browser stats, Q4 2011

Browser	Q4	ch	Q3	ch	Q2	ch	Q1
IE	40%	-2	42%	-2	44%	-2	46%
Firefox	26%	-1	27%	-2	29%	-1	30%
Chrome	26%	+3	23%	+4	19%	+2	17%
Safari	6%	+1	5%	0	5%	0	5%
Opera	2%	0	2%	0	2%	0	2%
Others	0	-1	1%	0	1%	+1	0
Volatility		4%		4%		3%

Year

Mobile

The yearly table reminds us how far Safari used to be in front of all other browsers, including Opera. It also shows Android’s surge, and BlackBerry’s rise and fall.

Global mobile browser stats 2011

Browser	2011	ch	2010	ch	2009
Safari	23%	-2	25%	-9	34%
Opera	22%	-2	24%	-1	25%
Android	18%	+9	9%	+6	3%
Nokia	15%	-1	16%	-3	19%
BlackBerry	11%	-5	16%	+8	8%
NetFront	3%	-1	4%	-1	5%
UC	2%	+1	1%	+1	0
Samsung	1%	0	1%	+1	0
Dolfin	1%	+1	-	0	-
Obigo	1%	+1	-	0	-
Jasmine	1%	+1	-	0	-
Other	2%	-2	4%	-2	6%
Volatility		13%		16%
WebKit	57%	+6	51%	-5	56%
Mobile	6%	+3	3%	+2	1%

Desktop

The yearly desktop table shows Chrome’s surge and IE’s fall from grace clearly. It also shows 2010 was Firefox’s heyday.

Global desktop browser stats, 2011

Browser	2011	ch	2010	ch	2009
IE	43%	-8	51%	-9	60%
Firefox	28%	-3	31%	+1	30%
Chrome	21%	+11	10%	+7	3%
Safari	5%	+1	4%	+1	3%
Opera	2%	0	2%	-1	3%
Others	1%	-1	2%	+1	1%
Volatility		12%		10%

In the fall of last year I was happy to be interviewed by Helen Emerson for The Developer Book Club.

We were talking about books that inspired me when I first got into web development, books that shaped my knowledge about JavaScript and various approaches. We also discussed the future of the web, languages, learning and I even got a bit philosophical at the end.

I think it’s also the first time I could actually put up with listening to me without turning it off.

If it sounds interesting, please listen to the interview with me.

It’s a new year, and we’re supposed to make some predictions. So I’ll try to order my thoughts about the post-Android market, although I should warn you I won’t make a true prediction but will be a bit wishy-washy and vague.

Back in September or October I was a lot more certain. Back then I predicted Android was going to be in trouble because of Google’s acquisition of Motorola.

My hypothesis is that Google’s acquisition of Motorola will make the other Android vendors look for other OSs to use. Google is now a player on the device market instead of just a software house, and Samsung, HTC, and the rest will start to think seriously about using another OS for their future devices.

Although this is still a very real problem for Android vendors, the lack of an alternative complicates matters considerably. Back in August I expected that webOS would be sold by HP in October at the latest to one Android vendor (privately I bet on HTC). Once that happened, other Android vendors would also start to cast around for alternatives.

The curious case of webOS

That did not happen. webOS will never be sold; instead it was open-sourced. This confused me mightily.

What happened? It turns out that HP asked $1.2 billion for webOS, and that’s way too much for an OS that has failed twice and has to be re-customised for new hardware once it’s been sold. Besides, it was reported that webOS was built on flawed software.

A third problem might be that HP demands too much influence on potential licensees, trying to position itself as a smartphone ecosystem curator like Apple and Google. There have been no reports on this (and it presupposes licensing instead of sale), but it’s something to keep in mind. Of course HP, not being a software house, has no chance of actually curating a succesful ecosystem, but that won’t stop it from trying.

On the other hand, Robert Cringely is positive, quoting especially webOS’s versatility. (Besides, he feels a truly open-sourced webOS would give HP the chance to build good hardware and compete with IBM and Oracle. A dinosaur competing with other dinosaurs will have zero impact on the smartphone market, so I ignore this angle.)

Other Android alternatives

The webOS debacle teaches us a valuable lesson: an OS is worthless without a device vendor making a major commitment to produce phones and push them to the operators’ sales channels.

Right now webOS does not have such an interested party, so its chances are bleak. On the other hand, this could change pretty quickly once a major vendor announces its intent to use the OS.

This device vendor intent is the most important feature as-yet lacking for two other potential Android replacements: Boot to Gecko and Tizen.

Mozilla people told me they’re working with a device vendor, but quite properly declined to name it. Samsung is Tizen’s co-chair, so one would assume it’s planning to take Tizen devices into production. Still, we’ll have to await more specific news before we can be certain that these OSs will become a significant factor for Android vendors.

I expect more news around Mobile World Congress, 27th of February to 1st of March. What we want to hear is that a vendor commits itself to one of these OSs.

The post-Android market

So what’s going to happen on the post-Android market? To be honest I don’t dare to make a prediction right now. Weasely, I know, but there you are. Let’s say I’ll return to this problem after MWC.

There’s no denying that Google has had an incredible stroke of luck when its insanity in buying Motorola was offset by HP’s insane handling of webOS. Android’s most direct competitor has disappeared in a cloud of vagueness, and the chance that Android vendors will defect from the flock has been diminished.

The best way of viewing the post-Android market is that all Android vendors are weighing their options, and that those options include Android. So if a vendor decides to continue with Android, that means it sees no better option right now.

That last occurrence would be bad for the smartphone market as a whole, I feel. It’s better to have healthy competition than to have one single OS occupy more than 50% of the market.

So let’s hope webOS, Boot to Gecko, and Tizen, all of which are HTML5-based, will be picked up by post-Android device vendors.

The end of a year. There’s so much to say and look back on, and at the same time I am already certain that I will temporarily forgot some of the amazing things that happened to me this year. For it was indeed a fantastic year!

People!

One thing I do know, though, is that I will only namedrop sparingly, since I’ve meet an abundance of fantastic and outstanding persons this year, and there is simply not room nor time to go through all of them. Suffice to say, this year has without a doubt been the year when I’ve met the biggest number of terrific individuals, and I hope you know who you are and how happy I am that I met you!

A new job

In March this year it was finally decided and happening – I joined Mozilla as a Technical Evangelist! Lots of new changes with working for something you truly believe in – a non-profit organization dedicated to keep the web open and free! It is naturally also a big change working full time from home (or, well, wherever I am at the moment), and quite liberating to work from literally anywhere as long as I have a laptop with me (and honestly, after having the new MacBook Air, I don’t think I’ll ever go back to a big bulky laptop again).

Someone special

For a good part of this year, I have been together with someone very special and I am really happy to have met a person who means a lot to me! She is smart, beautiful, funny, spontaneous and just an amazing being.

She is indeed one of a kind and I look forward to a continued great future together!

(I’m letting her be a bit incognito for now )

Travel and speaking

This year was packed with a lot of travel, speaking engagements in four contintents and a whopping 178,541 km covered during 95 days on the road. I’d like to briefly go through my journeys this year below. And, if you like pictures, below each destination there is a link to all photos from that trip, so don’t miss it!

All the slides and videos from my talks are available on Lanyrd.

Brussels, Belgium [February]

I went to Brussels to give a joint talk with Christian Heilmann about HTML5 at FOSDEM, and we spoke to a completely packed room!

Mountain View, USA [February]

A very intense trip to California, with arriving in the evening, followed by a full day of interviews for trying to get the position at Mozilla, and then travel home again the next day. It’s a long trip, but in hindsight it was definitely worth it!

Montreal, Canada [March]

I was speaking at the ConFoo conference, and the trip included some interesting meals and sightseeing. Plus, of course, a dip in the outside rooftop pool at the hotel, surrounded by snow!

I also got to know Jordi Boggiano here, and later on this year we also met in Italy and Switzerland.

[All pictures from Montreal in March]

Las Vegas, USA [April]

Microsoft invited me to take part of their MIX conference, and it was an extraordinary trip in so many aspects. Given the normal stance I get from web developers and the community, it was interesting, to say the least, to be at an event where the majority liked Microsoft and rooted for Internet Explorer…

It was also my first time in Vegas, and I complemented it with visits both to Hoover Dam (courtesy of Mike Taylor of Opera who drove me there) and visiting Grand Canyon, and also flying in it in a helicopter.

[All pictures from Las Vegas in April]

Vaasa, Finland [April]

Ok, I’ll be honest. No offense to Vaasa, but after a week in Vegas, it’s hard to compete. I did have a good time, though (I always do ) and the OpenKvarken conference was an interesting place to speak at. Also, having discussions with people like Monty Widenius (of MySQL fame) and Martin Storsjö of Bambuser is always a good thing!

[All pictures from Vaasa in April]

Verona, Italy [May]

Ah, Verona. Supposedly the home to Romeo and Juliet, something that the town had built upon immensely. A nice Italian town and the jsDay conference was a good place to be speaking at! First time actually meeting Patrick H. Lauke, of Opera, in person, which I’m quite glad for!

[All pictures from Verona in May]

London, United Kingdom [May]

Managed to find some time to visit my brother in London, and we squeezed in seeing Eric Clapton play at Royal Albert Hall and some good stand up at Comedy Store. Also happy to meet friends like Jake Archibald and his elusive girlfriend, Stuart Colville, Frances Berriman and more.

[All pictures from London in May]

Paris, France [June]

Between my old job and starting at Mozilla, I had a few weeks off and was quite happy to take my daughters to Disneyland Paris! It was a success, for all three of us, and it was an intense and joyous week!

London, United Kingdom [July]

Time to speak at the AJAX User Group and also get to meets tons of friends in, and around, London. Good times!

[All pictures from London in July]

New York City, USA [July]

I was quite happy to land this gig! Speaking for the GothamJS conference on stage on Broadway in New York City! Pretty cool! In 2000, I had a stint in New York and I hadn’t been back since. So, given September 11 and everything else that have happened during the last eleven years, I was extatic to be back, and it is a city I truly love.

[All pictures from New York City in July]

San Jose, USA [July]

Immediately following the New York City visit we had a Mozilla work week in San Jose. First one for me, having been employed for about two weeks, and we had a very nice off-site meetup and get together.

[All pictures from San Jose in July]

Zurich, Switzerland [September]

In the fall of 2010, while at a conference in Poland, I told Markus Leutwyler that he should organize something in Zurich. A little less then a year later he pulled it off, and I was happy to be asked to speak at the FrontEnd conference there. As I often do, I also managed to get some good sightseeing with some friends, which had us ending up outside the city in a moment that was like a mix of Deliverance and Blair Witch Project…

[All pictures from Zurich in September]

San Jose, USA [September]

Time for my first Mozilla All Hands, where all the employees meet up at the same location and have a week filled with talks, discussion and collaboration. I was impressed to see the professionalism from the leading people in Mozilla, and as a JavaScript developer, of course it’s mighty cool to have Brendan Eich as your CTO and David Flanagan aboard. Every evening was also filled with exciting events!

On the way home to Sweden, I had a layover in London for a few hours, so me and my brother managed to squeeze in a visit to Jimi Hendrix apartment since that specific day was Open House Day in London.

[All pictures from San Jose in September]

Los Angeles, USA [October]

After MIX in Las Vegas in April, Adobe MAX was my second massive conference this year. And man, I have to say, Adobe sure can put together a conference, and the outdoor party in downtown Los Angeles was amazing! Cirque du Soleil performance, Weezer doing a gig and much more! It was also my first time in LA, so I had a day packed with sightseeing.

On top of that, I managed to walk right into the shoot of the next Batman movie, The Dark Knight Rises.

[All pictures from Los Angeles in October]

Amsterdam, Netherlands [October]

Flying in directly overnight from LA, I got to Amsterdam the first morning of the Fronteers conference. Amsterdam is a place where I have lots of really good friends, and it almost becomes sort of an overload being there – it’s so intense!

[All pictures from Amsterdam in October]

Paris, France [October]

Believe it or not, this was the first time I was actually in Paris – I’ve only been outside the city before. I went there to speak at Paris Web which I quite liked. Giving a presentation that is live translated with both sign language and into French text on a screen is pretty fun! I also got to do all the touristy stuff as well – Eiffel Tower, Notre Dame, Musée du Louvre and Mona Lisa and more – by staying over the weekend.

[All pictures from Paris in October]

Johannesburg, South Africa [October]

First time in Africa, and why not start by going all the way down to South Africa? I spoke at the Tech4Africa conference, which was a great mix of varying speakers and attendees. The conference organizers also graciously offered all the speakers a three day safari in a game reserve seeing all the amazing animals and surrounds they have, and it was out of this world! Lions, elephants, rhinos, hippos, crocodile, giraffes, ostriches and so much more!

[All pictures from South Africa in October]

Santiago, Chile [November]

I flew directly from South Africa to Chile, via Brazil, to speak at the StarTechConference. After the high in South Africa I just wanted to stay there, but my visit in Chile turned out to be quite amazing as well! The different thing in Chile was that us international speakers were treated like rock stars, posing for pictures all the time, signing autographs etc. Slightly awkward when you know that you are just a normal person, but, I have to admit, quite entertaining too.

[All pictures from Santiago in November]

Berlin, Germany [November]

I got three days at home after Chile, and then on to Berlin and MozCamp Europe. My last travel this year, and while it’s great fun, I also felt how worn out I was and that I just needed to be home for a while. However, the most excellent company made this into yet another fantastic time.

[All pictures from Berlin in November]

Summing up the year

All in all, this year has been tremendous! Overall I’ve gotten to experience so much, meet so many people, see so many places and also grow as a person. I’m finally finding out who I really am, what I want and what I don’t want, and ultimately, what I want my life to be like. And that, my friends, is a genuinely wonderful feeling!

Happy New Year, and may all your paths be fantastic!

If you want to come to Mobilism 2012, 10th and 11th of May in Amsterdam, it’s best to buy your ticket before Saturday. Early bird prices, which knock off €100 of the ticket price, ends with the outgoing year, and why should you pay more than necessary?

Mobilism 2011 was a blast; see also the videos. We’re set to repeat and extend this success in May. with seven world-class speakers, including Ethan Marcotte, Jeremy Keith, Horace Dediu, and Jason Grigsby, who’ll show you how the mobile web works and how you should adapt to it as a web designer or developer. What’s not to like? And even more speakers will be announced later.

See you at Mobilism.

If you’re bored during the holidays I encourage you to take my poll; it’ll help me understand who my audience is. Please answer as many or few questions as you like; although I’d like to ask you to answer at least 15 to 20 or so.

QuirksMode reader poll

On Wednesday I discovered the Urtak service that allows you to run simple Yes/No polls, and I immediately created one for my readers. About 30,000 responses were added at the time of writing.

Urtak’s fun consists of three parts:

1. All questions are simple Yes/No.
2. You can stop taking the poll at any time, and continue later.
3. You can add questions yourself.

The questions are asked in random order, and if you’ve already taken the poll (and revisit it in the same browser) you’ll only see the new questions.

Readers have already submitted quite a few good questions. So if you have one, please add it. Just make sure that you ask only one question, and that it's unambiguously phrased. I have to approve all new questions, but I’ll do so as soon as possible.

Thanks for your cooperation. In January I’ll write a post with the highlights of the poll.

At Khan Academy we've been investigating teaching Computer Science to students in some new and interesting ways. The most interesting aspect of which is that we're likely going to be teaching them JavaScript as their first language.

We're in a very unique position as we're primarily aiming to teach students who've been through our previous math and science-centric curriculum. Because of this we can create some rather compelling exercises and projects that never would've been feasible otherwise.

The prospect of teaching the JavaScript language as a first language is actually really exciting. Teaching prototypal inheritance to experienced classical-inheritance-using developers is normally rather frustrating (and results in many libraries springing up attempting to replicate the classical style of inheritance in JavaScript, which is a whole realm of weirdness in-and-of itself). Teaching prototypal inheritance to someone who has never seen any form of inheritance before will decidedly be an easier task. The same goes for learning functional programming. JavaScript is a great language for experiencing functional programming and can be a major focus of our curriculum as a result.

As we've begun to look at the prospect of JavaScript-as-a-first-language a number of obvious warts stick out (as is obvious to anyone who has worked with JavaScript for any duration). To make sure that general warts don't crop up we will be using some form of linting (either JSLint or JSHint or similar) in the code editor to give the users contextual information on what's happening with their code and why they should be writing their code in a certain way.

We want to go beyond basic syntax tweaks though and find ways of using the language that'll result in an easier learning experience. In particular there are two changes which will likely result in a much simpler on-ramp to learning.

Note: These particular recommendations really only make sense if you're teaching JavaScript to someone who has never seen the language before and is really only programming with a set of specific, well-coded, libraries. Obviously more will have to be taught in order bring the students up to the level of "see any random piece of cross-browser JavaScript code and understand what it does."

Type Coercion

Type coercion is just a complete mess, as many many others have pointed out and as what Douglas Crockford typically teaches, as in JavaScript: The Good Parts.

It might make sense to discuss it far later in the education cycle... like after learning about prototypes, functional programming, and closures. Basically after everything that's actually important.

The first change that I'm recommending is that the students will only ever see, and use, === (and !==). While using '==' does have the advantage of being syntactically shorter there is so much type coercion baggage attached to it as to make it an exercise in futility to try and teach early on in the learning of programming.

The one exception that might be worthwhile to teach later on is the case in which you wish to see if a variable contains a null or undefined value. This can be done easily with a simple someVar == null check and is likely the one useful case of ==. (Another noted exception is the browser bug in IE where === checks against Window objects will always return false, but it's unlikely that we'll cover such specific browser issues in our curriculum.)

Falsy Values

For the same reasons that == can be messy, so can falsy values. Enforcing strict boolean checks would result in less edge cases but would certainly result in longer code. Perhaps education of falsy values can be limited to booleans, null, and undefined with number and string falsy values left for a later exercise.

Function Declarations

Perhaps the most interesting change that we can make is a rather subtle one, but it's eschewing normal function declarations for creating anonymous functions and assigning them to a variable.

There are a number of good habits that are instilled when you use this particular technique.

• Makes it easier to understand "functions as an object". I've found that when you show new developers a function being assigned to a variable it suddenly becomes much more obvious that a function is actually an object and can be manipulated as such (and that a function can be passed as an argument to another function). Thus students are advanced along the path towards a better understanding of functional programming.
• It enforces good semicolon habits. Traditional function declaration is the only situation in which semicolons aren't needed (save for traditional statements and loops, naturally) and it makes it much more obvious when they're required all the time.
• Doesn't have much of the baggage traditionally associated with functions and scope.

Block Scope

This is the remaining area that'll certainly be a challenge for any introductory student to understand and yet I don't see a particularly good solution here. The issue of variables declared within for loops hoisting up is more than enough to make most developers heads spin. I'll have to see if we can't come up with some intuitive ways of explaining how variable declaration works (and combining it with vigilant lint enforcement) rather than having a purely technical solution.

(While (function(){ ... })(); is a solution I'm skeptical that we'll be able to teach that early-enough on as to make it worthwhile.)

JavaScript as a First Language

It should be noted that while we're starting with JavaScript as a first language - largely due to its ubiquity, desirability in the larger workforce, lack of prior installation requirements, and ability to create something that's easy to share with friends - we're not going to be myopic and only focus on JavaScript. There are so many things that can be learned from other languages, not to mention entire skillsets that aren't terribly relevant to in-browser JavaScript, that it behooves us to try and bring as much of them into our curriculum as possible.

I talk a little bit more about our choice to use JavaScript and some of the browsers that we'll want to support in our development in the following video:

OK, it’s time for an experiment. I created a reader poll about QuirksMode, your testing habits as a web developer, and your devices.

The fun part is that this service, Urtak, allows you to add a question of your own after you’ve answered a few existing ones. Please do so! I’m very curious what you’ll come up with. Just make sure that you ask only one question, and that it's unambiguously phrased.

(Unfortunately Urtak is currently experiencing very heavy traffic, so if you post a new question it’ll take a while before I see it. And going through the results and cross-tabbing them is not yet possible.)

But please take the poll. It only involves answering Yes or No to about ten questions — and adding your own, if you so like.

And the best part is: if you return to the poll in a few you’ll likely see new questions to answer. I’ll post a reminder next week.