Tags: foreword

Whenever I dipped my toe in the waters of the semantic web, I noticed there were two fundamentally different approaches. One approach was driven by the philosophy that absolutely everything in the universe should be theoretically describable. The other approach was far more lax, concentrating only on the popular use-cases: people, places, events, and that was pretty much it. These few common items, so the theory went, accounted for about 80% of actual usage in the real world. Trying to codify the remaining 20% would result in a disproportionate amount of effort.

I always liked that approach. I think it applies to a lot of endeavours. Coding, sketching, cooking—you can get up to speed on the bare essentials pretty quickly, and then spend a lifetime attaining mastery. But we don’t need to achieve mastery at every single thing we do. I’m quite happy to be just good enough at plenty of skills so that I can prioritise the things I really want to spend my time doing.

Perhaps web design isn’t a priority for you. Perhaps you’ve decided to double-down on programming. That doesn’t mean foregoing design completely. You can still design something pretty good …thanks to this book.

Tracy understands the fundamentals of web design so you don’t have to. She spent years learning, absorbing, and designing, and now she has very kindly distilled down the 80% of that knowledge that’s going to be the most useful to you.

Think of Hello Web Design as a book of cheat codes. It’s short, to the point, and tells you everything you need to know to be a perfectly competent web designer.

Say hello to your little friend.

Stop me if you’ve heard this one before…

You’ve just followed a link to a cool-sounding new resource that one of your friends has recommended. Now you’re reading about how this could help you in your day-to-day work on the web. You excitedly click through to the documentation where the installation instructions are laid out before you. That’s when your heart sinks. “This is moon language!” you cry.

You are not alone. I don’t just mean that there are many of us who feel the same way. I mean you are literally not alone. You have Remy with you. He will be your guide.

I’ll be keeping this book close to hand when I’m navigating the intimidating dark depths of the Command Line Interface. But this isn’t a reference book. It’s more like a self-help book. This book will help me—and you—become a more efficient developer, better equipped to battle moon language. “It’s a UNIX system”, you’ll whisper. “I know this!”

Having read this book, I now have one question I ask myself before I confront an inevitable task on the command line: What Would Remy Do?

When it comes to the command line, WWRD will serve you in good stead (Warning: when it comes to just about any other aspect of your daily life, WWRD will almost certainly be disastrous).

What Would Remy Do? The answers lie within these pages…

I remember.

I remember when I was trying to make my first website. I was living in Germany and playing in a band. We decided the band should have its own little corner of the World Wide Web. I said I’d give it a go.

I remember finding everything I needed. It was all on the web. Designers, developers, webmasters …whatever you want to call them, they were selflessly sharing everything that they had learned. I lapped it up. I learned the lovely little language of HTML. I learned about using tables for layout and using 1 pixel by 1 pixel blank .gifs for fine-grained control. I even learned some Perl just so that people could fill in a form to contact us. Before long, our band had its own website.

I remember showing the web to the singer in my band. I showed him fan sites dedicated to his favourite musicians, sites filled with discographies and lyrics. I remember how impressed he was, but I also remember him asking “Why? Why are these people sharing all of this?”

I suppose it was a good question but it was one I had never stopped to ask. I had just accepted the open flow of ideas and information as being part and parcel of the World Wide Web. When I decided to make a personal website for myself, I knew that it would be a place for sharing. I use my website to share things that I’ve learned myself, but I also use it to point to wonderful things that other people are sharing. It feels like the hyperlink was invented for just that purpose.

One section of my site is simply called “links”. I add to it every day. The web is a constant source of bounty. There seems to be no end to the people who want to share what they’ve learned. “Here”, they say, “I made something. You can use it if you like.” I try to remember just how remarkable that is.

This spirit of generosity has even spilled over into the world beyond the web. I remember when Web Essentials was the first conference outside the US dedicated to sharing the knowledge and skills of the web’s practitioners. Later it became Web Directions. It served as a template and an inspiration for people all over the world.

It’s hard to imagine now in this age of wall-to-wall conferences, but there was a time when the idea of a web conference was untested. Without the pioneering—and risky—work of the Web Directions crew, who knows where we would be today?

A good event reflects the best qualities of the web itself. Designers, developers, UXers …whatever you want to call them, they conquer their fears to get up in front of their peers and share what they’ve learned. “Here”, they say, “you can use this if you like.” I remember how intimidating that can be.

I remember how honoured I was to be asked to speak at Web Directions in 2006. A decade can feel like a century on the web, but my memories of that event are still fresh in my mind. Not only was it my first trip to the Southern hemisphere, it was the furthest from home I had ever travelled in my life. I remember how warmly I was welcomed. I remember the wonderful spirit of sharing that infused my time in Australia. It reminded me of the web.

And now that same spirit of the web is spilling over into these pages. Designers, developers, baristas …whatever you want to call them, they’ve written down words for you. “Here”, they say, “you can read this if you like.”

I try to remember—but sometimes I forget—to say “thank you.”

I try to remember to say “thank you” to those early pioneers on the web who shared their experience with me: Steve Champeon, Jeffrey Zeldman, Molly Holzschlag, Jeff Veen, Eric Meyer, and of course, John Allsopp. I try to remember to say “thank you” to anyone who has ever put on an event—it’s hard work (just ask John). I try to remember to say “thank you” to the people who are making the web a better place for all of us through their incredible work: Ethan Marcotte, Sara Soueidan, Karen McGrane, and so many more.

And when I’m filling up the “links” section of my website on a daily basis, I try to remember to say “thank you” to everyone who has ever shared anything on the web.

I never did come up with an answer to that question my bandmate asked. “Why? Why are these people sharing all of this?” After all these years, I don’t think the answer matters. What matters is that I don’t forget how remarkable this spirit of the web is.

I remember.

—Scroll Magazine

I remember well when I got my hands on a copy of the first edition of Adaptive Web Design. I knew it would be good, but I didn’t expect to be quite so blown away after just one chapter. In that first chapter, Aaron managed to perfectly crystallise what I had been struggling to articulate for years on the true meaning of progressive enhancement.

In hindsight, I shouldn’t have been so surprised. Aaron is a multi-talented worker for the web and has cultivated a deep knowledge of many areas—particularly accessibility. But his real talent lies not in his way with technology, but in his way with people.

It’s all too easy for us—web designers and developers—to get caught up in the details of technical implementations. If we’re not careful, we can lose sight of the reasons why we’re designing and developing on the web in the first place. Aaron can take you on a deep dive into the minutiae of markup, the secrets of CSS, and the jargon of JavaScript, while at the same time reminding you of why any of it matters: the people who will be accessing your work.

I suspect that Aaron struggles to come with a title to describe what he does. Developer? Evangelist? Author? All those terms describe parts Aaron’s work, but they all fall short. I think the title that best describes Aaron Gustafson is …teacher.

Good teachers can work magic. They impart knowledge while weaving an entertaining tale at the same time. That’s exactly what Aaron does with this book.

You’re in for a treat. You’re about to read a story that is as instructional as it is engrossing.

Take it away, teacher…

It seems like the world wide web is forever playing catch-up. Back in the ’90s, the web was competing with CD-ROMs and coming up short …at least in terms of what could be technically accomplished. CD-ROMs offered richer interactivity, better visuals, and the possibility of using audio. But in the long run, that didn’t matter. CD-ROMs just couldn’t compete with the sheer vastness of the world wide web.

Later on, Macromedia (and later, Adobe) Flash went toe-to-toe with the web. Once again, it seemed like the web couldn’t match its competitor for animation, audio, and video. And yet, once again, the web outlasted its flashier counterpart.

More recently, we’ve seen a re-run of this same story in the world of mobile. Compared to native apps, the web just doesn’t appear to offer the same level of rich interactivity. But even here, I suspect that the web will still be stronger than ever long after the craze for native apps has faded away.

Each one of these proprietary technologies—CD-ROMs, Flash, native apps—could be interpreted as a threat to the open web, but I prefer to see them as the web’s R’n’D department. There’ll always be some competing technology that superficially appears to be gunning for the web’s dominance. In reality, these technologies demonstrate what kind of features web developers are looking for from browsers and standards bodies. If it weren’t for Flash, would we even have CSS animations? If it weren’t for native apps, would there be so much work put into providing access to device APIs?

The web will always be lagging behind some other technology …and that’s okay. Over time, the web’s feature set grows and grows, all the while maintaining backward-compatibility (something sorely missing from those competing technologies). The growth of the web’s feature-set might sometimes appear to be painfully slow, but it’s worth taking a step back every now and then to see how far we’ve come.

This book is like a snapshot of the cutting edge of what’s possible in web browsers today. The progress we’ve made might surprise you. It certainly surprised me. I’m somewhat flabbergasted by how much we can accomplish now with audio, video, and animations. And there’s no better person than Shane to do the flabbergasting. He’s like the Doogie Howser of web development. (Ask your parents.)

So settle in for a wild ride. Shane Hudson is going to take you to the edge.

I make websites. Sometimes I make music. Over the years, I’ve noticed an interesting pattern of behavior from some musicians—often self-taught—who think of themselves as creative types: they display an aversion to learning any music theory. The logic, they say, is that knowing the theory behind music will somehow constrain their creative abilities. I’ve never understood that logic (and I secretly believe that it’s a retroactive excuse for a lack of discipline). To my mind, I just don’t see how any kind of knowledge or enlightenment could be a bad thing.

Alas, I have seen the same kind of logic at work in the world of web design. There are designers who not only don’t know how to write markup and CSS, they actively refuse to learn. Again, they cite the fear of somehow being constrained by this knowledge (and again, I believe that’s a self-justifying excuse).

In the world of front-end development, that attitude is fortunately far less prevalent. Most web devs understand that there’s always more to learn. But even amongst developers who have an encyclopediac knowledge of HTML and CSS, there is often a knowledge gap when it comes to the Document Object Model. That’s understandable. You don’t need to understand the inner workings of the DOM if you’re using a library like jQuery. The whole point of JavaScript libraries is to abstract away the browser’s internal API and provide a different, better API instead.

Nonetheless, I think that many front-end devs have a feeling that they should know what’s going on under the hood. That’s the natural reaction of a good geek when presented with a system they’re expected to work with. Now, thanks to DOM Enlightenment, they can scratch that natural itch.

Douglas Crockford gave us a map to understand the inner workings of the JavaScript language in his book JavaScript: The Good Parts. Now Cody Lindley has given us the corresponding map for the Document Object Model. Armed with this map, you’ll gain the knowledge required to navigate the passageways and tunnels of the DOM. ix

You might not end up using this knowledge in every project. You might decide to use a library like jQuery instead. But now it will be your decision. Instead of having to use a library because that’s all that you know, you can choose if and when to use a library. That’s a very empowering feeling. That’s what knowledge provides. That is true enlightenment.