Es ist mir eine Freude—und eine Überraschung—wieder hier zu sein. No, really good to be back at Beyond Tellerrand. So I’ve been here in the odd years. I was here year one, year three, and now it’s year five. So it’s like the opposite of Star Trek films. It’s only the odd years that I’m here.
Today, what I’d like to do is I’d like to change your mind. When I say, “Change your mind,” I don’t mean I want you to reverse a previously help position. No, I mean I literally want to change your mind, as in rewire your brains.
That might sound like quite a difficult task: to rewire the brains of another human. But, the truth is, we rewire our brains all the time, right? When you see something, and once you’ve been shown it, you can’t un-see it. Well, that’s because you’ve had your mind changed. Your brain has been rewired.
Like the first time someone shows you the arrow in the FedEx logo, right, between the E and the X, and then every time you see the FedEx logo, all you see is the arrow, right? You can’t un-see that. You’ve all seen the arrow, right? Okay, good. Right?
Or the Toblerone logo, are you guys familiar with this? Who sees the bear in the Toblerone? About half the room. [Laughter]
Right? So now the other half of the room have just had their brains rewired because you’ll always see the bear.
Consider the duck—a perfectly ordinary, everyday duck. But then somebody, usually on the Internet, tells you all ducks are actually wearing dog masks. All ducks are actually wearing dog masks. [Applause]
Wait, wait, wait, wait, wait. When I show you the same picture of the exact same duck …so I have already succeeded in rewiring your brains.
But these are all very trivial examples, right, of having your brain rewired. There are much more important examples we’ve seen throughout history like Copernicus and Galileo with their heliocentric model of the solar system rather than the geocentric model. And it changed our understanding of our place in the universe.
What’s interesting about these kinds of brain rewiring, fundamental shifts is that nothing actually changes in the world itself, right? The earth always orbited around the sun, not the other way around. And yet, after Copernicus and Galileo, everything changed because our understanding of our place in the universe changed.
Or when Charles Darwin finally published his beautiful theory of evolution by natural selection, again, nothing actually changed in the natural world. Natural selection had been going on for millennia. And yet, everything changed because our understanding of our place in the natural world changed with Darwin.
I love this, by the way. This is a page from Darwin’s sketchbook. It’s one of my favorite sketches of all time where you literally see the idea forming in the sketch he made. What it reminds me of is this: This is another paper. This one sits behind a class case in CERN. “Information Management: A Proposal.” This is by Tim Berners-Lee, and this would go on to become the World Wide Web. This was something he had to present to his supervisor, Mike Sendall, and you can see what Mike Sendall wrote at the top. He wrote, “Vague, but exciting.” [Laughter]
Gave the web its go ahead. And in a way, what Tim Berners-Lee had to do then— it wasn’t enough to just invent, you know, HTTP, HTML, and URLs—he had to convince people that this was a good way of managing information. He had to rewire people’s brains. This idea of this network that has no centre where anybody can add a new node to the network; that requires some fundamental shifts …and the idea that anybody could access it. You didn’t need a particular computer or particular operating system. That this would be for everyone. Right, we had to rewire our brains to get that, to understand this decentralisation.
And then comes the problem of designing, developing for this new medium. How do we get our heads around it? Well, at first, we kind of don’t. At first what we do is we take what we already know from the previous medium and apply it.
Does anyone remember this book? Oh, yeah. Okay. We’re showing our age now. Creating Killer Websites, by David Siegel. It’s an old book. This—this was the guy who came up with the idea of using the one pixel by one pixel spacer gif, right, and giving it different dimensions. Tables for layout, right, all these hacks that we used to do to design for the web.
They were hacks, but they were necessary hacks because we didn’t have any other way of doing it until, you know, Web Standards came along. But, fundamentally, our idea of design was how do we make it look as good as the printed page? How do we make it look as good as what we’re used to from magazines, from designing for print?
And, of course, when you compare the web on that metric, especially 20 years ago, the web seemed woeful, right? 216 colors, 1 font: It seemed pretty hard to create killer websites. But people, even back then, were making the point that this isn’t the way to go around it. That what we should do is truly rewire our brains and accept the web for what it is.
John Allsopp wrote, 15 years ago—15 years ago, he wrote an article A Dao of Web Design. Who’s read A Dao of Web Design by John Allsopp? You are my people. The rest of you, please read A Dao of Web Design by John Allsopp. It’s wonderful.
What makes it wonderful, partly, is the fact that it’s still so relevant. I mean, you can’t say that about many articles about the Web that are 15 years old; that are more relevant today than the day they were written. Essentially what he’s arguing for is that we accept the web as the web. We embrace flexibility and ubiquity. Embrace that unknown nature of the web rather than trying to fight it, rather than trying to treat it like the medium that came before, right? As if it’s a poor, second cousin to print.
John pointed out that this isn’t new. This always happens. What happens is, a new medium comes along, and what we initially do is we take on the tropes of the medium that came before.
When radio came along, people did theatre on the radio. Then when television came along, they did radio, but on television. In each case, it took a while for each new medium to develop its own vocabulary.
Scott McLeod talked about this very same thing in his great book Understanding Comics. A different medium, but he noticed the same trend. We take what we know from the medium before and then apply it to this new medium, before we really get our heads around it, before we change our minds, rewire our brains.
When I look back at the history of design and development on the web, I think the brain rewiring started to happen because of this group, the Web Standards Project. When we think of the Web Standards Project today, we think of their work in convincing browser makers to support the standards, right? Lobbying Internet Explorer and Netscape to support things like CSS, but that was only half their work.
The other half of the work of the Web Standards Project was convincing us, designers and developers, to embrace the web, to use Web Standards. Like people like Jeffrey Zeldman writing books like this. I’ve met people who say that this book changed their minds. It rewired their brains. They weren’t the same person after reading this book as they were before.
I guess the central message that the Web Standards Project, Jeffrey Zeldman, all these standardistas were getting across back then was trying to get away from this idea that your presentation and your structure will be all clumped together in HTML and separated out, and that we could do that using Web Standards like CSS. And so that we could allow HTML to be HTML, and be used for structuring content, and allow CSS to be used for presentation.
Now, it’s all very well to read this or have someone tell you this. But, to truly have your mind changed and to, like, get it, get that lightbulb moment, I think there’s one website that did that. It was Dave’s website, the CSS Zen Garden, right? This was a machine for rewiring brains.
I had heard, yeah, okay, separation of presentation and structure. I get it. But then when you’re looking through, you go, whoa. This is actually the same HTML with different CSS, and the design could change that much. That’s when you really get it.
Remember that “a-ha” moment looking at the Zen Garden? You’re like, okay, now I get it—the separation of presentation and structure.
Of course, there’s the third layer we have on the Web, which is JavaScript, and that’s there for behaviour. Structure, presentation, and behaviour: that’s the broad idea behind progressive enhancement; that we have these three layers of building, one on top of the other. I usually illustrate this with the upper back torso of my friend Lynn because she’s really into Web Standards and this awesome tattoo that we have structure/HTML, presentation/CSS, and behaviour/JavaScript.
What this reminds me of is something I remember reading from the world of architecture. There’s a book called How Buildings Learn by Stewart Brand, a really good book. He talks about this concept of shearing layers or pace layers, that buildings themselves have different layers that they build upon that move at different paces, at different time scales.
The site of a building is on the geological time scale. It shouldn’t really change at all. The structure is also a fairly long-lasting thing. Then we build up. We build the walls. We build the rooms. And, within the rooms, we can move stuff around on a daily basis, but you’re not going to change the underlying structure very often, maybe a century or two, right?
I think this is useful for thinking about the web. On the web, I guess our site would be our URLs, the thing that shouldn’t change. Cool URLs don’t change. Then, on top of that, we get our structure with HTML. That’s what it’s there for.
There’s something in the design of HTML that’s really powerful, and it seems really simple, but actually it’s incredibly powerful. That’s this fault tolerant nature of HTML. It’s designed to be fault tolerant.
To explain what I mean, let’s look at what happens when you give a web browser an HTML element, an element with an opening tag and a closing tag, some text in between. Well, the browser is going to display the text in between the opening and closing tag. It’s standard behaviour.
Where it gets interesting is when you give a browser an element it doesn’t understand, right? It still just displays the text between the opening and closing tag, even though it doesn’t recognise that element. See, why this is interesting is what the browser does not do.
The browser does not throw an error to the end user. The browser does not stop parsing the HTML at this point and refuse to parse any further. It just sees something it doesn’t understand, renders the text between the tags, and carries on.
You all know this. This is a pretty simple facet of HTML. Yet, this is what allows HTML to grow over time. Because of this behaviour, we can start adding extra richness to HTML, introduce new elements, secure in the knowledge that older browsers will display that text in between the opening and closing tags. It won’t throw an error. It won’t stop parsing.
We can use that in the design of new elements to create fallback content. The fact that canvas has an opening and closing tag was a deliberate design decision. It initially came from Apple, and it was a self-closing tag. When it became a standard, they made sure they had an opening and closing tag so that they could provide fallback content for older browsers because of that fault tolerant nature of HTML.
The browser sees something it doesn’t understand. It just renders what’s in between the opening and closing tags. We get it with canvas. We get it with video. We get it with audio. Now we get it with picture.
This fault tolerant nature of HTML has allowed HTML to grow and evolve over time. When you think about it, the age of HTML is crazy. It’s over 20 years old, and it still works. You might say it’s a completely different HTML at this point, but I see it as an unbroken line. That is, it is still the same HTML that we had over 20 years ago.
It’s kind of like the Ships of Theseus paradox, like your grandfather’s axe. This axe has been in the family for generations. The handle has been replaced three times, and the head has been replaced twice. It’s like this philosophical question. Is it still the same axe?
If you’re thinking to yourself, “Of course it’s not the same axe, because the handle has been replaced three times, and the head has been replaced twice,” then I would remind you that no cell in your body is older than seven years, and yet you consider yourself to be the same person you were as a child—something to think on. [Laughter]
And what this allows for, this fault tolerant nature, is that we can grow HTML and, therefore, achieve a kind of structural honesty by using the right element for the job. Again, this is an architectural term, just the idea that you use the correct structure. Other than having a façade of something, you’re actually using the right element to mark something up. So, using tables for layout, that’s not structurally honest because that’s not what tables are for.
An example of structural honesty is if you need a button on a web page, you use the button element, right? It seems pretty straightforward. Yet, and yet, and yet, time and time again, I see stuff like this. Right? Maybe you’ll have class=button, role=button. An event handler, on click, make this behave exactly like a button. Call my lazy. I would just use a button.
Then there’s CSS, which we use for our presentation. CSS is also fault tolerant, which is also extremely powerful and, I think, has added to the robustness of CSS.
Just stop for a minute and think about all the websites out there using CSS, which is pretty much all of them now, right? You think about how different they are, how varied they look, how varied they are in scope, how different their CSS must be.
Yet, all the CSS on all of those websites, it boils down to one simple pattern—I think, a beautiful pattern—and it’s this: You have a selector, you have a property, and you have a value. That’s it. That is all of CSS.
We have some, you know, nice syntactic sugar so that the machines can parse this stuff, but this is it. This is what all of CSS is. Again, that is really powerful. What’s powerful about it is the fault tolerant behaviour.
Here’s what happens if you give a web browser a selector it doesn’t understand. It just doesn’t parse whatever is in between the opening and closing curly braces. Again, what’s interesting here is what the browser doesn’t do. It does not throw an error to the end user. It does not stop parsing the CSS at this point and refuse to parse any further.
Likewise, you give it a property it doesn’t understand; it just ignores that line. The same with the value: Give it a value it doesn’t understand, it ignores that line, moves on to the next one. That’s really powerful. That means, as new features start to arrive, we can start to use them straightaway, even if they aren’t universally supported because, what’s going to happen in the older browsers? Nothing. And that’s absolutely fine.
We get a kind of material honesty of using the right CSS for the job in the same way we get structural honesty with HTML. When we used to want rounded corners, we’d have to slice up a circle and put four background images and an element. Now we can just say border-radius, right? We get this material honestly from the fault tolerant nature of CSS, just as we get a structural honestly from the fault tolerant nature of HTML.
Then there’s JavaScript, not fault tolerant. To be fair, I don’t think it could be because JavaScript isn’t a declarative language in the same way that HTML and CSS is. HTML and CSS can afford to just ignore things that they don’t understand, right? JavaScript is a programming language. It’s a scripting language.
You actually kind of want the scripting language to tell you when you’ve done something wrong. You want it to throw an error. Debugging would be really, really hard if every time you made a mistake in a programming language, your environment just want, “Eh, don’t worry about it. Don’t worry about it,” right?
JavaScript will throw an error. If you give a browser some JavaScript it doesn’t understand, it will throw an error. It will stop parsing the JavaScript at that point and refuse to parse any further. So, it’s far more fragile than HTML or CSS.
Now, that’s okay as long as we use JavaScript the right way. As long as we’re aware of that fragility in comparison to the robustness of HTML and CSS, that’s absolutely fine. It’s just, we need to be aware of having safe defaults when we’re building. The safe defaults will be, well, your HTML, your structure, needs to be in place, right? Your CSS, you can’t rely on it, but if it doesn’t work, it’s not the end of the world.
What I’m saying is use JavaScript to enhance your sites, but don’t rely on JavaScript because of that fragile nature. Again, don’t get me wrong. I’m not saying, “Don’t use JavaScript.” I love JavaScript. I’ve written books on JavaScript.
JavaScript is absolutely awesome. But relying on JavaScript is a really dangerous game because of that fragility. I kind of think of it as like the electricity of the web in the same way as, in product design, you want to use electricity to turbo charge a system, turbo charge a product, turbo charge a building. But you don’t want to rely on electricity.
Jake Archibald, who is riffing on the Mitch Headberg joke, put it nicely when he said that, “When an elevator fails, it’s useless. When an escalator fails, it becomes stairs.” So, on the web, “We should be building escalators, not elevators.”
It makes a lot of sense to me. It’s a robust way of building. Yet, and yet, and yet, I see stuff like this. This is Instagram.com if the JavaScript fails. It has finished loading at this point. Nothing more will come into the page. There are many, many sites out there like that. Effectively, what’s happened here is that JavaScript has become a SPOF, a Single Point Of Failure in the way that HTML or CSS are very unlikely to do because of their fault-tolerant nature.
It seems very strange to me when confronted with these three layers of the web—HTML, CSS, JavaScript—that we would put all our eggs into the most fragile layer, right? That we’d turn the one with the fragile parsing into our Single Point Of Failure.
It’s all fun and games to point at sites like this where, if you switch off JavaScript, you get no content, but that’s not what this is about. That’s not what progressive enhancement is about. It’s not about people who switch off JavaScript. Who switches off JavaScript, right? Browsers are making it very, very difficult for people to choose to switch off JavaScript.
It’s about JavaScript failing for reasons you don’t even know. Maybe it happens on the server. Maybe it happens on the browser. Maybe it happens on the network in between. Just circumstances that are out of your control. That’s why you want to be building in a robust way.
This is Andy Hume. He puts it this way. He said, look, “Progressive enhancement is much more about dealing with technology failing than technology being supported,” right?
It isn’t, “Oh, we need to think about making it work in browsers that don’t have JavaScript.” No. Every browser doesn’t have JavaScript until the JavaScript loads. Things happen, and you need to embrace that you’re going to lose some of those packets. If it’s HTML or CSS, that’s going to be okay. If it’s JavaScript, that’s not going to be okay if you’re relying on the JavaScript.
What Andy is saying here, I think, was nicely paraphrased or summed up in a different way by my friend David who said, “Look, it’s simple. Build your apps so they aren’t a twirling shitshow of clown horns when JavaScript breaks.” Right? Seems pretty straightforward.
Perhaps more eloquently, Derek Featherstone said, “In the web front-end stack—HTML, CSS, JavaScript, and ARIA—if you can solve the problem with a simpler solution lower in the stack, you should,” right? “It’s less fragile, more foolproof, and it just works.”
Again, Derek is an accessibility guy, and he’s not making the argument here that it’s about access, that it’s about reach, about providing the service to everyone. No, no, he’s pointing out that, from an engineering point of view, this makes more sense. Foolproof, less fragile, it just works: that’s the reason to work this way.
What all these people are saying, effectively, is a reformulation of an existing principle, a principle by this man, John Postel. This is Postel’s Law, or The Robustness Principle:
Be conservative in what you send; be liberal in what you accept.
I see Postel’s Law in action all the time. Browsers: the way that browsers handle HTML and CSS, that fault-tolerant error-handling, that’s Postel’s Law in action. They have to be liberal in what they accept because there’s a lot of crap HTML out there, so they can’t throw an error every time they see something they don’t understand.
I see the robustness principle in action all the time, not just in web development, but in design as well. In the world of UX, let’s say you’re making a form on the web. Well, you want to be conservative in what you send. Don’t send the really long form with lots of form fields. Send as few form fields as possible down the wire. But then, when the user is inputting into that form, be liberal in what you accept. Don’t make the user format their credit card number or their telephone number with spaces or without spaces. Be liberal in what you accept. That’s just another example of Postel’s Law in action.
I love stuff like this because I’m kind of obsessed with design principles, this idea that these things are there. You might as well make them visible, make them public, write them down, put them on the wall because design principles are inherent in anything that humans build. We can’t help but imbue what we build with our own beliefs, with our own biases. That’s certainly true of software.
Software, like all technologies, is inherently political. Code inevitably reflects the choices, biases, and desires of its creators.
We talk about opinionated software. The truth is, to a certain degree, all software is opinionated. That’s okay as long as you recognise it, as long as you realise when you’re taking on the philosophy of the piece of software. Then you can decide whether you want to go along with it.
A simple example: If you’re using a graphics design tool like Photoshop to create a website. To be fair, Photoshop was never intended for creating web pages. It’s for manipulating photographs.
Let’s say you’re trying to design a web page in Photoshop. Well, you fire up Photoshop. You hit Command+N for a new document. The first thing it asks you for is a width and a height, a very fundamental design decision that maybe you’re not even conscious of making so early on in the process.
At the other end of the spectrum, if you have a Content Management System and that Content Management System has been made with certain assumptions about where the content will be viewed or what kind of devices will be viewing that content. If, in further years down the line, those assumptions turn out not to be true, you’re basically butting heads with the people who created that software. With any piece of software, you need to evaluate it on that basis.
If you’re choosing a framework, a front-end library or something, there are all these different things to evaluate. What’s the file size? What’s the browser support? What’s the community like? All really important questions, but actually the most important question is: Does the philosophy of this piece of software match my own philosophy? That way, if it does, you’ll work with it, right? It’s a tool that’ll make you work faster, and that’s the whole idea.
If it doesn’t match your philosophy, you’re going to be fighting it the whole way. This is why it’s possible for one group of developers to say, “This framework rocks,” and another group to say, “This framework sucks,” right? They’re both right and they’re both wrong at the same time. It’s entirely subjective.
We have a whole bunch of different tools we use in web development, and I kind of put them into different buckets, but these ones have become particularly popular in recent years, sort of bigger JavaScript libraries. Worryingly, people are putting more of the core content and functionality into the most fragile layer of the stack. I’ve sort of arranged them here in increasing order of opinionatedness.
If I’m trying to work in a progressive enhancement kind of way, and I take a look at Backbone, yeah, I could probably make it work. It does URL routing with a fairly light touch. I can probably work with it.
Then we get to Angular. It’s like, yeah, not so much. I mean maybe I could use a subset of Angular and still build in this progressive enhancement kind of way, thinking in this layered way. But, Angular actually has a way of thinking, right? There’s an Angular way of doing things. And, to get the most use out of Angular, you kind of need to accept its philosophy.
Then there’s Ember, which is like, no, no, no, very opinionated, like: JavaScript is everything. Forget HTML. Open body. Close body. That’s all you need, everything done in JavaScript.
If you’re going to choose to use one of these, make sure that you understand what you’re taking onboard. Make sure that you agree with its philosophy. If you do, that’s great. These are excellent tools that’ll help you work faster. But, if you don’t agree with them, don’t use them, because you’re going to be fighting the whole way.
You know, I was listening to an episode of Shop Talk Show, the great podcast that Chris Coyier and Dave Rupert do. They had John Resig on the show. They were asking him about these libraries and why he thought they were getting so popular. He, you know, would have a good opinion on this having created jQuery all those years ago.
He said something interesting about these big sort of monolithic libraries. He said, you know, “No one wants to think that what they’re doing is trivial.” I think there’s really something to that.
The way that these things are marketed is like these are for complex apps, right? You’re working on hard things. You need a really powerful framework like Angular or Ember. And it’s true; no one likes to think that they’re problems they’re working on just aren’t that difficult.
If you were at a cocktail party and someone asks you what you do, you describe your daily work, and then they said, “Yeah, that sounds pretty easy,” you’d be offended, right? That’s an insult that someone would say your work sounds easy. But if you describe what you do and someone says, “Wow, that sounds hard,” you’re like, “Yeah.” [Laughter] “Yeah, it is hard.”
You know, these libraries are like, “Oh, the stuff you work on is so hard. You need this library.” You’re like, “Yeah, I am working on really tough programs.” But these are frameworks for building elevators, not escalators.
Tom Dale is one of the creators of Ember. He said something a while back. He, by the way, is changing his tune. He’s coming around to the progressive enhancement thing, which is wonderful to see. But a while back he said, look, “JavaScript is part of the web platform. You don’t get to take it away and expect the web to work.”
Now, I disagree with this, but maybe not for the obvious reasons that you might think, which is that second clause. But actually, I take issue with the first clause, “JavaScript is part of the web platform.” What I take issue with is this framing of the web as a platform. I don’t think it is.
Again, language can be so important. Simon talked about this this morning, the importance of language. There’s this idea of political language where our words can subtly affect how we talk about things. This happens in English a lot, you know, political debates. You talk about collateral damage or friendly fire, right, weasel words that obfuscate their meaning.
But also, political language like if you were about to have a debate on tax relief. Well, before the debate has even begun, you’ve framed tax as something you need relief from, right? The same way if we’re talking about the web platform. Don’t get me wrong. There are great people using this phrase: webplatform.org, Web Platform Daily - wonderful, wonderful resources. But, the web platform …the web isn’t a platform.
If you think about what a platform is, you know, it’s an all or nothing system. I get it from a marketing point of view when you put the web on the same level of something like, you know, Flash, which is a platform, or iOS or Android, which is a platform. It’s kind of cool that the web can sort of put itself on that same level. It’s kind of amazing. I could wake up and go: I’m going to build an application. Now, should I build it in iOS, Android, or the web?
The fact that that’s even a question is kind of awesome, but it’s a bit misleading because the way that a platform works is, okay, I build something using the Flash platform and, if you have the Flash plugin, you get 100% of what I’ve built. But, if you don’t have the Flash plugin, you get nothing. 100% or nothing: those are your options.
The same if I build for an iOS device, an iOS app, and you’ve got an iOS device. You get what I’ve built, 100% of what I’ve built. But if I build an iOS app and you’ve got an Android device, you get zero of what I’ve built.
If I build something on the web, maybe you’ll get 100% of what I’ve built. Maybe close to it, 90%, 80%. But the important thing is that you don’t necessarily get zero, that you get something. And, if I’m building it the right way using progressive enhancement, you’re at least going to get the content. You’re at least going to get the HTML. Maybe you’ll get CSS. Maybe not all the CSS, but you’ll get some of the JavaScript, maybe not all the JavaScript.
The web is not a platform. The web is a continuum. To treat the web as a platform is a category error.
Just as we made the mistake of trying to get our heads around the web and thought of it as print design, now we’re making the same mistake as thinking that the web is software, just like any other software. We can’t treat building for the web the same way we treat building for any other platform. The web is fundamentally different.
I see sentiments like this. Joe Hewitt, an incredibly smart guy, frustrated by the web. He said, “It’s hard not to be disappointed by the HTML if you’ve developed for iOS, Windows, or other mature platforms as I have.” Yeah, if you’re going to judge it on that level, as if the web were a platform, I totally understand where your frustration is coming from. But the web isn’t a platform. The whole point of the web is that it’s cross-platform, that it doesn’t matter whether you’ve got iOS or Android, or what plugin you do or don’t have installed, that you get something on the web.
But what you have to understand about Joe’s frustration here when he said this, what he was trying to accomplish on the web was, he was trying to get smooth scrolling to work, which, yeah, okay, that is tougher on the web than it is in native. And all of these kinds of interactions—tapping, dragging, swiping—is kind of a pain in the ass to do this stuff on the web. But then you take a step back, and you realise, hang on, hang on. These are all sort of surface level implementation details on an interface. No one wakes up in the morning and thinks about these verbs, right? No one is like: I’m really looking forward to swiping today. [Laughter]
If you look below the implementation surface level to what people are actually trying to do, well, these verbs become more important, that people are trying to find stuff. They’re trying to publish stuff, buy stuff, share stuff. Then if you ask yourself, okay, how can I make this happen? You find you can do that pretty low down in the stack. Usually just HMTL will get you this far. Then you can enhance, and then you can add on the swiping and the tapping and the dragging and all of that stuff as an enhancement on top of the more fundamental semantic verbs lying underneath.
I think something that’s helped us get our head around this idea of what the web is, is responsive web design. Again, Simon talked about language, the importance of language. What Ethan did by coining this phrase and giving it a definition was, he helped rewire our brains to understand the web.
It’s interesting. In Ethan’s article when he first introduced the idea of responsive design, he references A Dao of Web Design by John Allsopp, building on top of that existing work. And, it is another term from architecture: responsive design. I feel like it goes hand-in-hand with progressive enhancement. If you think about what Ethan taught us was that, if you’re doing it right, layout is an enhancement.
Here’s the first website ever, the first website ever made, made by Tim Berners-Lee published on CERN. This is how it would look in a small view port. This is how it would look in a slightly larger view port, slightly larger again, right up to a wide screen view port. It’s responsive.
This may seem like a trivial, silly, little thing. Of course, there’s no CSS, right? Well, exactly. It starts off being responsive. The problem was never that websites weren’t responsive and we had to figure out how to make them responsive. No, no, no. The problem was we screwed it up. The web was responsive all along, and then we put that fixed width on it. We decided that websites were supposed to be 640 pixels wide, and then 800 pixels wide, and then 960—the magic number—wide.
Instead of talking about making a website responsive, we should actually be talking about keeping a website responsive. You get your content. You structure it in HTML. It’s responsive. You start adding CSS; the trick is that, in every step of the way, to make sure you’re not screwing up the inherent flexibility of the web. That rewiring of your brain is a different way of looking at the problem can make all the difference.
But, to think that way, to truly accept it that that’s the way to build, you kind of have to answer a fundamental question, and it’s this question: Do websites need to look exactly the same in every browser? I’m pretty sure at this point we all know the answer. If you don’t know the answer, you can find out by going to the URL dowebsitesneedtolookexactlythesameineverybrowser.com, built by Dan Cederholm, where you can see the answer, which is, “No!”
But, depending on the user agent that you happen to be visiting the site with, that will look slightly different because, hey, websites do not need to look exactly the same in every browser. Just to make sure that we’re all on the same page here, I’m going to ask for just one piece of audience participation if you could help me answer this question, please. Ladies and gentlemen, do websites need to look exactly the same in every browser?
No!
Good. That was pretty resounding, and that’s great because, if you truly believe that, if you accept that, then suddenly all the stuff that we’re afraid of like, “Oh, my God. There are so many devices, so many different browsers, so many different APIs, so many different screen sizes.” All of this stuff that we’re frightened of, if you accept that websites do not need to look the same in every browser, then it stops being something to be frightened of. It becomes something to embrace.
It actually starts to get really fun. I’ll finish with an example of what I mean. I’ll show you a pattern. This is, I’ll admit, a very, very simple pattern. It’s a navigation pattern, but to demonstrate sort of progressive enhancement and responsive design in action.
This is a pattern I first saw in Luke Wroblewski’s old startup, Bagcheck, where, to reveal the navigation, you can see there’s a trigger in the top corner there. If you hit that, you get the navigation. Now, what’s actually happened is that was nothing more than a hyperlink to a fragment identifier at the bottom of the page. You were jumped down to the bottom of the page where the navigation sits.
I really, really like this pattern because that’s going to work everywhere, right? Following links, that’s pretty much what browsers do. So, you know if you start with this, it’s going to work everywhere. I’ve used it on websites, right? You have that trigger. You hit the trigger. It’s going to go down to the navigation. Have something to dismiss the navigation. Actually, all that’s happening under the hood is you’re just jumping to a different part of the same page.
But here’s the great thing about progressive enhancement, about building for the web, is that you don’t have to stop here. Now that you’ve got that working, you’ve got something that works literally everywhere, you can build on top of that. You can enhance that.
A website I was working on with Stephanie, actually, we had some various navigation stuff going on. You’ve got search. You’ve got the “more” link. You’ve got the Menu. To begin with, all of that worked the same way. They were hyperlinks to fragment identifier further down the page, and you just followed those links.
But then I was able to enhance and say, okay, well, what if when you hit search, it slides in from the top? We can do that. JavaScript, CSS: we can do that.
What if that “more” menu is an overlay and sort of progressive disclosure on top of the content? Yeah, we can absolutely do that. Let’s have that menu slide in, in that off-canvas kind of way. Absolutely. Not a problem. If any of that doesn’t work, that’s fine. Websites do not need to look the same or behave the same in every browser.
Now, in order to do this, I would have to make sure that the browser understands the JavaScript I’m using because, remember, JavaScript isn’t fault tolerant. I don’t need to test for HTML. I don’t need to test for CSS. I do need to test for JavaScript.
The BBC had this lovely phrase they used called “Cutting the mustard,” where you’re literally checking to see if the browser understands what you’re about to do. In my situation, I was using querySelector, and I was using addEventListener. So I have an if statement to say, “If you understand these things, great. We’re going to do some JavaScript,” and that’s it.
There are two interesting things to notice about this pseudo code here. One is, I am detecting features. I am not detecting browsers. I am not looking at a browser user agent string. After listening to PPK, I think you understand why, right? [Laughter] It’s a mug’s game. Just don’t.
The other interesting thing here is that there is no else statement, right? If the browser understands these features, it gets these features. If it doesn’t, it doesn’t. Why? Because websites don’t need to look the same in every browser. I’m not going to spend my time making an older browser understand something it doesn’t understand natively, right?
To give you an example, let’s say I’m using media queries, as I am. It’s a responsive design. And I’m building it the right way, so I’ve got my usual styles outside the media queries. Then I put all my layout styles inside media queries. Well, some older browsers like Internet Explorer 8 or 7, they’re not going to understand those styles because they don’t support media queries.
What do I do about those styles inside the media queries? What do I do about Internet Explorer 8 and 7? Nothing. It’s perfectly fine. The content is well structured. It can stand on its own. Layout is an enhancement. I don’t need to make Internet Explorer 8 understand media queries.
Now, let me check just once again. Do websites need to look exactly the same in every browser?
No!
Good.
Marketing.
Marketing. Ah! That’s a good point. So what I’m suggesting here is aggressive enhancement, right? [Laughter] You give the browsers everything they’re capable of, and the other browsers that aren’t capable of it, don’t give it to them: aggressive enhancement.
People say, “I have to support IE8.” Marketing says, “You have to support IE8.” Actually, I agree. You should support IE8 and IE7 and IE6 and IE5. I think you should support Netscape Navigator 3. [Laughter]
Support. You should support those browsers, not optimise for them. There’s a big difference between support and optimisation. There’s a big difference between the marketing department saying, “You need to make sure your content is available to Internet Explorer 8,” and “You need to make sure the website looks exactly the same in Internet Explorer 8,” two very different things. I will absolutely do the first.
I support every browser. I optimise for none.
Look, I know it’s hard. I get it. You’d be like, “Yeah. You haven’t met my boss,” or, “You haven’t met my clients. I think websites don’t need to look the same in every browser, but it’s these people. They think that they do, so I’m doing it because of them.”
That seems like such a waste of your time and your talent. That, confronted with that situation, and you know full well that making something work and look the same in an older browser is just ridiculously hard and not the best use of your time. Yet, you go and do it because the boss, the marketing department, whoever, is telling you to do it. You’re solving the wrong problem.
If you are making a site look the same in Internet Explorer 6 as it does in Chrome 30 jillion or whatever it is now, then you’re solving the wrong problem. The real problem to be solved is changing the mind of the person who thinks the website needs to look the same in both those browsers. That’s the real problem is to rewire someone’s brain, probably someone in the marketing department. And I get it because that’s hard.
Technology—technology is kind of easy, right? Give me a problem. I’m going to solve it with HTML, JavaScript, CSS, and code. Give me enough time; I think I could probably solve it. Human beings? Yeah, they’re hard, a much trickier problem. But you would at least be solving the right problem rather than wasting your time and your talent trying to make something look and work the same in an older browser as it does in a modern browser.
But I do get it because it seems impossible to convince someone like that, right? Yet, things do change. It seemed impossible when the Web Standards Project was trying to convince browsers to support standards and convince us to use standards. Why would we switch from using tables for layout? We knew how to do that. It was never going to happen, and it happened. It is possible. People can change.
There’s a certain irony in this approach of progressive enhancement is that you are making sure that things are going to work further down the line as well in devices that you can’t predict. The irony here is that the best way of being future friendly is to be backwards compatible.
There’s this idea that progressive enhancement was maybe, well, it made sense ten years ago, but it’s an idea of the past. It’s a different web now. We’ve moved on.
No, progressive enhancement is the one idea that has stood the test of time so well, right? It’s a technology of the future. It’s not a technology, but a way of thinking for the future. Today we’re thinking about screens still. What about interfaces that don’t even use screens? That’s when you really have to think about your structured content first, right?
What about if the network isn’t available, this whole idea of offline first? What if we start thinking about the network itself as an enhancement? Again, this way of thinking, progressive enhancement, that will stand you in good stead.
You know what’s funny is I showed you the first website ever made, but I showed it to you in a modern web browser. When you stop and think about that, that’s kind of amazing. I showed you a website that’s over 20 years old and it still worked in a modern browser.
Here’s what it would have looked like at the time, right? This is the kind of browser that was around, something like the Line Mode Browser.
Here’s what’s really amazing. If you’re building your websites the right way, you could take a website that you’ve built today and you could look at it in a browser from 20 years ago. Kind of mind boggling, but that’s exactly the idea behind the web: that anybody could get at that, that this is for everyone.
I saw a tweet go by, and it said:
Wow. You really don’t get the momentous idea of the web until you sit next to a guy with a old Nokia and another with a brand new iPad.
Now that—that is an idea that’s worth rewiring your brains for.
Thank you.
Licence
This presentation is licenced under a Creative Commons attribution licence. You are free to:
- Share
- Copy, distribute and transmit this presentation.
- Remix
- Adapt the presentation.
Under the following conditions:
- Attribution
- You must attribute the presentation to Jeremy Keith.