Loading...Web Development
Web Standards Distilled to Best Practices
In the “online community” of Web Design there are articles aplenty telling you to use “Web Standards” and use this technique or that technique to do things the “right way”. There’s only a few places that attempt to summarize things or distill this advice. I think in our sound bite society that’s important—especially for those in the industry who have yet to learn the newer techniques.
There’s also not a lot of ways to do that however, so when I saw Standards for Life’s “Standards in a Nutshell”, it was along the lines of something I’d been thinking about for months—anyone who is a standards advocate should be thinking of new and better ways to sum things up and convey the information. We need more of this. The Standards in a Nutshell graphic is a fantastic demonstration in a simple visual way of showing the way it works even for people who aren’t of a technical nature.
I also prefer to use the term "Best Practices" over "Web Standards", as I feel it is a broader description of what we're doing, really.
So what are the Best Practices?
For all the efforts of the Web Standards Project, endless blogs about Web standards, CSS, JavaScript etc. there’s still a portion of Industry which just doesn’t get it. There’s people that learned their skills in the 1990’s or just don’t follow the latest trends.
But here’s a shot at some basic rules to follow.
Comform to the W3C Web Standards as best as the project allows
- Use the elements for what they are (example: a header is a header, not text with a SPAN element around it)
- Validate to HTML or XHTML (standard or transitional, but validate)
- Break things up by the Trinity (Structure/Content, Behavior, Style)
Use Cascading Style Sheets (CSS)
- No INLINE Styles
- Name classes and IDs in your markup and CSS not what they look like, but what they are
JavaScript
- Use unobtrusive JavaScript
- Name classes and IDs not what they do, but what they are
- Degrade gracefully, be able to use the tool without JavaScript
- Use the W3C DOM where you can, not proprietary DOM elements such as document.all
Be Concerned with accessibility even if not a requirement
- Unless you’re working on an Intranet or some other controlled environment, it matters
- Again, degrade gracefully
Organize Your File Structure In a Logical Way
- This isn’t a Web standards thing, but common sense when building a site
There’s more, but do these simple things and you’ll start to benefit immediately.
Where are we today?
I agree with the principles behind comments such as these on the "New Professionalism". But there are extremes and gray areas. Different projects merit different approaches. But it's nice to think the above rules should always be kept in mind.
This isn’t a religion. Take it easy. I’ve witnessed serious flaming on mailing lists and in forums when people question things and others rant and rave about things like, “how could you possibly use a table for layout, what were you thinking??”. The other day there was a fairly heated discussion at work about Header Elements (h1, h2, h3…) and their hierarchy rules.
It’s open to interpretation, and every project is different. Read the spec if you have to. It’s there online for everyone to read. And in time, things will sort them out. Look at where we are today as opposed to even three years ago, we’re in a much better place.
I prefer to think of things, especially if you’re using a Transitional DTD (it’s called transitional for a reason) as a continuum. There’s a lot of gray areas. The world needs to work it’s way in there, little by little, but the battle isn’t won and we still have a ways to go. Work with people, don’t berate them. Lead by example. In the end, there’s standards and specs, and then there’s reality.
Especially when people are still using things like ASP.NET 1.1, but that’s a different article.
Apr 11, 02:03 AM in Web Development (filed under Web-Standards)
Possibly Related Articles
Commenting is closed for this article.