I’ve read a lot of articles and blog postings about the advantages of web standards, and the techniques and strategies for employing them. But in all my reading I haven’t come across an article that specifically addresses the issue of using standards in a team environment. Building a standards-compliant site when faced with a team of developers who don’t follow the them can be rather daunting, especially when you’re the lone voice pushing for new and improved methods.
I’ve been a web standards advocate (in my own small way) for about a year. Like many others, I’d been using CSS for a quite a while to define fonts and style links and what-not, but had never really engaged in full-throttle CSS design. Also like many others, a little orange book opened my eyes to the value of standards and a pretty little garden convinced me of the power of separating content from presentation. I became a born again web designer.
And (to further extend the fundamentalist religion analogy) I began to preach the gospel and urge other web heathens to convert. I had seen the light, and felt it my duty to save the souls of those poor saps still caught in the dark ages, still building IE-centric pages with deeply nested tables. And it’s often an uphill battle.
Those who know the Word also know the reasons web standards help business; compatability, searchability, accessability, save bandwidth, easier maintenance, faster redesigns, etc. But in most corporate environments revenue is king and — let’s face it — if your idea doesn’t generate revenue it’s going to be pushed to the back burner. The decision-makers are not easily convinced that it is worthwhile to devote the time and resources required to convert an entire site to standards, no matter how you spin the ROI. On top of the development time, there’s the learning curve involved in getting an entire dev team up to speed on the technology.
Luckily, the drive for steadily increasing revenue also means a well-managed e-commerce site will never stagnate. New features are always being added, existing features are always being improved. And if you’re part of a web development team on such a site, every new project is a fresh opportunity to slip in some more standards compliance, hopefully paving the way for that dream redesign if/when it eventually happens.
Many cooks, one pot
Large sites are built by teams because it’s just not possible for one person to handle all aspects of development. On a typical smallish development team, you’ll likely have three or four programmers, one or two QA engineers, at least one DBA, and most likely a single front-end designer who jockeys all the pixels. The front-end graphic designer will make the pages look good, while the back-end programmers write the code to make the pages work. DBAs and QA testers don’t normally deal with page markup and styles, so for the rest of this article let’s just assume the rift lies between the front-end designer and the backend coder. We can also assume your project does use some CSS, and that you have an external style sheet used throughout the site.
While we’re making assumptions, let’s assume the front-end designer in question is actually writing his/her/your own markup. A shocking number of professional web designers don’t actually have a hand in page construction. They’ll often just hand off a picture of a web page to another developer who must then slice and hack and attempt to make a working web page that looks like the picture. Let me take a moment to slap their collective wrists and implore those designers to buy a few books and learn some markup.
On any project, the production work will tend to flow one of two ways: front to back, or back to front. In the front-to-back workflow, the designer builds a static HTML mockup, which is then delivered to the programmers who insert all the functional bits. Back-to-front development starts with an ugly yet functional page which the designer must then beautify. Not being a programmer myself, I much prefer to work front-to-back, since there’s no risk of me breaking any of the complex programming as I rework the page to make it pretty. But that’s just me. Either approach will still yield the same result — a working dynamic page that looks good.
If it ain’t broke, fix it anyway
If you’re the one writing the markup, you can take measures to ensure standards compliance. When other developers work on the same page later, encourage them to follow the original markup to maintain the integrity of the final page. If they need to add something more, they can refer to what’s already there and hopefully not stray too far from the standard. Label each section or area of the page so it’s easy to discern where the content ends and the footer begins, for example. Including clear and helpful comments in your markup is an invaluable aid to everyone.
It’s much easier to start with a compliant foundation than it is to add compliance later. At some point you’re inevitably going to have to work with someone else’s markup, and that’s where it gets harder, especially when that markup is clogged with spaghetti soup.
Cleaning up bad markup is no fun, and you always have to be sure you’re not significantly altering the way the page looks or functions. There are still plenty of things you can do to streamline existing HTML and get it to approximate valid XHTML. For starters:
- Close all open tags, and be sure they’re closed in the reverse order in which they were opened. If you’re aiming for XHTML, add that closing “/” to optionally-closed tags like
img,inputandbr. It’s not valid if you’re serving an HTML4 doctype, but it’ll be less cleanup when you make the switch down the road. - Make paragraphs into actual paragraphs (
<p>yadda</p>) and eliminate those obnoxious<br><br>pairs. - Convert all tags and attributes to lowercase. This includes JavaScript event handlers, so
onMouseOver=function()becomesonmouseover="function();". - Double-quote all values. Some people use single quotes out of habit, and some development tools like MicroSoft Visual Studio may omit the quotes unless configured otherwise.
- Strip out unneccessary presentational markup where you can, to be replaced by CSS rules in your style sheet. There is no need for every cell in a table to be marked up as
<td class="content">when you can make each cell inherit the style from a parent (Netscape 4 and IE in quirks mode have issues with passing rules down to child table cells, but that’s a matter for another article). - Do away with font tags and redundant tag nesting. If you encounter something like
<font class="doohickey">doohickey</font>at least convert it to aspan. - Replace deprecated tags like
<center>and<small>with their proper XHTML+CSS equivalents.
It’s also a good idea to validate your markup as XHTML even when you know it’s not valid. Using the W3C’s “verbose output” you can easily spot any unclosed or improperly ordered tags, unquoted values, and so forth. You may not be able to address all of the errors, but catch as many as you can.
All of this cleanup does no harm even in a table-based layout, and it’s one subtle step closer to compliance. There will be less headache down the road when you have to revisit the page for any maintenance, enhancements or redesign.
Testify, amen
I’m pretty low on the totem pole at my company. I’m not in any position to force my fellow web developers to follow a particular methodology. I don’t set the goals or write the business requirements for our projects. I can’t dictate how other people perform their tasks, I can only make suggestions and offer alternatives. But I firmly believe that lean clean markup and CSS is the best way to build a website. I believe in giving the end user the freedom to choose their own browser and not be excluded. I believe this, and out of the goodness of my heart I wish to share this powerful message with my brothers and sisters in cubicles around the world.
Ok, maybe I’m going a little overboard there. But if you practice what you preach by following web standards in your own work and encourage your teammates to do the same, you can quietly convert them. Eventually you won’t have to push for standards — the standards will just be, well, standard.