Skip to main content

Web Standards, Part I: Conversion to Web Standards

This article was originally posted at Blogs@SI on April 22, 2005.


DoctypeJust having served on a panel that presented to Penn State Web developers about converting to Web Standards, I'm reminded once again that the biggest challenge with talking (or writing) about this subject is figuring out what on earth can be said that already hasn't been discussed six ways to Sunday. And not only by the Web Dev community in general, but by individuals such as Jeffrey Zeldman and Eric Meyer.

Well...

The fact is, Web developers interested in going this route but who aren't quite ready are looking for a solid starting point and a process that minimizes reworks. That's the approach I took with this audience, and it is the approach I take with my own development:

1. Build incrementally and validate early and often.
This comes second nature to applications programmers: By building an application a little at a time and testing after each increment, debugging is confined to small blocks of code. Instead of entire pages. There are lots of validation tools available, including w3c's validators. I primarily use FireFox's Web Developer Extension (chrispederick.com/work/firefox/webdeveloper) to validate XML, CSS, and other code. This combines a useful set of tools with the most standards compliant browser on the scene. Even though I may not have made changes recently in the style sheet, I validate this incrementally as well. The reason: errors in code can throw themselvs out as CSS errors. Of course, frequent validation will not take the place of careful coding. For one thing, code can validate but still contain problems. For another thing, the more carefully you code, the less cleanup you will need to do after validation.

2. Start with a completely new development environment.
Many developers disagree with me here. They prefer to work with existing files, cleaning up legacy code as they go along. My thinking is, if the site is in need of conversion, it likely has a whole lot of other issues that should be addressed as well: overall architecture, dynamic code and queries, administration and workflow, database structure, page design, and content. Converting to WS without addressing these issues is a bit like putting new guitar strings on a milk crate. Starting with a new, clean dev environment also does wonders for your mental state. It just feels great to leave all that junk behind.

3. If you're new to WS, make sure you take the time to choose the correct doctype.
Your doctype is the backbone of your Web page. You should go no further until you are confident that you have this set up correctly. I could say a lot more about this, but Jeffrey Zeldman says it better: alistapart.com/discuss/doctype/4.

4. Organize your style sheet in a way that makes practical sense, and comment this organizational scheme.
Keep categories of styles together according to their functions: tag styles, formatting, classes, and so on. This is just common sense, I realize, but it's shockingly easy to allow a style sheet to rage out of control.

5. Give semantic names to styles - and other page elements such as includes, for that matter.
If you name a div "lefthandnavlinks," what happens when the site gets redesigned and they're no longer on the left hand side of the page? Your div name makes no sense. There's a better reason for semantic naming, however: it enhances accessibility: w3.org/TR/1999/WAI-WEBCONTENT-19990505.

6. Develop a cognitive map of the Web page you are converting.
I do this directly on the Web page, setting up the layout and putting placeholders in where content will go: [Banner], [Global Navigation], [Main Content], [Footer], and so on. Apple has an article on its Developer Connection that provides some examples of simple page maps: developer.apple.com/internet/webcontent/bestwebdev.html. Developing a page map allows you to construct the page, plug in your CSS, and validate without the added noise of content elements. Content will come later. Page maps also have a refreshing way of making you think more clearly about the page - and the site - you are constructing: with only the structure present, page real estate issues come to the forefront.

7. Don't overuse divs and don't overuse classes.
The Apple site, above, also talks about Classitis and Divitis.

8. Look for opportunities to simplify.
Table-based Web pages were a breeding ground for clutter - in code, in design, in navigation, and in little pieces of content lying here and there. WS-based designs tend to make Web design far more streamlined and efficient.

And that is a very, very good thing.

Popular posts from this blog

Plone Advocate Andreas Mantke to Lead Site-Administration Workshop at 2012 LibreOffice Conference

I just published this article at plone.org on Andreas Mantke, a deputy member of the Board of Directors of the Document Foundation for LibreOffice . Mantke led a workshop for new Plone site administrators in the LibreOffice community during its annual conference last week. See the full article at plone.org/news/andreas-mantke-to-lead-site-administration-workshop .

Announcing the 45th Eastern Primitive Rendezvous

The 45th Eastern Primitive Rendezvous takes place September 23-October 1, 2022.   For more information, visit the official EPR website and Facebook group . We will be hosting the 45th Eastern Primitive Rendezvous on our family farm, near East Smithfield, PA. The dates are September 23 - October 1, 2022.  This is a living-history event depicting 18th-century activities. Visitors can tour the camp each day from 10 a.m. to 4 p.m.  Tuesday, September 27 is School Tours Day, during which we welcome classes from all of the area schools. Campers need to preregister ( nrlhf.org/pdf/pre-reg.pdf ), and period-correct clothing and gear are required.  For the exact location and more details, visit the  official EPR website  and Facebook group . For those of you who attended the 2017 EPR, this is the same location.