May 05, 2008
In the old days of the web a site's presentation was entirely hard-coded in the HTML. It had handy things like font tags which is what one used to say what face the text was in, what color, size, and so forth. Other ways of presentation were to say what background color, or "bgcolor," the table cells were, what background images they used, what colors the borders should be, etc., which was important then because layout was done almost entirely in tables. This worked OK, but a need for more control of webpage presentation necessitated more evolution of HTML at the cost of it becoming more complex and difficult to update. Basically code for pages grew longer and longer... and uglier and uglier. And it didn't even all work all of the time, considering that Netscape and Internet Explorer - the two leading web browsers at the time - utilized tags that the other did not, causing major cross-browser compatibility headaches. Web designers and developers dreamed of a better way, a way to more separate presentation and content. And by 1999, they had one: Cascading Style Sheets, or CSS.
Non-cascading style sheets have been around in one form or another even before most people knew what an internet was. But it wasn't until 1994 when a style sheet method was proposed that closely resembled the CSS of today, the most important difference being the "Cascading" part, which means interaction and prioritization between an author stylesheet, user stylesheet, and then a User Agent (browser) stylesheet. It wasn't until late-1996, though, that CSS level 1 Recommendation was published by the WC3. And unfortunately it wasn't until 1999 that a web browser achieved near-total adoption of CSS standards (Internet Explorer), and by that time development of CSS Level 3 began, which is still being tinkered with today.
A lack of support for CSS (and probably, also, a lack of knowledge of it) is why I don't think I ever created a style sheet until about 2002 or so. And I think the same timeline can be applied to most designers and developers. Old habits are hard to break, especially when CSS was still fraught with bugs and inconsistent cross-browser support. But we forged on, knowing that even with its problems CSS was the Promised Land, a way to finally get more consistent presentation and separate it from the content so both would be easier to maintain.
And Separation of Presentation and Content is considered to be an important aspect of this new era of the Web we're in now, often called "Web 2.0." And by now and all web designers or producers worth their salt should be almost entirely or using CSS (along with DIV layers, which have essentially replaced tables) for presentation. Font tags have all but vanished; Dreamweaver, arguably the most popular WYSIWYG editor, snubbed its nose at font tags several years and versions ago. Bolding and italicizing text directly in the HTML are still around, though, but the tags are now "strong" and "em" (emphasis), respectively. (Honestly I don't know what was so wrong with the "b" and "i" tags, but oh well.)
So how does it work, one might ask? How is separation of presentation and content achieved? Simply put, a CSS file is coded with classes and IDs which you reference in the webpage file - after you've linked the webpage file to the CSS file of course. In these classes and IDs you declare what each one of them does to the text, DIV layer, table cell, etc., which could be defining font colors, font size, background colors and/or images... I could go on and on. The point is, your style definitions are saved to be reused over and over again, instead of having to copy and paste the same hard code over and over again, which is what we had to do in the old days. And THAT makes for cleaner, simpler, more elegant code, and makes editing the content much easier. This is very important, since more emphasis on Content these days versus monolithic marketing fluff that used to dominate the domain of corporate websites. And this emphasis includes making content more living, ever-changing, especially user-managed content, as in with blogs.
You can get too crazy with CSS, though. When I first got into it my coworkers were all hopped up on defining a bazillion things in each class in an effort to make the HTML pages shorter and shorter, to the point where the simpler pages were only about five lines long. That was pretty cool, but the downside was that most of those really bloated classes were not reusable in multiple situations. And it just shuffled the complexity from the HTML over to the CSS. This philosophy does not work, especially since developers, when they're taking an HTML/CSS prototype into a Content Management system, like to reuse classes whenever they can. This is definitely a bad method of coding CSS, especially if the site is to be dynamic and content-managed.
But there are many different philosophies with CSS one can use. There are almost as many methods of designing them as there are designers. And which ones are good or bad pretty much depend on who you talk to. And of course, the best way to do it, any designer or producer will tell you, is the way he or she does it. But if you just remember to make the classes as reusable as you can, like for instance relying on "strong" or "em" tags in the HTML to further format a text class so you can reuse it in multiple places, you're doing good. Or even, if you're applying classes to table cells, you may even want to - *GASP!* going back to defining widths and text alignments of tables, cells, or DIV layers in the HTML!
But that comes up less and less often with how the use of DIV layers is eclipsing the use of tables these days and you will rarely want to define widths of DIV layers in the HTML, actually; it's better to apply a double class to it or an ID. But still, that philosophy is a good one to keep in mind. Just always be thinking "How can I make this class more reusable?" and you'll usually be on the right track.
For example, when you're redefining header tags like H1 or H2 (which is a good idea for headers in terms of Search Engine Optimization - SEO) you might not want to define the color, in case the header might be a different color in different situations. What I like to do, personally, is set up the site's color scheme at the beginning of the style sheet for the sake of a consistent vision of the branding, give each color an appropriately-named class, and then apply that class to the H1 tag, which I've already redefined to have other attributes. I will only put the text color in the H1 redefnition if I am absolutely certain that the color of each header will always be the same.
Let's say that the client changes branding a little, or they (or you) decide that the header would be better to be another font face. Or size. This is where Separation of Presentation and Content can be extremely useful. If you just change that one redefinition of H1 and reupload the sheet, boom, suddenly all the H1 headers are changed. Easy, huh? In the past, that could have taken 20 or 30 minutes, or maybe even an hour or so if the site is gargantuan, depending on whether or not you had a good "Find and Replace" feature on your WYSIWYG editor. And things like that can really affect budgets and timelines.
Being able to do that can mean that sites can get a fresh coat of paint, as I had mentioned earlier, instead of a whole redesign. You can sometimes reskin a website by only modifying things in the style sheet. You might even get away with restructuring it just by redefining classes controling attributes of DIV layers - but usually it's more complicated than that (the possibility of this depends on the forethought the producer had, and the more clever he or she was when constructing the initial site). But the point is, there may not be a need to go in and touch the content at all. The site can, in theory, change around it. For instance, a News and Events module could be shrunk, expanded, or moved to a different area of the page or site, or its asthetics could be changed - like color and so forth - without changing its content or programming behind it. And if content of that module or anything else does need to be updated, it should be as simple as it usually is.
What is the future of CSS? Well, it's murky, to be honest. The developers are still working on CSS3 and trying to get it fully released - someday, but in the meantime are adding to CSS2. This website has all the nitty gritty there. There is an argument, though, in the CSS community on whether or not to issue new versions of CSS2 while we're waiting for CSS3 to be fully realized. Some people think that perhaps it's not a new level that's coming anyway, just more modules. But one thing is for sure, Presentation and Content, for the most part, will continue their separation and maybe someday their divorce will be final, if you will.
For more information on CSS as well as some useful tips and tricks, websites like A List Apart or the CSS Discuss Wiki are great resources to consider to ehnance your knowledge of it or maybe just to put a few more tricks in your CSS magic hat. Those are just a few of many, though. I reccommend lots of web searching. So, Happy Googling, folks!
comments powered by