We often come across css code in dire need of optimization (details have been changed to protect the guilty), and shows a misunderstanding about the power of css:

As you can see, several properties are repeated across elements.
These can (and should) be consolidated.

Let’s consolidate them first by applying very common properties to the body element:

Okay, now we see a lot of repetion is still happening here. Much of this repetition can be removed by using the comma (,) selector, which allows you to make lists of elements:

There is a pattern to the font-size, margin-height, and line-heights. We will now use this to our advantage to make life even easier.

With just a few basic css selectors, this code was cut in half.

The “cascading” in “Cascading Style Sheets” has several facets: computed values, inheritance, and specificity. Understanding how these cascades work is an integral part of your css ninja training.

Computed Values

Many of the values assigned have a unit. Some of these are relative (like em and <span>), and some are absolute (like px and in). Relative values are based on their parents: an element with a width of 50 uses the element’s parent to determine the actual width of the element.

Likewise, if both the parent and child elements’ font-sizes are 1.5em, the child’s actual font size will be larger than the parent’s.

Absolute values do not change based on their parent values. These are often obvious: color: red; for example. Pixel values are absolute, though the actual value displayed by the UA(User Agent) may differ (due to display or text-size settings).

Inheritance

Inheritance is the passing on of attributes from parents to children. It works in CSS like this: An element’s font color is set to red. The color for its child elements will also be red (if left unspecified or set to inherit).

Specificity

This is how CSS decides between competing styles. Take a look at the following code:

So what color do the elements end up with? To answer that question, we need to know how the competing selectors are chosen.

Each selector has a particular weight outlined in this table:

These weights are all added up and the “heaviest” selector set wins. So using the css above, here are the results:

Links

w3.org
wikipedia
htmlhelp

The problems with the new solution are many. The ones that concern me:

• After just a few versions, the browser will be hopelessly bloated and bogged down trying to maintain several versions with all of their features and bugs
• The point of the solution is to make browser bugs immortal. But will there be bugs in the bugs? Will the peekaboo bug or hasPosition act differently on the embedded IE6 from the original IE6? My head hurts just thinking about it.
• Like it or not, web design is a craft. The building industry doesn’t give special exceptions to architects who want to build a skyscraper out of wood just because they’ve always built birdhouses and wrap-around decks. Instead, they tell the architects to learn about steel and concrete and glass or find a new industry.

Those issues aside, maybe version targeting is not all bad (God help me, but I trust that Eric Meyer). But I agree with Ethan Marcotte that the solution is elsewhere; and by elsewhere i mean right here.

It’s not complicated. The flaming will die down. The Web will be saved. Our job – our craft will get a little easier and a little better.

The Solution

Microsoft should release stand-alone downloadable versions of Internet Explorer.

It should also give IE7-8-9-10 the ability to “nest” browsers in the parent browser window, just like Firefox already has. Sure, the <meta http-equiv="X-UA-Compatible" /> tag could still be used to automatically specify the IE version, and the user could be asked if they want to view the file in the pre-selected X-UA-Compatible version or in the current (IE8-9-10) version they have now. Then, if the version is not installed, they could choose to install it or go ahead and view it in some other installed version.

IE7 has a plugin architecture; IE8 should too. The only thing missing is the standalone IE releases (MultiIE already does it for XP, but it fails horribly in Vista).

I think this gives all of us the best of all worlds: Corporations who need a certain version of IE for their intranet will have it. Users who want cutting-edge compatibility and speed will have it. Developers who need a solution for future-broken sites under IE11 will have it. Standardistas who need those versions to browser-test for backward compatibility will have them.

Freezing all future versions is not the answer; we will be sorry. Let us pick-and-choose the fossilized browsers as we need them and we will all have what we want.

The use of px units, when viewed with IE6 or IE7, leads to fonts you can’t resize (unless you turn off some seriously buried preferences). Every other browser on every platform can enlarge or reduce fonts in any CSS unit, including px. It’s true that pt makes sense only for print stylesheets, but px is a “relative” unit, as I keep reminding people.

Joe Clark makes a good point about the nature of font resizing in ie vs all other browsers.  I, too, think it should be up to the consumer to use a browser (or accessibility software) that is compatible with their needs.

However, I still use relative font sizes in my web design projects.  It seems to me to be the most accessible method because of the ie limitations.

Whither do I turn? Do I embrace my capitalist side, saying caveat emptor, download Opera if you’ve got a problem with your eyes or do I continue listening to my communistic all-for-one accessibility side that says keep struggling late nights with relative font sizes?

I think the capitalist (and pragmatic) side is winning. Is that wrong?

squish squash

Smashing Magazine has a great comprehensive article on Microformats and their future.

Microformats are a cool technology: they allow metadata (such as vCard info: Name, Address, Postal Code, etc.) to be inserted directly into traditional markup using existing hooks like classes.

Don’t discount this kind of stuff, people. Its going to be native in Firefox 3, and if adoption rates are high, they could be everywhere.

Google’s massive databases come from its tiny minions “crawling” the web, traversing links and storing page views. They are called “spiders,” and for your site to get a good search rank from Google (and MSN, and Yahoo, etc… each of which has their own spiders), you need to know a little bit about what they are and how they work.

This is by no means a comprehensive explanation of spiders or seo methods. Volumes are being written about those topics. This is just a basic introduction to spiders and accessability on the web.

References

• Google’s official Googlebot FAQ


• Googlebot in Wikipedia


• How Google Works from GoogleGuide

Spiders

First of all, spiders are not people. They are programs run from Google’s servers that view your websites in a stripped-down, text-only virtual browser. Second, unlike your house, having your website crawling with spiders can be a very good thing.

Black Dog’s home page might look a little like this when viewed by a spider:

This is a screenshot of a text-only view of blackdogdev.com’s homepage. As you can see, the big photo of an adorable dog is gone; so is our nice-looking logo. All that remains is the most important part: the content. The text is the only thing the spiders care about.

Accessability

A spider can’t tell the difference between a photo of your dog and a photo of a fire engine, unless there is text available to give it meaning. Typically, this is achieved using an image’s alt attribute.

On blackdogdev.com, the alt text on the big dog photo is not very specific: “Loading Image…” doesn’t really mean anything. The logo, however, is better. Its alt text is “Black Dog Studios”. Much more relevant!

These alt attributes aren’t just for search engines. They are also used by screen-readers for the blind, who cannot see the screen at all but still take advantage of the wealth of knowledge on the net. For the images on your site to be meaningful to the blind or to spiders, they must have descriptive alt tags: “Portrait of Henry Flagler, January 2, 1830 – May 20, 1913” rather than “H_Flagler”. alt tags should never be left blank.

Remember: if you can’t navigate your site without graphics or flash, then spiders and the disabled can’t either. If you don’t like what you see when your site is stripped down to just text, a structural redesign may be in order.

Tools

See this blog entry in a text-only browser.

To see your site like Google does, you can use any of the available text-based browsers out there. A short list includes:

• Lynx, for UNIX and Linux, propably the most popular console-based borwser around
• Yellowpipe Lynx Viewer Firefox extension. This is what I used for the screenshot. Very handy.
• delorie.com’s online Lynx converter will turn any url into a Lynx-like text page.

For those of us who care about the semantic web, standards, or the W3C, The Web Standards Project needs to be in your feed reader. I’ll admit, it wasn’t in mine; until now that is.

The design of the site is awesome, and they eat their own cooking. (Plus, they use WordPress!) They employ css tricks I have seldom seen used before, and consistently use semantic tags (<abbr>, <q>).

The best trick of all: the sibling selector. Why? Because it allows for truly semantic output with the leanest markup possible. Before, I might have marked up a simple content block like this:

[html]

Title

This is an introduction sentance or paragraph. It is supposed to represent a blurb about the article below.

content

content

content

content

Footer. Date or links, or whatever.

This way, all of the elements have class hooks. CSS is applied using the classes and simple hierarchies:

[css]
div.content { }
div.content h1 { font-size: 1.8em; }
div.content div.block { border: 1px solid black; }
div.block p.intro { font-weight: bold; }
div.block img { float: right; }
div.block div.mainbody { clear: both; }
div.mainbody p { color: #006; }
p.footer { font-size: 0.7em; color: #888; }
[/css]

Class hooks are helpful, but not really needed if you use sibling selectors! You, too, can write super-styled code without the additional markup headache!

[html]

Title

This is an introduction sentance or paragraph. It is supposed to represent a blurb about the article below.

content

content

content

content

Footer. Date or links, or whatever.

See, that code is cleaner and easier to maintain. The CSS required to

[css]
div.content { }
div.content h1 { font-size: 1.8em; }
div.content p { color: #006; }
div.content h1+p { color: #000; font-weight: bold; clear: both;}
div.content h1+img { float: right; }
div.content img { float: left } /* Just for fun */
div.content p.footer { font-size: 0.7em; color: #888; }
[/css]

That’s all there is to it. Now, the line between content and design is darkened.

One thing: the class hook remains on the footer element. This is because adjacent-sibling selectors do not work in reverse. The selector applies only to the element after the +, and there is no selector that applies to a previous adjacent-sibling element.

Sources

For those of us who care about the semantic web, standards, or the W3C, The Web Standards Project needs to be in your feed reader. I’ll admt, it wasn’t in mine; until now that is.

The design of the site is awesome, and they eat their own cooking. (Plus, they use WordPress!) They employ css tricks I have seldom seen used before, and consistently use semantic tags (<abbr>, <q>).

The best trick of all: the sibling selector. Why? Because it allows for truly semantic output with the leanest markup possible. Before, I might have marked up a simple content block like this:

<div class="content"><br />

   <h1>Title</h1><br />

   <img src="url" alt="pic related to story">

   <div class="block"><br />

      <p class="intro">This is an introduction sentance or paragraph.  It is supposed to represent a blurb about the article below.</p><br />

      <div class="mainbody"><br />

         <p>content</p><br />

         <p>content</p><br />

         <p>content</p><br />

         <p>content</p><br />

      </div><br />

      <p class="footer">Footer.  Date or links, or whatever.</p><br />

   </div><br />

</div>

div.content { }

div.content h1 { font-size:1.8em; }

div.content div.block { border:1px solid black; }

div.block p.intro { font-weight: bold; }

div.block img { float:right; }

div.block div.mainbody { clear: both; }

div.mainbody p { color: #006; }

p.footer { font-size: 0.7em; color: #888; }

<div class="content" ><br />

   <h1>Title</h1><br />

   <img src="url" alt="That image again"/><br />

   <p>This is an introduction sentance or paragraph.  It is supposed to represent a blurb about the article below.</p><br />

   <p>content</p><br />

   <p>content</p><br />

   <p>content</p><br />

   <p>content</p><br />

   <p class="footer">Footer.  Date or links, or whatever.</p><br />

</div>

div.content { }

div.content h1 { font-size:1.8em; }

div.content p { color: #006; }

div.content h1+p { color: #000; font-weight: bold; clear:both;}

div.content h1+img { float:right; }

div.content img { float:left } /* Just for fun */

div.content p.footer { font-size: 0.7em; color: #888; }


	
That’s all there is to it.  Now, the line between content and design is darkened.
	
One thing: the class hook remains on the footer element.  This is because adjacent-sibling selectors do not work in reverse.  The selector applies only to the element after the +, and there is no selector that applies to a previous adjacent-sibling element.
	
Sources


Eric Myer wrote about them.

The W3C recommends them.

John Gallant and Holly Bergevin say IE7 supports them.