With the recent release of Firefox 3.5, we’re very pleased to announce the release of updates to our useful developer tools: Dust-Me Selectors, and CodeBurner for Firebug.

Dust-Me Selectors is a standalone extension that finds unused CSS selectors, and is particularly useful for updating legacy sites, allowing you to throw away all those redundant rules without worrying that something, somewhere might be using them.

CodeBurner for Firebug, as its name suggests, is an extension to the popular developer tool, Firebug, and extends it with searchable reference material for HTML and CSS.

We’ve been beavering away behind the scenes on updates to both these extensions, waiting for the final version of Firefox 3.5 — and now that it’s been released, here they are!

Dust-Me Selectors in particular benefits from this browser update — thanks to improvements in Firefox’s JavaScript engine, it now performs significantly faster, with a typical "find…" operation around 50% quicker than in Firefox 3.0!

But that’s not nearly all! Both new versions also bring a host of improvements and new features:

New features in Dust-Me Selectors Version 2.2:

• new tabbed preferences dialog that’s neater and more user-friendly
• added a new spidering preference "don’t spider external sites", which resricts the spider to pages on the same domain as the sitemap
• bugfixes to make "find…" and "spider…" keyboard triggers more reliable cross-platform
• improved error handling throughout
• removed two unecessary preferences to streamline the spidering logic: "ignore www difference" and "ignore fragment identifiers" in URLs, both of which are now enabled all the time

New features in CodeBurner for Firebug 1.2:

• improved search algorithm gives better results
• special search now includes "other attributes that are valid for this element" as well as those which are actually defined for it
• code examples for CSS properties now include direct links to live examples online
• the original search term is now indicated in search results
• slightly modified license clarifies the distinction between "use" and "redistribution"

Both of these updates have been uploaded to the Mozilla Add-ons site, however since all submissions are reviewed manually, it may be a day or so before they become available from there, or through the automatic updates channel. So if you can’t wait that long, you can grab them straight away from SitePoint:

• Dust-Me Selectors v2.2
• CodeBurner for Firebug v1.2

As always, we welcome your comments and feedback on both of these extensions — and if you’ve any ideas for features you’d like to see, please don’t hesitate to let us know!

Truthy and Falsy Values

The following values are always falsy:

• false
• 0 (zero)
• "" (empty string)
• null
• undefined
• NaN (a special Number value meaning Not-a-Number!)

All other values are truthy, including "0" (zero in quotes), "false" (false in quotes), empty functions, empty arrays, and empty objects.

var a = !!(0); // variable is set to false
var b = !!("0"); // true

Comparing Falsy Values

Falsy values follow some slightly odd comparison rules which can lead to errors in program logic.

The falsy values false, 0 (zero), and "" (empty string) are all equivalent and can be compared against each other:

var c = (false == 0); // true
var d = (false == ""); // true
var e = (0 == ""); // true

The falsy values null and undefined are not equivalent to anything except themselves:

var f = (null == false); // false
var g = (null == null); // true
var h = (undefined == undefined); // true
var i = (undefined == null); // true

Finally, the falsy value NaN is not equivalent to anything — including NaN!

var j = (NaN == null); // false
var k = (NaN == NaN); // false

You should also be aware that typeof(NaN) returns "number". Fortunately, the core JavaScript function isNaN() can be used to evaluate whether a value is NaN or not.

If in doubt…
Use strict equal (===) and strict not equal (!==) in situations where truthy or falsy values could lead to logic errors. These operators ensure that the objects are compared by type and by value.

var l = (false == 0); // true
var m = (false === 0); // false

Has truthy or falsy logic ever caused you grief in JavaScript code?

I for one find it quite counter-intuitive to specify descendants’ styles like this:

#banner { color: white; background: black; }
#banner a { color: yellow; }
#banner p { margin: 0; }
#banner ...
#banner ...
#banner ...

… and on, and on, and on. Instead, this makes way more sense to me:

#banner {
  color: white;
  background: black;
    a { color: yellow; }
    p { margin: 0em; }
    ...
}

And how about variables? They’d be cool:

@logo = #457301;

h3 { color: @logo; }
#sale { border: 1px solid @logo; }
.alert { background: @logo; }

Are you with me? Well, Less promises to make these daydreams and more a happy reality. You’d write a style sheet using the Less syntax, which is exceptionally easy to pick up — it’s just CSS with some added CSS-like extras. You then use the Less Ruby gem to convert it into regular CSS — run it on the command line, or incorporate it into an app.

Less permits you to use variables and nested selectors, as seen above, but also offers a way to include classes within classes, and some simple math operators. Sweet! Let’s put Less through its paces and see how it copes with a simpler style sheet.

Let’s say I’m making a style sheet for a reasonably common grid structure, like so:

Usually, I’d decide on a width for the entire page (let’s say 960 pixels — it’s a popular size) and construct various widths based on that, perhaps indeed using a grid system from a framework. I’d like the topmost boxes to occupy one third of the width of the container, the second set of boxes one quarter, and the footer boxes one sixth, so I’ll divide accordingly using my handy calculator. I have a particular favorite green, which I’d like to use as a heading color for some boxes, a border color for the secondary headings, and as a background for the footer. There’s an item that looks kind of like the footer, but with a different font. Oh, and I’d like to add some basic font specifications to each of the sections — the text should become smaller the further you go down. All groovy:

#container {
  width: 960px;
}
.box {
  float: left;
}
#main .box {
  width: 320px;
}
#main .box h3 {
  background: #450;
}
#secondary {
  font-size: 90%;
}
#secondary .box {
  width: 240px;
  border-bottom: 1px solid #450;
}
#footer {
  font-size: 80%;
}
#footer, #super {
  background: #450;
  color: #fff;
}
#footer .box {
  width: 160px;
}
#super {
  font-family: cursive;
}

All groovy, that is, until I decide I’d like to change the width of the container. Now I have to go back and edit the widths of container and each of the descendent boxes on main, secondary, and footer. Then, I decide I’d like to use purple instead of green, so I then have to change the color of the main boxes’ headings, the secondary boxes’ borders, and the footer boxes’ backgrounds. Annoying!

Let’s imagine that I used Less for this task instead. First, of course, I’ll need to install Less, which is a quick job on the command line:

sudo gem install less

Now I’ll open a new text file and start writing Less. I’ll specify a
base width in a variable, @base:

@base: 960px;

And my favorite color:

@pretty: #450;

I’ll then use the @base variable to specify the widths of the main, secondary, and footer boxes as a fraction of that overall width. To define each of the box children of each section, I’ll use nested selectors to define how I want the box children of each section to appear. The @pretty variable is used wherever I need to specify that color. Here is the rest of my Less file:

#container {
  width: @base;
}
.box {
  float: left;
}

#main {
  .box {
    width: @base / 3;
      h3 {
        color: @pretty;
      }
  }
}

#secondary {
  font-size: 90%;
  .box {
    width: @base / 4;
    border-bottom: 1px solid @pretty;
  }
}

#footer {
  font-size: 80%;
  background: @pretty;
  color: #fff;
  .box {
    width: @base / 6;
  }
}

Since super looks just like footer, but with a different font, I’ll use Less’s class inclusion technique (they call it a mixin) to tell it to include these declarations too:

#super {
  #footer;
  font-family: cursive;
}

I’ll cook up a CSS file using this simple statement on the command line:

lessc mystylesheet.less

Out pops a style sheet with much the same content as the one I made in the usual fashion above, with the exception of my footer and super declarations. Rather than being grouped, the common declarations are repeated:

#footer {
  font-size: 80%;
  background: #450;
  color: #fff;
}
#super {
  font-size: 80%;
  background: #450;
  color: #fff;
  font-family: cursive;
}

More on that small annoyance later.

Now, since Less created much the same style sheet, you might be wondering where I’m going with this. Well, here’s where we come to the part where it’s time to change my mind about the width and color, and this is where Less really comes into its own. This time, I only need to change two lines in my style sheet. First up, let’s adjust the value of the base variable, like this:

@base: 720px;

Now, let’s change the green to purple:

@pretty: #619;

Now, I can leave the rest of the declarations alone and generate a new CSS file. The boxes’ width recalculations and color replacements are done for me:

#container {
  width: 720px;
}
.box {
  float: left;
}
#main .box {
  width: 240px;
}
#main .box h3 {
  color: #619;
}
#secondary {
  font-size: 90%;
}
#secondary .box {
  border-bottom: 1px solid #619;
  width: 180px;
}
#footer {
  font-size: 80%;
  background: #619;
  color: #fff;
}
#footer .box {
  width: 120px;
}

#super {
  font-size: 80%;
  background: #619;
  color: #fff;
  font-family: cursive;
}

Of course, this is a very simple example. In the real world, a complex grid-based template could contain dozens of declarations based on a single figure; a color scheme could revolve around two or three basic shades. Using Less, we can treat these base definitions as true variables, and spend less time maintaining them.

Less’s inclusion method could be tidier if it was clever enough to group the common elements of the mixed-in declarations. On the other hand, I kind of like the way it comes out here — I like to organize my style sheet into sections according to purpose:

/* heading styles */
...
/* main content styles */
...
/* footer styles */
...

If there’s a style I like the look of in the heading area, and I want an item in my footer to resemble it, I’d prefer to avoid storing that footer item in my headings section. If you want to be clever and use grouped selectors, you’ll have to put both those styles somewhere. The convenience of the feature outweighs this small nuisance for me, and of course using mixins is absolutely optional.

I love it when clever folk come up with great ways to save time on CSS, and I can see I’ll be making good use of this nifty tool in future. You can check out Less at its web site.

In this article, we will implement event latency, i.e. the response to an event will occur a little time after it fired. This is often useful in situations such as creating drop-down menus. So let’s start with a little HTML and CSS code (it’s kept brief for the purpose of this example, hence no DOCTYPE)…

<html>
<head>
<title>Latency test</title>

<style type="text/css">
#element1
{
	width: 20em;
	margin: 20px;
	background-color: #dff;
	border: 2px solid #00d;
}

#para1
{
	text-align: center;
	padding: 10px;
	margin: 30px;
	background-color: #ccc;
	border: 1px solid #000;
}
</style>

</head>
<body>

<div id="element1">
	<p id="para1">Hover over me...</p>
</div>

</body>
</html>

This just produces a box similar to the following…

Now we’ll add a little JavaScript just before the closing body tag…

<script type="text/javascript">

window.onload = function() {

	// get nodes
	var element1 = document.getElementById("element1");
	var para1 = document.getElementById("para1");

	// define events
	if (element1 && para1) {
		element1.onmouseover = Handler;
		element1.onmouseout = Handler;
	}

	// event handler
	function Handler(e) {
		e = (e ? e : window.event);
		var on = (e.type == "mouseover");
		Highlight(on);
		return false;
	}

	// highlight or dim element (pass true|false)
	function Highlight(on) {
		para1.firstChild.nodeValue = (on ? "over" : "out");
		element1.style.backgroundColor = (on ? "#ffd" : "#dff");
		if (!on) alert("moved out");
	}

};

</script>

This adds a couple of (DOM0) events that fire when the cursor moves over or out of the light-blue element1 div. An event Handler function is called to sort out IE inconsistencies and discover whether a mouse over or out event was fired. The Highlight function is passed true (mouse over) or false (mouse out) and it changes the paragraph text and background color accordingly. Finally, if the mouse is moved out, an alert box is shown.

The script works, however, when we move the mouse into the grey paragraph box the “moved out” alert appears. This occurs because the browser fires two events - a mouseout for element1 and a mouseover for para1. Although we did not delegate an event handler for para1, browsers implement a technique known as bubbling and events will propagate through all element1’s descendants.

In this example, we only care if the last event fired was a mouseout that was not immediately followed by a mouseover. We can therefore fix the problem in our Handler() function with a little event latency:

	var timer;
	function Handler(e) {
		e = (e ? e : window.event);
		var on = (e.type == "mouseover");
		if (timer) clearTimeout(timer);
		timer = setTimeout( function() { Highlight(on); }, 300);
		return false;
	}

When an event occurs, we clear any existing timeout. A new timeout is then created which calls the Highlight function after 300 milliseconds (Highlight(on) is contained in a function so the value of ‘on’ is retained by the closure). This process makes it impossible for Highlight() to be executed any more frequently than every 300 milliseconds. When it is called, only the most recent value of ‘on’ is available.

Reload the page and you will notice that there is a short delay before any event animation occurs. In addition, the alert will only appear when you move outside of the blue #element1 box.

I hope you find the technique useful in other JavaScript projects.

With Opera Unite, developers will create applications — or Opera Unite Services — which run in the end-user’s browser, connect directly to other computers, and share data. Sample scenarios outlined by Eng include media sharing, instant communication, and anything in a “class of social software on the web.” The end goal suggested in Eng’s announcement includes restoring power to end-users to communicate with each other, using their own infrastructure (personal computers, residential internet connections etc.).

In an article on Dev.Opera, Chris Mills explains how to get up and running with the latest Opera Unite build. Mills offers a fairly concise description for Opera Unite — “a collaborative technology that uses a compact server inside [Opera] to share data and services.”

As Google, Yahoo! and Microsoft seek to create centralized platforms and capture mindshare, Opera Unite aims to steer the web away from a centrally-managed architecture run by “computers with more power than the rest” (servers). Opera believes that a new set of opportunities exists where servers are not required and applications can communicate directly with peer systems. Should Opera succeed, this would strike at the heart of user-driven content sites, many of which rely on users sharing media with a select group of friends for traffic. Interestingly, Opera Unite seems to make no attempt to challenge fundamentally centralised systems, such as search engines, nor does it attempt to replace online communities that thrive on sharing content to a general audience (YouTube, anyone?).

A quick run through of Opera Unite is promising — a wizard in the Opera 10 beta (available under the Tools menu) takes the user through the process of creating an account, and helpfully offers to attempt to configure UPnP (no port forwarding instructions in sight — the system is clearly optimized for as little configuration as possible). Once set up, the Opera Unite sidebar appears, and a list of default services is available.

Enabling the file sharing application, for example, adds a File Sharing entry to a list of available services on a public URL (generally http://(computer name).(Opera username).operaunite.com). This public URL represents a landing page of sorts for the user, and Opera suggests this is served from the end-user’s machine, although the hostname of the public URL resolves to an Opera server. Additionally, while any browser can be used to browse available content, it appears that Opera Unite is required to actually access content, e.g. download shared files.

The initial release feels extremely stable, although Opera emphasizes that the Unite technology is still in alpha, and there will undoubtedly be challenges with complex networking environments (NAT, no UPnP etc.) for which the technology is yet to be battle-tested. Builds are available for Windows, Linux and Mac OS X.

Download Opera Unite and let us know what you think.

One prominent voice in this arena is Nicole Sullivan, who has developed a methodology called Object Oriented CSS (OOCSS). She outlined this approach to writing CSS at Web Directions North 2009, and the 48-minute video is available.

Sullivan is a talented and engaging presenter, but I found the video a lot to take in all at once. Since watching it, I have applied the principles of OOCSS to an internal project here at SitePoint, and I feel like I have a better grasp on what it’s all about.

A Change of Perspective

Just another framework? Think bigger: “OOCSS isn’t really a framework … but a way of writing scalable, sane, maintainable CSS,” writes Sullivan. Sullivan uses and recommends a grid framework like Yahoo!’s YUI Grids, but you’re free to write your layout styles from scratch using OOCSS principles if that’s your thing. But OOCSS applies equally to the work you do after you have implemented your site’s layout, as you design the blocks and content that slot into your layout.

Most web designers tend to write CSS code so that it requires as little extra markup (whether <div> or <span> tags or class attributes) as possible. Fundamentally, adopting OOCSS is making a mental shift towards easy maintenance and reuse of your styles, even if it means writing extra HTML markup.

OOCSS methodologies help you to look beyond your immediate design goals and organize your code so that adding new site content that reuses the same styles in the future becomes trivial. With OOCSS, adding a new type of page to your site should mean that there’s no need to create additional CSS styles or selectors. New page types should be able to reuse existing CSS styles as much as possible.

When designing a site with OOCSS, you must break your design into reusable components, which OOCSS calls objects. Each component is a fixed HTML structure, to which you apply a set of CSS rules that control its layout (in OOCSS parlance, the structure), and another set of CSS rules that control its appearance (the skin). That component can then contain arbitrary HTML content: paragraphs, lists, tables, and so on, all of which is styled independently of the container in which it appears.

This last point is crucial. Under OOCSS you must avoid what Sullivan calls “location-based selectors” — that is, styles that affect content differently, depending on the part of your site in which it appears. If you want, say, a list to look different in a particular part of your site, you should add a class attribute to it and apply the styles based on that attribute. This ensures that the list can be lifted out and reused elsewhere on the site, with its style remaining intact.

An Example in Code

Let’s say every page of your site had a sidebar, the code for which looked like this:

<div class="sidebar">
  …sidebar content…
</div>

Now, let’s say you had a set of pages where you wanted this sidebar styled a little differently — say with a different background color to highlight a sale on certain products. You would probably also want to make changes to some other elements of those pages because of this sale, too.

Traditionally, your approach to this might be to add a class to your page’s <body> tag:

<body class="onsale">

“Brilliant!”, you would think. “Now I can make all my style adjustments for this sale without making any further changes to my HTML code!” Then you would set about writing a bunch of style rules like this one:

body.onsale .sidebar {
  background-color: #FFA500;
}

The approach recommended by Object Oriented CSS is quite different. Instead of a single class applied to the body of your page, you would create a new class for each type of element that you wanted to change for the sale. Here’s what the sale style for the sidebar might look like:

.onsalesidebar {
  /* extends .sidebar */
  background-color: #FFA500;
}

This class is said to extend the existing class that describes the standard style for the element. You then apply it in addition to the existing (base) class:

<div class="sidebar onsalesidebar">
  …sidebar content…
</div>

Now, a content editor can confidently copy and paste this sidebar code into another page of your site, or even a brand new page, and know that it will be displayed with the same styles applied. The same principles apply to the styling of the content within this sidebar.

The guidelines for OOCSS actually recommend a considerably more complex HTML structure for reusable components like this, which enable more intricate styles to be applied to them — including rounded corners and border effects — but this simple example effectively demonstrates the fundamental principles behind OOCSS.

What’s the Point?

Sullivan works at Yahoo, where her primary focus is on improving web site performance. Aside from the copy-and-paste reusability of styled HTML content and component blocks, OOCSS claims to offer significant benefits in performance.

By prioritizing the reuse of CSS styles across your site, OOCSS results in considerably smaller CSS files, but slightly larger HTML files. This trade-off is desirable because the size of your CSS files directly influences the amount of time that the browser displays a blank page while your site loads. Smaller CSS means less time spent looking at a blank page. Once your CSS has loaded, your site’s HTML content is displayed progressively as it loads. The result of this trade-off, then, is greater perceived performance, even if the total load time is slightly longer.

Furthermore, by avoiding location-based selectors, you reduce the amount of work that the browser has to do to determine the actual appearance of any given element on the page. Especially on mobile browsers, but even on the desktop, this can produce significant performance gains.

Is It Worth It?

If you’re lucky enough to be the only front-end developer working on a project, you might like to take the OOCSS principles for a spin. Where the reusability benefits of OOCSS really shine, however, is when working in a team environment.

Senior front-end designers can define the reusable structures for the site. Visual designers can apply attractive CSS skins to those structures. Content editors can write the content that slots into those structures with confidence, knowing that only the styles they expect will be applied to the content they write.

Coaxing an entire team to jump aboard the OOCSS bandwagon can be a significant undertaking, however, and that’s the point I’m at here at SitePoint. Having applied OOCSS principles to a little project on my own, I now have to decide if it’s worth bringing this to the SitePoint design team.

What do you think? Are the benefits of OOCSS worth the extra discipline required to adopt it, or is CSS complicated enough already?

The solution might please some site owners and publishers. Unfortunately, there are several reasons why blocking the blockers is futile, self-defeating, and could lead to less advert revenue.

1. You won’t stop every ad blocker
The code provided will work for some ad blockers some of the time, but it certainly will not stop every one. No single technique will ever be suitable in all situations. Will the cost and effort required to implement multiple solutions ever be recouped?

2. Accessibility problems
Your page will fail for anyone who has JavaScript disabled. It may also fail for those using alternative devices such as screen readers. That might be acceptable to you — those users are not viewing your adverts either. However, it is also likely to affect a proportion of your regular visitors. Be prepared for complaints and additional support costs.

3. It’s easy to beat
Anyone with modest technical skills can prevent your block. The majority of Adblock users are technically literate: all are Firefox users who install browser add-ons, many will understand how the blocker works, and some will edit their own regular expressions.

Your content can be revealed by changing the Adblock rules, viewing the source code, disabling CSS, using an alternative stylesheet, or modifying the code using Firebug or the Web Developer Toolbar.

4. Your revenue may not be affected…
They majority of advert revenue is raised when a visitor clicks an advert. AdBlock users are far less likely to click adverts even if they are forced to view them. Will blocking the blockers really increase your advertising revenue?

5. …or it could go down
Blocking your premium content simply makes it unavailable to a proportion of users. Will that concern them or will they go elsewhere? These visitors are your customers: making it difficult for them could harm your business.

We have already established that visitors using ad blockers are likely to be technically literate. These are the very people who might have blogs, use online bookmarking, or participate in social networking. Will they link to your content if you’re making it more difficult to view? How would that affect your link building and viral marketing effort?

The web is not the same as print and you cannot force a user to view a page the way you intended. Anyone can block adverts, images, CSS, JavaScript, Java, Flash, ActiveX, or modify any aspect of your page to their own personal preference.

If you write articles to make money and are convinced advert blockers affect your revenue, there is a simple solution: start charging for content. Why publish content under the pretense that it’s free/sponsored, then complain about a proportion of users who fail to click ads? What is really at fault — the ad blockers or the business model?

Ultimately, I suspect advert blockers have a negligible monetary effect on the majority of web sites. If revenue is down, perhaps there are more obvious problems to address first?

See also:

• How to Block the Advert Blockers
• Why File Naming is More Important Than You Think

Do you use an advert blocker? Are they the scourge of the internet? Are you convinced they have a negative effect on your advertising revenues?

Detecting for the presence of advert blockers is not possible. Different implementation technologies are used and they are not necessarily embedded in the browser. Ad blockers also work in different ways: some use a long list of advertiser domains whilst others use regular expressions to suppress matching URLs.

Regular expression matching is used by one of the most popular blockers, Firefox’s Adblock Plus add-on. However, we can exploit URL checking using a technique that prevents Adblock users viewing your content unless they disable the add-on.

Your HTML page should follow this example:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html lang="en">
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<title>Advert Blocker blocking</title>
<meta http-equiv="content-language" content="en"><meta name="language" content="en">

<style type="text/css">
#content { display: none; }

#blockermessage
{
	font-weight: bold;
	text-align: center;
	padding: 4px;
	color: #fff;
	background-color: #c00;
}
</style>

<script type="text/javascript" src="/banner-advert.js"></script>

</head>
<body>

	<div id="content">
		<h1>Main content</h1>
		<p>This will be hidden to people using advert blockers.</p>
	</div>

	<div id="blockermessage">
		<p>Please switch of your advert blocker and enable JavaScript to view this page.</p>
	</div>

</body>
</html>

Explanation:

• The main content should be contained within an outer element, such as <div id="content">.
• You should provide an alternative message for people using an advert blocker, as shown in <div id="blockermessage">.
• It is important that the first two CSS rules on the page style these elements. Since external CSS file can be blocked, I would recommend embedding it directly in the HTML. The #content rule must be set to display: none, whilst the #blockermessage rule can be styled big, bold or in any way you choose.
• Finally, an external JavaScript file is included. This should be given a file/folder name that will trigger ad-blocking rules, e.g. banner-advert.js.

The code for banner-advert.js:

// reveal content to those not using an advert blocker
if (document.styleSheets && document.styleSheets.length > 0) {
	var ss = document.styleSheets[0];
	var bRule = (ss.cssRules ? ss.cssRules : ss.rules);
	if (bRule.length > 1) {
		bRule[0].style.display = "block";
		bRule[1].style.display = "none";
	}
}

It works in the following way:

1. As the page is loaded, the main content is switched off for everyone and only the #blockermessage is shown.
2. For most people, the banner-advert.js code is executed immediately. This alters the embedded styles so #content becomes visible and #blockermessage is hidden. It occurs before the main content is displayed so users should not see any difference.
3. AdBlock will spot banner-advert.js and refuse to load it. The styles are not modified so the main content remains hidden.

That should please many premium content site owners. But — hold back — I strongly recommend you do not implement this on your web site! There are a number of technical issues and blocking the blockers is futile … see Why Blocking Ad Blockers Will Fail.

See also: Why File Naming is More Important Than You Think.

position: relative allows an element to be shifted from its original position either horizontally (using left or right) or vertically (using top or bottom).

position: absolute allows an element to be positioned with respect to a containing block using left, right, top or bottom (the containing block is the nearest ancestor node with a position of relative, absolute or fixed).

Positioning nodes is therefore straightforward, e.g.

HTML:

<div id="outer">
	<div id="inner"></div>
</div>

CSS:

#outer
{
	position: relative;
	width: 200px;
	height: 200px;
	margin: 20px auto;
	border: 2px solid #c00;
}

#inner
{
	position: absolute;
	left: 50px;
	top: 50px;
	width: 96px;
	height: 96px;
	background-color: #ddc;
	border: 2px solid #00c;
}

(The actual width and height of the inner block will be 100px owing to the addition of the border).

The following boxes are rendered in every modern browser (including IE6):

Less well known is that you can apply all the left, right, top and bottom properties at the same time. The following CSS will render the inner element identically:

#inner
{
	position: absolute;
	left: 50px;
	right: 50px;
	top: 50px;
	bottom: 50px;
	background-color: #ddc;
	border: 2px solid #00c;
}

The width and height of the inner box will remain 100px, but we do not need to need to explicitly set the dimensions.

This could be useful when:

• the spacing around the element is more critical than the width or height. You can also use negative left, right, top and/or bottom properties to make the inner box larger than its outer parent.
• you have multiple inner elements with differing borders and padding but need consistent outer spacing. This method allows you to create a single style for all those elements.

JavaScript animations can also benefit since it can be easier and quicker to resize an element if you do not need to calculate the resulting width and height, e.g.

// expands and contracts the inner box
window.onload = function() {

	var inner = document.getElementById("inner");
	var offset = 100, dir = -1;
	setInterval(function() {
		inner.style.left = inner.style.right = inner.style.top = inner.style.bottom = offset+"px";
		offset += dir;
		if (offset == 0 || offset == 100) dir = -dir;
	}, 10);
	
}

A note about browser compatibility: this technique works in all the main browsers, except IE6 which only understands explicit widths and heights. There’s a surprise!

Inline styles are those defined in the HTML itself, e.g.

<p>This is an 
<strong style="color: red;">inline style that should be blue</strong>
.</p>

Inline styles have the highest priority of all CSS. In general, I would recommend you avoid using them and place your CSS declarations in external files. However, you may not have that luxury if you are working on a legacy system or do not have direct access to the HTML code.

Fortunately, there is a way to override inline styles from an external stylesheet:

strong[style] { color: blue !important; }

This will force the text in the strong tag to become blue in the example above. The method appears to work in all major browser, including:

• Internet Explorer 8.0
• Mozilla Firefox 2 and 3
• Opera 9
• Apple Safari, and
• Google Chrome

Internet Explorer 6 and 7 are the notable exceptions. However, this technique is not something you should use on a day-to-day basis. Keep your CSS clean and only override inline styles when there is absolutely no alternative.