Why CSS
Here’s part 6 of the ongoing serialization of Refactoring HTML, also available from Amazon and Safari.
The separation of presentation from content is one of the fundamental design principles of HTML. Separating presentation from content allows you to serve the same text to different clients and let them decide how to format it in the way that best suits their needs. A cell phone browser doesn’t have the same capabilities as a desktop browser such as Firefox. Indeed, a browser may not display content visually at all. For instance, it may read the document to the user.
Consequently, the HTML should focus on what the document means rather than on what it looks like. Most important, this style of authoring respects users’ preferences. A reader can choose the fonts and colors that suit her rather than relying on the page’s default. One size does not fit all. What is easily readable by a 30-year-old airline pilot with 20/20 vision may be illegible to an 85-year-old grandmother. A beautiful red and green design may be incomprehensible to a colorblind user. And a carefully arranged table layout may be a confusing mishmash of random words to a driver listening to a page on his cell phone while speeding down the Garden State Parkway.
Thus, in HTML, you don’t say that “Why CSS” a few paragraphs up should be formatted in 11-point Arial bold, left-aligned. Instead, you say that it is an H3 header. At least you did, until Netscape came along and invented the font tag and a dozen other new presentational elements which people immediately began to use. The W3C responded with CSS, but the damage had been done. Web pages everywhere were created with a confusing mix of font, frame, marquee, and other presentational elements. Semantic elements such as blockquote
, table
, img
, and ul
were subverted to support layout goals. To be honest, this never really worked all that well; but for a long time it was the best we had.
That is no longer true. Today’s CSS enables not just the same, but better layouts and presentations than one can achieve using hacks such as frames, spacer GIFs, and text wrapped up inside images. The CSS layouts are not only prettier; they are leaner, more efficient, and more accessible. They cause pages to load faster and display better. With some effort, they can produce pages that work better in a wide variety of browsers on multiple platforms.
Shifting the markup out of the page and into a separate stylesheet allows us to start with a simple page that is at least legible to all readers, even ones with ten-year-old browsers. We can then apply beautiful effects to these pages that improve the experience for users who are ready to handle them. However, no one is left out completely. Pages degrade gracefully.
Shifting the markup out of the page also has benefits for the developers. First of all, it allows different people with different skills to work on what they’re best at. Writers can write words in a row without worrying about how everything will be formatted. Designers can organize and reorganize a page without touching the writers’ words. Programmers can write scripts that add activity to the page without interfering with the appearance. CSS allows everyone to do what they are best at without stepping on each other’s toes.
Whereas CSS is a boon to writers and designers, it’s a godsend to developers. From a programmer’s perspective, a page is much, much simpler when all the layout and style information is pulled out and extracted into a separate CSS stylesheet. The document tree has fewer elements in it and isn’t nested as deeply. This makes it much easier to write scripts that interact with the page.
Finally, the biggest winners are the overworked webmasters who manage the entire site. Moving the markup out of the pages and into separate stylesheets allows them to combine common styles and maintain a consistent look and feel across the entire site. Changing the default font from Arial to Helvetica no longer requires editing thousands of HTML documents. It can now be a one-line fix in a single stylesheet file.
CSS enables web developers, webmasters, and web designers to follow the DRY principle: Don’t Repeat Yourself. By combining common rules into single, reusable files, they make maintenance, updates, and editing far simpler. Even the end-users benefit because they load the style rules for a site only once rather than with every page. The smaller pages load faster and display quicker. Everyone wins.
Finally, let’s not neglect the importance of CSS for our network managers and accountants. There may be only a kilobyte or two of purely presentational information in each page. However, summed over thousands of pages and millions of users, those kilobytes add up. You get real bandwidth savings by loading the styles only once per user instead of with every page. When ESPN switched to CSS markup it saved about two terabytes of data transfer a day. At that level, this translates into real cost savings that you can measure on the bottom line. Now, admittedly, most of us are not ESPN and can only dream of having two terabytes of daily traffic in the first place, much less two terabytes of daily traffic that we can save. Nonetheless, if you are experiencing overloaded pipes, or you are unexpectedly promoted to the front page of Digg, moving your style into external CSS stylesheets can help you handle that.
Continued Monday…
June 6th, 2008 at 3:20 pm
The problem is that for real-world sites you really can’t separate presentation from content with HTML and CSS. The tools just aren’t there.
Look at CSS Zen Garden for example (whose book is one of the book ads above, at least when I write this), you would expect their example page to be as presentation-less as they come, but when you look at it (and read the book) it turns out that the HTML is littered with extra layout-related tags because otherwise it wouldn’t work. It’s impressive that they can get that many different looks with the same HTML, but the reason is that there is quite a lot of nonsensical code in there, code whose only purpose is to plug the holes where CSS just doesn’t cut it.
Most of what you say in this installment is true, but its not very pragmatic. The Zen website and book has the same problem, there’s this idea of HTML+CSS and separation of presentation and content which is talked about page up and page down, but when it comes to the code it’s all “oh, but we had to stick this div there to make sure that that thing over there could be styled like we wanted”. The idea that HTML is content and CSS is presentation is too simplified, HTML is content, and HTML is presentation.
In most cases what you have is content stored in a database, as text with simple HTML tags for things like links and emphasis (which is exactly how this comment will be stored). This is where HTML is content. Then you have a template of some kind which sticks that content in a structure defined in HTML. Some things in the structure is content, like “this part is a menu”, but many things most definitely aren’t, they are just about which order the tags need to be in to make CSS layouting possible. Lastly, on top of all this you have a CSS that defines the rest of the layout, things like widths and sizes of things and also does the styling (fonts and colors). It’s not CSS that separates presentation from content (although it helps), it’s using a database and a templating engine that separates the two.
June 7th, 2008 at 8:58 am
The CSS Zen Garden is a little out of date. Some of the techniques used there are no longer state of the art; and in particular the extra divs you note are usually not necessary any more.
Templating systems are important (this site uses one) and do a good job of separating markup from content on the authoring side, even if they use presentational HTML. They’re less useful for anyone who needs to consume the data though since it’s no longer obvious what’s presentation and what’s not. The best of both worlds is a templating system built around CSS, that only uses HTML for semantics rather than presentation.
June 9th, 2008 at 10:49 pm
It’s seems to me the CSS makes a remarkable point. If a client does not need super-puper presentation
he has facilities turn the CSS off or use his own CSS.
Presentation layer shifts on _client_ _side_.
April 17th, 2009 at 8:21 pm
[…] Why CSS – Elliotte Rusty Harold […]
October 10th, 2011 at 9:05 am
[…] Why CSS – Elliotte Rusty Harold […]