Archive for the ‘Web Standards’ Category

Web Standards Again

Greetings! Many times we have clients that have trouble understanding the role of web standards and why they are important. So I created this high level explanation that I hope will suffice. It is, by its very nature, simplified and incomplete, so don’t stone me to death. Here goes…

The World Wide Web Consortium (www.w3.org) is the standards body for the internet. They define the standard “language” or markup that web pages are written in. All of our documents are written in the strict flavor of XHTML (eXtensible Hypertext Markup Language) 1.0 which is very intolerant of errors. Conforming to these standards has several practical benefits. First, the site is easier to update since all of the content is easy to read and logically organized. This reduces cost for updates to the site. The W3 provides a validator to check pages against the XHTML standard and report any errors that it finds.

Secondly, strict XHTML mandates that the graphical presentation of the page (how it looks) be separated from the actual content of the page. So there is a separate file we create called a “stylesheet” that determines how the page will look. All of the graphics, colors, and layout are determined by this stylesheet. This is a benefit because it makes for smaller, faster loading pages which can rank higher in search engines than bloated pages that are slow to load. It also makes it easier to update how the site looks. For example, as autumn approaches you could change the entire look of the site by changing the colors in the stylesheet to fall colors. This is much more efficient than redesigning a site in the old days when each individual page had to be changed at great expense.

Lastly, search engines look for unique, relevant content that is organized well. By keeping all of the content in a separate file, the content can be organized so that the most important information is close to the top of the document while repetitive elements such as the navigation links are closer to the footer.

Be sure to read this post about HTML validation for SEO

There is a great FAQ on web standards and their importance at: http://www.webstandards.org/learn/faq/

Good Luck!

—Alan

The img Element Vs the CSS background-image Property

Don’t know when to use the img element or when to use the CSS background-image property? Don’t fret; there is hope. Read further and all shall be revealed.

The img element is best used for pictures that are completely unrelated to the stylesheet. That is, pictures that would need to display no matter how much the look of the site changes. These would be pictures related to a news article or photos in a gallery.

The CSS background-image property is for images that make up the appearance of the stylesheet. These pictures on one stylesheet would be different or just completely absent on another stylesheet. They don’t add to the content of the page in any way and are only there to give the page its “look”. These image files would be stored in the stylesheet’s images folder. (See my last post for more on this.)

Just another tip from your uncle Kyle!

—Kyle Blizzard

Organizing Your CSS Files

When I create a web site, I like to organize my stylesheets and images into a specific folder structure. It keeps things tidy and separates presentation files (stylesheets and images) from content files (pages and images related to the content). It also leaves room for additional stylesheet “themes” for your site.

Here is an example of this folder structure:

/styles/
/styles/default/
/styles/default/images/

Default in this example would be the name of the “theme”. The sites I develop typically do not have multiple themes for the user to pick, so I don’t usually take the time to give them fancy names. However, if your site utilizes multiple stylesheets that the user could choose from (such as at the CSS Zen Garden), creative names would be helpful.

All stylesheets for the Default theme would be placed in the /styles/default/ folder. Likewise, images used by those stylesheets would go in the /styles/default/images/ folder.

This method keeps your styles consolidated and makes it easy to use them across multiple sites. All you need to do is copy the folder to the other site; you don’t need to pick through the images folder and figure out which ones are used by the stylesheet and which ones aren’t.

Technically, you wouldn’t even need to copy anything to another site. You could just specify the full URL in the link element or @import rule on the page, but I urge you not to do this. Your visitors may be using security software that sees cross-site references as malicious, thus blocking the stylesheet from downloading or, worse, blocking the entire page.

—Kyle Blizzard

ASP.NET and XHTML Validation

If you’ve ever created an XHTML 1.0 Strict page containing an ASP.NET form element and ran it through the W3 Validator, you’ve undoubtedly noticed it’s reported as being invalid no matter what you do and no matter how valid the code actually appears. This is because ASP.NET adjusts the way it renders markup according to the requesting user agent. ASP.NET pities the W3 Validator and sends it bad code. This can be fixed with a “browser” file. The file and instructions on its use are available from that page.

However, that’s not all. The validator will now see your pages the way you see them in your browser, but ASP.NET is still rendering an invalid name attribute on your form element! You need to add a line to the system.web section of your web.config file:

<xhtmlConformance mode="Strict" />

Now ASP.NET plays nice with the W3 Validator and renders a valid XHTML Strict form! Now you can stop using the XHTML Transitional doctype and start using the XHTML Strict doctype on your ASP.NET pages!

—Kyle Blizzard

The Target Attribute and Strict XHTML

So, you’ve decided to start creating your web sites with valid strict XHTML 1.0 and CSS. Your client wants a “links” page containing none other than links to other web sites. So you oblige and, to keep your client’s visitors on his site, you make the links open in a new window. So you throw in target="blank" and you’re done. Just run it through the W3 validator…

There is no attribute “target”? What gives?!

Yes, indeed, target is not a valid attribute in XHTML 1.0 Strict. There’s really only one way around it of which I’m aware, and that’s by using Javascript. My preferred method is as follows:

<a href="http://www.blizzarddigital.com/blog/" onclick="window.open(this.href, 'OffSite').focus(); return false;">

This opens the URL in a new window and brings it into focus if the user had previously opened an “OffSite” window and didn’t close it.

You would still put the desired URL in the href attribute just like with any hyperlink. That way, if the visitor for some reason has Javascript disabled, the link still functions correctly. It just wouldn’t open in a new window.

One caveat though—in Firefox 2 and later with default settings, this code causes the linked site to open in a new tab, not a new window. If you find this to be a problem, there is a way around it, and that’s by adding the window options parameter such as:

<a href="http://www.blizzarddigital.com/blog/" onclick="window.open(this.href, 'OffSite', 'directories=yes,location=yes,menubar=yes,resizable=yes,scrollbars=yes,toolbar=yes').focus(); return false;">

Those are all the options required to make the window appear normally with default tool and menu bars—kind of a pain. At this point, you may want to move the code into an external Javascript file. The function I use typically looks like the following:

function OpenOffSite(a)
{
window.open(a.href, "OffSite", "directories=yes,location=yes,menubar=yes,resizable=yes,scrollbars=yes,toolbar=yes").focus();
return false;
}

Then the onclick attribute of your anchor would look like so:

<a href="http://www.blizzarddigital.com/blog/" onclick="return OpenOffSite(this);">

Your links now open in a new window! Welcome to the world of XHTML conformity. 🙂

—Kyle Blizzard