The Power Of Simplicity

• Listen to the audio.
• Watch the video.
• Download the slides.

I wanted to start with a story, because as Joeschi mentioned, the whole Open Device Lab thing …it sort of started a few years ago. I was doing this mobile browser panel at Mobilism.

Has anybody been to Mobilism in Amsterdam? Right, a few people. It always finishes with this sort of panel, and if you were at the first one, which was, gosh, three years ago now, we had this panel with these representatives from browsers or device manufacturers.

And I’m asking them questions and we’re discussing stuff, and at some point the topic of testing came up. It was like, “What can we do as developers, what can we do to test?” And everyone on the panel was going, “Oh, no problem, we’ve got this great emulator. You just go to this URL and use our emulator.” And I was like, really? Emulators? And when it got time to Q&A, one of my friends, Lyza—Lyza Gardner from Cloud Four Consulting in Portland—she was like …her hand was up straight away and she was like, “Emulators? …are you shitting me?”

I mean, really, we need real devices to test on. But of course it’s really hard. How do you scale that? How do we all get hold of real devices? There’s just too many of us, there’s not enough devices to go round.

So Lyza and other people there—Jen Hanen and other people—were talking about this idea of an Open Device Lab. And in fact Lyza and her business partner, Jason Grigsby, started to set about doing this, where they were going to set up an Open Device Lab in Portland, and anybody could come and use the devices. And I thought; that’s brilliant, I really want to keep track of how this progresses.

So every now and then, I’d see Lyza or Jason at a conference and I’d say, “Jason, how’s it going with the Open Device Lab thing? How’s that progressing?” And he’d say, “Oh it’s going great. We just signed the papers to establish ourselves as a non-profit and now our lawyer is looking through the blah, blah” …it was just a whole bunch of bureaucratic red tape. And my heart began to sink, because I thought, “Oh this is never actually going to get off the ground, is it?” Because it’s so complicated; there’ so many moving parts involved in getting set up.

So meanwhile, I myself at the Clearleft office, I’m starting to grab together a few devices; not many. Just a handful of devices, and I’m testing on these devices, and I’m kind of thinking, this is such a shame that most of these devices spend most of their time just sitting there, not being used. It’s not that often that I walk over and actually use them to test stuff. And I remembered Jason and Lyza and this whole idea of an Open Device Lab that we’d talked about at Mobilism. But I remembered what Jason had said about how it was getting set up as a non-profit and going through the paperwork and the insurance and all this stuff, and I thought to myself, “Fuck it!” I thought, “I’m just going to do it1”

So I wrote a blog post, and I put out a tweet and said, “Hey, anybody in Brighton who wants to come use our devices: come use our devices.” I didn’t look into the insurance costs. I didn’t look into the liability if someone slips and breaks their neck. What if a phone gets stolen, what then? What if …what, what, what? I decided …I’ll wait until those things happen and then I’ll deal with the problem.

And you know what? Nothing’s ever happened. It’s actually been just fine. I think it’s a pretty good way to go through life. You know what? I’ll deal with the problem when it comes up.

Because what it meant was that this Open Device Lab actually got off the ground. And even better—and this was not the reason why I wrote the blog post or put the call out—but even better, within the same day as I said this, there were other people in Brighton said, “Oh that’s a great idea. And by the way, I have this device and I’d like to give it to you.” Or “I’ve got these devices sitting in a drawer or sitting on my desk and I would like to bring them around and add them to the collection.”

I mean, literally, within twenty four hours, I had twice as many devices as when I started. And that wasn’t my plan when I opened up the Device Lab, but it was a great bonus.

And of course since then, Jay and other people have taken that idea and run with it and it’s fantastic and it’s really great that tomorrow there’s going to be this meet-up of people running Device Labs, people interested in running Device Labs; it’s really great.

Our Device Lab has now grown. We’ve got somewhere between thirty and forty devices. I’ve kind of lost track of how many devices we have. But the reason why I tell this story—partly to set the scene about the whole Open Device Lab stuff that’s going on this week in Nuremburg—but it’s also kind of a testament to the power of simplicity which is what I wanted to talk about.

The complex route would’ve been doing the paperwork and figuring out the insurance and making sure that all my Ts were crossed and all my Is were dotted, and I just went for the simple route. I mean, let’s face it, I also went for the lazy route, and this talk could equally be called The Power of Laziness, because I’m a very lazy person. But I think that laziness can be a positive characteristic if it results in simple solutions. Because simplicity, I do believe, is very powerful.

When we talk about having power as web developers, well, one way that we have power is with the tools that we use and they are pretty much power tools that help us do our job, and there’s some fantastic tools. First of all there’s tools like this, tools that we use as part of our workflow.

(Git, Sass, Less, Yeoman, Grunt…)

These are tools that we install on our own machines or we install on our servers or on our staging servers to help us get our work done faster. And I’m guessing you maybe use none of these; that’s fine. May be you use some of these. Maybe you use all of these. That’s fine; you use whatever you need to, and they help you get your job done. They are these power tools.

Like I said, one thing that unites them is that these all happen …these tools, they do their work before the files are published to the web, before the user sees them.

Now, we have a whole bunch of other tools that I would put into a different category. These are equally powerful, and they do wonderful things and they’re terrific tools, but they go onto the user’s machine. And I’m less keen on that approach, and I like to avoid it where possible.

(jQuery, Modernizr, Bootstrap, Boilerplate…)

So with the other tools, I’d say yeah, go for it, do what you want. With these ones, I’m a bit more reluctant. I’m not saying don’t use these tools, but I would say, don’t use these tools by default. Don’t assume you need to use these tools. It’s kinda like: wait until you need the tool and then use it.

Rachel Andrew wrote a great blog post about this, and she called it, Stop solving problems you don’t yet have, which I think is a much better approach to take. Rather than having your boilerplate with everything that you possibly might need, just start with nothing, and only use the tools as and when you need them.

I see a lot of projects start with jQuery by default. You don’t know yet whether you’re going to need jQuery. You probably will; you probably will end up using it. But start without it and see where it goes.

But the other reason why I’m hesitant to use these tools is not just this approach—that you should stop solving problems you don’t yet have—but also because these tools are installed on the client machine: it’s the client who ends up paying the price in terms of the extra downloads: extra HTTP requests and performance.

And I know they’re very, very optimised. All of those tools are really lean and mean, but it can be death by a thousand cuts when you start to add up all those little plug-ins, one by one.

So last year at Fronteers in Amsterdam, Alex Russell gave a talk and he said that polyfills are a tax. And that’s kind of the point I’m trying to get to, that they’re a tax that we impose on the user.

Now those tools aren’t necessarily polyfills, although maybe I’d consider some of them. Polyfills …you’re all probably familiar with the idea of a polyfill? Right; the idea that a browser doesn’t do something according to the spec so we’re going to pull it up by its bootstraps and make it understand the spec. I like the philosophical approach behind polyfills, which is, we’re going to make it understand the way things should work, so we make it work like standard. But there is this taxation element involved because the user has to download those tools.

But I understand why people reach for those tools, to try and bootstrap up those older browsers, try and bootstrap up the browsers that aren’t yet following the standards. But I’m going to push back a bit against that even as being a desirable solution.

I’m going to push back, actually, against a term, and it’s this term: The Web Platform.

Just to be clear, I do not mean I’m pushing back against webplatform.org, which is fantastic and the work they’re doing is absolutely …I say the work they’re doing …the work we all are doing at webplatform.org is wonderful.

But it’s that phrase, the phrasing of the web platform.

I sometimes go off on rants about this idea of political language, that the way we phrase things can unintentionally affect how we discuss those things. This idea of political language, coined by George Lakoff in his book, Metaphors We Live By, that the way we frame discussions has that subtle effect.

For example, when people talk about conservative values, putting together those words, no one talks about liberal values. Or tax relief. Straight away, before you even start the discussion, you’ve framed tax as being something that you need relief from. It’s very subtle political language.

On the web, we’ve had it, and I’ve railed against this in the past: the mobile web. As a phrase, I hate it.

There is no mobile web. And if you talk to people who use that term they say, “Yeah, I don’t mean it as literally a separate web for mobile devices. I mean the web as experienced on mobile devices.” But that phrasing—the mobile web—subtly influences the way we think and maybe we do start to think about, oh yeah, the desktop web and the mobile web. It’s subtle.

And so this idea of the web platform, I don’t like that phrasing. Because I don’t think the web is a platform.

I understand why people reach for this term, the web platform, or the open web platform, that’s another phrase. The adjective “open” at this point has kind of become meaningless. If Facebook can use the word “open”, then it really has lost all meaning. But this idea of the web as a platform, I get why from a marketing perspective, we’d want to use that phrase, because it puts the web on equal footing with genuine platforms.

I would say Flash is a platform, and native: iOS and Android and these things. They are platforms, in that it’s all one bundle. And the web isn’t like that.

What I mean is, if you use the Flash platform, then anyone with the Flash plug-in can get your content. It’s on or off. It’s one or zero; it’s binary. Either they have the platform or they don’t. Either they get all your content, or none of your content.

And it’s similar with native apps. If you’ve got the right phone, you can get my app. All of my app. You don’t get bits of my app, you get all my app. Or you get none of it because you don’t have that particular phone that I’m supporting.

And the web is not like that. The web is not binary, one or zero, on or off. It’s not a platform where you get one hundred per cent or zero per cent. It’s this continuum.

People talk about the web stack, and that kind of makes a bit more sense to me, that there’s these layers. Thinking of the web in terms of layers makes more sense.

And the problem with thinking about the web as a platform and putting it on equal footing with these things… On the one hand, it’s great that this is even a question that someone could say, “I’m going to make an application, it’s going to be on the internet. Hmm… will I make it on the web or will I make it in iOS or will I make it in Android?” The fact that it’s even a question, that the web is on the same footing as those platforms, is really great, actually, and if you’d told me five or six years ago that that would be a genuine question, I would have said, “Are you kidding? The web can’t possibly compete!” But now the web does compete.

But in competing we are also kind of trying to ape those genuine platforms, and in doing so, we lose what makes the web special. We lose actually a lot of the positive attributes of the web in trying to imitate these other genuine platforms. And if you do start comparing the web to native platforms, the web’s going to come up short: no doubt about it.

Joe Hewitt. He did Firebug a few years ago, which was great, and then he went to Facebook and he was working on the mobile site for Facebook. And he said:

It’s hard not to be disappointed by HTML if you develop for iOS, Windows or other mature platforms, as I have.

He’s treating the web as a platform, same as any other platform, and finding it wanting. Because by the standards he’s using to compare it, it appears to be less mature, less capable.

But you have to understand the way he’s approaching the comparison he’s making is because what he was trying to do—the particular thing he was trying to do on the mobile app for Facebook—was scrolling, or something like that. It was like, “How do I do good inertial scrolling on the web?”

He got really frustrated because it turns out, it’s really, really hard. And so he concludes the web sucks. And if you are trying to do these particular things, these are all definitely easier to do on a unified platform like Android or iOS or Flash, anything like that, then they are on the web, the chaotic, messy web.

(scroll, swipe, tap, drag…)

But I think we need to look deeper than these particular interactions, because these interactions are entirely surface level.

When you think about what we do on the web everyday, why we use the web. We don’t use the web to scroll or swipe or tap or drag. “I’m really looking forward to swiping today!”

(publish, find, share, buy…)

The verbs we use, the verbs that we want to participate in are things like this: we want to find stuff, we want to publish stuff, share stuff, buy stuff. These are the important things, and this is where the strength of the web lies. The strength of the web lies in being able to enable people to carry out all of these verbs, no matter what device they’re using, no matter what browser they’re using.

Vasilis talked about this. It is the universality of the web that gives it its strength, and if we just keep trying to compare the web to other platforms, like native platforms, and we’re just purely comparing the surface attributes like scrolling and swiping and tapping and dragging, API access, stuff like that, then yeah, you’re going to find the web wanting. But if you flip that round and you compare any of those individual platforms to the ability to carry out any of these things, no matter what browser you’re using, no matter what device you’re using, then the web absolutely trumps those platforms, because of its universality.

And what this reminds me of—and I know I bring this up all the time—but it reminds me of something that John Allsopp wrote thirteen years ago in A Dao of Web Design.

I do this every time, but I’ve got to ask. Who has read A Dao of Web Design by John Allsopp?

All right. Shame on most of you! Everyone needs to read this; seriously, it is like a manifesto, it is the star to sail our ship by. It’s a wonderful piece of writing, and it’s thirteen years old, and it’s more relevant today than the day it was written.

Now when it was written, the point John was making was, all these designers were comparing the web to print, because that was the background they were coming from; they were comparing it to a previous medium and finding it wanting, because they were comparing the surface attributes: What fonts can I have? How many colours can I have? Control over the viewport size. And by those standards, they were declaring the web sucks.

And John was saying, no, you’ve got to turn it ‘round and see the web for what it is, embrace it as its own medium; this very, very flexible medium—exactly what Vasilis was talking about.

And I think this is exactly the same mentality we’re seeing for people who are comparing the web to other platforms like native. They’re comparing the surface attributes and finding it wanting, and what they’re not doing is embracing that inherent flexibility of the web, the strength of the web. Its universality, its reach. That’s where is power comes from.

So I don’t think it’s good to seek to put the web on the same level as something like Android or iOS because it’s an apples and oranges comparison; they’re such different things.

The web is not a platform. The web is a stack, and it’s a technology stack as much as anything else.

There’s the stack of the technologies driving the web, which is HTTP, plus URIs, plus HTML. That’s one stack. But even in the browser, we have this other stack: HTML, CSS, and JavaScript, and they are independent layers. Independent. If we’re doing thing right, they are independent layers so that you could lose that top layer, and everything would still be accessible, it would still have that universality, still have that strength of the web.

The whole point is that we don’t have the choice between zero and a hundred per cent, that it isn’t on or off, that anywhere in this messy stack, you’re going to get some of the JavaScript, some of the CSS, depending on the kind of browser you are.

And of course responsive design definitely taps into this idea of giving different browsers or different users the best experience for their particular browser, adapting to them.

One of my favourite quotes about responsive design comes from Trent Walton, a brilliant graphic designer, visual designer, web designer, in Austin, Texas. And he was wary of responsive design, because he was used to making websites the old-fashioned way where he had a fixed width website, and he got to control the terms of engagement, which is how we built websites for over a decade. We dictated to the user the terms of engagement, because you must be using a browser that’s at least eight hundred pixels wide or a thousand and twenty four pixels wide. You must have this JavaScript capability, you must be on broadband. Whereas responsive design—and I would say, just good web design in general—it’s much more of a two-way conversation between the designer and the user, and the user comes to you and says, this is what I’ve got, can you work with me? So yeah, I can give you this, you don’t support that: that’s fine. I can definitely give you the content.

Responsive design isn’t about mobile, but it’s not about desktop either. It’s about the web. I think Responsive design ties into that flexible nature of the web that John Allsopp was talking about thirteen years ago, and in some way, responsive design is the new term for an old idea, which is One Web.

The web is flexible by default. This is the very first website ever published, written by Tim Berners-Lee. It now resides under its original URL on the CERN web server. This is how it would look in a small screen; this is how it looks slightly bigger, slightly bigger again. I could look at it in a slightly wider browser.

It’s automatically fluid, because the web is automatically fluid. That’s part of the nature of the web. Tim Berners-Lee didn’t have to do anything special to make it work on those different screen sizes: it already worked in those screen sizes.

And that’s something important to remember when people talk about responsive web design. It’s not like the web is fixed by default and then we have to work at making it responsive. The web is responsive by default, and as we start to add complexity using CSS, using JavaScript, the actual trick is to not screw it up. To not break the inherent flexibility that’s in the web.

So we talk about making websites responsive, but actually we should probably talk about keeping websites responsive.

I kind of think the same way about accessibility. Again with the political language, we talk about making websites accessible. If you have well-structured HTML document, it is already accessible. You then make choices during the development process that would hinder the accessibility, through CSS, through JavaScript, through whatever. So again, the key is not about making websites accessible, it’s about keeping websites accessible.

And the same with responsive design. It isn’t this big, mammoth task to make a responsive website. You just open an HTML document. It’s responsive. The trick is, not screwing it up.

And it’s we who’ve been the ones adding our filters onto the web. We’ve been the ones that have been constraining the web and trying to make it behave like some other medium, whether that’s print, whether that’s a native platform. We’ve been doing that. Instead of embracing the fluidity of the web and the fact that the web is this continuum, this stack of technologies, and that within each part of that stack, there is a continuum.

So you’ve got to start with HTML. Well, you’ve got to start with your content, obviously. But then you structure your content, and the way we structure our content is using HTML.

And within that HTML stack, we can still choose to provide the best experience we can to different browsers, safe in the knowledge that we’re not going to break things for older browsers, and that’s not an accident, it’s just because of the design of HTML: the error-handling model of HTML.

To give you en example: over the past few years we’ve gained a number of new input types for forms. Input types such as number, search, url, whatever. We can use these. We have been able to use these for years. We can use these because of the error-handling model of HTML.

If a browser sees an input type that it doesn’t recognise, it just assumes it’s type = text. So if you put input type = foo, input type = bar, the browser will see that, and will go, oh you probably meant text.

It will not break. It will not stop rendering the page. It will not throw an error to the user.

Now that is massively useful. It’s massively useful because we can extend HTML constantly, which is happening all the time. New elements, new attributes get added, safe in the knowledge that those new elements and attributes won’t break in older browsers; they will simply be ignored in older browsers. That is actually hugely, hugely powerful.

That means that you can start using the stuff before it’s supported on every possible browser.

I can’t tell you how annoyed I get when somebody writes a great article in Smashing magazine about some new HTML attribute or a new CSS property or something, and the first comment is from someone saying, “I can’t use it. I still have to support (insert old browser here).”

Define “support!” You will be supporting the older browser; you’re not going to break things in the older browser. They’re not going to get the nice enhancements that the newer browser will, so if you do use input type = number, a newer browser like an iOS will reward you by giving you a different keyboard, so here for example you get this number and symbol keyboard instead of the qwerty keyboard, simply because I used input type = number.

Just to take this a bit further, if I wanted genuinely nothing but numbers, if I didn’t need any of those symbols, it would be possible to go even further and say, inputmode = numeric (there’s a whole bunch of inputmodes in the spec and you can check those), and that would then bring up a numeric keyboard.

Be careful using that, because a lot of times you might think you’re asking for a number, an integer, and actually you still need to have dots or commas or minus signs, plus signs, so be careful when you use it.

Browser support for this? None. No browsers support this today. But you can start using this today. You put this in your document; it will break in zero browsers, because every single browser will just ignore it. But future browsers will support this.

We don’t pay a penalty for using this stuff today, and actually if you want to get the same effect today, you can fudge it by using the pattern attribute, which is supported in quite a few browsers. And with the pattern attribute you just give it a regular expression—now you’ve got two problems—and you get the same effect.

But I would go ahead and use both. Use the pattern attribute—it’s a short term solution—but use inputmode, even though it’s not supported in any browsers.

So the error-handling model of HTML is crucially important for the way that the web has been able to evolve, and it’s exactly the same with CSS.

CSS all comes down to this one pattern.

selector {
    property: value;
}

We have a selector, and inside that you’ve got a bunch of rules that consist of properties and values. That’s it. That’s all. CSS is encapsulated in this one pattern.

And what’s really important is the error-handling model for this pattern. If you use a selector that the browser doesn’t understand, the browser will simply skip over that set of rules. It won’t break, it won’t throw an error to the user; it’ll just ignore the whole selector. If you use a property the browser doesn’t understand, that’s fine, it just skips onto the next rule. And if you use a value it doesn’t understand, that’s fine, it just skips onto the next rule again. It doesn’t break.

It’s such a beautifully simple pattern, and yet immensely powerful. And this is how we get new CSS features all the time. And we can start adding those new CSS features before they’re supported everywhere. It’s the power of simplicity.

Now, when it comes to JavaScript, things are different.

The error-handling model of JavaScript is different. It’s a programming language. Some people don’t think so, but it is. It’s a programming language, and that means the error-handling model has to be different. You have to have things like syntax errors, just to make it feasible.

If you have an error in your JavaScript, parsing will stop. If you have an error in your JavaScript, the user will see an error. It’s very, very different to HTML and CSS.

And what that means is, we have to be more careful with JavaScript. I’m not saying don’t use JavaScript: I love JavaScript. But we have to be a little bit more careful in how we employ it because of that fragility, because of the error-handling model.

You have to test …do you support this method or property? If so, okay, we’ll use it. But you have to do that test to make sure.

The point is, you shouldn’t rely on JavaScript, precisely because it’s the most fragile part of the web stack. Again, I’m not saying don’t use JavaScript: use the hell out of JavaScript. JavaScript’s awesome. But don’t rely on JavaScript. Use it to enhance what you’re building. Enhance the hell out of what you’re building.

It’s the idea of progressive enhancement, which we’ve already heard about today.

And the way you can think about progressive enhancement, just to give a classic example, is as an escalator. An escalator can never break, it can just become a set of stairs. An escalator’s a set of progressively enhanced stairs, although the people here did not get the memo, because this is somehow out of order. I can walk on it.

Perhaps a better example is those moving sidewalks in the airports. They can never break. They just become floors. Again, somehow this is out of service. I’m pretty sure I can still use it!

Here’s a better example. An electric toothbrush can never break. It can just become a toothbrush.

In all these examples, they use electricity, but they don’t rely on electricity. Electricity makes them better at what they do. It makes for a better experience, but these things aren’t reliant on it, and I think we should be using JavaScript like electricity; to enhance the experience, but not to rely on it. You don’t want to be one of those smart houses that use electricity that relies on electricity. You want it to enhance it.

But too many websites I see rely on JavaScript, which as I said, from an engineering perspective, I find really strange, because it is the most fragile part of the stack.

This is squarespace.com if JavaScript isn’t available; the page has finished loading at this point.

And this is my Facebook timeline, if JavaScript isn’t available. Although Facebook do acknowledge this is a bug, and you can fix the bug by enabling JavaScript!

Which is actually a very good point, and as Vasilis mentioned, it’s not about people switching off JavaScript. That use case …frankly these days in browsers, it’s really, really hard to switch off JavaScript.

It’s about that reliance on JavaScript. And again, I’m going to repeat the quote that Vitaly used, but it’s true, that:

every user is a non-JavaScript user while the page is loading.

It’s about avoiding that reliance on JavaScript. It’s not about people who switch off JavaScript. It’s about the things you can’t think of; it’s about the situations you can’t anticipate.

To give you an example, I think this was last year, the page for downloading Google Chrome, for two hours, nobody could download Google Chrome. Nobody in the world could download Google Chrome, because when you came to this page, and you clicked on that button, nothing happened. There was an error on line 580 or whatever, of the JavaScript file that was being pulled in. Probably completely unrelated. Probably a misplaced comma, something like that. But it meant that nobody in the world could download Google Chrome for two hours. A pretty vital part of Google’s business model, I would imagine.

The reason for this was the way that the HTML had been structured using this JavaScript pseudo-protocol; the mixing of the layers.

</a>

There’s now a reliance on JavaScript. There’s some event-handling binding going on here that means that pressing that button does nothing unless the JavaScript works. Instead of say, I don’t know, linking to the download of Google Chrome?

But the point here: progressive enhancement is not about people switching off JavaScript or anything like that. It’s about the things you can’t predict.

I like the way that Andy put it here, that:

progressive ehancement is more about dealing with technology failing than about technology not being supported.

That’s probably actually the more important use case of progressive enhancement.

So, if you find yourself using anything like this in your HTML, stop yourself. These are anti-patterns.

</a>

</a>

The only time it’s acceptable to have this in your DOM is when they have been injected using JavaScript, because then you know that JavaScript is available. If you were writing this in your lower stack of HTML, you’ve already created a reliance on something further up the stack.

And there’s a lot of people doing this, it’s kinda sad. Since the Flickr relaunch, they’ve started relying on JavaScript for their simple actions. On FourSquare, they’ve gone out of their way to make this button look like a button, feel like a button and act like a button. But it’s a span, and they probably had to attach a whole bunch of events and probably some ARIA roles and all this to make it work just like a button. I said I was lazy: Me? I would use a button.

When I see this kind of stuff, it makes me angry.

It also puzzles me, as I said, from a purely engineering perspective. I know I said I’m lazy, but I mean that in the way that I try to find the simplest solution that works and go with that. To me, using a button would have been the simpler solution. From an engineering perspective, why would you want to make all your content that you could have in a robust layer like HTML, to make that reliant on JavaScript? It just seems like a crazy engineering decision.

And when I think about engineering decisions, I always think of this guy: the late, great Jon Postel, who’s no longer with us unfortunately. And he coined a principle, Postel’s Law, also known as the Robustness Principle:

Be conservative in what you send, be liberal in what you accept.

And the way I was describing the error-handling model of browsers with HTML and CSS, they are very much fulfilling the Robustness Principle. They have to be liberal in what they accept, because there’s a lot of shitty HTML and CSS out there, so they have to accept that crap, and not break and not throw an error to the user. They can’t have the same draconian error-handling model that JavaScript has. We tried that. It was called XHTML2. It did not work. It was not good for putting in front of users, and this is about the user experience.

The Robustness Principle is fundamentally about the user experience, and I see the Robustness Principle, Postel’s Law, crop up all the time when it comes to UX.

If you think about form design, you absolutely want to be conservative in what you send; send as few form fields as possible for the user to fill in, giving them the least amount of work to do. And be liberal in what you accept from them. Don’t make them put spaces in their credit card numbers, or don’t make them take out the spaces in their credit card numbers. Be liberal in what you accept. Just another example of Postel’s Law.

And just generally, if you’re building on the web, use Postel’s Law. Put your content into well-structured HTML. Enhance it with CSS. Enhance it, but don’t rely on, JavaScript.

We have these other tools. These are tools that have a different viewpoint, in my opinion.

(Ember, Angular, Backbone…)

These are tools that generally have an unspoken assumption that JavaScript is available all the time, that they do rely on JavaScript.

Now it is possible to use some of these libraries, these tools, these frameworks, in a progressive enhancement way, but it’s really hard work. You’re kind of going to be fighting against the tool, whereas if you make the assumption, “I’m building this single page thing that assumes the existence of JavaScript,” then these tools will help you work really fast, because they’re really, really good tools.

But what I don’t want is for you to change how you approach web design or web development based on the tools you use. That would be the tail wagging the dog.

When it comes to any tool, and particularly software, the most important thing is not about what browsers does it support, how powerful is it, how lightweight is it. No, no. The most important thing behind any of those tools we use every day is the philosophy of the person who made the tool and whether that philosophy aligns with your own philosophy.

If the tool aligns with your own philosophy, you will work together with the tool, you will work faster. If the tool clashes with your philosophy, you’re going to find it really hard and maybe you’ll end up giving into the tool’s way of doing things, and I think that’d be a real shame.

The tools should not be dictating the way we work. We should be using tools to help us work faster.

So I find these tools not that useful for me. I’m not saying they’re bad tools—this is entirely subjective. They’re not that useful for me because of the way that progressive enhancement is so built into the way I approach building on the web.

These are not so useful for turning stairs into escalators, but they’re really, really powerful at building elevators.

Now you may be saying sure; “I agree with what you’re saying, Jeremy, that’s all fine and good for documents. But I’m building a web app.”

Now in all seriousness, would anybody like to define web app? And you may not use the tautological definition, an application on the web. Like an actual definition. Not describing the characteristics of it; a definition. Anyone?

Okay. You see, I think that a web app is one of those things …like there was that famous obscenity trial when the judge couldn’t define obscenity, but he said, “I know it when I see it.” I think that’s how we feel about web apps. Or brunch. What is brunch? We all know what it is, intuitively; we can’t put our finger on it, because as soon as you try and define what a web app is, it’s hard to draw that line. It turns out, any document that happens to have a link in it or just a couple of form fields or any bit of enhancement is technically a web app, because now the user’s accomplishing some task.

The best definition that I’ve found of web app is, “a web app is a website that requires JavaScript.”

But I understand why people reach for this term; it’s very similar to the reason why we reach for the term, the web platform. It brings with it an air of something better than mere documents. That we’ve moved on from the old web, that we’re more mature because we’re not building websites. No, no, we’re building web apps. We’re working on the web platform.

But mostly I see it used by developers as a get-out-of-jail-free card.

“Yeah, I would love to use Progressive Enhancement, but I’m building a web app.”

“Oh, I’d love to make sure that it’s accessible. But I’m building a web app, so I get out of jail free.”

Grinds my gears.

So what I’m talking about, basically, is the very simple, very old idea that we just embrace the web, the simplicity of the web.

We’ve been handed this gift with these layers, and we should embrace the idea of progressive enhancement.

And there’s this myth around Progressive Enhancement that progressive enhancement means, then you’re designing for the lowest common denominator. No, no, no. Not true. With progressive enhancement you are starting from the lowest common denominator, which is any browser that can render an HTML page. You are starting from the lowest common denominator. But there’s absolutely no limit to where you can go.

Anything that you can build that requires JavaScript, you can build it in a progressively enhanced way. Anything that’s been built with Backbone or Ember or Angular, any of those tools, can be built in a progressively-enhanced way.

It may be hard, especially at first, but that’s no reason to shy away from it.

I see this all the time; I go and I give workshops, and I say, “You can do this, look at what you can do!” And people go “Yeah, but that’s hard.” It’s like, well, suck it up! This is our job.

And also this ties back to what Vitaly was saying, that it’s only hard to begin with. It’s like he said, with your first responsive website, if you’ve been building fixed width websites for ten years, then yeah, first time you try to build a responsive website, it’s going to be really hard. But the second time will be easier, and the third time will be easier again, and then it just becomes normal.

And with progressive enhancement, it’s the same. It just becomes normal. It isn’t harder. It doesn’t take longer. It doesn’t cost more money.

But there’s a fundamental thing, a fundamental philosophical approach that you have to approach your work with, if you’re going to use progressive enhancement. And it’s simply answering the question, do websites need to look exactly the same in every browser?

A very simple question. And you can find out the answer to this question by going to the website, dowebsitesneedtolookexactlythesameineverybrowser.com, where you will see the answer written out there on the screen: No.

However, the answer will appear different, depending on the browser you’re using, because of CSS and JavaScript enhancements. It’s a self-describing definition of progressive enhancement done by Dan Cederholm.

Now I hope in this room I don’t have to convince anyone that this is the right answer to this question, but I guess I’d better make sure.

Now you have proven yourselves extremely unwilling to perform any kind of audience participation with Vitaly, and I’m hoping you won’t let me down here. I’m just asking for one word here, so I’m going to ask: Do websites need to look exactly the same in every browser?

Audience: No!

Excellent! Excellent. That is the correct answer.

And once you do that, it changes how things look. It changes with this onslaught of devices. “Oh my God, we’ve got so many devices to deal with, so many browsers, so many different sizes, so many different capabilities.” It stops being something to be afraid of and panicking about. It’s okay, websites do not need to look the same in every browser. It becomes something that you can embrace.

It actually becomes kind of fun. It’s awesome: it looks so different in this browser than it does to that browser. That is a good thing. I’m talking about supporting every possible browser. Supporting every possible browser.

Now, there is a difference between support and optimisation. I do not mean you optimise to make things look the same in every browser. You are supporting every browser.

It should look very different in different browsers. A new browser should display your website differently to an old browser. If it looks the same in an old browser as it does in a new browser, you’re probably doing something wrong; you’re focusing your energies somewhere.

I’m going to finish up with a pattern to demonstrate this power of simplicity. I’ve been talking theoretically about all of this. Let me just show a pattern of simplicity, and this comes from responsive design.

It’s a really simple pattern that I love, when it comes to navigation in responsive design. I first saw this on a website that Luke Wroblewski had built, his previous start-up, Bagcheck. But I’ve used it myself on this personal site I built.

And it’s this pattern where at the top corner of the screen, we have a trigger that reveals the navigation, then we can get rid of the navigation again by activating that trigger at the bottom. Now, how this works is that arrow in the top corner is nothing more than a hyperlink. It’s a hyperlink to a fragment identifier at the bottom of the screen. So all you’re doing when you hit that arrow is you’re just jumping to the bottom of the document, where I’ve got the navigation. And that arrow at the bottom of the document is nothing more than a hyperlink pointing to the top of the document.

It’s super-simple, and it works in every single browser. So I love this pattern.

But I don’t necessarily need to stop there. What I’ll do is I will use that as my starting point. Now I’ve got this working, I know this works in every browser, I can do my browser testing if I need to, to tweak it, but this works. But now I can go ahead and enhance it.

So on a project recently, this was for Kew Gardens in the UK, a little responsive sort of pilot project. We got a whole bunch of navigation things going on here, because clicking that search button should reveal a search form, and clicking that menu is supposed to reveal menu navigation. And clicking that “more” link, that arrow is supposed to reveal more options. And each one of them is supposed to have a different behaviour, a slightly different animation.

But what I did, for all three of those interactive elements was, I just used that pattern where they’re just hyperlinks to the things at the bottom of the page. So at the bottom of the page, there’s a search form; at the bottom of the page, there’s the menu; at the bottom of the page is more links, and I just linked to them. But now, I can enhance, if the browser supports the JavaScript and the CSS I need it to, then when you click that search button, let’s have the search appear from the top. It involves manipulating the DOM, doing some stuff. That’s fine, it’s an enhancement. If anything goes wrong, that’s okay: it works without the JavaScript.

Likewise, with the menu or with this “more” option, you click it, there’s this kind of progressive disclosure pattern happening here. It’s just an enhancement to what would normally happen, which is it’s a link to the bottom of the page.

And finally the menu, I’ve employed that off-canvas pattern where it just kind of zooms in from the side. But again, that’s an enhancement for the browsers capable of doing that. If the browser isn’t capable of doing that, that’s fine; they get the old-fashioned link to the bottom of the page. It still works. Everybody still has access to the information; everybody can accomplish their task. It’s progressive enhancement in action.

And what I’ll do, because some of this does require JavaScript, is I will make sure that the browser understands that JavaScript. We do that by this nice phrase that the Guardian and the BBC have been using, which is “cutting the mustard”. We saw some examples from the Guardian site earlier from Vitaly, how they have the set of things that the browser must fulfil in order to execute the good JavaScript, the enhancements.

So in this case, I probably don’t need that much, I’ll probably just test, does this browser understand query selector? I need that. Does it understand, addEventListener? Yes, well that’s probably all I need.

Good, I’ll load in the JavaScript I need to enhance my page and add on that lovely electricity that is JavaScript.

Notice, there is no else statement here. If you support this stuff, you get the JavaScript. The end. There’s no, “if you don’t support it, okay, well I’m going to load in this polyfill to make you understand the JavaScript.” I think besides being a tax on the user, it is also fundamentally opposed to the idea that websites do not need to look the same in every browser.

Now you all said “No” to that question, do websites need to look the same in every browser, but I’m wondering whether you’re actually really living it.

What I’m talking about here is not just progressive enhancement, but aggressive enhancement. That if the browser doesn’t support a CSS property or JavaScript method, you just don’t give them that enhancement.

Let me give you an example. Media queries in Internet Explorer 8, 7 or 6. Internet Explorer 8, 7 or 6 does not support media queries, so don’t give them what’s inside the media queries, those enhancements.

Now, do websites need to look exactly the same in every browser?

Audience: No.

Hmm …good.

Some of you are lying.

And I know what you’ll say if I confront you with your lie. I know you’ll say, “I have to. My boss. My client.”

The amount of times when I’ve given a talk on progressive enhancement or some technology; using Ajax and progressive enhancement, using responsive design, conditional loading, whatever it is, and I give my talk and it gets to the Q&A and someone puts up their hand and says, “You’ve convinced me, but how do I convince my boss?”

I don’t know your boss! I’m sorry. I do not have the answer to that question. It’s also your job.

This idea that you have to make things look the same in Internet Explorer 8 as they do in a browser that does support media queries or querySelector or any of these things …No, no. You’re choosing to go along with that. You are complicit.

It is part of your job that you don’t keep holding the web back. What a waste of your time and your talent to be devoting more time to an older browser that doesn’t understand this stuff and making it try and understand it, than in using these new features.

I’m going to repeat what Rodney said:

You are part of the web. Take care of it.

And if you have a problem and you’re trying to make it work, do what Rodney was saying. You don’t spend time fixing just your problem. If the browser doesn’t support something or if there’s a bug in the browser, let’s let the browser makers know, using webplatform.org, moving the web forward. That’s where our job lies. It’s not just about our little day to day jobs and pleasing the boss.

I know, we’ve all got mortgages to pay and we have to put food on the table, but if all you care about is making money, then you’re no better than a prostitute.

The web is ours to take care of, and if you are still making websites look the same in Internet Explorer 8 or 7 or 6 as they do in a modern browser, you’re part of the problem.

And I don’t want to hear it that it’s your boss or your client is making you do it. Go to gov.uk, it’s the website of the British Government. I can’t imagine a stodgier organisation. And yet, they manage to do it. They managed to convince their boss to do everything right. Responsive design, web fonts, usability; everything about it is fantastic; progressive enhancement all the way.

So I don’t want to hear it that “I’d love to do this stuff” …because I know what you people are like…I know what you people are like. Meckern. We love to meckern all the time… “Oh I’d love to use this stuff, but I can’t because Internet Explorer doesn’t support it.”

During the very first talk when Jay was showing new CSS features. Remember the error handling model of CSS, that browsers don’t support and just ignore it, right? I saw people in the audience bringing up caniuse.com. Naaahhh…

The arrow of time moves forward. Let’s move with it. Stop focusing on some past browsers and let’s focus on the web of today, because if you’re building things right, the past browsers are supported. It all depends on your definition of support.

If you’re using progressive enhancement, you are supporting every browser. Internet Explorer 8, 7, 6, 5, 4, all the way down. You’re supporting text only browsers. You’re supporting browsers that don’t exist yet.

There’s this website you can go to, futurefriend.ly, which me and some friends put together when we were kind of freaking out, trying to figure out how do we deal with this onslaught of devices? How do we deal with what’s coming down the pipe next year, two years, five years? We don’t know.

And we put together some guiding principles for ourselves and maybe you’ll find them useful as well, but one of the surprising things that came out of it is that a lot of very old-fashioned things like good old-fashioned information architecture, good old-fashioned progressive enhancement, using HTML, using links and forms, and then enhancing with JavaScript …that will serve you in really good stead.

And actually, one of the best ways to be future friendly is to be backwards compatible.

And embrace Postel’s Law.

Thank you very much.