The question I have today is: is it really so bad to break the rules to serve a greater good? Would Whitman’s flowing poetry feel as smooth if it were corrupted with the common ideas of rhyme and meter? Would a journalist’s point be as emphatic if she were restricted from using one-word exclamations?

I believe the same thing goes for web developers when they learn web standards. “XHTML will make my site more accessible, faster, cleaner, prettier, and cooler? Of course I’ll learn it!” So the naive web developer goes along his merry way, thinking that web standards are the best thing since Tim Berners-Lee, but he never learns or questions the reasons behind standards: the underlying fabric of HTML, CSS,XML and other less popular standards.

The standards framework

Many of us have learned an instrument in our lifetimes, so we’ve been forced to learn the framework of music: notes, key signatures, transitions, etc. Upon learning that framework, we can then transcend it, and play jazz, or techno, or other non-traditional genres, but we had to learn the framework first. In order to go beyond the rules, we first have to learn them by heart.

As such, it’s a good thing that we are ignorant in our first stages of web standards development. We need to learn to write good, solid HTML and CSS; we need to learn the differences among versions of the standards, and the DOCTYPES or namespaces that go along with them; we need to learn the ins and outs of cross-browser development.

Now, I like to think that I wasn’t totally naive when I first started learning well-written HTML and CSS. I’d heard the arguments, and I knew what was going on, at least in a theoretical, abstract sense. But I didn’t really know what I was getting into. I thought that by having a CSS-styled website, I would just be able to swap it out whenever I wanted, and we could change the look and feel in a matter of hours. While this is true in a sense, it’s also not the full truth. I still needed to know about good templating; about separating presentation and style; separating data from markup; and about separating styling into groups of layout, color, typography, and media.

Back to our roots

I think in the midst of learning all this new technology and fresh ways of doing things, we forget why we do them, and instead get caught up into dogmatic beliefs that XHTML is the only way to go, that tables should never be used, no matter what, and that divs can and should be used to do anything. But why do we even have standards? Why do we need them in the first place? Well, there are certainly auxiliary benefits to writing good HTML and CSS, such as saving bandwidth (and as such, improving the user experience for dial-up users), providing better accessibility, and enhanced precision and control of layout and theme. But really, there’s one reason why we develop with web standards.

Ease, speed, and maintainability of development.

That’s it. Although selfish at first glance, that’s really the reason that we have web standards in the first place. But before too many start screaming that “no, we’re doing it for the users”, let’s take a look at another powerful industry for a quick moment. Eli Whitney is often credited with division of labor and repeatable, reusable parts. It was Ransom Eli Olds and Henry Ford who turned the ideas into the modern assembly line. Instead of building cars piece by piece, with each automobile at least slightly different from the next, these two pioneers generated interchangeable, reusable parts. In effect, they created their own internal standards so that they could perform better.

What if nobody had ever tried out the idea of the assembly line and interchangeable parts with cars? Well, each car would still be custom-built, expensive, and very hard to maintain. Also, we wouldn’t have common safety features such as airbags, since they would essentially be untestable. Automobiles would be about as useful as tireless, slightly faster horses, rather than the speedy, relatively safe, maintainable vehicles that are manufactured today.

The same goes for web standards. Without them in place, we would still be in the first browser wars, where Microsoft and Netscape competed by adding their own proprietary features to HTML and Javascript (then commonly called DHTML, since the standard wasn’t effective). So, they are useful in the sense that they force browsers to compete on features, rather than rendering, and also that they provide a framework for web developers; an assembly line, if you will.

So, remembering that web standards are created for two reasons: user agent conformity and developer ease, why is it that there is so much conflict about dogmatic use of certain standards and de facto methods of development? I think it’s because of ignorance of the truth, and unwillingness to see the less-than-ideal current state.

The truth of the matter is, as long as a website or web application is usable across different browsers (meeting requirement 1), and is easily maintainable by the developer (requirement 2), why should it matter which standard we choose? Some people use XHTML because they feel it provides them with a better control over their website; I use HTML because I maintain that same level of strictness in my coding style. Certain developers like using Dreamweaver templates, while I like to use SSI instead. It’s a matter of personal preference at that point.

Current state and moving forward

I spoke above about the current state, and I’d like to revisit that. This is the crux of the issue, and is the only reason that I don’t advocate sticking entirely to the standards in complex situations. The only reason that we go “above and beyond” the standards is because certain browsers don’t support the standards that are the way to the future. My reasoning for not using XHTML is that it really doesn’t provide any benefit for me as a developer. I can make my tags lower case if I want to, and can make sure to close each and every one of them. XHTML just forces that upon me at this point. Now, when we get to the unfortunately distant future where people use browsers that can actually support the xml+xhtml doctype, then we’ll be able to do the cool stuff that web standards will provide.

User agents are complex beasts, and unfortunately take a long time to catch up to standards, so until they do I will use plain old HTML, as it serves the purposes of most of my sites.

Today is a good day–a good day for a little bit of Apache black magic, URL rewriting, and environment variables. Apache, in its creators’ great benevolence, allows us to set and use our own custom environment variables that are available from anywhere on your website through Server-Side Includes.

Traditionally, people use them to determine if someone is hotlinking images by setting an environment variable based on the referring page.

However, today is a new day. Today, we want to use URL rewriting and our secret powers to write out an environment variable based on what URL we’re browsing to on our site.

Why would we want to do that, you ask? Well, once we’ve figured out which section of a site we’re on, we can also conditionally include files using SSI. The most obvious benefit to this is to automatically include a header or footer for the current section of a site you’re on.

Of course, by now some of you are surely saying “oh gee, that would be so easy to do with PHP”. Well, this is pretty easy too, and it’s language independent so it appeals to a wider crowd.

The ground rules

I like to keep all my assets, including CSS, JavaScript, and includes in one folder: the all-powerful /_assets/ folder. Include files go in the /_assets/includes/ folder. Today, we’ll be working with /_assets/includes/header.shtml and /_assets/includes/footer.shtml. They have the .shtml extension so that they can do SSI work–more on that later.

Step 1: Set up URL rewriting rules

Rewrite rules take the following form:

RewriteRule PATTERN SUBSTITUTION [FLAGS]


In our case, we’re not going to be substituting any URLs, because we don’t actually want to redirect the URL, we only want to read it and set a variable from it. So, instead of a URL, we use a “-” (dash).

To actually set a variable, we’re going to need to set a flag in the form [E=VARIABLE_NAME:VALUE]. You’ve probably used [R=301] and [R=302] if you’ve done some URL rewriting in the past, so this might look familiar.

So, here are the RewriteRules we need to detect the current section.


RewriteRule ^((index|default)\.(.*)|)$ - [E=CURRENT_SECTION:index,NC,L]
RewriteRule ^(.+?)/(.*)$ - [E=CURRENT_SECTION:$1,L]


Pretty easy, right? Both rules set the CURRENT_SECTION variable; rule 1 sets it to “index” if you’re on an index page, rule 2 sets it to the name of the directory you’re in. Rule 2 only runs if rule 1 doesn’t catch the URL; i.e. you’re not on the front page.

If you’re on http://www.example.com/jordan/, “jordan” would be the value of CURRENT_SECTION.

All set? Let’s move on.

Parsing .shtml files for SSI

Before we leave our .htaccess file, we also need one more thing: the ability to parse .shtml files for SSI directives. Our /_assets/includes/header.shtml and /_assets/includes/footer.shtml files both will be using SSI, so we need to make sure that they’re parsed for it. Most hosts have this enabled, but let’s not assume anything, ok?

Simply add this line somewhere in your .htaccess file:

AddHandler server-parsed .shtml


Create section folders

We’re going to store all our files at /_assets/includes/sections/NAME_OF_SECTION/. For the sake of this example, we’re going to assume we’re at the URL http://www.example.com/jordan/, and that we want to include a header and footer file.

So, create the folder /_assets/includes/sections/jordan/, and create 2 new files: header.shtml and footer.shtml.

Set up variable checking

The last thing we need to do is create the checks in our /_assets/includes/header.shtml and /_assets/includes/footer.shtml files to read in CURRENT_SECTION and include the header and footer files, respectively.

The following code goes in your header.shtml file, wherever you want to actually include the sub-header.

<!--#include virtual="/_assets/includes/sections/${CURRENT_SECTION}/header.shtml"-->

In our example, this will point to /_assets/includes/sections/jordan/header.shtml.

Well, this works, except it tries to find this folder no matter what, even on the index page. What we need to do is exclusive lock out folders that we don’t want to have the section header. While we’re at it, let’s create a way to turn this off at the flick of a switch.

First of all, put this above the include directive:

<!--#set var="USE_SECTION_HEADER" value="true"-->


Now, let’s add in the checks to make sure we actually want to include for this folder:

<!--#set var="USE_SECTION_HEADER" value="true"-->
<!--#if expr="
$USE_SECTION_HEADER = true &&
$CURRENT_SECTION != 'index'
"-->
<!--#include virtual="/_assets/includes/sections/${CURRENT_SECTION}/header.shtml"-->
<!--#endif-->


You may also want to wrap the include directive with a div tag so that you can target it with your CSS. If there are other directories you don’t want to have a sub-header for, you can add them into the if block as well.

So, our final code to place in the the header looks like this:

<!--#set var="USE_SECTION_HEADER" value="true"-->
<!--#if expr="
$USE_SECTION_HEADER = true &&
$CURRENT_SECTION != 'index' &&
$CURRENT_SECTION != 'directory-with-no-section-header'
"-->

<!–#endif–>
We can copy and paste this into /_assets/includes/footer.shtml, and then change a few things so that it looks like this:

<!--#set var="USE_SECTION_FOOTER" value="true"-->
<!--#if expr="
$USE_SECTION_FOOTER = true &&
$CURRENT_SECTION != 'index' &&
$CURRENT_SECTION != 'directory-with-no-section-footer'
"-->
<div id="section-footer">
<!--#include virtual="/_assets/includes/sections/${CURRENT_SECTION}/footer.shtml"-->
</div>
<!--#endif-->


Level Up

Maybe you can take these concepts and do something even cooler with them. It’s relatively easy to expand the URL rewriting to include sub-subsections, so maybe that’ll give you a start.