Zorked!

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.

I like my CSS to be right. And by right, of course I mean “my way”. Now, I try not to be anal-retentive about many of these things, but they’ve been valuable for me in easing maintenance work. They provide consistency and readability, which is what I like, since I’m lazy.

Now, everyone and their mom (assuming their mom is a web developer/CSS guru) has already gone over how they like this, so I know I’m beating a dead horse. However, I think it’s worthwhile to explain why I do it this way.

Property assignments

For example, display: block is a property assignment. There are two rules here. First, I keep all property assignments within a block alphabetically ordered so that I can find them with no problems.

Example:

.section {
background-color: #F00;
display: block;
height: 100px;
text-decoration: blink;
width: 200px;
}


I generally keep them in this format: the “sort of compact” method. The selector goes on the first line, along with the opening bracket. Then, all the property assigments are listed, one per line, and then the closing bracket is on its own line. Nice and readable.

If there is just one property assigment, as is the case with certain things, everything will go on one line, from the selector to the closing bracket. ex: a:link {color: #600; }

Declaration ordering

I try to keep all my declarations in the same type of hierarchy as they would normally appear in an HTML page, or however makes the most sense. Generally, tag-based selectors (h1, a, p, marquee [just kidding]) all come at the top, followed by class selectors for repeated elements, and then finally for single-use, ID selectors.

File hierarchy and structuring

This is really the most important part: how you organize the way you store your CSS files on your site. In Roots, the way I’ve split up my files is first by media type, and then by function. In addition to separate files for each media type, I create little snippets for layout, color palettes, typography, forms, etc. By allowing SSI to process my CSS files, I can keep everything organized and easily maintainable, yet only have one file that the client has to download.

Here’s the quick rundown:

Common CSS

/common/ - this is where I keep snippets that are used among media types, examples being the subfolders below…
»color-palettes/ - all main color for every element on the site is stored in a color palette CSS file, so that I can change color schemes at any time.
»typography/ - obviously, for all font declarations. Once again, I can change the typography with one line change. This is especially useful for when different media types require certain fonts.

Screen CSS

/screen/ - All code for the screen media type, including some files that simply reference a file in the /common/ folder. The main file here is screen.css, from which everything else is SSI’d in.
»color/ - This is one of those places where it’s just a reference to a color palette. I also include some overrides or additional declarations, if necessary.
»layout/ - This is where anything related to layout of elements on a page is stored. Layout grids and code snippets galore!
»»grids/ - I store a variety of grids here, generally for 1-, 2-, or 3-column layouts. Any one of them can be swapped in at any time
» - In this /screen/ folder are files for the header and footer, navigation, forms, and standard content. Keeping them separated helps for maintenance–if something’s wrong in the header, I don’t have to sort through a bunch of declarations in some huge file to find it.
»typography/ - this, like the color folder, is simply a place to reference which typography palette I wish to use.

Print CSS

/print/ - All code for the print media type. This is much more trimmed down than the screen folder.
»color/ - Once again, the color folder, for the same purpose as in the screen media type
»layout/ - This folder is for print layout, and only contains 3 files: base.css, content.css, and layout.css. Base.css is for setting up print-specific things, such as paging. Content.css is for standard elements, and layout.css is for basic layouts…no grids here, most likely.
»typography/ - Just like the screen media type

Handheld CSS

/handheld/ - All CSS for the handheld/small screen rendering goes here.
»color/ - The infamous reference color folder appears again.
»layout/ - This folder contains header and footer, navigation, forms, and basic content, just like the screen layout folder, but does not provide anything for grids, since that’s not very good for handheld devices. Basic layouts can be done in the content file.
»typography/ - Typography’s folder is here to join in the fun as well.

Aural/Auditory CSS

/aural/ - There’s just one file here, since there’s not much to do for aural. Not much support these days, so what can you do?

Sections and Pages

/_sections/ - Whenever you need to override or add some styles for certain directories/sections of your site, they go in here.
/_pages/ - For page-specific overrides, you can put a CSS file here rather than using inline styles if you want to have some of the benefit of SSI parsing or client caching.

Base.css - Default style simplification

Let’s not forget the magical base.css file, which tries to reduce as many of the differences in default styling among browsers. Mostly, this is margin and padding work, but also there are some font sizing things and list edits to take care of.

You’re probably trying to figure out why anyone would ever use their toaster to browse the Web. Well, chances are good that nobody actually will, but it makes for a better visual.

The next Web-enabled devices

In reality, your television will probably be the next household item to connect to the Internet on a regular basis (no, I’m not talking about Microsoft’s bastard child, WebTV). Through 2006, we’ve already seen a huge increase of on-demand programming which follows essentially the same server/client model as this website. The technology is there, and it’s available, so it’s essentially just a matter of time before it hits the mass market.

What’s after that? Probably your stereo equipment or radio, so you can just stream that Internet radio station through your alarm clock in the morning, and directly into your tired little head.

Let’s not forget work: every piece of equipment that you see as pretty stupid today will be growing much smarter in the next few years: scanners, printers, copiers, fax machines, and the office phone system. While those may not necessarily be connected to the Internet, they may connect to the Intranet using some text-based browser. Heck, some may already do that, and I just don’t know about it.

The Web is about communication

Technology tends to enhance communication, which I think of as the translation of ideas into sensory input. Education, music, chatting, collaboration, business, physical training: all require communication in one of its many forms. As technology keeps moving, I believe we’ll see the progression of the Internet into each of those communication spaces. Guess what that means for web designers? We need to be thinking way ahead of today’s user agents and devices, and toward a future that holds a much wider variety of visual and auditory communication methods.

Modal representation

I believe the way of the future is modal representation: change of the way something is perceived, depending on the method in which it is accessed. The most important piece of this is our good old friend, separated content and presentation. If we have content that can be transformed with an external file or mechanism, all we have to do to make our website compatible with new technologies is to create a presentation for that mode (or, if possible, allow for the same output across multiple modes). Of course, I’m not bringing up anything new here: you’ve probably heard about the CSS @media rules.

HTML is not the final answer

However, let’s be honest with ourselves: HTML has been around a long time, and is very much widespread as I’m sure you know. HTML is not the future though; it simply cannot be changed fast enough to keep up with changing requirements, although it is usefully generic in that it can display and provide guidelines for document formatting. Even assuming that manufacturers would/could update their browsers every month to keep up with specifications changing in that same time frame, that still wouldn’t be fast enough. That’s where the concept of even using HTML is at fault when it comes to forward compatibility.

What I’m saying is this: separating your content from your presentation is good, but it’s not going to be the end-all. Eventually, your site will have to be revamped for future web user agents, simply because HTML is not flexible enough to allow for possibilities that the future holds. Let me clarify: HTML alone is not flexible enough. People will say that you’re future-proofing your website, but in reality, you’re just making it very easy to update and maintain, two very worthy causes. Thing is, we don’t know how people will be developing the Web in the future, but it’s safe to say that it won’t be HTML as we know it.

What does the future hold?

So what is the future? Well, I think the W3C is on the right track with XHTML: HTML conforming to the XML standard so that it can be extended with namespace, transformed using technologies like XSL, and presented to the user agent with technologies such as CSS. The “problem” with the Web is that it constantly evolves. People find new ways to do things and present information all the time, and the HTML standardizations just can’t keep up. I think there should be a self-describing, extensible standard for markup, transformation of that markup, and formatting of that markup.

Browsers are holding back the Web

What’s holding us back? In a word: browsers. At the time of this writing, Internet Explorer 6 comprises the majority of all user agents in use today, and it doesn’t support the capabilities of reading XHTML as XML, which is really the benefit in the first place (not code standardization, as many like to think). Not that other browsers are doing all that great either, but the standards haven’t been around, so I won’t be too hard on everyone. Here’s the thing: browsers should be very ignorant as to what’s happening with the markup, transformation, and formatting of a document, but right now they do a lot of their own interpretation of the standards. Markup is “validated” against a browser’s own cache of a DTD, rather than comparing against the referenced DTD in the doctype, or the included namespace in the case of XML. So, rather than self-describing, we have a very static language.

The same goes for CSS: browser manufacturers spend forever implementing the changes from version to version of CSS. Why not have a “doctype” for CSS as well, that can reference a specific standards document that defines how selectors should be interpreted, how the box model should work, etc. That way, whenever an update to the standards document comes out, web developers can just point to the new DTD, and the browser will theoretically be able to render it. Sure, this is a lot of work on the part of the browser manufacturer, but to really expand the Web’s horizons, I think that sort of functionality is necessary.

The shining light of the group is XSL, which already does its job pretty much as well as you could expect. Transforming XML isn’t always an easy task, but virtually any transformation is possible using the XSL sub-languages. However, the standard could once again define how selectors should be interpreted, as I’ve described for CSS above.

Back to modal representation

If XHTML/XML, XSL, and CSS worked the way I mention above, then developers would be able to transform the XML, and format that output with CSS based on the current mode. So, while your recipe website will be graphically enhanced and will have news, interviews, etc. when viewed in a “normal” browser, when someone navigates to it from their oven or refrigerator’s browser in the future, the first things they’ll see are a recipe search tool, and a list of popular recipes. This brings up another conundrum: eventually, we’ll have to have more than just modes, we’ll have to have sub-modes, or classes, of user agents. For example, a future mode type may be “appliance”, which is useful because you’ll probably know that it’ll have a lower resolution screen, and not as sophisticated of an input scheme as a normal computer, but you’ll definitely need to be able to differentiate an “oven” appliance, a “refrigerator” appliance, and a “dishwasher” appliance.

The future for now

For now, what do you do? True XHTML isn’t really a viable option at this point, since certain browsers which will remain unnamed can’t have it served as xml. Internet Explorer. What I suggest for the time being, so that it will be easy to transition into XHTML, is to use HTML 4.01 Strict and enforce lower case tags and quoted attributes internally. If you stick to that, the transformation from HTML 4.01 to basic XHTML in the near future shouldn’t be too difficult. Make sure you separate your content from your presentation, as that is the crux of the matter in the first place.

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'
"-->

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

<!–#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.

Ok, first of all, you should be displaying full text for your feeds; none of this crap where you only display a teaser. Teasers are a waste of time, and just wear me out. I have RSS feeds because I DON’T want to visit the site and wait for all your images to load. I want to be able to judge for myself whether your post is important without having to visit the real thing.

Anyway, here’s my point in this article: you should design your articles with RSS feeds in mind first. If you run a blog, that’s probably how a lot of your viewership reads what you write. What does this mean for your code? Well, it means you need gracefully degrading, semantic HTML.

Semantic HTML

You need descriptive HTML that splits your articles into sections logically. You don’t always have access to CSS styling (or at least, you can’t count on it), so you should be using your headers, paragraph elements, and lists as appropriate. If your article is viewed without anything other than default styling, your readers will still be able to easily skim to where they want to read.

Graceful degradation

If a feed reader does support HTML (most nowadays do), you won’t be able to count on certain things, like external stylesheets, background images, or video and normal images working properly. If you post a video, make sure to also post a link directly to the video.

Basically, if something you’re writing won’t work without CSS, find a different way to do it. You can’t make your feed look just like your web page, and you shouldn’t try either. They’re essentially different media.