Sample page using semantic mark-up as viewed in Firefox.

Sample page using non-semantic mark-up as viewed in Firefox. Give or take a few pixels these look pretty much the same.

Sample page using semantic mark-up as viewed in Internet Explorer 6. As you can see, the banner breaks in IE 6 but everything else looks pretty much as expected. The page also breaks in IE 7 and IE 8 though the IE 8 version looks different. I've included these samples as a reminder to always check sites in multiple browsers.

Sample page using non-semantic mark-up as viewed in Internet Explorer 6. Again it looks almost the same at the semantic version, even breaking in the same manner.

The other day, Aaron Rester posed this question on Twitter: Webbies: any advice on explaining semantic HTML to non-webbies?

I wrote back that I usually show them some source code and walk them through things like using h1 and so forth for headers. That is what I usually do. In fact I'd just done that the other day when I was showing someone the changes I would recommend for search engine optimization (SEO).

But the question made me wonder if my explanations were adequate. If someone doesn't know anything about HTML or other mark-up languages, will such an explanation make sense? Or is there a better way to explain the differences between structural and presentational mark-up to clients and new Web designers?

Why do clients and other non-webbies need to know about semantic HTML?

Typically this topic comes up most often when one is discussing issues related to search optimization and accessibility. If a client needs to enhance their site for SEO, I may be recommending changes to the code that they won't even see when looking at the page in their browser. Understandably they will want to know why they should pay me to do things to their site that they won't notice. The changes we make may not be visually apparent, but they will convey additional information to Web browsers and search engines that can aid accessibility, usability and searchability.

What is semantic HTML?

Semantics is the study of meaning. Merriam-Webster's Online Dictionary provides us with a definition that relates closely to how the term is applied to HTML "3 a : the meaning or relationship of meanings of a sign or set of signs; especially : connotative meaning." HTML uses elements that convey structural meaning to Web browsers and other user agents such as search engine crawlers.

Writing a page in semantic HTML simply means that you are applying the appropriate structural elements to the various bits of content on a page. Huh? Code elements act like labels that tell the Web browser what each section of content is. HTML gives us structural elements to indicate headers, paragraphs, lists, tables and so forth. If I want to tell the browser to start a new paragraph, I'll type <p>. If I want to start a new subhead, I'll type <h5>.

Then isn't all HTML semantic?

You would think so, but no. Web browsers can be both fussy and forgiving. I can code the same content in multiple ways that will each look very similar when viewed, but will actually convey differing amounts of information to user agents.

Instead of using an <h5> I could use <p><strong>in front of my subhead and make it look the same as it would using <h5>. Such usage would be considered presentational mark-up. It can affect how the header looks, but it is not semantically correct because it doesn't let user agents know that this is a subhead. If a Web designer applies the incorrect elements to page content, the site may look perfectly acceptable. But it is not passing on vital information that user agents may need to:

• Help a visually impaired visitor navigate the page using screen reading software.
• Tell Google and other search engines what topics are the most important ones on the page.
• Show that you are citing a reference document such as a book.
• Indicate that you are presenting computer code, etc.

Same content, different mark-up

To illustrate this point I've created 2 very simple Web pages, one uses semantic mark-up and one using non-semantic mark-up. Basically the non-semantic version uses <p> for just about everything. When you view the pages through a regular browser you'll see that the semantic and non-semantic versions look pretty similar. They both look normal in Firefox, Safari and Opera, and they both break in various versions of Internet Explorer. You don't see the difference visually until you look at the pages in the text browser, Lynx.

When viewing the semantic page on Lynx, we can see that there is order to the page; it looks a bit like an outline. The menu looks like a menu and the headers standout to provide an introduction to the other text.

HTML elements in action, offering added information to user agents

Text readers for the visually impaired and search engine spiders are getting even more information than we can see in the Lynx semantic html example. They know that each menu link should be distinguished from the next. The use of an unordered list for the menu tells user agents to separate these links in a way that use of <p> does not, and allows users of screen readers to jump through or skip these elements to proceed to the main text. In the non-semantic version this is not clear, a text reader may speak all of those links together, making it more difficult for the user to navigate.

These user agents can also tell that the first header is more important than the second because it has been coded as an <h3> while the second header is an <h4>. Headers are ranked in order of importance from 1-6. Here we're using an <h1> for the site name, the most important header on the page. Search engine crawlers will see words in an <h1> as being more descriptive of the page as a whole. This is useful for search engine optimization, because we can include our keywords and phrases in our various headers to let the search engines know that core topics we are covering on the page. Thus on this page you'll notice that I've used the phrase "semantic HTML" in both the text and subheads (which in this case are <h5>'s.) That said I've not used it in every subhead because having these headers make sense to you, the reader, is still more important than SEO. People come first, then robots.

In this example I've focused on just a few a few of the many HTML elements that are important to semantic mark-up, but hopefully these will give you a clearer sense of how such usage can help SEO and accessibility. Other elements such as address, cite and blockquote can add additional meaning to a page's code. You can learn more about other elements and related issues in the reference links below.

Semantic mark-up, validation and content

It's always a good practice to validate your code to check for errors and potential problems, but site validation doesn't guarantee that you've used the best mark-up for the site. While the validator can make sure you've used allowed elements, it has no way of knowing if you've them in the most appropriate manner. Both the semantic and non-semantic page samples used in this post were produced using valid W3C standards compliant XHTML and CSS. One is clearly better formed than the other, but both also break in Internet Explorer.

Thus it's also important to check sites in multiple browsers and to simply think carefully about how visitors will read the site. If my samples were for real sites, I'd fix the IE problem, but I used it here to remind us that using valid semantic code is just the beginning. There will always be additional details we must consider.

It's also worth noting that, when it comes to SEO, a semantically well-formed site is not a substitute for good content. Search engines such as Google are designed to help users, like you and me, find the most relevant pages for the information we seek. With that goal in mind they have to accommodate a wide variety of coding differences. If your competitor has great content and plenty of good inbound links, while yours does not, then his/her site will still win out, even if the code is atrocious. But if you can produce great content and present it in the appropriate format you will be off to a good start.

Semantic HTML Resources

• The Elements of Meaningful XHTML (presentation showing examples)
• Fangs Screen Reader Emulator
• Guide to Semantic Use of HTML Elements
• Illinois Information Technology Accessibility Act Implementation Guidelines for Web-Based Information and Applications 1.0
• More than one H1 on a page: good or bad? (Video by Google's Matt Cutts)
• Semantics in HTML 5
• W3C Semantic Data Extractor
• W3C: G115: Using semantic elements to mark up structure

As the semester winds down, and the holiday season encroaches, it seems there are more and more events to publicize, greetings to send, end-of-year newsletters to distribute, holiday sales to promote, etc. T'is the season for HTML e-mails. Alas, as many of you know, creating and distributing an HTML e-mail message is far more complicated than building a regular Web site. As we struggled in the days of the browser wars, today we struggle with the myriad ways popular e-mail programs support HTML. Anyone who has had to create an HTML e-mail message, or has received one they couldn't read, knows what I mean. So today I'll present five tips that should help to make your e-mails readable by the masses.

Throughout this article I'll refer to the sample Gothfest 2009 e-mail pictured (in various renditions) on the right. This sample was created with certain features in mind to demonstrate how such an e-mail will render in different programs.

1. Use images to convey a mood or theme, not to present content.

In many popular e-mail programs, the default preference is to have images turned off in incoming messages. Thus many of us receive e-mails with little boxes and some indicator that says "click here to load images." If you are like me, you rely on the remaining text of the message to make you decide if you should bother or not. Recently I received a message from a well-known business magazine in which the only text provided stated only the name of the magazine and its address. The subject line was equally informative in that it said something like "Special News Update from Magazine X."

The rest of the content was contained in .jpg files linked in the message. This is problematic for two reasons:

1. Sighted readers, such as me, have no way to judge whether the message is worth reading (or not) unless we click on the image. If we're busy reading through a long list of e-mails we may just send it to the trash. If the sender didn't care enough to present the information clearly, then why should we care enough to read it?
2. Readers with vision problems who rely on screenreading software have no way to read a message that is part of an image. They are relying purely on the text of the message and any "alt text" provided for the image. This particular message didn't include any "alt text" so the message was lost to such recipients.

We all want our messages to be read. To ensure that they are readable by everyone in your audience, just be sure to include all the important points as actual text. This doesn't mean you can't use images to add visual interest, it just means that your message will be accessible to everyone whether they can see the pictures or not.

In the Gmail screenshot on the right we see a sample message without images. The original file contains two images, a picture of Death and a white background image with shaded edges. Because the content is text-based the main message is available and the alt text provides a description of the missing photo. This would also be readable in a text-only mail program with no colors or styles available.

2. Use Tables for Layout (WHAT????)

Most of us know that tables are meant for tabular data and CSS is meant for style and position. Alas many e-mail programs, including Gmail, don't support the positioning features of CSS. If you want to put text on the left and an image on the right—as I did in the sample— and you can't use the float property of CSS, you're stuck with tables.

To create this layout I made a table that has 3 rows of one column each.

• The top row has a dark background, a green bottom border and contains the title.
• The middle row has a white background and contains another table with one row and two columns.
  • The left column contains a background image, but no background color and features the main text. With images off the white background from the main table will show through so that the text is still easily read.
  • The right cell has a dark background and the Death picture. With images off the picture is replaced with alt text. In our sample this is showing up as black which indicates that the table cell should be restyled to feature a lighter color.
• The bottom row has a dark background, a green top border and the opt-out message. In some of our samples the e-mail is showing up as dark blue which is hard to read against the dark background. In the Macmail version it has been re-styled in a light green that is easier to read.

To get a better idea of how this was set up, view the source code.

3. Use HTML 4.0 Standards Compliant Code to the extent that you can.

Going back in time to use tables makes us feel like we're breaking the rules of HTML, but it is still possible to adhere to standards compliant HTML in e-mail if you use the HTML 4.01 transitional doctype. While adhering to Web standards is a good idea in general, I also find it helpful for testing and troubleshooting e-mail files. When I find a problem in my message, the first thing I'll do is validate the file. This helps me determine if the problem is a simple coding error or if it is due to a feature not supported in one of the e-mail programs I'm testing. By eliminating any coding errors I can then focus on the work-arounds I may need to implement to solve the e-mail specific problem.

4. Use inline styles

Most of us are used to using external or embedded stylesheets. Alas, some programs don't support those. To ensure that your styles aren't ignored, use inline styles to format everything in the document. This takes more time and adds to the code, but will be accepted by more programs. For example, to style the top table cell and the header within, I used the following code:

<th scope="col" width="700" style="background-color:#24333a; border-bottom: 1px solid #87d143; color:#c02c18; text-align:left; font-family: Georgia, serif;" ><h1 style="margin: 10px 30px 10px 30px; letter-spacing:2px;">GOTHFEST <span style="letter-spacing:0; font-weight:normal;">2009</span></h1></th>

To add an inline style to an html element just include style=" " and put your regular CSS information within the quotes.

In this case I styled the top row (which uses a <th> because it is a table header) to have a dark background, green bottom border, red type, left-aligned text and Georgia or other available serif font. The title was put in an <h1> header styled to have 10 px margin on the top and bottom and 30px on the left and right. I also added 2px of letter spacing. I surrounded 2009 with a span styled to use 0px of letterspacing and a normal font weight. I incorporated the letter spacing and the 2009 span changes mostly to see if they would be carried through in the e-mail programs I tested.

Note: When coding for the Web I find padding works better to ensure files work well in IE 6, &, Firefox etc. But I've found that padding seems to fail more often than margin in e-mails, so I use margin to ensure that I retain space between paragraphs in as many programs as possible.

People sometimes worry that they'll lose too much flexibility if they try to stick with Web standards, but this example shows that despite the limited support of CSS in e-mail there is still room for experimentation. These styles worked in most of the programs I tested.

5. Test your mail in several different e-mail programs.

The e-mail standards project provides information on what features are supported by the most often used e-mail programs. These offer helpful guidelines, but the only way to know what will work for your file is to test it in as many different programs as you can. You can do this by installing several programs on your own computer and by enlisting the aid of friends and colleagues. I can access my work e-mail in Outlook 2003, MacMail, Gmail and Case's Webmail, so I send myself messages then check them in each program. I haven't upgraded to Outlook 2007 (as I'd no longer be able to test 2003) so to test that I send messages to my colleague Kim—who patiently lets me look over her shoulder or makes screen captures for me to evaluate.

As my samples indicate, your e-mail will not look the same in every program. That's O. K. The important thing is to make sure that it renders cleanly in each and degrades nicely if images or styles are not available. If you can do that, you will ensure that your message doesn't get missed because of poor formatting.

I can't embed HTML code in Outlook. How do I send an HTML e-mail?

How you send an HTML e-mail depends on your mailing list and the programs you have available. If you're regularly sending mass e-mails to large lists, you may wish to use an e-mail service such as Target X or Constant Contact. There are many such services available. Check with your organization to see if they already have an arrangement with a preferred vendor.

For occasional mailings sent to smaller lists, or via listservs such as those available through https://lists.case.edu, you need an e-mail program that will allow you to insert HTML. Case's Webmail program, found at http://mail.case.edu let's you paste HTML into your message body, but only if you are accessing it through Internet Explorer.

An easier option for most users is Mozilla's Thunderbird, available for Linux, Macintosh and Windows. Thunderbird is free and very easy to install. To send an HTML e-mail just click the "Write" button to compose a new message, type in your recipients addresses and subject line then go to the "Insert" menu and choose "HTML." A box will pop up in which you can past the code from your HTML file.

Learn more about HTML e-mail

• E-mail Standards Project
• CSS and Email, Kissing in a Tree
• How to Code HTML Email Newsletters
• Outlook 2007 change sends HTML email back to the future, for better and worse
• E-mail Standards Project

Last week's entry on outbound links spawned a lot of discussion, including the question of whether one should have outbound links open in a new window (or tab depending on the user's browser and preferences). Although many others have already written about this topic, it comes up often enough that I think it is worth discussing. Disclaimer: links that open in a new window or tab—when that wasn't my choice—are a pet peeve of mine, but I will attempt to explore the topic objectively.

What is the intended purpose of having links open in a new window or tab?

Those who recommend having links open in a new window do so with the intention of making it easier for users to return to the original site. Anyone who surfs the Internet knows that it is easy to get lost down a rabbit hole of links. For example, if I provide you with a link to Chuck Palahniuk's Web site, you might:

• follow the link
• peruse the section on author interviews
• read Dennis Widmyer's latest interview with Craig Clevenger
• then decide to add The Contortionist's Handbook to your Amazon shopping cart.

By now, the theory goes, you will have either forgotten where you were before or forgotten how to get back. If I'd set the Chuck Palahniuk link to open in a new window/tab (this is the only link on the page that opens a new window), you could just go back to your original window/tab and you'd be back where you started. Of course if the link opens in the same window, and you are using a current browser such as Firefox, you can simply click the down arrow next to your back button to navigate back through the series of links you just followed.

So which is better? Is it easier for a user to go back to a different window or to just use the back button?

I've always found it easier to use the back button. With one click I can go back and read another interview or I can choose to go all the way back to the original blog. To me that seems far easier than wading through a sea of windows, or looking at an array of tabs to find the one you want. But everyone is different. In researching this article I discovered a Get Satisfaction page in which a user actually requested that links on Pownce open in a new window. Two of the responders agreed that they would prefer new windows, while two others (including Pownce/Digg designer Daniel Burka) disagreed. I saw these differing opinions in many places.

Where does that leave us? Preferences vary, so unless you survey the users of your particular site it may be difficult to determine if your audience likes or dislikes it when a link opens in a new window. Pownce was able to solve the problem by giving users a setting that lets them pick which behavior is the default while they're on Pownce. But that's not an option for most sites and blogs. With that in mind, I think it is most appropriate to leave it in control of the user. If a user wants to open a link in a new window he can do so by right-clicking (Windows) or ctrl-clicking (Mac) the link in question. I often open links in a new tab if I know that I'll want to flip back and forth between them. I just don't want them opening up new tabs spontaneously.

Standards and accessibility issues related to opening links in new windows

If you're in the pro new window camp, I've probably not yet changed your mind. But there are more issues to consider.

W3C HTML and XHTML Recommendations

The traditional way to have a link open in a new window is to include target="_blank" in the link. The target attribute is not included in the recommendations for HTML and XHTML strict, therefore sites using target with a strict doctype won't validate. From what I've gathered target is not included because not all browsers support the attribute, particularly when it comes to browsers running on mobile devices. (This may change in XHTML 2.0 as the attribute may serve new needs as mobile browsers evolve. A valid alternative is to use javascript.

W3C Web Content Accessibility Guidelines 2.0 (WCAG)

According to the WCAG Success Criterion 3.2.5, "Individuals who are unable to detect changes of context or may not realize that the context has changed are likely to become disoriented while navigating a site. For example: individuals who are blind or have low vision may have difficulty knowing when a visual context change has occurred, such as a new window popping up. In this case, warning users of context changes in advance minimizes confusion when the user discovers that the back button no longer behaves as expected." To avoid this confusion they recommend that users should be notified if a link will open in a new window and if possible be given the choice to not have it open in a new window.

Kant's Categorical Imperative: What if everyone did it?

While writing this I kept having a vision of wandering the Internet in a world where every external link opened a new window or tab. In this vision it was only a matter of minutes before there were so many tabs open in my browser that I had to use the left and right arrows to scroll through them. Worse yet, instead of tabs windows began spawning as quickly as Tribbles and suddenly my desktop was impossible to navigate. This made me think of Kant. In his first formulation of the Categorical Imperative he states that one should "act only in accordance with that maxim through which you can at the same time will that it become a universal law." While this idea was meant to deal with issues of morality, it's easy to see how it could be applied to lesser situations such as links opening in new windows. If links always opened in a new windows it would pose significant usability challenges.

Naturally most sites don't open everything in a new window or tab. If they did we'd all be swimming in windows. Instead, most site designers choose to open new windows only in particular circumstances. Some designers do this only for external sites while others reserve the technique for opening up .pdf files. While I'd still prefer that links open in the same window, giving me the choice of whether or not to open them in a new tab, I understand that many may disagree. Most people have committed one way or another with few remaining undecided. But, whatever your preference may be, I hope this discussion will help the next time you're debating where a particular link should open.

Learn more about opening links in pop-up windows or tabs

• Accessible Pop-up Links
• D. Keith Robinson's Gorilla Web Tips: Launching New and Pop-up Windows
• Don't let your web site fall out of the window: opening new browser windows
• How evil is the target attribute?
• New-Window Links in a Standards-Compliant World
• Open New Window Still Has Usability Issues
• The target attribute and opening new windows
• Top Ten Mistakes in Web Design
• WCAG 2.0: H83: Using the target attribute to open a new window on user request and indicating this in link text
• WCAG 2.0: SCR24: Using progressive enhancement to open new windows on user request

Registration is now open for summer classes at CaseLearns. Whether you're building your first Web site, adding video to your blog or just want to learn something fun, CaseLearns has a number of options available.

The classes listed below may be of particular interest to those developing or maintaining Web sites.

If you are new to Web design and want to learn Dreamweaver, I recommend reading I'm not going to teach you XHTML/HTML, but you should learn it anyway and doing the homework assignment before taking your first Dreamweaver class.

All CaseLearns classes are open to current Case faculty, students and staff, emeriti faculty, alumni, and Senior Scholars. Case affiliates may register if openings are available. Class schedules are subject to change. Please visit the CaseLearns Web site for the most current information.

Adobe Acrobat 8: Introduction

Instructor: Debbie Korodi
Prerequisites: Familiarity with Windows or Mac OS; knowledge of Microsoft Word.
Wednesday, June 18, 2008 9:00am-Noon

Adobe Acrobat 8: Creating PDF Forms

Instructor: Debbie Korodi
Prerequisite: Knowledge of Adobe Acrobat 8.
Thursday, August 7, 2008 9:00am-Noon

Digital Images I: Introduction & Basic Photoshop

Instructor: Jared Bendis
Wednesday, July 9, 2008 3:00-6:00pm

Digital Images II: Advanced Photoshop

Instructor: Jared Bendis
Prerequisite: Digital Images I: Introduction & Basic Photoshop
Wednesday, July 16, 2008 3:00-6:00pm

Digital Images III: Even More Advanced Photoshop

Instructor: Jared Bendis
Prerequisite: Digital Images I and Digital Images II
Monday, July 21, 2008 3:00-6:00pm

Dreamweaver CS3: Introduction

Instructor: Thomas Hayes
Tuesday, July 15, 2008 1:00-4:00pm

Dreamweaver CS3: Intermediate

Instructor: Thomas Hayes
Thursday, July 24, 2008 1:00-4:00pm

Dreamweaver CS3: Advanced

Instructor: Thomas Hayes
Tuesday, July 29, 2008 1:00-4:00pm

How To Make Web Pages Using HTML: Part 1

Instructor: Thomas Hayes
Tuesday, August 12, 2008 1:00-5:00pm

How To Make Web Pages Using HTML: Part 2

Thursday, August 14, 2008 1:00-5:00pm

Introduction to Pachyderm

Instructor: Jared Bendis
Wednesday, July 30, 2008 3:00-6:00pm

Understanding RSS Feeds

Instructor: Brian Gray
Thursday, July 17, 2008 10:00am-Noon

Video Workshop I: Introduction To Digital Video

Instructor: Jared Bendis
Thursday, July 10, 2008 3:00-6:00pm

Video Workshop II: Advanced Digital Video

Instructor: Jared Bendis
Prerequisite: Introduction to Digital Video
Thursday, July 17, 2008 3:00-6:00pm

The resolution on YouTube is not as crisp as the original.
You can also view the video in higher resolution .mov format.

Back at the turn of the century, embedding video was complicated. Streaming required a special server, you had to decide what format(s) you wanted to stream, then you had to provide links to whatever software users might need to view your video—in case it wasn't already installed on their computers.

With YouTube, that's all changed. Now you can just go to the YouTube page for the video you wish to embed, copy the coding they provide, paste it into your html file or blog entry and publish the page.

It's just that easy—unless, like me, you care about adhering to Web standards. In that case, it requires a few more steps, but don't worry, they're not that complicated. YouTube videos can be embedded on the Web using swfobject.js—in a manner similar to the method I described last year in "Embedding Flash Objects for Internet Explorer." You can also use this method for embedding regular Flash .swf files. Just substitute the path to your .swf for the YouTube link in the instructions below.

Downloading swfobject 2.0

SWFObject 2.0 provides a significant upgrade to SWFObject 1.5—what we'd previously been using to embed Flash .swf files. To begin you will want to download the new script from the SWFobject project page. After downloading the script, you can upload it to your site, in whichever directory you prefer. Note: SWFobject 2.0 is not backwards compatible with 1.5, but the script has the same file name, swfobject.js. If you are already using 1.5 on your site—and don't plan to immediately edit all the pages that use it—you should rename the file to something like swfobject2.js or store it in a different directory so that you don't write over the prior version.

Generate the embed code for your page

While you could do this manually by following the instructions in the documentation, the SWFobject team has provided a rather handy Web-based code generator that we'll use in this example.

1. Go the the YouTube page for the video you wish to embed and copy the embed code provided.
2. Paste this into a blank file in Dreamweaver or your preferred editor. We won't be using this code in our page, but we'll want it for reference.

   <object width="425" height="355"><param name="movie" value="http://www.youtube.com/v/b-tYxJcFj9I&hl=en"></param><param name="wmode" value="transparent"></param><embed src="http://www.youtube.com/v/b-tYxJcFj9I&hl=en" type="application/x-shockwave-flash" wmode="transparent" width="425" height="355"></embed></object>

3. Within this code you will see a link to the video after value=". Within this link there may be an ampersand. Escape the & by typing amp; after it.
4. Copy this link,http://www.youtube.com/v/b-tYxJcFj9I&amp;hl=en, then go to the SWFObject 2.0 HTML and JavaScript generator.
5. Paste the link in the box to the right of "Flash (.swf):."
6. Near the top of the generator, choose between static and dynamic. I will be using static in this example as dynamic would require me to put additional code--specific to this video--in my header. Here on the blog my headers are part of my templates so I can't use anything that would be specific to only one entry. (The documentation offers additional information on the static and dynamic methods.)
7. Copy the width and height values from the YouTube embed code and paste them into the dimensions boxes in the generator.
8. Click on "more" in the SWF definition box if you like to edit additional attributes.
9. In the HTML definition box choose the version of XHTML or HTML and character encoding you use on your Web site.
10. Click the "Generate Code" button.

Embedding the video in your page

1. Copy the script code found with the head of the generated output.

   <script type="text/javascript" src="swfobject.js"></script>
   <script type="text/javascript">
   swfobject.registerObject("myFlashContent", "9.0.0");
   </script>

2. Paste this into the head of your HTML file or blog templates. Note: Because I have already been using the previous version of SWFobject on this blog, I named my script swfobject2.js before uploading it to the server. Therefore I must also change the name in this code then add it to the code that is already in my templates. Thus my files will include:

   <script type="text/javascript" src="swfobject.js"></script>
   <script type="text/javascript" src="swfobject2.js"></script>
   <script type="text/javascript">
   swfobject.registerObject("myFlashContent", "9.0.0");
   </script>

3. Copy the object code found within the body of the generated output.

   <object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" width="425" height="350" id="myFlashContent">
   <param name="movie" value="http://www.youtube.com/v/b-tYxJcFj9I&amp;hl=en" />
   <param name="wmode" value="opaque" />
   <!--[if !IE]>-->
   <object type="application/x-shockwave-flash" data="http://www.youtube.com/v/b-tYxJcFj9I&amp;hl=en" width="425" height="355">
   <param name="wmode" value="opaque" />
   <!--<![endif]-->
   <a href="http://www.adobe.com/go/getflashplayer">
   <img src="http://www.adobe.com/images/shared/download_buttons/get_flash_player.gif" alt="Get Adobe Flash player" />
   </a>
   <!--[if !IE]>-->
   </object>
   <!--<![endif]-->
   </object>

4. Paste this into the place in your file where you would like the video to appear.
5. Upload the file to your server and watch the video!

SWFObject Resources

• SWFObject devblog
• Active Content Developer Center
• IE Automatic Component Activation Now Available (Internet Explorer users will no longer have to click to activate videos embedded using the static method.)
• SWFObject discussion group
• SWFObject 2.0 Documentation
• YouTube JavaScript Player API Reference

About the Embedding YouTube Videos the Standards Compliant Way video

The video screen captures were recorded using iShowU, a program I discovered yesterday afternoon. The scenes were pieced together, and audio was recorded and added in iMovie. As this was my first time experimenting with iShowU some portions of the video are a bit wobbly, but overall I found it very easy to use. I expect my skills will improve with time.

I'll post more about the process as I become more familiar with the software. Members of the Case Western Reserve University community interested in producing similar instructional videos may also wish to visit the Freedman Center which offers tools and instructions on this and related topics.

I've recently come to the conclusion that a great number of Web developers either don't know about Web standards, or simply don't care. For those who aren't already aware of the standards I'll offer a brief introduction along with resources for additional information. For those who don't care, or who are anti-standards, I'll offer some examples as to why I feel they're important. For those of you already in the know, feel free to add your own advice, examples or pet peeves in the comments section.

The reason for Web Standards

According to the Web Standards Project Mission, "The World Wide Web Consortium (W3C), along with other groups and standards bodies, has established technologies for creating and interpreting web-based content. These technologies, which we call "web standards," are carefully designed to deliver the greatest benefits to the greatest number of web users while ensuring the long-term viability of any document published on the Web."

Think of these as the rules of the road. When you are driving a car in Ohio you know you have to drive on the right side of the road, stop at stop signs, not enter an intersection unless there is room for your vehicle on the other side, yield to pedestrians, etc. If you are driving in Hong Kong you know to drive on the left and follow the various rules relevant to that jurisdiction. Following these rules makes the driving experience more pleasant for everyone; whereas ignoring these rules will, at best, annoy other drivers and, at worst, cause a traffic related fatality.

In most cases, a non-standard Web site isn't likely to cause fatalities, but anything is in the realm of possibility. Errors in formatting can cause content to render incorrectly. Imagine if the word "Never" wasn't visible to users reading the sentence "Never pour gasoline on an open fire." A reader unfamiliar with the combustible nature of rising gasoline vapors could easily immolate himself. That's an extreme example, but whether your site is about fire prevention or your book club, you probably don't intend to misinform or confuse your readers.

Following Web standards lets you increase the odds* that your site will be properly rendered by most browsers and user agents and that your information will be more accessible to users and search engines.

* I say "increase the odds" rather than "guarantee" because there are still differences between the way browsers interpret the standards.

What are the Web Standards?

Different standards are available for different purposes, but for the most part standards will define the type of coding that you should use when creating a Web page or stylesheet, or the procedures or policies you should consider when creating the site. Thus if you are building a site in HTML using Cascading Style Sheets, and want to ensure your site is Section 508 compliant for accessibility, you might follow the standards for HTML 4.01, CSS 2, and Section 508.

For example, HTML standards specify using <p> to start a paragraph, <h1> for a primary header and <em> for emphasis. CSS standards specify things like color and position, so that a purple header could be defined in a stylesheet by: h1 {color:#571963}. Using a descriptive word or phrase in the alt tag of images conforms to accessibility standards (both 508 and WAI).

One of the most overlooked HTML standards seems to be the inclusion of the correct document type. For example, if you are building a site using XHTML 1.0 (as is true of many Case sites) you would include this document type:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"  
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

This small piece of code tells browsers and user agents what version of HTML you are using, so they don't have to guess when rendering the site. This is like telling Babel Fish whether you want to translate a phrase from Dutch to English or from German to English. If you don't give it the right information you may not get the right result. I'm amazed by the number of sites don't include this basic information.

Another important standard for HTML 4.01 and XHTML 1.0 is the separation of format and presentation. <h3>Headline</h3> is an example of format, indicating that something is a header. Styling the <h3> with CSS, either in the document or in an external stylesheet, to be a certain size, color and font would be an example of presentation. In the old days of the Web this was done within the HTML using the now deprecated <font> tag. In the past one might have typed <h3><font color="33ff33" size="5">Headline<font></h3>. This not only filled up your page with a lot of extra code, but it also meant that if you decided later to make all of your <h3>'s a different color you would have to go and change all of the font codes one by one. When using a style sheet you can define how your <h3>'s will look in one place. To change the color you just make the one change in the stylesheet and you are ready to go.

Separation of format and presentation isn't a particularly new idea, but adoption has spread slowly. CSS 1 was first introduced in 1996 and the CSS 2 recommendation has been around since 1998. While many sites use CSS, it is still not uncommon to stumble upon current sites that are still using older codes such as <font>.

Why this has been on my mind

A few weeks ago a friend sent me a link to a pretty cool looking site for an online magazine. Alas the site wasn't standards compliant and therefore didn't work properly. This particular site was Flash-based with dimensions too big to fit my screen. The page had no scroll bars so I couldn't get to the menus to navigate through the site. I could see the whole site on my Mac, but not on my Dell, and I'm pretty sure I'm not the only one to have had that problem. Since I couldn't navigate the site, they might as well have posted a page that said "Do Not Enter. We don't care about your business." If they had built a compliant site they would have ensured greater accessibility to users and not had this problem.

I've found a number of other non-compliant sites while working to compile a list of local Web developers. Departments without Web staff often look to outsource their Web projects and turn to me for referrals. Thus I'm trying to put together a list of local (to support the regional economy) developers who I can trust to build compliant sites that follow the Case design scheme, maintain a logical navigational structure and support the goals of the client. This has not been an easy task.

The problem is that almost anyone can learn to build a Web site, but only a few can do it well. There are a lot of firms out there, but the quality of work varies dramatically, and only a handful build standards compliant sites. Sites with major compliance errors don't end up on my list. This isn't just because I'm persnickety. If a site fails validation because of a few stray &'s or they've forgotten to close a few <p>'s I'm not worried. Such errors are easily corrected and don't disturb the overall functionality of the site. But if a site uses <font> tags, doesn't include a doctype, leaves alt tags blank on all of their images, etc., then I will conclude that its designers are not professional and will not be able to offer the client the advice or service necessary to implement a successful site.

Conclusion and Disclaimer

If you've ever built a Web site, you've followed at least a few of the standards. The site wouldn't work if you hadn't. For example if you left out the <body> tag your page wouldn't render. Since we're all following some of the standards anyway, I would just encourage everyone to learn and apply more of them. As you become more familiar with them you'll find that your sites become both easier to use and easier to build. To learn more about Web standards visit The Web Standards Project and the resources below.

Standards compliance is an ongoing goal of mine, but I'm only human. Not every site I've built is standards compliant, and the errors become more egregious the older the pages may be. Since I readily acknowledge this you don't need to go hunt them down, they are out there, and I know it!

Web Standards Resources

• Asterisk Web Standards Archive
• Designing With Web Standards, Second Edition by Jeffrey Zeldman
• Jeffrey Zeldman: King of Web Standards (Business Week)
• Section 508: The Road to Accessibility
• The Web Standards Group
• The Web Standards Project
• W3C Cascading Style Sheets, level 2 CSS2 Specification
• W3C Cascading Style Sheets, level 1
• W3C HTML 3.2 Reference Specification
• W3C HTML 4.01 Specification
• W3C XHTML™ 1.0 The Extensible HyperText Markup Language (Second Edition)
• W3C Technical Reports and Publications
• Web Accessibility Initiative (WAI)
• World Wide Web Consortium (W3C)

Last month in my entry about
HTML/XHTML I provided a homework assignment for those who wanted to try learning a bit of XHTML. I know some of you are still working on the project, but as I've completed it myself, I'll walk you through some of the elements of the site.

If you have not yet started the project, you should go ahead and give it a try before reading this, but I leave it to you to decide what works best for your learning style.

My results

On the right is a screen capture of the site I built, Wolves, our social cousins. As you can see, there isn't much to it. Per the instructions, I included a photograph, headers, links, and list elements. I didn't apply any style formatting so nothing has been done to affect color, font or positioning of the elements on the page.

While the site isn't visually interesting, it is visually informative. The use of headers such as h1's, h3's and h6's help to differentiate between title, page header and footer. The use of a list for the menu makes that easy to follow as well.

Content

Given the reason for building the site, I spent very little time researching and writing about wolves. Anyone hungry to learn about wolves will be disappointed. Knowing this, I explained the reason for the site on the "About this site" page and included my contact information. Were this a serious site, it would still be important to include a page explaining the parameters and scope of the project.

About the document structure

You can view the complete code used to build this by going to the site and selecting "view source" from your browser menu. What follows is a breakdown of the elements used, with some general information about each.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-
transitional.dtd">

The Document Type declaration is used to tell user agents such as Web browsers what type of code was used to create the document so that they may render it appropriately. The World Wide Web Consortium maintains a list of valid document types.

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">

The html tag indicates the start of the document, the format (XHTML) and the language (English).

<head>
<meta http-equiv="content-type" content="text/html; charset=iso-8859-1" />
<title>Wolves: a web site demo</title>
<meta name="Keywords" content="wolves, unstyled web site, sample web site for tutorial" />
<meta name="Description" content="Sample web site to demonstrate simple xhtml files without any style formatting" />
<meta name="author" content="Heidi Adams Cool" />
</head>

Information within the header provides additional information to the browser, such as the page title—which is shown at the top of a browser window—and meta tags which can provide added information to search engines. In this example I've included author information, a brief description of the site, and keywords related to the site. While keywords help search engines reference your page, it is more important for them to be accurate than plentiful. A list of 200 keywords will not raise your site rankings, whereas a short list of words or phrases—specific to your site—will complement the other data these engines collect.

<body>

All content intended to be read or heard by users is enclosed within the body tags.

<h1><img src="wolf.gif" alt="wolf head" /> Wolves: our social cousins</h1>

The title of the site is enclosed within opening and closing h1 tags. In XHTML all elements must include both the opening and closing tags. In earlier versions of HTML, opening tags alone were sufficient. XHTML provides headers h1 through h6 with h1 being the largest. They should be used from large to small in descending order of importance. The words contained in headers are also referenced by search engines to help determine what is the most important content on your site. If one rendered the same words in plain paragraphs with bold text, user agents would not be able to recognize them as being more important.

In this example I have enclosed the wolf image within the h1 tag in order to affect it's placement on the page. When using CSS, I would handle the image separately. The img tag is "self-closing." As there is only the one tag it incorporates a closing slash at the end before the angle bracket. Manual line breaks <br /> and horizontal rules <hr /> also function in this manner.

<ul>
<li><a href="index.html">Home</a></li>
<li><a href="about.html">About this site</a></li>
<li><a href="species.html">Species</a></li>
<li><a href="haiku.html">Haiku</a></li>
<li><a href="links.html">Links</a></li>
</ul>

Here I've treated our menu as an unordered list. When I later add CSS to the page this will allow me to control whether the list has bullets or not, whether it is vertical or horizontal, etc. The linking words are enclosed within opening and closing anchor tags. As each page is located in the same folder I have used short "relative" links that use only the file name.

When including adjacent links in a document, such as those found in a menu, the use of a list helps to differentiate them. If instead we had put these in a paragraph with manual line breaks, user agents wouldn't easily know where one link ends and another begins. This is of particular importance for browsers for the visually impaired. When lists are not practical, you should always remember to put an actual character such as a comma or vertical bar between such links.

<h3>Home</h3>

Here I've enclosed the page header within h3 tags. I could just as easily have used an h2, but by skipping that I can save that tag for something more important if necessary. In the Case templates, we use h2's on the opening page of a site within the gray or colored box, and h3's for individual page headers.

<p>Wolves are a member of the family, <a href="http://en.wikipedia.org/wiki/Canid">Canidae</a>, which also includes dogs, foxes, coyotes, and jackals. It is thought that wolf-like animals evolved from a common ancestor 2-3 million years ago, while more familiar species such as the gray wolf probably emerged 1 million years ago. </p>

<p>Like dogs, and our own species, humans, wolves are social creatures. Whether hunting prey or nurturing their young, wolves work together for the good of the pack. </p>

Most of your text will be enclosed in paragraph tags as shown here.

<h6>Questions? Contact <a href="mail:cool@case.edu">cool@case.edu</a> or visit the <a href="http://blog.case.edu/webdev">Web Development Blog</a> at <a href="http://www.case.edu">Case Western Reserve University</a>.</h6>

I enclosed the footer information in h6's. While I could have used paragraph tags, I think the use of the header tags helps to distinguish this content from the main text. The use of the smaller header also indicates that it is of less importance to the subject than are the h3's. I feel it is important to include some sort of contact information in the footer. If a user finds an error on your page or has a question he/she needs to have a way of contacting you. If the contact person for the site is different than the content person for the subject matter, then you should include both somewhere on the site.

You will notice that the footer includes links to an e-mail address and to an external site. The external site makes use of a full url (uniform resource locator, aka address) in which the http:// designates that the link uses the hypertext protocol. The e-mail address begins with mailto: to indicate that it uses the mail protocol.

</body> </html>

As with other tags, the body and html tags must be closed.

To learn more about the tags used in this document, and XHTML in general, visit the resources listed in the previous entry. For our next project, we'll add the functionality of cascading style sheets to make our site look a bit spiffier.

To build a new site you will need to download the appropriate template files, and make sure you have the appropriate editing software on your computer. Case recommends using Dreamweaver as your XHTML editor. Dreamweaver is available—through the Software Center—as a component of Macromedia Studio 8. Dreamweaver is a great tool, but it is only a tool. A hammer is a useful tool for hitting a nail into a wall, but it still depends on you to both hold the nail, and to guide the hammer with appropriate force and precision. Similarly, Dreamweaver requires you to tell it what to do with the content you type or paste into it. You will find it is far easier to control Dreamweaver if you understand the basics of HTML and XHTML.

What are XHMTL and HTML?

XHTML (Extensible HyperText Markup Language) and HTML (HyperText Markup Language) are forms of SGML (Standard Generalized Mark-up Language) which allow users to define the structure of a document and its component parts. The first version of HTML was developed in 1989-1990 by Tim Berners-Lee and was fundamental to his invention of the World Wide Web. HTML 4.01 is the most current version. XHTML extends the abilities of HTML and can work in conjunction with XML. Case Web templates use XHTML 1.0 Transitional.

While I've included links to the specifications above, don't worry too much about the technical stuff. For your purposes you mostly need to understand that HTML and XHTML allow you to define areas of a document such as the body, headers, paragraphs, links and images so that a Web browser or other user agent knows how to structure the elements. Note that I said structure rather than present. Presentational elements which control the look of a site, such as font, color, boldness, and alignment, are not controlled through XHTML or HTML 4.01. Instead they are controlled by Cascading Style Sheets (CSS). XHTML handles structure, while CSS handles style. I'll discuss CSS more carefully in a separate post.

Building your first site in XHTML 1.0: A homework project

I find it is easier to learn by doing, so what I usually recommend is that you build yourself a little Web site from scratch. Knowing that you have your Case templates and Dreamweaver already installed, I want you to leave them closed in their folders and ignore them. We will not be using either for this project.

Your assignment

Using a plain text editor, build a five page Web site (in XHTML 1.0) about your favorite animal. You should be sure to include your site title on each page, topical headers on each page, subheads when appropriate, at least one bulleted list, and a navigational menu. Each page should include links to other pages within the site and to external Web sites, and a link to an e-mail address. I would like you to include at least one photograph or illustration (please only use images you have permission to use), but I do not want you to apply any styling such as font choice or color to the site. We will do that in our next project, learning CSS. Once your site is complete, go to http://validator.w3.org/ to make sure your code is valid. Then post a link to your site in the comments area below so that we can all see how you've done!

Tools to complete the project

• Text Editor: If you are using Windows, I recommend Notepad. If you are on an older Mac, use SimpleText, on a newer Mac, TextEdit. Users of other operating systems, such as Linux, should use whatever plain text editor they prefer. DO NOT USE WORD, WORDPERFECT OR OTHER WORD PROCESSING PROGRAMS.
• Image Editor: Adobe Photoshop CS2 is available through the Software Center, but you may use whatever program you prefer. For this project you will probably only need it to resize your image.
• A place to post your site: Case students, staff and faculty may sign up for free space at http://filer.case.edu. Others should consult with their ISP to see if Web space is included in their account, or sign up with a free service such as http://geocities.yahoo.com/join/.
• A method to upload files to your site: FTP (File Transfer Protocol) was once the dominant choice for uploading files, but is now joined by many others including Secure FTP and WebDAV. A variety of stand-alone clients are available, FTP is built into Dreamweaver, and Mac OS X has built-in WebDav support. http://filer.case.edu supports FTP and WebDav, but also offers an easy-to-use Web interface for file transfers. Your host provider should let you know which protocol they support.
• A Web browser to view your site. If you are reading this online, you already have one, however, I recommend Firefox.

Resources for learning XHTML and HTML

As I indicated in the title, I'm not going to teach you the code. Many others have provided perfectly good resources for this. The ones I used back in the dark ages of the early 1990's are now well out-of-date, and I've not read any of the following in their entirety, but I have read and skimmed bits of each, and they seem sufficient. Please make sure not to use any resources geared to older versions of HTML as they will include code that is no longer in use.

HTML Books

Safari Proquest subscribers, including users from many universities, can read these online at no cost. For others I've included links for ordering the books from Amazon.com.

Absolute Beginner's Guide to Creating Web Pages, Second Edition By Todd Stauffer

This book seems to cover all of the basics, and provides some background information about the Web that you may find interesting. Even without reading the entire book it should give you the information you need to build the site for our assignment. The author recommends testing your site locally, but I think you will be better served by uploading your pages as you go and testing them in a live environment. Purchase Absolute Beginner's Guide to Creating Web Pages (2nd Edition) from Amazon.

HTML for the World Wide Web, Sixth Edition, with XHTML and CSS: Visual QuickStart Guide By Elizabeth Castro

While a bit dryer than the previous title, Chapter 3. Basic (X)HTML Structure walks you directly through the process of building a page, and should provide you everything you need to complete this project. You can skip the chapters on formatting as we'll be using CSS to apply formatting in a future assignment. Purchase HTML, XHTML, and CSS, Sixth Edition from Amazon.

Designing With Web Standards By Jeffrey Zeldman

While more advanced than the the other two books, this is the most accurate and precise of the three, specifically because Zeldman's focus is adherence to Web standards. Once you've gotten a feel for the basics of HTML, this book will help you understand how and why to use proper structural code. Jeffrey Zeldman is one of the foremost experts in this field, and also runs the popular and very helpful e-zine, A List Apart. Purchase Designing with Web Standards (3rd Edition) from Amazon.

Online Resources

W3 Schools

W3 Schools offers tutorials on a variety of Web related topics including HTML and XHTML. Their XHTML tutorial expects you to know HTML, so read that one first.

HTML Source

These easy-to-follow tutorials range from "My first site" to more advanced topics such as CGI Scripting. Some of the tutorials include deprecated code, but they also explain why these are no longer recommended, so that users gain additional understanding.

W3C Markup Validation Service

This resource checks your Web page to let you know if your code is valid, and if it is not, what the errors may be. Very handy both for ensuring clean code, and for finding errors that may be causing problems in your pages.

The World Wide Web Consortium (W3C)

While no single entity owns or controls the Web (though the telcos are trying to change that) the W3C can be considered the defining authority. As the developers of Web standards and guidelines their mission is "To lead the World Wide Web to its full potential by developing protocols and guidelines that ensure long-term growth for the Web." Their site includes all of the official recommendations and a variety of reference materials.

There are many other reference materials available online, but the above should be sufficient to get you started. So go ahead, open up your text editor, give it a try, and let us know how it turns out!

Next: Homework Review