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

This post will be more relevant in the future when more browsers support the new CSS 3 Selector specification, which includes a lot of neat attribute and pseudo-element selectors, among other things.

I’ve been looking for a way to do alternating table rows with CSS only; no JavaScript and no adding class=”alternating” to the tr element in server-side code. After a tiny bit of experimenting, I found the following solutions:

Alternating every other row:

tr:nth-child(odd) {
background-color: #CCCCCC;
}

tr:nth-child(even) {
background-color: #6699FF;
}

Changing between 3 different colors:

tr:nth-child(3n-2) {
background-color: #FF9900;
}

tr:nth-child(3n-1) {
background-color: #006633;
}
Read the rest of this entry »

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.