I'll never forget the first time I saw Jeffrey Zeldman. It was in 2002 and I was at Web Design World in Boston. I had never heard of him before, nor had I ever heard of Web Standards. The moment he started talking I could almost sense that I was about to have my paradigm shifted. It was like I was walking around behind someone who kept dropping money out of their pockets, trying to pick up all the bills and change - faster than I could keep up with. The words he spoke had that much value to me. At that time, I was really at a crossroads in my career. I had been doing web design for more than a year, but I was doing it all wrong. I was using FrontPage to create table-based layouts, CSS was still a mystery and I knew nothing of Web Standards. I thought that Flash-based web sites were great, but had no ability or desire to learn the ActionScript to create that "wow" factor in Flash. I was seriously wondering if I should drop web design and go a different direction in my career.
At that conference, I soaked in every word and returned home with a passion and excitement about HTML, CSS and Web Standards. I was convinced that this method of building web sites was something I could not only do, but love doing.
I know Blue Beanie Day is not a tribute to Jeffrey Zeldman. Its a day to recognize the importance and impact of Web Standards on our industry. But for me personally, its a day to tip my
hat beanie to Mr. Z and say "thanks". I wouldn't be where I am today without his influence.
On Saturday, I had the privilege of speaking to the DFW Adobe Users Group (DFWAUG) about CSS and modern, standards-based web design. After several weeks of mounting anxiety about my first public speaking venture, I nervously delivered a presentation entitled CSS Fluency: Speaking the Language of Cascading Style Sheets. The premise behind CSS Fluency is simple. In the programming world, there’s a common axiom, “If you can describe it, I can program it.” Although not a programming language, the same can be said for CSS. If you can learn to speak the syntax using natural language to describe style rules, then you’ve begun the journey of mastering CSS.
Much to my surprise, the talk was well-received and it seemed that everyone in the room learned something new, particularly me. The members of DFWAUG are a warm, friendly bunch of people, which really helped put me at ease and we ended up having a great conversation about CSS and web design. I’d like to thank everyone at DFWAUG for having me there on Saturday and for being a great audience and asking a lot of relevant and intelligent questions.
"Good is the enemy of great."
I read the book a few years ago and that statement resonated with me then as it does today. Over the past few months, I've had the opportunity to work with other designers, critique other designers' work, have my work critiqued, defend my own design decisions, defend web standards and see up close and personal examples of good design and examples of great design.
What I'd like to do, in a series of forthcoming blog posts, is to talk about some areas in which designers can move from merely "good" to truly "great". With your help via the comments, I expect to learn some things along the way, too. Before I begin, let's talk definitions. I'm using the term "designer" very broadly here. For purposes of discussion, let's say "designer" applies to your typical web designer / developer / front-end developer / web producer- type "web person". Also, to make sure we're all on the same page, let me be clear that in this discussion that good does not mean bad - obviously. This is not a good vs. evil comparison. Good is good, but who wants to be good? Don't we all aspire to be great? I hope so, but I digress. Let's jump in to Part 1 of this series.
Good to Great, Part I: Good designers write valid (X)HTML, great designers understand the value of semantic markup and code accordingly.
This is a subject near and dear to my heart, because I just happen to love (X)HTML. I love the order, logic and structure that can be harnessed with (X)HTML. But this isn't about a Utopian approach to writing (X)HTML, its about doing what makes sense and using the markup language to provide a logical structure and meaning to web pages. Writing markup that validates perfectly against the W3C specifications does not make one a great designer. Indeed, this goes further than mere code validation.
In my projects, I definitely try to ensure that my code validates - in most cases. But I could write perfectly valid (X)HTML that is junk in terms of achieving a semantic structure for a web page. A great designer is able to write valid code, but also takes it a step further and writes efficient, well-structured, easy to read, semantic markup that enables future flexibility, lends itself to accessibility and reduces page weight as much as possible.
Let me illustrate below two ways to code the same information:
<div class="headline">My Favorite Music</div>
<div class="text">Following is a list of my favorite bands (or artists), sorted alphabetically:<br />
Collective Soul<br />
Frank Sinatra<br />
The Fray<br />
Third Day<br />
Tim McGraw<br />
<h1>My Favorite Music</h1>
<p>Following is a list of my favorite bands (or artists), sorted alphabetically:</p>
Both of these code examples are valid (X)HTML, but the second one is more semantic, making use of appropriate tags to create meaningful relationships between the pieces of content. Which is the better code? Well, the critics would say they are the same - that you get the same result visually in the browser. But a great designer knows that what lies beneath the visible is just as important as what the users actually see.
So what's the big deal?
Have you ever had a conversation with someone that liked to use the word "thing" too much? For example, "Hey, could you hand me that thing over there? Its there, next to the box thing. No, not that thing, the other one. Thanks." If you've had such a conversation, you'll remember that while you were probably able to understand them in the end, it was not as easy as if they would have used more descriptive words. To me, non-semantic markup is the same way. Code like
<div class="title"> gets the job done on the surface, but does not use the tags that were meant for describing a heading, which makes it much harder to understand, by humans and by machines that will read the code.
"Practically speaking, however, semantic markup is markup that is descriptive enough to allow us and the machines we program to recognize it and make decisions about it. In other words, markup means something when we can identify it and do useful things with it. In this way, semantic markup becomes more than merely descriptive. It becomes a brilliant mechanism that allows both humans and machines to “understand” the same information."
Therein lies the power of semantic markup. Good designers writing valid, yet non-semantic markup are able to put a check in the "valid code" box, but they are missing out on the flexibility and forward-compatibility that is attained when great designers build a website with semantic, well-structured (X)HTML.
So do you have what it takes to be a great designer? You're on your way if you understand the value of semantic markup and practice writing meaningful, rather than merely valid (X)HTML.
Sometimes when I'm in hurry I'll write a quick note on my hand instead of on a notepad. I've also been known to be too impatient to go hunt down a pair of scissors to open a package from Amazon.com, so I'll use my a car key instead. Such shortcuts work just fine when you're in a pinch. But if you are performing an important or very repetitive task, using the right tool is much easier and more efficient. Similar scenarios are played out in the web development world all the time, which is not the place for taking shortcuts or misusing your tools. What we're talking about here is semantics.
Most tools were designed for a specific purpose, to do a specific job. HTML markup was formulated the same way.
I'm an advocate of clean, standards-based markup. When I talk about markup, I'm referring to HTML. When I refer to standards-based markup, I'm talking about semantic HTML written in such a way as to separate the structure of the page from presentational elements. I'm a firm believer in keeping HTML virtually free of presentational elements and avoid using
<br /> (line breaks) and
(non-breaking spaces) to position information on a Web page and using HTML tags for their intended purpose, such as using a
<ul> (unordered list) to markup a list of items, be they items in a grocery list or a navigation menu. All presentational elements can and should be defined in separate CSS files.
Who Cares Anyway, Right?
The upside to developing Web sites in this manner is tremendous. Depending on your perspective or role in a given Web project, you may appreciate a wide array of benefits - fortunately there are enough to go around for everyone involved.
Web Master: If you're the guy responsible for updating and making changes to a Web site, you'll enjoy the ease of maintenance that semantic code provides.
Marketing Manager: Does driving more traffic to your site sound like a good idea? Semantic HTML practices produce well-structured documents that are easy for search engines to read, so developing sites in this manner is good for enhancing SEO.
Owner: If you're the owner, you're sure to see all the benefits, but you'll especially appreciate the increase in performance. Cleanly coded Web pages are usually smaller in file size and make for faster downloads, resulting in less bandwidth waste, which makes this a cost-cutting measure. Who doesn't like to save money?
So the next time you're in a hurry and reach for the nearest butter knife to turn a screw instead of a screwdriver, remember semantics and how they save time and effort over the long haul, especially if you're developing Web sites.