There’s been a good bit of talk lately about CSS resets, and how good/bad they are. This conversation tends to come up every 6 months to a year and always gets people excited. This time around, Jonathan Snook’s No CSS Reset is “the culprit”. I think his general sentiment is good, and he comes to almost the same conclusion, except that I’ve actually created the Base CSS file that he speaks of. More to follow…

The Ugly

I’ve seen lots of people use a star reset: * {margin: 0; padding: 0;}. If you use this by itself, and you aren’t resetting margin and padding on other elements like headings, p, and form elements, you are going to get bitten. Hard. Firefox and IE6 are the special offenders here: form elements, especially checkboxes, radio buttons, and selects will get styled especially poorly and need to be restyled with some padding or the arrows won’t appear, or they become impossible to select.

The Bad

The bad is when you don’t do any common groundwork; every project means you start over and you avoid CSS resets like the plague. Ok, so this isn’t really all that bad, but it’s going to cost you a lot of time in the long run, especially if you’re developing on a team. What happens when you have the n00b that doesn’t understand some of the nuances of cross-browser text sizing, or the way different form elements are handled? You’ll probably say “educate them!” or “then don’t let them touch it until they know what they’re doing!”, but that essentially makes them non-productive. It’s bad practice to make CSS more magical than it already is; give everybody a headstart and lay a common framework.

The Good

As usual, we want to find the middle ground.

I think Eric Meyer’s CSS is moving in the right direction, but it’s a bit bare at the end result. I think the point of a base CSS is that it’s supposed to look decent after you’re done so that you don’t have to think about every style. The idea is to make it look very similar cross-browser, not to pull a Dark Ages Catholic Church and reset everything. Eric mentions this in his article, but a lot of people just download and plug it in.

There are plenty of UI frameworks out there that have a common CSS file that they use, mostly filled up with proprietary classes and IDs, but you can often extract bits and pieces from the generic parts to use. The point is, rather than resetting everything, you can instead create a foundation or base for your CSS to at least make it cross-browser friendly, and at least presentable by default.

I’ve been using my current base.css file for about 3 years now, and I update it from time to time. Feel free to use it if you’d like. You can see it in action at http://labs.zorked.com/lib/base.html

Download: Base.css

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.

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.

5. Clean up your code

Search engines like clean code: code that is minimal, and accomplishes the simple purpose of presenting the content to the user. In other words, you want a high text-to-HTML ratio. This will come naturally if you have separated your markup from your presentation using style sheets, but you can probably do even more. Avoid tag soup and “div-itis”, and include scripts, stylesheets, and other site elements externally, rather than inline.

Currently, some search engines are marking off for bad code, and I expect this trend to continue in the future. Also, go ahead and validate your site against an HTML DOCTYPE; make sure to choose the right DOCTYPE, too.

Things like formatting are inconsequential, so you don’t need to go through and indent your pages. Just make sure that elements are correctly nested and that HTML is valid against the DOCTYPE you chose. The W3C validation tools are quite useful:

• W3C HTML validator
• W3C CSS validator

4. Set up clean URLs

This is minor, but it can help. Most content management systems will allow you to do this automatically, and it’s not too hard to do it yourself using Apache’s mod_rewrite if you already have “bad” URLs set up that you don’t want to mess with.

Essentially, the idea is to have URLs that include the keywords you’ve chosen to promote for your page and site (you have chosen keywords, haven’t you?). For example, this page has “seo” and “search engine rankings” in the URL (/blog/archive/lazy-mans-seo-5-easy-ways-to-improve-search-engine-rankings/). Search engines prefer that form to /blog.php?page=400243. It’s also good for visitors, as they’ll have an idea of what the page is about, just by looking at the URL.

By the way, some CMSs use an underscore to separate words. Google (and other search engines, I presume) prefers the use of a dash instead, so if you have the option to switch, do so.

Granted, this isn’t going to make you #1 in the results pages, but it does help.

3. Use semantic document outlining

The original purpose of the Web was to help transmit ideas through documents. As such, HTML gives you pretty good options for semantic outlining of your documents. The most important of these are the header tags. Specifically, <h1>, <h2>, and <h3> have the greatest weight for search engines. The <strong> and <em> tags are also good (but don’t overuse them, as it gets hard to read).

How does it help? Text within an h1 tag, for example, will be emphasized to a search engine as important, relative to the rest of the page. Placing keywords in that text will help “rank” those keywords highly when the page is indexed, so make them relevant.

2. Make a complete sitemap

Sitemaps are a very useful area of your site, both for search engines and for users as well, for the same reasons: sitemaps provide a structure to otherwise non-linear websites, and will help the deeper, meatier webpages show their stuff.

Aside from a standard sitemap web page, you should also create a Google Sitemap. While your ranking isn’t automatically increased just because you have one, it does help to make sure more of your content is indexed. You can automatically generate a sitemap by doing a quick Google search, but one of the better tools I’ve found is from Enarion.

1. Create powerful titles for each page

The <title> element is your best friend in SEO, so make sure it has your keywords in it at least once. Try to find a balance between readability and keyword usage; if in doubt, err to the side of readability.

You have around 60-70 characters that will really be counted and displayed in search engine results, so take that into account. Don’t try to force your company name or the current section into the title, as it will dilute the potency of the keywords that are specific to that page. Here are the exceptions: if it’s the home page (then, obviously, you should put the company name), if your company name is short, or a keyword is part of the section name.

You don’t have to repeat your keywords in the title, but it’s a nice little extra if you can do it without making the wording sound stilted or stupid. Once again, err on the side of human readability. Rememer, just because you’re at the top of the search engine results doesn’t mean somebody will click on your link, especially if the page title sounds dumb.

One more thing: try to keep it alphanumeric. Diamonds, colons, spades, or extraneous marks detract from: 1. the number of characters that your keywords have to fit into, and 2. the professionalism and credibility of the page. Keep it simple. Use a pipe (|) or dash to separate phrases or sections in your title, if you even need a separator at all.

To summarize…

1. Use as few HTML tags as possible
2. Include stylesheets/scripts with the link tag
3. Put keywords in your URLs, and use a dash to separate words
4. Put keywords in headers, strong, and em tags
5. Make both a regular and a Google sitemap (Yahoo and MSN also support the same spec now)
6. Titles should be meaningful and to the point

If you don’t already know, a doctype is a declaration that goes at the very top of your HTML pages. The main reason most people have this declaration is to switch among rendering methods, although you can also serve your pages as text/xml to achieve the same effect (more on that later).

There are several doctypes to choose from, depending on what you’re doing. The first ones deal with versions of HTML back to 2.0, and include “modes”, such as strict, transition, and frameset. A lot of attention has come to the newer XHTML doctype in the last few years, for various reasons. Some has to do with elitism, I suppose, but I think the majority seems to come from bandwagoning instead of from research. So, how do you choose which one is right for your website?

Why do we even use DOCTYPEs?

First of all, it’s important to understand why we have the doctype declaration at all. Essential, the doctype is a reference to a structure, list of elements, and list of attributes that are available to a certain version of HTML. Theoretically, browsers are supposed to use that reference to comprehend elements and attributes that are found while parsing an HTML document. In reality, browsers have their own “cached” reference that they validate against to distinguish elements.

Benefits of using DOCTYPEs

So what benefit does the doctype get you right now? Well, it gives you an easy way to change among rendering methods, and can help when you’re checking your document against a markup validator, since the validator will most likely verify the HTML against the DTD it finds from the doctype reference.

There has to be some other reason why you would use one doctype over the other though, right? Well, yes. The XHTML doctype, when adhered to, forces the HTML to conform to XML standards (hence the name), and can be served as XML. Theoretically, that would allow people to extend their XHTML with other cool W3C standards like MathML and SVG right in line with the rest of their markup, whereas HTML 4.0 requires authors to use an image, or a plug-in to display the math markup or SVG object. If this were how things actually worked, then I would jump directly onto the XHTML bandwagon.

XHTML is too advanced for the current state

But here’s why it’s too good to be true. For one, it must be served as application/xhtml+xml to take advantage of the above-said features. That point brings us to our next problem: older browsers cannot recognize the new features, and will either break or badly malform the content. IE6, for example, cannot handle the application/xhtml+xml mime type in the first place, although there are workarounds; other browsers will break upon seeing the inevitably invalid code, as the pages were probably made for lax HTML standards, not strict XHTML. Even if not, error handling is very poor for XML across the board for browsers in use today.

This brings us to why people really use XHTML (or what passes as it): standardization across documents. Developers (understandably) want lowercase tags, quoted attributes, closed tags, and any other consistencies XHTML offers that I’m leaving out. In my opinion, the important ones here are quoted attributes and closed tags, which can be enforced by using any strict doctype, whether it be HTML or XHTML. Lowercase tag names can be enforced with internal standards documents.

The differences among DOCTYPE modes

The last point touches on it, but I’d like to go into more depth about doctype modes: strict, transitional, and frameset. Let’s totally throw out the frameset mode, as you really, really shouldn’t be using frames at this point. Use server-side includes, templating, or a content management system if you’re wanting to have a standard header, footer, navigation, whatever. That leaves us with strict and transitional. If you’re just now getting the hang of writing standards-based HTML and CSS, or are converting an old system to CSS templates, transitional is fine. But that’s just what it is: transitional. Once you have the hang of it or have the opportunity to rewrite, move on to the strict doctype. See Roger Johannson’s 24 ways article for the differences, and more info ».

Recommendation: use HTML 4.01 Strict

So when do you use certain doctypes? For now, I recommend using the HTML 4.01 doctype. Not necessarily because it’s the best DTD in the world, but because XHTML is still in its infancy, and currently isn’t well-supported by browsers when it comes to rendering and error checking. It’s good to revisit this argument every once in a while to see if it’s worth the change yet. In the meantime, you have the choice between transitional and strict modes. Only use transitional if you’re truly in a transition period.

One final note: use the URL reference in the doctype. For example: <!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN”
“http://www.w3.org/TR/x1/DTD/x1-strict.dtd”> instead of <!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN”>. This allows future user agents to validate against that DTD so that 20 years from now, if your website is still around, user agents that conform to the W3C standards will be able to at least interpret your web pages.