What are reset stylesheets?

For those that don't know, a default reset stylesheet is a .css file that you use in your HTML documents. The file has CSS rules that effectively neutralize a browser's default rendering of HTML elements and positioning. It sets all margins and padding to 0 and removes text decoration, size, and weight from HTML tags that normally have these by default, like the header tags (h1 - h6), em, and strong.

To use a reset stylesheet, you link it in your header like any other stylesheet. Then, when you're writing your own CSS, you can choose exactly how each element is to look. You can turn the bold text back on for the headers, and set the exact amount of padding you want, for example. Set your font faces and spacing however you like. The idea behind this extra work is that when a browser is reset to this zeroed-out state, you can specify exactly what you want your elements to look like, and practically all browsers will have an easier time rendering your design as you intended it rather than how the browser's defaults want to display it. The reset stylesheet removes the browser's defaults, so you don't have to worry about them.

If you want to try out a reset stylesheet, you can get Eric Meyer's reset stylesheet here, or you can try out YUI's Reset.

Keep in mind: resetting in web design, like many other things, has its pluses and it has its minuses.

Reset stylesheet advantages

Resetting greatly helps a designer build designs that look most similar (sometimes, identical) cross-browsers.
Because a reset will "zero out" a browser's formatting of your HTML, you get total control in your own CSS to declare exactly what you want, without the worry of whether or not a specific browser is going to tamper with your design.

Reset stylesheets can be modified to suit your tastes. A reset doesn't always have to zero out absolutely everything. Maybe you're comfortable with how the different browsers handle some things, or maybe you have a different idea for what the baseline for most of your projects should be. You can modify a reset stylesheet to suit your needs and create a uniformity amongst your work that is unique to you.

An experienced designer who resets can save time. It's true that learning to use a reset stylesheet can take some time to get used to, but once you've learned the ins and outs of your reset, and have your own modifications that you've built over time, you can pop your reset and modifications into a design and just start designing.

Simply put: your HTML document becomes a blank canvas and you can work with whatever CSS you wish.

Reset stylesheet disadvantages

The "clean slate" effect takes some getting used to. This adds a bit of a learning curve to your web design, which you're probably already nice and familiar with. Most likely, you've built up your methods and workflow over time, and something as drastic as a reset stylesheet can slow you down again.

Because resetting takes everything down to basics, you have to re-add things that you might think should just be included, like bold text in headers. You'll also need to pay special attention to where exactly you want all your design elements to appear, and how. Things you used to let the browser take care of, you now have to code for. This leaves you writing more CSS than you probably want to, or even need to.

Even through all this extra work when using a reset stylesheet, the reset still doesn't guarantee that your designs will look identical in various browsers. In fact, in some extreme cases, your design may end up looking no different across browsers than if you hadn't used a reset stylesheet. YUI's reset stylesheet, for example, works best with just what they consider "Grade-A" browsers, and some parts of the reset don't affect browsers not on this list. Granted, the Grade A list is the list of browsers we all design for primarily, anyway.

Differing points of view on reset stylesheets

Eric Meyer released his stylesheet, and people picked it up then seemingly immediately split into groups: those who like it, those who hate it, those who don't use it but can see its usefulness, and those who use it if the job calls for it. Want to see some people who fall into these various groups?

Jonathan Snook is one who falls into the "those who don't use it but can see its usefulness" group. He posted on his site his thoughts on reset stylesheets, and why he doesn't use them. In a nutshell, he states that reset style sheets take things overboard, and while he doesn't necessarily have anything against them, they just don't suit his tastes. In his opinion, they require too much work to go about re-declaring things in your own CSS that should just be there, which reset style sheets take away.

Eric Meyer obviously falls into the "those who like it" group. After Jonathan's post above, Eric felt that people were getting the wrong idea about his thoughts on reset stylesheets, so he cleared things up on his site. He never intended reset stylesheets to become a "be-all, end-all" solution to cross-browser compatibility, and in fact, wants and actively encourages users you take his reset and modify to fit their tastes, or even not to use it at all if they don't want to.

Jens Meiert (grouped in "those who hate it") states pretty strongly Why Reset Style Sheets are Bad. Jens says that "novices should not use them, [and] experts would not use them," then goes on to list the reasons why (load time increases and accessibility concerns, among others) and lists alternatives to resetting.

If you'll read through the above links, you'll find that many of the comments on those sites are made by users who fall into the last category: "those who use it if the job calls for it."

What do I think?

When it comes to resetting in my web design, I fall somewhere between "don't use it but can see its usefulness" and "use it if the job calls for it." When I've played with it for my own local pet projects, I found it adding time to the project that I could have avoided. I can see, though, that if I spent some more time with it and made my own tweaks, which is what Eric intended with the idea of a reset sheet anyway, it might speed up my work in the future and help my designs. For right now, though, for anything serious, I won't use it, but I'll still recommend others give it a shot.

It's a tool.

Everyone has their own method of designing and they have their own tools. These tools include your text editor of choice, your operating system of choice, what graphics editors you use, palette generators if you choose to use them, and now, reset stylesheets. If you prefer to draw your design on paper, scan it into Photoshop and add color, then cut the design into divs, that's what you do. If you prefer to mark up the HTML of your site first, then tack on a reset stylesheet and build your CSS before adding your images, great. Everybody does things differently.

I think it's best to view a reset stylesheet as a tool in your toolbox. It's in mine, and while I'm not too good with that tool yet, I know some people can use it masterfully, while others choose not to use it at all. Either way, the craft is yours to do with what you wish, how you wish to do it. I don't think the inclusion or non-inclusion of a reset stylesheet says anything more than, "Hey, this designer used/didn't use a reset stylesheet."

I'd like to encourage users who are thinking of using a reset stylesheet to give it a shot in their next project. Maybe you'll like it, and if you don't, then no harm done; you can always just not use it.

As part of an upcoming article for WPDFD, I'm going to showcase and discuss some good-looking, functional, and well-coded designs. If your design can match any of these three primary descriptors, a screenshot of your design and a link to your site might make it into the article.

Just drop me a line at drodriguez@wpdfd.com with links to any of your designs that you think should make it. I'm not yet sure how many designs I will be displaying in the article, but if the article is well-received and readers seem to enjoy it, I'll probably do more articles like it later. So, even if you don't make it into the first article there's a chance you'll make it into a later one.

In addition, the best designs have a good chance of ending up on our Featured Designs page. Sweet!

Feel free to submit your design by e-mailing me directly.

For your design to make it into the first article, please submit it before Wednesday, May 7, 2008. Don't worry if you can't make it by that time, though; you can still submit your design after May 7. Hopefully, if there are more articles like this later, you'll have a chance at getting into one of those, and there's always a chance at ending up in the Featured Designs.

Here's looking forward to seeing all your beautiful works!

Typography in your Web design is undoubtedly important. For some time now, it's been taught and practiced that using a sans-serif font is the best choice for page content and large blocks of text in Web design, while serif fonts should be reserved for use in small doses or as the style of choice for your headings. WPDFD even has a very recent article that states this. Some other places you can find this teaching:

• About.com
• Urban Fonts
• Web Design Reference

In a nutshell, here are some of the key points in using sans-serif fonts.

• Sans-serif fonts look good at most sizes.
• They tend to have a more contemporary or business feel.
• Most operating systems render them neatly.
• Serif fonts tend to lose readability at smaller sizes.
• Serif fonts, when viewed on a Windows computer, may look terrible. This is because Windows has a ClearType ability that smoothes the edges of screen fonts, which would make the serif fonts look good, but many Windows computers don't have this option turned on by default.
• Sans-serif fonts, on the other hand, can look good with or without Windows' ClearType turned on.

Overall, designing with sans-serif fonts for your main content is a good general typography rule for your Web design. Many often-visited sites use sans-serif fonts for viewing on the web, and it certainly works well for them. Google is an obvious example. Also, Microsoft and Yahoo follow this convention. Especially prominent sites in our own field, like A List Apart use it to very good effect. And if you'll take a quick look around, you'll notice WPDFD sticks mainly to sans-serif fonts, as well.

But. (You knew that was coming, didn't you?)

I fired up my RSS reader recently and came across a fairly attractive page with an entry about designing with type characters. This particular page doesn't touch directly on using serifs in Web design, but I found it easy to read.

It was also fairly refreshing. Seeing so many sans-serif fonts used in only so many ways on the Web isn't exactly tiresome, but it certainly does lend a certain charm to serif fonts when you seem them executed well in Web design.

That same page above also has links to a few other pages that use serif fonts well. For your convenience, I'll link them here, too, and include my thoughts:

• Twisted Intellect
  I like this page. It reads well and it's a very elegant design. The typography here is very nice.
• The 3rd SEED Conference
  While Twisted Intellect uses serif fonts, it doesn't use them for lots of content. The 3rd SEED Conference does exactly the opposite: the entire design is serif fonts; no images. It's just layout, placement, and typography. This is executed beautifully and I really like what's been done here.

There are some other sites I've come across while just browsing leisurely, too, that caught my eye with their use of serifs.

• Jens Meiert: Why Reset Style Sheets are Bad
  This is a good-looking, minimalistic blog that uses serif fonts to good effect. And hey, the page even touches on an interesting topic.
• Fun With Fonts
  This is not only a cute short story about a robot; it's also a good use of typography. The serif font here accomplishes its job very well.

The examples of good-looking pages above were all delightful to look at and to read. As opposed to sans-serif fonts, it seems that serif fonts do take a bit more skill for a Web designer to wield effectively, but the payoffs can be quite impressive.

Things to keep in mind

From what I can see, there are numerous advantages and disadvantages to using a serif font.

Benefits of using a serif font:

• Thanks to the vast majority of web sites using sans-serif fonts, using a serif font can lend your page a refreshing, personal, warmer, and more visually attractive appeal. Any or all of these effects can be accomplished with the right styling.
• A page using serif fonts is different, and helps you stand out.
• Serif fonts tend to give a web designer more to "work with." Their shapes can range from rigid and stoic to elegant and understated.
• I think serif fonts benefit more from color and experimenting with color, though this is just personal opinion on this one.

Things to watch out for when designing with serif fonts:

• This is one of the biggest points against using a serif font, so pay close attention: Serif fonts, especially when italicized, usually look terrible in Windows! The ClearType preference must be turned on for the fonts to look nice, and many Windows users do not know where to turn ClearType on or what ClearType even is.
• Serif fonts lose readability at smaller font sizes. A medium to large font size works best.
• See here for an example of how serifs can break down and make the eye struggle at too small a size.
• Serif fonts tend not to have a "business" feel about them, so it's probably still best to avoid them when designing a commercial site. They lend themselves better to "personal" or "informative" content.

When you really look at the points against serif fonts, though, you can see that generally they break down into two main problems: readability in Windows and text size concerns. Both of these problems aren't as big a trouble as you might think.

For one, Internet Explorer 7, while not the best browser around, uses its own ClearType rendering, whether or not ClearType is turned on in a user's Windows settings. Most Windows users still use Internet Explorer to browse, so serifs for these users will seamlessly look as you, the designer, intend them. The widespread use of Internet Explorer 7 alone significantly reduces the concern for how serif fonts will look in Windows.

Secondly, if a user does use Firefox or another browser in Windows, your concern for how your serifs will look can drop a bit more. It's safe to think that most (or at least some) users who have another browser installed also have enough knowledge of Windows preferences that they'll have ClearType turned on, or have the knowledge of how to do so.

As far as text size is concerned: that's totally up to you. This is a non-concern as far as many Web designers consider it, since you are the designer and can choose to use a decent-sized serif font. This leads to a third point against serifs that is focused more on you than on technicality: serifs are a bit tougher to use in Web design than sans-serifs.

That's not a terribly large issue, though, because it's one that you can get around with your design. In fact, as is the case with the sites I've listed above, it may not even be something to "get around," but instead an intentional tool to work with in your design.

Keeping the "design" in Web design

I would like to see more modern Web designs using serif fonts for their content. They look really nice when used well, and it's a scary thought to think that we may be running into design clichés with the whole sans-serif-for-content "rule." The Web is a great canvas, and I hope designers can continue to do great and beautiful things with it, especially when those beautiful things step outside the lines and manage to remain functional.

A sample page

Let's begin with a small sample Webpage. You can view it here. This page uses a small, pretty standard design with some low-key colors to help emphasize the content. This is a good use of design and color if your site fits in the "content is king" category (and most sites do), especially if your content consists of articles or other long blocks of text, like a blog.

The thing to notice here is that the text does its job: it communicates a message and the user can walk away having consumed your content. But the text is the same across the whole page, with the exception of a color change in the small subheading below the header text and the positioning of it. Here's the CSS that's being used in the sample page.

body {
	text-align: center;
	margin: 0;
	padding: 0;
	background-color: #363942;
	color: #382513;
}

#container {
	margin: 15px auto;
	text-align: left;
	background-color: #D8CAA8;
	border: 1px solid #4B1E18;
	padding: 0px;
	width: 850px;
}

#header {
	height: 80px;
	border-bottom: 1px solid #284907;
	margin-bottom: 15px;
	padding: 15px;
}

#header h1 {
	position: relative;
	vertical-align: center;
	color: #382513;
	margin-bottom: -10px;
}

.subheading {
	color: #284907;
}

#sidebar {
	border-left: 1px solid #8FB65F;
	margin: 0 0 15px 15px;
	padding: 0px 15px 15px 15px;
	float: right;
	width: 175px;
}

#content {
	padding: 0 15px;
}

#footer {
	clear: both;
	border-top: 1px solid #284907;
	padding: 15px;
	margin-top: 15px;
}

Choosing your fonts

To improve readability, we'll want to choose a font that looks good with the colors you've chosen and at the size you plan on making your text. Typically, a non-serif font is advisable for the main content, while headers benefit from the added noticeability of serif fonts. If you come from a print background, this may sound backward. Usually, in the print world, serifs are preferred for blocks of text because the serifs help the eye distinguish each line. However, modern operating systems have options to smooth the edges of screen fonts automatically, so non-serif fonts come out looking better as main content and serif fonts look good in small doses.

With this in mind, I'm going to use one of my favorite lines when it comes to CSS and fonts:

font-family: Arial, Helvetica, sans-serif;

These fonts are some of the safest you can use in your design, and if cross-browser compatibility is a concern, memorize them. They're good to use on their own, or you can use them as a starting point for your non-serif text. In this case, for simplicity's sake, I'm going to stick with just these three for the content. The body section of the CSS now looks like this:

body {
	font-family: Arial, Helvetica, sans-serif;
	text-align: center;
	margin: 0;
	padding: 0;
	background-color: #363942;
	color: #382513;
}

And with that small change, the overall readability of the page has changed slightly for the better: see for yourself.

The slight change is good, but all of the font is still the same family and this creates a bad sort of uniformity. We want some distinction going on here, so let's set our headings and subheading apart from the rest of the content. We'll ignore the h1 at the very top for a bit, since we'll want to do something a little different with that in a second.

For the subheading and the heading in the content, I'll be using a serif font. Just like above, this next line is probably one of my favorites:

font-family: Georgia, "Times New Roman", Times, serif;

Again, these are some of the safest fonts you can use in Web Design, even if it's just for a starting point and you plan to expand your typography a bit later. Reserve this line for headers and other places where it would look good in small doses; the eye has a tougher time reading serif fonts on a screen than non-serif fonts so whole blocks of serif text can be jarring.

So now, our subheading class looks like this:

.subheading {
	color: #284907;
	font-family: Georgia, "Times New Roman", Times, serif;
}

And we need to create a new rule for h2 tags in the content section. We do so like this:

#content h2 {
	font-family: Georgia, "Times New Roman", Times, serif;
}

Alright, now the header information is more separated from the content, which is good. Take a look here.

Now, what about that h1 header we have at the top of the page? We're going to make it larger and give it less contrast to its background. This is so that users will know what site they're on, but won't be distracted by the header.

We'll do this with this code:

color: #6B5846;
font-size: 48px;

And the full header h1 rule now reads:

#header h1 {
	position: relative;
	vertical-align: center;
	color: #6B5846;
	margin-bottom: -10px;
	font-size: 48px;
}

You can view the modified header here.

Now we turn our attention toward the sidebar and footer. The text in the these places is the same as the body text in main content area. The sidebar and footer typically play secondary roles, so we'll give them smaller text and a different font family with a single font rule:

font: 12px Verdana;

Now, our sidebar and footer divs have the following CSS:

#footer {
	clear: both;
	border-top: 1px solid #284907;
	padding: 15px;
	font: 12px Verdana;
	margin-top: 15px;
}

#sidebar {
	border-left: 1px solid #8FB65F;
	margin: 0 0 15px 15px;
	padding: 0px 15px 15px 15px;
	float: right;
	width: 175px;
	font: 12px Verdana;
	color: #5A4735;
}

Right now, the content text feels a bit overwhelming. We'll reduce its size with this:

font-size: 15px;

And we'll put it in the content rule, so now it reads:

#content {
	padding: 0 15px;
	font-size: 15px;
}

And now we have our fifth iteration of the CMRT page. We've taken some good steps in making sure the different sections of our site each have their own look and feel while still feeling unified. Now, we can take it a step further with the line-height property.

line-height — Be good to your visitors!

Your visitors are there to see whatever content you have up on your site. They've come to see you and they're your guests! Treat them well. You don't want to strain their eyes when they view your page. Use line-height to make your text more readable. Adding more line height to your text increases the amount of space between each line, and it helps the eye make that jump as it moves down your content.

We'll give the content div a line height of 160%, which basically gives it 60% more line height than it normally has, based on font size. This is a decent amount of line height and gives the text some room to breathe. For the sidebar, since the text is smaller, we'll only give it a line height of 140%. So, now our content and sidebar CSS are as follows:

#content {
	padding: 0 15px;
	font-size: 15px;
	line-height: 160%;
}
	
#sidebar {
	border-left: 1px solid #8FB65F;
	margin: 0 0 15px 15px;
	padding: 0px 15px 15px 15px;
	float: right;
	width: 175px;
	font: 12px Verdana;
	line-height: 140%;
	color: #5A4735;
}

And with this, the text takes on a much more pleasant look. See here. The eyes don't have to work as hard to read the text now, so it's easier for your visitors to consume your content.

Adjusting letter spacing

There are only a couple of places where letter spacing comes into play with this page, but it too can play a part in increasing your site's readability and help make each element on the page more distinct. Headers and headings are usually good candidates for letter spacing. From a design point of view, you can use letter spacing on your header text to add some improved visuals to your page, like we're going to do in the header div with this:

letter-spacing: 20px;

This increases the space between the letters of your text by 20px. 20px is a big number for ordinary text, but for the header at the top of the page, which is just 4 letters, it helps it stretch to be just about as wide as the subheading beneath it, giving it more of a header feel.

For the headings (the h2 tags) in the content of the page, we're going to increase the letter spacing by just 2px. This will lend the headings a more prominent feel and separate them further from the text, and the adjustment is minor enough that it will not distract from reading:

letter-spacing: 2px;

So our header's h1 CSS and our content's h2 CSS now look like this:

#header h1 {
	position: relative;
	vertical-align: center;
	color: #6B5846;
	margin-bottom: -10px;
	font-size: 48px;
	letter-spacing: 20px;
}

#content h2 {
	font-family: Georgia, "Times New Roman", Times, serif;
	letter-spacing: 2px;
}

You can see what it all looks like when done right here.

Expanding on this CSS

There are a lot of different ways you can apply these properties, too. For the design of the page I purposely used a simple, rather unintuitive design so I could focus on the text as it changed during the above steps, but applying this kind of CSS to a much more vibrant and elegant design can drastically improve its effect on your visitors. I don't intend to "pretty up" the CMRT sample page, and if I do, it will be for a totally separate article, but if you'd like to take a crack at making it look prettier while preserving the font and text adjustments, hit me up and we'll talk about it.

Stay tuned for more of the Simple CSS series!

Original design; strict, valid XHTML; top-level page:

Original design; strict, valid XHTML; interior page:

My project was to take four programs: CoffeeCup Visual Site Designer, Microsoft Expression Web, Adobe Dreamweaver, and Microsoft Frontpage 2003 and attempt to recreate the two designs above. Here's the catch: I could only use the WYSIWYG (what you see is what you get) features of each program. I could not edit the code directly at all.

Why do this?

I went to this year's South by Southwest Interactive Festival and attended a panel there titled, "Does Tomorrow's World Need Designers?" The entire purpose behind the panel was to get some meta thinking going on. The focus and general idea was that in the (possibly near) future, individuals would have the tools to easily create and "design" unique visuals for all things — Websites, shoes, cars, you name it — without the need of a professional designer. It was even brought up that in a worst-case scenario, even artificial intelligence could get so advanced that it would "learn" design and create things like unique, appealing Websites on the fly.

I'm not so sure about that last part. But the part about the everyday Joe having the tools he needs to design his site without the skills and knowledge of a designer (that is to say, without knowing HTML, CSS, or having the trained eye of someone who has been working with the Web for years and has seen its trends) interested me. So, arming myself with a series of the most popular WYSIWYG editors, I set out to see how close to this reality we have come.

First up: Frontpage 2003

I went into this application knowing full well that this thing is old. Old though it may be, it's still in good circulation and still one of the most-used programs for butchering the Web with bloated code and table-based layouts building Websites.

Overall, building the design in WYSIWYG-only mode with Frontpage was a clunky pain in the rear. I was forced to draw table layout cells and "style" them with Microsoft Office-style tools, like, "Format Cell..." and "Cell Properties." It was pretty clunky is all I can say, and many times, the cells didn't want to stay where I put them. When you add a new layout cell, all the others try to guess where they're supposed to go in relation, leaving you to manually drag them back to their intended spots, or using the annoying eraser tool (which sometimes erases in the right spots, and sometimes doesn't) to erase borders and cells that the layout added on its own when you added your intended cell.

There were some things I simply couldn't do, like add the background image to the header, without manually coding. So the background had to stay out. In the end though, the product came out looking pretty neat in the designer:

Frontpage 2003, in the design view:

Unfortunately, though, in a Web browser, the design didn't look quite the same:

Frontpage 2003, top-level page, viewed in a real browser (Firefox 2):

The interior page design came pretty close, though:

Frontpage 2003, interior page, viewed in a real browser (Firefox 2):

Frontpage 2003 Pros:

• Lots and lots of features
• Decent help system

Frontpage 2003 Cons:

• Way outdated software
• Still prefers to use tables for layout
• Lots of features, but most you will never use
• The sheer number of features thrown at you can be overwhelming
• Not newbie friendly
• Not veteran friendly
• Barely intermediate friendly
• A page can look one way in the design view, but drastically different in production, and because the design view looks fine, how are you supposed to fix it?

And in this corner: Adobe Dreamweaver CS3! (Mac version)

I knew Frontpage would be a nightmare, which is why I decided to work with it first. I didn't really know what to expect with Dreamweaver. I'd heard good things; I'd heard bad things.

I have to say, it was a nice change of pace from Frontpage. Drawing a layout in a similar manner as I did in Frontpage was much easier, because I could actually use divs instead of tables for the layout. The easiest way to do it was to use the AP (absolutely positioned) divs rather than the normal divs, because to get the most out of a non-AP divs I'd have to do some manual coding.

Drawing the layout was a snap. I drew it up in matter of seconds, and it only took a few minutes to tweak it so the positions were nearly pixel-perfect. You can select a div and move it pixel-by-pixel with the arrow keys on your keyboard, so that was nice. I then filled each div with the content I wanted before I styled the divs.

This is where things got a little clunky. There are very few WYSIWYG tools for adding background colors, changing text (except the size and face), adding margins/padding, aligning a background image, etc. I searched for quite a while for ways to style my page without having to type my own CSS, but it was futile. Eventually I broke down and used the "CSS" button, which seemed to be the only way to style these divs to the point that they would be able to mimic the original design I was working on. The CSS button brought up a semi-intuitive dialogue that let me add some styling to the selected object, and when I was done, the style went over to the pane on the right side of the window.

It was in this little pane that I did almost all of my styling, using almost hand-coded CSS. I say "almost" because there are drop-down boxes that let you choose from a list of elements, like "body," "h1," "a," "a:hover," etc. Since I was not actually in the raw HTML file and typing my styles manually, I figured this was something that could "squeak by" as WYSIWYG. Though in reality, someone who didn't know CSS would have a hard time building an attractively modern site this way.

Having said that, I do think Dreamweaver CS3 is a great program in a professional sense. If I was not limited by this project to just the WYSIWYG mode and could actually use the code editor, I can see Dreamweaver being pretty useful to those who like professional applications for this sort of thing. (I still personally prefer a text editor and a local version of Apache/PHP/MySQL). Though, it is a little overly-technical; the wording for some of the options and the methods of styling they use could be more intuitive and streamlined.

In the end, this is what the site looked like in Dreamweaver's design view:

Dreamweaver CS3, top-level page, in designer view:

And here's what the end result looks like in a browser:

Dreamweaver CS3, top-level page, in a browser (Firefox 2):

Dreamweaver CS3, interior page, in a browser (Firefox 2):

Notice in the top-level page how Dreamweaver had a bit of trouble converting some of the symbols when text was pasted into it. All in all, though, the end result was pleasing and it came close to the original design. Unfortunately, though, I can't say that Dreamweaver CS3 is a tool to quickly-and-easily build a site if you have little knowledge of CSS.

Dreamweaver CS3 Pros:

• Can do some advanced things with the visual editor if you know the CSS
• Adding basic CSS properties to divs with a CSS button is fast on creation
• Drawing a layout with AP divs is a good quick start

Dreamweaver CS3 Cons:

• Not very newbie friendly
• Minimal styling can be done without knowledge of CSS
• Managing your styles and divs can be a pain once you've already created them
• Many features and tools are in illogical places, forcing you to hunt around for them
• You need to know HTML and CSS if you plan to just jump in and use the program; there are no tools for beginners

Ah, Expression Web. Let's see what you've got.

Microsoft's successor to the very dated Frontpage next took the stage. Here's how it went down.

I was presented with Expression Web's interface and, while there was definitely a lot going on there, it was organized pretty well. Just scanning the interface with my eyes, I almost immediately saw the <div> tag just sitting there on the right side of the window; in a neat little pane. Knowing that I needed five divs for the site, and seeing how much time I had to send tweaking the position and styles in Dreamweaver when I used absolutely-positioned divs, I double-clicked the <div> tag five times. Five divs were dropped into my design window, indicated by a small "div" tab and a dotted outline, one on top of the other in block format.

Inside each div I could type and edit text or add images/tables/lists/whatever, as if each div was its own little Word document, using all the familiar Microsoft Word tools. This made adding the divs and their contents easy. So in just a few minutes, I had five divs on my page in blocks, all filled with all their content in 12-point Times New Roman font. Now came the hard part: styling everything. If this was going to be anything like the other WYSIWYG programs I've used (see above), this would be an exercise in stumbling about aimlessly until I found what I needed.

Thankfully, Expression Web is not those other programs. I noticed a “New Style” link on the right side of Expression Web’s window. I clicked it. A dialogue popped up with a menu on the left side with the most commonly-used CSS modifications. Sections like “Box” for the box model (padding and margins), “Layout” for positioning and floating, “List” (for lists when you want to style them; I didn’t make much use of this but it made it easy to change the bullet type when I needed to, and I could see it being easy to create a floated-list navbar with this), and others like “Background,” “Font,” and so on. This dialogue was pretty intuitive, and as long as you know the basics of CSS, you can stumble around in it as an intermediate user and accomplish what you’re looking for. I was able to use this dialogue to assign backgrounds, margins and padding, floating, and positioning to all my divs, because there’s a neat little checkmark at the top of the dialogue that says “Apply to the selected page object.” So if you select an entire div, it gets the CSS. Select just a single word or li element, and only that gets the style. And I didn't have to hand-code a bit of it.

As I added styles to all my divs, they jumped around the page to fit in their proper places. Things (like the footer) that were set to “clear: both” (via the designer mode) jumped to the bottom of the page and filled the entire width of the window, as intended. Text that should wrap wrapped in all the right places; Expression Web handled it pretty well.

At this point, my page was essentially done. I just needed to make a few tweaks to the page. This is where things started to get a little more difficult. Intuitively, I would be able to select any of my divs or other elements within those divs and right-click it, then edit the CSS in the same dialogue I created it in. Instead, when you try something like this, Expression Web throws you into Split view, showing you the raw HTML/CSS of the page in a top pane and your design view in the bottom pane. This was jarring; I didn’t want to edit the code (that wasn’t the point of my project), I wanted to change the CSS in the designer.

It turns out there’s a “Manage Styles” pane on the right side that has a list of all the styles you’ve created. If you mouseover any element on your page, it tells you what style it is using. You then find that style in the Styles manager, right-click it, and then click Modify Style. I think “Edit Style” would have been better wording, and secondly, finding this feature was jarring. Everything had gone so smoothly up until that point.

In any case, using Modify Style brought up that same dialogue and making tweaks was simple enough. However, I needed to make several tweaks (I wanted to go back to some divs and add a bottom border; I also wanted to go back to a couple of the lists and apply custom bullet images; plus, I wanted to change the link colors in only one div). Making several tweaks was too time-consuming, because for each tweak, I had to mouseover the element I wanted to change, find out what style name Expression Web had given it, and then go into the Styles Manager, right-click the style, and click Modify Style, then click Apply/OK before the tweak was done. When you need to make several tweaks, this is not the most intuitive way.

After making all the necessary tweaks, the page came out almost exactly as I wanted it in the designer.

Expression Web, top-level page, in designer view:

And the results in a browser were good too.

Expression Web, top-level page, in a browser (Firefox 2):

Expression Web, interior page, in a browser (Firefox 2):

Expression Web pros:

• If you know a little about HTML/CSS, you can jump right in.
• Easy to get the layout of the page set up with several divs.
• Great styles dialogue to help you style a whole page or just an individual object.
• Just about everything was self-explanatory.
• Easy to scan the program with your eye to find the tool you need.
• Each div you create feels like a mini Word document, with all the familiar text formatting tools.
• Easiest software for someone with a little knowledge of HTML/CSS to just pick up and run with.
• Pages created in this software looked practically perfect in the major browsers I tested them in (IE7, Firefox 2, Safari, Webkit, Opera).
• Of all the programs, Expression Web and Visual Site Designer came the closest to reproducing the subject page exactly. (More on VSD in a bit).

Expression Web cons:

• Making minor tweaks is quick... if you want to make one minor tweak. You have to follow a series of steps to change some of the smallest things, and if you want to change a lot of little things it takes more time than it should.
• The right-click menu is semi-useful in design view, but an "Edit Style" option would do wonders for this program, making it run smooth as silk instead of just "really well."
• Great program; a bit of a steep price. Not good for complete beginners.

Truly WYSIWYG: Visual Site Designer

I've already stated it above: Expression Web and Visual Site Designer came the closest to exactly reproducing the subject page exactly. But how does Visual Site Designer perform?

If I may express the answer in one word: "really well." (Okay, two words.) Upon opening the program, I'm presented with three options: New Website, Open Website, and Use Template. Tempted as I was to browse the templates, this was not my goal. I clicked New Website, and I got a small dialogue asking me for the basics of my design. Title, height, width, background color, and link/visited link colors. After filling out these settings, I clicked OK and the designer view popped up. A blank white screen with tools on the left side and along the top of the window.

It only took a quick moment to familiarize myself with the tools that were there, and it was easy to tell what each tool did at a glance thanks for the colorful icons. Any tools that weren't labeled directly (like the Page, Fill, Effects, Link, and Styles tools) had mouseover tooltips and a handy dialogue explaining what they do when you use them the first few times that you can disable via a "do not display this dialogue next time" checkbox.

There were no divs, no HTML tags, no CSS styles; the entire designer is truly WYSIWYG. Creating the layout of my page was braindead simple: pick the rectangle shape tool, give it a color, draw. I drew the header, sidebars, and footer in a matter of seconds, and was able to adjust their shapes, colors, and sizes in the object window. The object window was a neat little feature; it floats as a separate little window, and it changes to depict the settings of whatever tool you have selected. This way, you never have to look around for your tool settings; they're always in the object window so you always know where to look.

After drawing the layout of the page, it was time to add the text. Clicking the text tool changed the object window to let me change the font family and size, and I could see that there were other options that would let me do things like add drop shadows or even rotate text if I wanted to. Unfortunately, this design did not call for these fun-looking features so I had to dismiss them for now and just type normal, colored text.

When I clicked on my page with the text tool, a red text box popped up with a little handle on top that I could use to drag it, and left/right arrows on either side of the box so I could widen/shrink it. I stretched the box to a decent size and typed in the content, then highlighted the text and formatted it with the correct colors/sizes in the object window. Repeating this process for each section of my page, I was done with the page content in minutes.

Similarly, dropping in images was a breeze. Click the image tool, browse for the image, click OK. Now you can freely drag it anywhere on your page. Again, in the object tool, I saw more features than I required, like adding a glow/shadow or shaping the image (rounded corners, pentagon, circle, etc.), but again my design did not call for this so I had to play with those later.

By the time I had my page laid out the whole thing was 95% done, I had lots of objects on the page. Sidebars, a header, a footer, a background image for the header, a few textboxes, a couple of images... none of these by themselves was any problem at all to create. However, when I needed to go back and change something, I found myself having to watch carefully where I clicked my mouse. There's no way to "lock" objects in place in Visual Site Designer, so when I wanted to select the text in a sidebar, for example, I had to be careful to select the text instead of the sidebar, or else I might end up dragging the sidebar accidentally or worse, changing some of its attributes. This was not a major flaw, because there is a multi-step Undo in case you accidentally do something like this, but the entire operation in Visual Site Designer seemed designed to be fast and smooth, and for the most part, it was; but this little bit of technicality hindered the "carefree smooth design" feeling I got when using the software.

A really big time-saving feature in Visual Site Designer was its "copy page" function. When you click the "Add Page" button to create a second page (which I needed to do for the interior design), I was given the option to copy an existing page. I copied the homepage, and it created an exact replica of the page I had just created. Now, all I had to do was adjust the left sidebar and remove the sidebar on the right, then change the content and I was done with the second page. If I wanted to create more pages, I would definitely be using the copy page function to keep my design intact and keep all pages uniform.

I never once had to type a line of HTML or CSS to do this. In fact, I couldn't: Visual Site Designer is completely WYSIWYG; you don't get direct access to the page's HTML/CSS. Visual Site Designer handles it all for you in the background. However, this is not to say that if you want to use HTML you can't; Visual Site Designer has an HTML Tool that will let you insert an HTML object. Basically, this creates a div of any size/shape/position you want, and you can insert hand-written HTML, CSS, Javascripts, whatever. Unfortunately, for the sake of this project, I could not use that.

So, in the end, here's what the page looked like in Visual Site Designer:

Visual Site Designer, top-level page, in design view:

And in a browser, the designs look pretty close to the original page.

Visual Site Designer, top-level page, in a browser (Firefox 2):

Visual Site Designer, interior page, in a browser (Firefox 2):

Visual Site Designer pros:

• Really cost-effective. A mere $49.00 USD, compared to $399 (Dreamweaver), $299 (Expression Web) or $129 (Frontpage, through Amazon.com).
• Really easy to use.
• Of all the programs, Visual Site Designer and Expression Web came the closest to reproducing the page exactly.
• Truly WYSIWYG; no need to know HTML or CSS. Extremely beginner friendly.
• Fastest of all the Web editors to complete the job.
• Built-in one-click upload.
• Manages all your files for you.
• All the tools feel unified; they share the same properties window so you always know where to look to change settings.
• Many shapes to choose from, and placeable guides with X Y coordinates make it easy to design a layout.
• Creating new pages for your site while keeping the same layout is easy; just create a new page, and select the "copy page" function to copy an already-existing page and just change the content.

Visual Site Designer cons:

• No code view; you can't edit the HTML directly (however, there is an HTML Tool that will let you use advanced HTML and scripts on your page in an object-based manner).
• Cannot edit pages that already exist. VSD can only create new sites, or edit sites it created.
• Click carefully; you don't want to accidentally move some of your page elements if you have multiple stacked on top of each other. This isn't a major flaw because you can always Undo, but if you're in a hurry you could accidentally select an object you don't want selected.

So, does tomorrow's world need designers?

Heck yes. In a nutshell, I wouldn't recommend Frontpage 2003 to anybody for any purpose, to be perfectly honest. Dreamweaver CS3, though, could be a good application for serious web development for those who already know the technical side of things, and I really think it could be good for web developers in a professional environment, but because of its high "techy-ness," it's definitely not a tool that could let the average Joe create a "Web 2.0" site.

Expression Web and Visual Site Designer, though, are steps in the right direction if providing easy-to-use WYSIWYG tools is the future of Web design. In a reality check, though, in most of these programs, I could not have created anything near the designs I did above if I wasn't already familiar with Web design. If I was to challenge the average Joe with the project above (to exactly copy an already-existing design from scratch), he'd have to sit down and do some research first, and I imagine it's reasonable to think it would take him days to accomplish the task.

The only exception is Visual Site Designer, in which you can basically just draw your page. But even with software this intuitive and quick-to-master, the tools are no replacement for knowledge and skill in the field of design.

Expression Web and Visual Site Designer are both Grade A tools, but professional and even hobbyist Web designers are a long way off from being replaced by such tools, though beginners, intermediates, and veterans can find something to like in both of those programs.

The ominous, impending uprising of maniacal artificial intelligence that designs Websites, on the other hand, may be something to worry about...

For many front-end developers, HTML remains mostly an excuse. It is viewed as a language of hooks, constructed for adding javascript, css and other enhancements to web documents. In recent events, this kick-started a small semantics debate again, where people were reminded about the semantic value of HTML. A reminder voiced by raging standardista, still fired up from previously fought debates and awareness battles.

HTML != Semantics

Everyone with a passion for front-end development will recognize the importance of the standardista when it comes to HTML awareness. Yet this doesn't mean that their methods should go totally uncriticized. With all the attention they raised for the semantic function of HTML, some people have started to see HTML as a purely semantic language. Which it is not.

Evidence of this can be seen in the "divitis" issue that followed the early rise of web standards. When front-end developers were urged to switch from table-based layouts to div-based layouts, some took the advice a bit too literally. They turned everything into divs, ignoring the semantic purpose of the elements at hand. This triggered an ever bigger reaction of the standardistas and led to demonization of the div element. Divitis was considered the AIDS of front-end development and using divs became almost taboo. Only when absolutely necessary were they allowed.

Enter Minimal HTML

The fear of purely structural elements (divs and spans) branched off a new movement. A group of people that didn't believe in the absolute need for structural elements and tried to build pages with purely semantic elements as much as possible. They banished extra divs when used for styling but forgot about the original function of the div and span along the way. In the end, they made HTML a poorer language than it was supposed to be.

Consider the following two basic page layouts. A simple layout consisting of four main areas. The context area gives contextual information on the main content area. A layout like this (not considering any graphical design enhancements) could easily be made with four divs. This is setup A, preferred by minimalists. Setup B shows a situation where the layout is build using five divs. Take a moment to think which setup you prefer, purely on a structural basis.

HTML = Semantics + Structure

HTML is more than just semantics, it's also about structuring your document. The main difference between both type of elements is that semantic elements explain the purpose of an element, while structural elements explain the relation of its content to the content of other elements within a document.

In setup A we have four separate divs, structurally all on the same level. This tells us all divs are related in the same way, only the order of appearance will indicate some sort of relationship. In setup B the main content and context area are grouped in a content div. This is an indication that the relation between context and main content is a lot stronger or at least different than the relation to the other element. And on the other hand, the content area shares a similar relation with header and footer.

Structurally, setup B not only holds more information about the relationship between the separate areas, it's also more correct. This makes it the better implementation of the two. The extra div used to group main content and context is not useless, but adds useful meaning to the document.

Enter Minimalitis

Minimalitis is the disease formed by the aversion of divitis, and is equally dangerous as divitis. People who suffer from minimalitis will write badly structured documents and will often incorrectly use (or simply abuse) elements to avoid the use of divs (often they use a p tag) and spans (em, strong and even the b tag are popular). Another sign is the merge of block and inline elements on the same level. While this is not exactly illegal, it's a serious warning of possible minimalitis and bad structuring.

And yet, the cure for this disease is simple. Reinstate the power of the div and span, but use it for its intended purpose. Use divs and spans to bring structure to your document. Contain elements that share a similar relationship within the same level. Use it to separate elements from others that share a different relationship. And use them together with a meaningful class or id whenever you don't have a valid semantic element to describe your content.

The Future of Structuring

Luckily, the people working on HTML5 have understood this and added a couple of extra structural elements to the language. Instead of leaving us with a simple div and span, two elements with a simple structural meaning, they added elements like footer, header, article, section and aside to help us better define structures in HTML documents.

The fun thing about these elements is that they not only hold structural meaning but also semantic meaning. Instead of simply structuring a document they hint at the relationship elements bear to other elements or the page in general. Tags like footer and header not only contain a section of a document, they also hint at the function of the contained elements and the relation to the other elements on the page.

Hopefully this will give the opportunity to those suffering from divitis or minimalitis to write better structured code while keeping the document as semantic as possible. Until then, just know that a div has more power than simply adding a rounded corner or border to the graphical design. Structural elements are there to reveal relations between elements, a sometimes forgotten power of HTML.

Personal Promo

Niels Matthijs spends his spare time combining the luxury life of having no kids and a wonderful girlfriend with the agonizing pressure of blogging under his Onderhond monicker. As a front-end developer he is raised and nurtured at Internet Architects, a Belgian company investing a lot of time in making the web a more accessible and more pleasant place.

7. A Usable Page Weight

Ironically I used to hate the Web. I started with dial-up and it was a miserable experience. Moreover, back in the day it seemed that every site I visited required some sort of plugin or add-on to make it work. Frankly, the Internet was a pain in the butt. This has changed on some levels. The need for plugins or add-ons is greatly reduced what with operating systems pre-loaded with all the necessary support. But some people still have dial-up. For the last six years I’ve had cable broadband and it’s a dream. I’m spoiled. And it’s very easy to forget the less fortunate and go hog wild, loading my pages with heavy graphics. It’s easy to forget how doing this will make for a less-than-happy experience to traditional dial-up and distant DSL users. Gotta keep the weight down.

I’m not saying the Web isn’t a place for heavyweights, it is, but with due consideration. If you want to offer heavyweight graphics and whatnot, let visitors navigate to them, instead of offering them on the initial page load. And warn users if something big is coming up. It’s only fair to allow those who want to opt out the opportunity to do so.

I suggest aiming for an upper limit of 100kb per page of combined background and embedded images (this is testable). You can buy a lot for a 100kb. To get the most bang for the buck, reduce the over all number of images, optimize them exporting only flattened, compressed files, and please pre-size embedded images for their location (being sure to add the height and width attributes to the img element). I’ve seen thumbnail-sizes that were really 900kb monsters with styles off! That’s just wrong.

8. A Helpful Error Page

If you’ve ever been lost, it’s always nice to see some helpful soul willing to give directions (assuming you are willing to admit you’re lost). On the Web you can be that helpful soul. Not only, as mentioned in the last installment, can you offer a site map to proactively guide your visitors, you can offer a friendly, styled “404” error page (or pages if you want to cover more errors). Your error page should offer at the very minimum offer a link home, a navigation menu, and at least a link to the site map. If you want to be a really helpful soul, though, try combing most if not all your nav tools and putting them on one page. Make a perfect 404 page offering a site map on the page (easy with dynamic site maps), search, even contact info, and more.

This is not hard to do. Ask your Web host for starters. Specifically ask them about custom error pages since you’ll want to provide something useful and most default server error pages, even styled ones, aren’t really very helpful at all.

9. Good Headings

In the last installment I spoke of the importance of using the right mark-up for the purpose at hand. I mentioned headings but didn’t go into detail. That’s because headings are so important they, well… they deserve a heading of their own. The use of headings is logical, and styling them is wide open, just use your imagination.

What good are they? They offer section demarcation, semantics and ordering, beauty in the right hands, a search indexing benefit, greater accessibility, and even a navigation source for some users of assistive technologies like screen readers. What more incentive could you possibly need to act on this recommendation?

10. Jump Links Provided

You may have detected by my suggestions so far that I’m big on helping Website users. I feel that the easier my sites are to use, the better their experience will be. I want them to not only find the goods, being supported along the way as needed, passively and on demand if at all possible, but I want them to want to come back. So, one of my twelve is going to have to be offering skip or jump links. I find these are very helpful to everyone with exception to most of those who use a mouse or pointer — and that is a greater number of people than you may realize. A jump link affords users the opportunity to jump down the page to the content or navigation, by-pass redundant or lengthy sections, access help content, and jump back up the page if you consider a top link or back to menu link a jump link. I do. Some may argue that it’s a replication of browser behavior offering links like this, but I’ve not heard recently of record numbers of browser-savvy surfers if you know what I mean. Plus, they’re simply innocuously helpful.

One rule: If you’re going to offer jump links, it’s best to make them visible, but not always necessary. There are ways to hide jump links from view while still maintaining a high level of accessibility and usability to a very large percentage of users. Do note, however, that displaying them will increase that percentage to 100.

11. Focus Styles

I’m not a dedicated keyboard user, but I do use my keyboard a lot. It’s helpful at times, convenient at other times. It’s an option. Sometimes I use my keyboard on the Web, tabbing onto pages, bouncing around from link to link following the natural source order of the page. Sometimes, however, depending on the site, this can be difficult. I’ll be tabbing along, minding my own business, when all of a sudden, wham, I’m lost. I don’t know where I am on the page. The reason is invariably the developer of the site failed to offer one to the most simplistic of accommodations: link :focus. Probably due to simple ignorance. But I’m here to change that.

To offer link focus it involves nothing more than a simple style sheet entry, like this:

The a:active is for Internet Explorer, and to provide the when-activated styling on other graphical browsers. Obviously you can get more creative, but that above will help make your Web pages a lot more navigable to keyboard users and nobody will suffer a diminished experience.

12. Robots.txt File

You may be wondering why I included something so mundane as a robots.txt file in this line-up, but I feel it’s very helpful to have one. It provides instructions to honest indexing robots and spiders like the GoogleBot, telling them to stay out of certain directories you don’t really want them in anyway. Why have your bandwidth wasted needlessly?

Some people, I’ve heard, want to disable right-click on their sites thinking that they may somehow actually succeed in stopping people from copying their images (can’t be done), yet they don’t have a robots.txt file excluding their images directory. The latter would be far more worthwhile. It’s very easy to make one, there are even tools you can use to help you get the job done.

Is There More?

The short answer is, yes, of course. But if you satisfy all twelve items in this two-part article, you have done well. You’ll be offering a quality site that is a cut above many sites of the Web. And the benefits, you may find, will actually be noticeable, and perhaps even tangible. Happy coding.

1. A Proper Navigation Menu

Any domain on the Web that consists of more than one page is a Website and as such needs to be navigable. Now this might seem obvious, but if that is so, why do I occasionally encounter sites with mystery meat navigation? Or, on a deeper level, are inaccessible because they require JavaScript or images in order to function. These must be a upper layers consistent with a progressive enhancement, not a requirement. An easy to use and accessible navigation menu must be available. There are other concerns as it pertains to building a proper navigation menu, as well, such as…

• Its link styling the :hover, :focus, and :active pseudo elements.
• The semantic use of lists to properly organize your links into a proper menu.
• And even going so far as marking the current page.

2. A Meaningful, Well-Formed Title

By meaningful title I am specifically referring to the title element — what’s shown on the title bar of your browser. Ideally the content title should come before the site (this helps search users find stuff like your main content heading, instead of seeing your site name over and over again) and, if at all possible, each page should have its own title. This is an example of an effective use of the title element:

Note: I prefer using a hyphen separator, but the vertical bar or pipe used on this site is fine.

3. A Method of Contact

I can’t recommend putting your email address on your site, even obfuscated unless done in a way that is actually secure (shop around but buyer beware, many touted methods don’t work indefinitely), but offering a means of contact is almost always necessary. It not only lends itself to sense of legitimacy, it’s simply the right thing to do in service to your visitors. To facilitate this, offering a phone number and address is good, if possible, and a contact form is a nice option in lieu of a mailto: email link that not all visitors will be able to use anyway. However, since some visitors are robots or people up to no good, use a secure contact form. It has been argued that client-side spam filtering negates the need to protect your email address on the Web, but your address can still be harvested and put into use. There is no winning this war — not as long as common account names like info@yourdomain.com, contact@yourdomain.com, and admin@yourdomain.com can be put to use as soon as you register a domain name — but it doesn’t mean we should make it easy.

4. A Site Map

Not all site visitors are well served by a site map and not all sites require one. Say, for instance, you have a basic five page site with a clear and consistent, and readily available, navigation menu. You could probably do without a site map. But how many sites freeze at five pages? Experience over time has taught me domains tend to sprawl as new needs inspire new pages or applications. Start your site map as soon as it starts to grow, or consider adding it to your site from the beginning. At first you can link to it from the footer, then later move the link to a more obvious location as the site grows, since more visitors will find it useful. On small sites I will often incorporate the site map into a “site help” or “site info” page, killing off numerous birds with a one stone — accessibility and copyright statements, privacy policy, etc. If you aren’t yet convinced, also know that many users, most notably the blind, will seek a site map first since it gives them a snap-shot of the domain’s offerings, so to speak.

A site map can be as simple as a Web page with an unordered list. Maintaining it can be quite simple: add a new list item when a new page is added. The hardest part is actually remembering to update it. That’s where the beauty of dynamic site maps really shine. Applications such as WordPress, as just one example, afford users the opportunity to create everything from simple to complex site maps with not much more than a simple function call. “Plugins” are also available further simplifying the process for novice users. And if you want to step it up a notch, you can also offer an XML site map but know that an HTML site map is what I am referring to. People should come first, not robots and spiders.

5. Passive Accessibility

I’m not going to bore you with some soliloquy. I will say this, though: Your Website should be accessible. Whether or not you do it for your visitors or for yourself is irrelevant. If you do it purely to satisfy your own needs your visitors will also benefit… can’t be helped. So, it’s all good. If you’re not familiar with the advantages to having an accessible site, maybe this presentation will help explain why accessibility makes sense. If you’re not familiar with Web accessibility, there are helpful links on the last page of the presentation. You can also get some basic info from the Web Accessibility Initiative (WAI).

6. Standardized Markup

This, like offering a proper navigation menu, may seem obvious, but it’s a big failing across the Web. From using tables for layout, to the improper use of breaks, to using a "big-bold" font style instead of a heading. Using the right markup for its designated purpose, without going overboard by stretching it usage, is useful not to not only accessibility and usability, but the practice of using semantic markup helps ensure forward compatibility. Truthfully, if you’re about to build a new Website and you’re planning on using tables and old practices, fuggedaboudit. You won’t be doing yourself or your client a favor if you don’t make peace with CSS and valid HTML 4.01 (for awhile) or XHTML 1.0/1.1. (A little accessibility awareness isn’t going to kill you either.) Web standards aren’t a joke and your cooperation in their adoption is of great importance.

Move on to Twelve Things Most Sites Need - Part II

The MAMP Package

You can download this complete, self-enclosed web development environment from the MAMP website.

After downloading and opening the MAMP .dmg file, simply drag and drop the MAMP folder to your Applications folder. If you like, drag and drop the MAMP dashboard widget into your Library/Widgets folder. No command line, no installation required.

Run the Mamp.app application, and configure the servers to your liking. I always set the Apache and the MySQL port to their defaults rather than the MAMP default. I've already made sure that Personal Web Sharing is turned off in my System Preferences. But if you like, you can have both available by using the MAMP defaults for the Apache and MySQL ports. You'll need to make sure to use those ports in your URLs and your database connections, though.

You can also choose where to have your htdocs folder (your site root) if you don't want it in /Applications/MAMP/htdocs. You could have it in your own user folder if you like. I just leave it where it is, and in the Finder drag the htdocs folder into the left sidebar for quick access.

You can also choose which version of PHP you want to develop for. That is one advanteage to the Dashboard widget; you can quickly switch PHP from 5 to 4 for testing purposes.

Of course, the Pro version has a lot more options, but I find the free version quite sufficient for development purposes.

The MODx CMS

For a few years now my preferred content management system has been the MODx CMS/CMF. For my intermediate level of PHP programming and HTML/CSS design skills it has proven to be a perfect match. I'm not going into installation and configuration of MODx, since it has extensive documentation as well as a Wiki and a very helpful forum community.

The biggest advantage of MODx to the web designer is its simple templating system. Actually, it's not really even a system. You simply use the HTML code for the look you want, as in any flat HTML file, then replace content text and dynamic data (such as menus) with simple tags. Each document is processed to replace those tags within the HTML template with material relevant to that page as the page is requested.

The advantage to the PHP programmer who wants to develop custom dynamic content is the separation of the presentation from the layout using simple tags to include the final return value of your code.

Put together, this makes MODx a perfect framework for Web 20 and AJAX applications. And that brings us to the meat of this article.

Using the Extjs Library

The next version of MODx will be a complete rewrite of the existing application. The back-end management makes extensive use of the Extjs javascript library. I've worked with Javascript and AJAX from raw XMLHttp functions through Prototype, Mootools and JQuery. But I thought that, given my favorite CMS will be using ext, it would be a good idea to get familiar with that library. So when I needed to do a redesign of a client's site that had a plain PHP data view grid, I decided to turn that into a fancy AJAX paging grid with column ordering and a simple search field.

The requirements were that when a user logs in to the site, he is sent automatically to the data viewing page. This is a built-in function of the MODx user validation system, so that was no problem. Second, the data viewed must be filtered by the username of the logged-in user. Third, the data must initially be sorted by an arbitrary field. Then the user must be able to sort the data by the column of his choice. Fourth, the data grid must enable paging, since many of the viewers will have several hundred records of data to view. Fifth, the user must be able to enter a simple word or phrase and view all rows where any of the fields contain that word or phrase.

A basic ext paging grid fulfills three out of the remaining four requirements, with the addition of the initial filtering parameter being so simple that it almost qualifies anyway. I'm no Javascript guru, in fact I frequently wonder why I have anything to do with it at all, but this project turned out to be not so bad.

For the most part, I simply copied the sample paging grid. I only needed to adjust a few things to customize it for my situation. It took a bit of searching through the documentation, and a bit of trial-and-error, but in the end a really nice grid was set up.

Hacking the Paging Grid

There really wasn't much to do to modify the demo Paging Grid to suit my purposes. I simply removed the parts that I obviously would not be using and modified those that I would. The hardest part was digging through the ext API documentation to figure out what parameters were passed to the back-end processing script by the ext AJAX request mechanism.

First, it's important to always set the path to the single-pixel transparent image that is used to format the actual grid generation by the javascript. By default, this is set to the ext site, so you need to set it to wherever you installed your ext library files.

Next, you need to set up the data store object. There are a number of parameters for this object, but most of them work just fine with the defaults for most uses. To see the full set of options for the store object, go to the api documentation, then ext->data->store in the menu on the left.

I just modified the proxy and the reader objects to suit my needs. Since my data resides on the same server as the script, I used the HttpProxy.

For the reader, you need to adjust the incoming values to match your data fields. The elements need to match the names you give your array of database rows and the row count in your processing script. The 'id' value is the HTML tag ID that ext will use for the grid for styling and DOM traversal, so it can be whatever you like.

One issue that is not really ext-specific but caused me a few hours of grief is to watch out for the commas ending the parameters. Be very careful not to have a stray comma, especially after the last parameter in each object definition. Internet explorer takes violent exception to extra commas and won't display your grid at all. Commas aren't very big, and IE is not very helpful in its javascript error messages, so it's not always easy to figure out why IE is being so recalcitrant.

Once your data store is set up, the actual grid gets defined. First, establish the layout of your data in the grid by configuring a ColumnModel object. Again, it's not at all difficult to modify the demo grid's column model to fit your data model. The documentation for the grid and column model objects can be found at on the same API page, this time in the ext->grid section.

To make the columns of the grid sortable, you can either specify each column being sortable as you define them in the ColumnModel, or you can set the default sortable status after defining the column model object.

Setting up the grid itself was a bit more involved. It took some study of the API documentation to understand what all of the options were for, and which ones I wanted enabled and which ones I wanted to disable. Primarily, you need to set 'el' to the HTML element you put in your page's HTML to contain the grid, 'store' to the store object you defined earlier, and 'cm' to the column model object you defined.

The bottom bar (bbar) is of key interest, since it's here that the paging and the search field would be defined. There are a number of bottom bars you can choose; fortunately the demo paging grid comes with the paging bar you want for a paging grid. The bar itself is an object, and has its own entry in the API documentation at ext->util->PagingToolbar. The object has all of the functionality of paging controls built-in, all you need to do is set the parameters, such as how many rows to show at a time, and what to display as information on the right side of the toolbar.

Adding a Search Field

This was the hardest part of the whole process. Actually, it only took me about half an hour to get the basic paging grid working with my data. Adding a button and a field for entering a search word or phrase took another two days.

It turns out to be pretty easy to add things to the bar, it was just a problem in finding out how, and a lot of trial-and-error getting it to work right. Of course, a stray comma as mentioned earlier didn't help, since it was difficult to tell whether it was my attempts to add to the bottom bar that was killing IE or something else altogether.

In the end, I finally figured out that all you need to do to add elements to the bottom bar is simply put what you want in the 'items' parameter. To make a long story short, I'll just show the code I ended up using.

What this does is first put a hyphen after the paging controls. Then it inserts a default element, a button, and defines the handler function for the button's onclick event. The button's definition doesn't need to be specified as does the input field added later, since they are the default for added items to this toolbar. The handler function just reloads the grid's data store. Since the grid is not yet completely defined, the bbar object is not yet available, so you can't use its copy of the store object. That is why I used 'grid.store.load()' instead of 'bbar.store.load() in the handler function.

The input field for the search word or phrase took a bit more defining. The 'xtype' tells ext what kind of element this is. It needs an ID so its value can be gathered later to pass in the AJAX request. The autoCreate values tell ext how to generate the element; in this case it will be an HTML input tag, with the tag elements as specified.

With the grid object finally defined, it's time to build it.

At this point, you'll actually get an empty grid displayed on your page.

Since my requirements included filtering the data, I need to establish the parameters that will be sent to the processing script in the AJAX request. This is accomplished by the data store's baseParams parameter. I created a handler function for the store's beforeload event.

This gets my client's login name from a display on the page, and gets the search word or phrase from the input field I added to the bottom toolbar. Now every time the store is loaded it will send these values to the processing script.

And at last, the AJAX request is sent off, with the initial values for paging.

Looking at the original demo code, you'll notice that the whole thing is wrapped in one big onReady function. As soon as the page is loaded and the DOM is available, the AJAX request is sent and the first set of data will appear immediately. The paging toolbar automatically keeps track of where it's at in your data, so each subsequent request will carry the appropriate start and limit values with it.

The Processing Script

Ext doesn't care at all what scripting language you use for processing the AJAX request. It only requires that the return values be in the same form that you specified in the 'reader' parameter of your data store object. In this case, I used a json reader, so my script needs to encode the result set from my database query in json format.

The ext AJAX request will send request parameters as GET if only a default set of parameters are used. If custom parameters are added, then it uses POST. In PHP it might be safest to use the REQUEST array to be able to access both.

I had a little trouble figuring out what parameters ext sends for the column sorting feature, but finally found the relevant documentation in the ext->data->store API documentation, in the Remote Sort configuration item. It sends two parameters, 'sort', the field to sort by, and 'dir', the direction to sort (asc or desc). Armed with this information, plus that it can be seen from the demo that the paging parameters are 'start' and 'limit', and I had defined the baseParams myself as 'client' for the client name filter and 'filter' for the search field value, I was able to build my SQL queries to establish the number of records being returned, and to get the desired rows to load into an array of objects to be json encoded. The exact details are not important, as every scripting language will have its own way of dealing with building the queries and connecting to and querying the database. The database itself isn't even important here, since your request processing script can access any available database from sqlite to Oracle.

Once the data is gathered and the results json encoded, the request result are returned to the AJAX handler.

This line in PHP invokes the callback handler with 'total' set to the number of rows returned, and 'results' a json encoded array of the rows returned by the query.

The reader object defined in the data store object's parameters can take this data and feed it to the grid, which will organize the data into the form specified in the column model object. The 'results' array will be loaded into the reader's 'root' parameter. The 'total' value is loaded into the reader's totalProperty parameter.

Although it took a bit of study, the ext data grid example proved to be an excellent starting point for a customized data display. It makes a very pretty sortable paging grid with additional custom features in the toolbar with a minimum of bother. I've always known that Javascript and AJAX could make some nice user interface tools, but as I get to know ext I can see a lot of very interesting possibilities for future applications.

About the Author

sottwell has been my alter ego for more than ten years now. It didn't come easily as I grew up in an environment where "those computer kit things would never be of any use, and girls don't do that kind of thing anyway". Married right out of high school, it was more than 20 years later before my husband finally decided that he could use a computer himself, so we would get one. A year later, I bought the parts to build my own. The shop owner didn't want to sell me the parts; he actually told me, "Go home and knit booties for your grandchild". Four days later, I faxed him from my new computer requesting a return fax of his price list. Within two minutes I had a surprised phone call from him, and a few months after that he offered me a job.

Since then, I've run two computer sales and repair businesses in two hemispheres, taught online programming courses in assembly, C++, QuickBasic and VisualBasic, worked for a high-tech startup, and now I work in freelance web development. It's been a lot of work, but it's also been a lot of fun. On the way, I've added six more grandchildren, and yes, I can knit booties for them!

You can see what I'm up to at my two sites, sottwell.com and loripsum.co.uk.

Design on the Web has obviously come a long way too. The 'standards battle' appears to have been won, developers have been shown the light and it's only a matter of time before font tags and spacer gifs become a distant memory. We're past the 'browser wars' and Internet Explorer 6 is finally losing its stranglehold on the market, giving way to more standards-compliant contemporaries or at least IE7.

These two developments are linked. Society's dependance on the Web is affecting kids before they hit double figures. I've had the pleasure of showing my two young cousins the wonders of Google and watching their faces light up at the interactive content freely available to them. As more and more kids use the Web every day, they'll want to learn about the ins and outs of this fantastic tool and begin to dabble in HTML and CSS. The larger the user base, the more developers are bound to emerge.

There's never been a better time for this to happen either. Those who explore beyond the inputs of a blog entry form will find an industry very different to that discovered by the previous generation. Imagine going back in time and building your first Website with clean, semantic markup, separated CSS and unobtrusive JavaScript. The methods are no harder to grasp than were tables in the 90s, but not having to unlearn all those bad habits will give every budding developer a head start.

If we're lucky, IE8 will have taken hold and the new breed of developers will be designing for a purely Acid2-approved range of browsers. I won't speculate on the benefits future developments in CSS and HTML could bring alongside this but hopefully we'll see an increase in pace as result of the industry's increasing popularity.

It won't all be plain sailing; more young people getting into Web design is bound to bring problems too. A tolerance of bad design and usability seems to have built up amongst users of sites like MySpace. There is a danger that this will continue, filling the Web with deserted, poor quality blogs and Websites. Also, as formal education in the subject is lacking and cannot keep up with the latest Web technologies, quality work will only really come from those who have the passion and determination to pursue it in their own time.

I built my first Webpage in 2002 (unfortunately using old methods) just as the standards movement was picking up speed. I may have continued to design that way for years were it not for the community sharing tips on forums and personal sites. The agelessness of the 'Net breaks down barriers between experienced and teenage developers. I was able to get friendly advice on building my first site when I was 11, a testament to how the Internet can educate kids where schools let them down.

When I launched samrayner.com at the beginning of this year, the response from people I had never met was as positive as the reactions of my family and friends. For one of my first blog posts, Veerle Pieters and Elliot Jay Stocks were kind enough to let me use their sites as examples after receiving an email from me out of the blue. Its great to see the recently announced finalists of the SXSW Web Awards in a category devoted exclusively to the student Web designers who are refreshing this industry with new talent and new ideas.

This spirit of openness and encouragement is what I have come to love about the Internet. I look forward to the new generation of Web designers and hope to do my bit to help them bring creativity, innovation and a new perspective to what we do.

First Method: Inline Style

The first way to do this would be to apply a style attribute to your links containing the CSS property "text-decoration." Like so:

 <a href="link-to-page-here.html" style="text-decoration: none;">Link text here!</a> 

This will create a link with no underline, but it will only affect that link, so you'll need to apply the style attribute to each link that you want to appear without an underline.

Second Method: CSS Declarations in the Header

In the <head> section of your page, you can declare CSS that will affect the entire page. If you want all of your links to appear without an underline, you'd put this in the head section of your page:

 <style type="text/css">
 a { text-decoration: none; }
 </style>
 

So, overall, the top part of your HTML might look something like this:

 <html>
 <head>
 <title>This is the title of my page!</title>
 <style type="text/css">
 a { text-decoration: none; }
 </style>
 </head>
 <body>
 Rest of your content goes here.... 

Now, every <a> tag on your page will have its underline removed and there's no need to include the style attribute in each individual link.

There's a lot more to learn about CSS than just what's here, but I figured this short article would help some people out. It's a good way to get your feet wet with styling your page with CSS.

If you'd like to learn more, read CSS From the Ground Up.

If you're a new designer or you're already building pages and need to up your game, read on. These are the things that every Web designer should know.

Web Design Basics

First, you need to sit down and think about what your goal is with your Website. I already have the answer to that question for you, but do you?

You may immediately come up with answers like, "to make money," or "to tell my story," or "to keep up to date with friends." These are the ideas for your site, but they most likely are not your goals.

You may not know it yet, but your goal with any Website is to have it seen. You won't make money, share your story, or keep up to date with friends if nobody sees your site. Even worse, you won't accomplish any of these things if someone does see your site, but quickly turns away. The only way to keep your visitors from leaving your site almost immediately is to have a good, effective design.

Web design is so open-ended and the ways to build your website are numerous. As with anything else, though, it's good to have structure when building your site and always keep a handle on the best practices. Below you'll find a few of the most important rules and guidelines to designing an effective Website.

This is Rule Number 1, and the Number 1 Rule: Keep it simple. Don't make the user think about anything! The key words to remember are "instant gratification." The Web is becoming faster and filled with more and more information every day. Users have the freedom to pick and choose whatever medium best suits their needs the fastest, and you can bet they will instinctively exercise that freedom at every opportunity. If your website doesn't immediately and effortlessly meet their expectations, they will click their Back button and get right out. This rule will be emphasized more a bit later, but always keep this in the back of your mind.

Know your HTML. This one may seem obvious at first glance, but there are too many people out there using WYSIWYG (what you see is what you get) editors and trying to pass themselves off as "web designers" without knowing any HTML. Don't get me wrong; I think WYSIWYG editors have their place among the consumer base, but they're simply not the right tool for a completely effective and successful Web design that will hold a visitor's interest and make your ideas worthwhile.

There are plenty of places online where you can get some basic HTML training, and of course you can always keep an eye on WPDFD for new ways to do things in HTML. If you don't know HTML and are serious about building an effective Web design, you can start by perusing the links below to get a handle on HTML.

• W3Schools HTML Tutorial
• PageTutor.com: HTML Tutorial
• [Book] My Website is Better Than Yours
• [Book] Amazon.com: HTML, XHTML, and CSS, Sixth Edition (Visual Quickstart Guide) (Paperback)

Use "Web safe" fonts. There are hundreds of thousands of fonts nowadays, but only a small handful of them are considered "Web safe." Not every computer is going to have every font installed, so when you use a font on a Website that a visitor doesn't have, their web browser will default to a fallback font. The fallback will likely make your design look much uglier on the site and deter visitors if it's difficult to read.

You can find a list of Web-safe fonts here.

Stick with standard layouts. Naturally, as a designer, it's fun to get creative every now and then and come up with a site that doesn't follow conventions. Maybe your site is completely Flash-based and uses the keyboard's arrow keys for navigation, or maybe your site scrolls left and right instead of up and down. While these designs are creative and make a statement, they are not effective designs. This is because users, when they visit a website, expect a standard convention. Sites like these cannot be easily scanned or navigated, and it slows the browsing process. If the experience is jarring in any way, you're likely to lose a visitor.

Good, standard layouts can be found everywhere. Take a look at this very site, WPDFD. It's a two-column layout with top main navigation and a header/footer. It's simple and the focus is on the content. Your browsing experience isn't hindered in any way. Other sites with good, clean and usable designs include A List Apart, Simplebits, and artypapers. Oh, and of course, you can't forget Google and its host of utilities.

Try to keep images small. Not necessarily physically small, but small in file size. It's true that a majority of users are connecting with a broadband connection these days and page loading time is not nearly the concern it was back in 1998 when the majority of users were dialing up to the Internet with a telephone line. But bandwidth is still a concern for a Website, especially one that hopes to attract a lot of traffic. Primarily, bandwidth costs money. Secondly, if you keep your site's filesize as low as possible, your site will load up blazing fast on a broadband connection, and that still impresses users today.

On the same note, try to keep code clean. Using good coding techniques will keep your site's HTML small and easy to maintain, and again, it will conserve bandwidth and help your site load faster, which is what visitors want. If you used any of the links above in the "Know Your HTML" section, you'll learn how to code proper HTML. There are steps you can further take, though, and practices to avoid common pitfalls, that you can find in the following links.

• Clean HTML Code - Cleaning Up HTML Coding
• What Beautiful HTML Code Looks Like
• Learn About HTML Validation

Avoid distracting elements on the page. Distracting elements, like animated gifs or Flash animations/advertisements with too much movement and action tend to distract a visitor. If your page is riddled with this kind of distraction, your content becomes more difficult to find, and even worse: it becomes more difficult to read when the visitor does find it. This is a good way to push your potential new visitor right out the door, and expect them never to come back. If you have a good reason to use an animated gif, use it, but keep it part of your content, not part of your layout. An animated gif of a weather radar in an article discussing precipitation patterns is fine, for example, because it furthers your content. An animated gif that spins in your sidebar that says "E-mail Me!" is a distraction, and just a decoration. Avoid decoration of this sort.

Advertisements are often flashy and animated. It's important to make money off of your Website, but try to keep a policy in place where advertisements must not be too flashy and they should remain as relative to your content as possible.

Users Don't Read, They Scan

An important concept that you'll want to keep at the forefront of your mind while building your Website is that the average Web user is looking for instant gratification. You need to keep things simple as your site is only one of hundreds of thousands out there and if your site doesn't meet visitors' expectations immediately after they see it, you'll lose them. Again, it's important to reiterate: keep it simple.

It would be ideal if every visitor read and analyzed every portion of a Web page, but they don't. Instead, they quickly scan your page for the following things:

• The information they're looking for
• The pictures they want to see (if any)
• The place to click to get further on your site.
• The way out, or the way back.

The first two things you see on the above list have to do with the user. Those are the "instant gratification" items. If they can't find these things immediately (a span of a second or two), they look for the next two, which deal with your design and the functionality of your site. If they can't quickly, effortlessly, and easily find all the places to click to get further on your site, they'll look for the last option: the way out. This is usually their browser's back button.

Eye-following studies have been done to determine where a user looks when browsing the Web. In the results of these studies, you can see that users follow an F-shaped pattern when scanning your page, and their attention is held very shortly on entire sections of the page that don't immediately suit their needs.

Because users are so easily deterred, it's important that you keep your design clean. It's possible to make a design that is good-looking and functional at the same time. The design should serve a purpose and never be fully decorative. Always remember: content is king! The content is why you created your site, and it's what the users are there to see. Make it as easy as possible to get to, and as easy as possible to read. To keep it easily-accessible, make sure your navigation is easy. If a user can't easily identify the ways to get around your site, the user won't be around long.

To be sure your navigation is easy to use, try to build a design that, at a glance for the user, can answer the following three questions:

1. Where am I? (Present)
2. Where can I go? (Future)
3. Where have I been? (Past)

Your site should have indicators or some sort and links that answer all these questions without the user having to click their back button or read the page URL. A List Apart has a great article about navigation that is well worth your time to read.

Browser Compatibility

A Web browser is an application that allows a user to access the World Wide Web. Popular web browsers include Internet Explorer, Firefox, Safari, Opera, and Netscape.

Not all browsers were created equal. IE displays things differently than Firefox does. Both of these may display things differently from Safari, Opera, and Netscape, as well. Basical