On Designers writing HTML

Should designers know how to write HTML? Mark says, "It depends." I respect his opinion, but here's the bottom line for me - if I were hiring a web designer, I'd require them to know HTML. →

The Button Element

I've been doing a lot of thinking about buttons lately. I've even gone so far as to come up with a Button Theory. I know - this is heady stuff, but don't worry, I'll go slow.

First things first

My Button Theory can wait for another day. The purpose of this post is to talk about the <button> element.

If you're the type that likes to use native browser buttons, more power to you. Nothing wrong with that. But if you prefer to create images to replace the native browser buttons, then you may want to consider using <button> instead of the familiar <input> tag in your forms. Last year some time, I read an article by Particletree showing how they had "rediscovred the button element". At the time, I instantly wanted to try it out. Alas, I am just now getting around to it.

Before I get into "why", let me show you what I did and how I did it. I've replaced all my <input> tags with <button> tags in my forms. On the surface, it looks like this:

A similar button replaces my Submit buttons and the Search button (see search field in header above). The implementation was actually much easier than I anticipated. The HTML is academic:

<form>
  <button class="send" type="submit">Send Message</button>
</form>

The CSS is where you can really do some nice things. I chose to keep it simple and apply a background image and a :hover property (without Javascript), which I was able to achieve with only two style rules:

button.send {    background: #D1E9F4 url(img/plane.png) no-repeat 5px 50%;    color: #007CB3;    font-weight: bold;    font-size: 12px;    padding: .7em 10px .7em 40px;    border: 1px solid;    border-color: #F1F8FC #88C3DD #88C3DD #F1F8FC; }

button.send:hover {    border: 1px solid;    border-color: #88C3DD #F1F8FC #F1F8FC #88C3DD;    color: #004767;    text-decoration: none;    cursor: pointer; }

I have tested this in Safari, Firefox (both Mac and PC), Camino and Internet Explorer 6.

So, why did I bother?

I mean, the <input> tag works fine, right? Why change it up? A button is a button you say? Perhaps, but ...

  • I like learning new things about HTML, so I thought it would be fun to try this out.
  • You have a wide array of styling options available, as you can put any code inside the <button> tag, such as <span>, <strong>, <em>, etc. Alex Griffioen shows an example of this flexibility.
  • It allows you to make site-wide changes to your site by updating a couple CSS rules rather than having to modify several image files.
  • From a functional standpoint, it behaves the same way as a traditional <input> tag. For example, you can tab-select to the button to give it focus, then hit the space bar to submit the form.
  • Another reason is that I feel like it helps keep things straight a little more between the CSS I have for form fields and the CSS for buttons, rather than having both of them tied to the <input> tag.

Hopefully this has been somewhat helpful for someone looking for creative inspiration regarding buttons. I also hope that someone does not find some hole in my markup or style that would render me a fraud. Of course, your mileage may vary, but let me know if you have any issues with the <button> element.

What's in Your Bookstack?

I've been tagged. Stephen is wondering what's in my "Bookstack". My bookstack: a few of the books I'm currently reading.

Every now and then I'll pick up a book, usually a novel, that sucks me in to the point I can't put it down and I read cover to cover in a short period of time. But more often than not, I get a new book, read a few chapters and then before I finish, I'll start reading a different book. This happens a few times and I start stacking them on my desk or next to the bed to read whatever interests me at the moment.

The books in the photo above (from top to bottom):

One day soon (????), we'll have a tool to track and share what is in our Bookstacks. Until then, I'll tag a few others (Cori, Christian, Josh and Andy) to find out what kinds of interesting things they're reading.

Good to Great

In the book Good to Great, Jim Collins asserts:

"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 />
Cofield<br />
Coldplay<br />
Collective Soul<br />
Frank Sinatra<br />
Switchfoot<br />
The Fray<br />
Third Day<br />
Tim McGraw<br />
U2<br /></div>

<h1>My Favorite Music</h1>
<p>Following is a list of my favorite bands (or artists), sorted alphabetically:</p>
<ul>
<li>Cofield</li>
<li>Coldplay</li>
<li>Collective Soul</li>
<li>Frank Sinatra</li>
<li>Switchfoot</li>
<li>The Fray</li>
<li>Third Day</li>
<li>Tim McGraw</li>
<li>U2</li>
</ul>

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.

I think Joshua Porter and Richard McManus said it best in their article, written for Digital Web Magazine:

"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.