The Adoption of CSS and Why You Should Care if You Have a Website

By Paula Apynys, July 10, 2010

When the web first became “open to the public”, HTML was the only language you could use to build web pages. Original html pages were pretty much all text, then came the addition of images and tabular data enclosed in tables. But HTML wasn’t built to do anything fancy visually, and certainly wasn’t equipped to create the kind of visual effects people had gotten used to with the explosion of desktop publishing software.

But people very quickly began wanting to format pages in attractive ways. So they improvised. Thus HTML began to be “bent” to create “presentational effects” in ways that had not been intended. Meanwhile, at this time browsers were proliferating and they were using closed, proprietary languages, making it difficult for web developers to create one-size-fits-all pages. A page that looked fine in one browser might fall apart in a different browser. This created a nasty feedback loop where ever-more elaborate layouts were jerry-rigged and then “hacked” to make them work reasonably well from browser to browser as well a on PC, Mac and Linux operating systems. Jerry-rigging the html created “bad code” and bloated code that made pages take longer and longer to download at a time when web access was still painfully slow.

Enter, the WC3 Consortium.

The WC3 Consortium

“The World Wide Web Consortium (W3C) is an international community where Member organizations, a full-time staff, and the public work together to develop Web standards. Led by Web inventor Tim Berners-Lee and CEO Jeffrey Jaffe, W3C’s mission is to lead the Web to its full potential.” (http://www.w3.org/Consortium)

Founded in 1994, “W3C was created to ensure compatibility and agreement among industry members in the adoption of new standards. Prior to its creation, incompatible versions of HTML were offered by different vendors, increasing the potential for inconsistency between web pages. The consortium was created to get all those vendors to agree on a set of core principles and components which would be supported by everyone.” (http://en.wikipedia.org/wiki/World_Wide_Web_Consortium)

The W3C went to work on the problem of HTML’s limitations. Now, the W3C had no authority as such. No one could be made to apply their standards or disciplined for not doing so. And, indeed, WC3 standards have been adopted at wildly disparate rates by browsers and technology companies. But general consensus was and is that operating without agreed-upon standards makes life more difficult for everyone so W3C recommendations are now treated as the de facto rules.

Style Sheets

Style sheets or styling was a concept that had been used in Desktop Publishing programs. The basic idea is that you can set up a “style” for, say, a headline. The style would declare that the Font should be Times, the size might be 20 pixels, the color could be Blue, and maybe you would Bold it. Once you’ve set up those specifications on a style sheet, then you could go through a document, highlight the headlines and click the style “Headline” and instantly you’ve got a line that’s blue, bold, 20 pixels tall and in Times font. That means you don’t have to highlight each and every headline and go to a dropdown menu to select “Times” and another dropdown menu to select “Bold” and another menu to select “Blue” and yet another menu to fill in “20 pixels”.

With HTML, that’s what you were basically having to do to style text. Instead of having a way to apply the same style over and over you had to apply each attribute, one at a time over and over, and every repeat became part of the coding that had to be loaded into your browser before you could read it. This created a tremendous amount of redundant coding.

That was bad enough. But on top of that, HTML did not have any built-in capabilities for more sophisticated effects, such as placing a Headline inside a color filled rectangle that was indented 20 pixels from the left. So people began using Tables (which had been designed to display tabular information similarly to an Excel spreadsheet) to place text and objects where they wanted them on pages. Then they began placing tables inside tables to get more and more precise and sophisticated effects. And each cell in a table had to have styling applied, one at a time. That combined with the various other “hacks” that had to be used to force pages into shape for different browsers added even more redundant coding.

People also created artwork for things like headlines which enabled them to do anything their art software was capable of, so long as they could ultimately export the artwork as a .gif, .jpeg, or .png. (See sidebar.) Artwork “weighs” more than live HTML text and, as far as the coding is concerned, any piece of artwork, regardless of how complex, is read as an .img (for image) by browsers, search engines and screen readers. Sometimes web designers literally created entire pages that were reduced to a .jpeg which meant none of that text was readable by search engines, etc. (You can add descriptive information about an image via what’s called an “alt” tag, and, indeed, per CSS2 you should always do so, but back then nobody did.)

Other than slow load times, it didn’t really matter that much to site visitors with reasonable vision because, like a word processed document, they were looking at the finished product. When you use Microsoft Word to create a page, you see what the page looks like—it doesn’t matter to you what the coding behind the scenes looks like. But on the web, it’s different, because, while people view the “public” page, browsers, search engines and screen readers are actually viewing the source code. (See sidebar) And the source code was a mess.

So, to bring us back to WC3, the consortium concluded that a form of styling would be the best way to deal with the problem of visual layout on web pages. While several different technologies were considered, in the end, Cascading Style Sheets became the language of choice for managing the look of web pages. CSS1 was released in 1996, but it took until the year 2000 for any browser (Internet Explorer 5.0 for Mac, as it turned out) to actually support CSS1 fully, and another 7-8 years for all the major browsers to just about fully support CSS2 (which made significant improvements to CSS1). But current versions of Internet Explorer, Firefox, Opera, Chrome, Safari and others just about fully support CSS2.

Among the beauties of CSS (there are many that I won’t go into here) is that it dramatically reduces the amount of style coding that has to be loaded with a page. With rare exceptions, the CSS code is placed on a separate file that is linked to the webpages in the site. So one file’s worth of coding can serve hundreds of pages. Then, if you decide to change your headlines from Blue to Green, you can change one line of code in the CSS file and it will change the headlines on every page to which it’s linked.

CSS2 also enables “stacking” so that you can create beautiful background images and textures and lay text on top of them—something that had been impossible in HTML. And, whatever effects you do, the source code that remains on individual web pages can be structured appropriately and get search engine spiders and screen readers quickly to the meaningful page content.

The not-so-beautiful thing about CSS is, basically, it’s a deceptively simple but fairly challenging language to learn. It consists of sets of rules that are simple in themselves, but in combination can be very complex and can lead to unexpected outcomes. Learning to lay out pages using CSS is not an easy undertaking, nor a quick one. So, it raises the bar for Do It Yourselfers a lot higher compared to learning HTML.

Widespread support of CSS for layout also introduces a wrinkle with respect to WYSISYG (what you see is what you get) tools (such as FrontPage/now Microsoft Expressions Web, Dreamweaver, Kompozer and others). They can deploy CSS but they do it in ways the ends up either generating extra code in order to “work” when the person misuses the CSS, or the pages don’t work and the person doesn’t know why. Tables were much easier to manipulate to get effects. They created bad code but they were pretty easy to understand.

The Next Wave

Currently the majority of legacy websites are table-laden, hack-heavy dinosaurs that need to be updated. Until recently browsers did not fully support CSS but now they do, so the time has come. Additonally, Google has recently added page-load-time to it’s algorithm which dictates where pages should rank in Search Engine Results Pages (SERPS). It’s only one of many factors that are weighed, but it’s one more reason to think about an update if your website isn’t CSS-based.

We’ve recently completed CSS redo’s of 2 longtime client sites. One site kept the same look visually. The other site kept the same content but had a new visual design. The difference in page sizes was striking. Both sites realized page size reductions of 60-75%! We also dispensed with hundreds of lines of coding. (Sites can be seen at http://www.industrialtimestudy.com and http://www.zaretandsonsviolins.com

So, if you have an older website and are thinking of updating, or if you’re commissioning a brand new site, make sure your layout is built using CSS!

Back to Top

Back to Resources Page

What are .jpegs, gifs and pngs?

Artwork that appears on web pages (photos, logos, any kinds of graphics) come from a number of original sources. But to be usable on a web page, images/graphics have to be saved in formats that will work on the web. The three most common web formats are:

• JPEG: named for the Joint Photographic Experts Group who created this standard;
• GIF: named for the Graphics Interchange Format;
• PNG: stands for Portable Network Graphics.

Professional photographers and web designers use software that saves graphics to these formats. These formats allow for “optimizing” which reduces the file sizes of the graphics while maintaining a high level of visual quality. (The smaller the file size, the faster it loads in the browser window.)

What is Source Code?

When you use a word processing program, you type words on a page and they flow into sentences, stack up in paragraphs and look pretty much like a typed document on a piece of paper.

You have the option, typically, of showing invisibles or hiding invisibles. Showing invisibles displays some of the formatting symbols that are being used to format your page (like paragraph returns). But otherwise, your page looks like a page with text and maybe some boxes with headers or footers or graphics, etc. However, behind the scenes your word processing program is generating programming code that actually makes your program work and lets you see your pages as functional documents.

When you open a web page in a browser, you have the ability to actually see the programming code that behind the scenes is making the page work. Look for the “VIEW” tab at the top of your browser window or monitor window and there will be an option in the drop down menu to “view source” or “view source code”. If you select this option, you’ll generate a separate browser page that will be filled with HTML (and Javascript and PHP when used) code. That source code page is the page search engines and screen readers actually “read”. They don’t see the page you see.

An effective combination of HTML for structuring the page content (think Outline: main header, sub header, sub-sub head, etc.), and CSS for layout (where does the logo go? how many columns? how wide are they? what size font for headlines? and way more), creates clean code.

Search engine bots like clean code and clean code helps improve your search engine rankings. Screen readers like clean code, or rather, visually impaired people who have to use screen readers like clean code because it cuts out extraneous junk being read to them.

This site was built in WP, using our custom theme.