Clickjacking does not rely on bugs in any software. Instead, the technique is simply an abuse of the growing graphical capabilities that advanced web standards like CSS provide to web browsers. A good introduction to clickjacking is provided by Steve Gibson and Leo Laporte on their Security Now! podcast.

As far as I’m aware, only Firefox when combined with the NoScript add-on and Internet Explorer when combined with the GuardedID product provide any measure of protection against clickjacking attacks. To date no other browser can detect, alert, or otherwise help you to avoid or mitigate the risks of clickjacking attacks.

That said, there’s gotta be something users of other browsers can do. Well, it may not be as much as what NoScript can do, but there is something: use a user style sheet to help expose common clickjacking attack attempts.

clickjane.css helps detect clickjacking attacks for all browsers

Until browser manufacturers provide built-in protections against clickjacking attacks in their software (which is arguably the best place for such logic in the first place), I’ve started putting together a user style sheet I’m calling clickjane.css that attempts to instantly reveal common clickjacking attempts. Since it’s a CSS user style sheet, this approach should be cross-browser compatible so that users of any browser including Safari, Opera, and other browsers that don’t have other means of protecting against clickjacking attacks can use it.

I’ve only recently learned about this class of exploits and so I’m not supremely well-informed on the topic. As a result, the clickjane.css file is relatively sparse and currently only reveals what I’m sure is a small set of clickjacking attmpts. However, as I research the topic further and learn more about the actual underlying HTML and CSS that clickjacking uses, I’ll be updating the clickjane.css code to reveal those attempts as well.

Naturally, contributions and assistance in any form are most welcome! Learn more about clickjane.css as well as how to use it at the Clickjane CSS Github wiki.

Before and after clickjane.css

Here are two example screenshots of a benign clickjacking demo.

1. Before:
   

   Screenshot of Safari before clickjane.css is used to expose clickjacking attempts.

2. After:
   

   Screenshot of Safari after clickjane.css is used to expose clickjacking attempts.

Good habits you should get into to mitigate clickjacking risks

Here is a list of behaviors that you should make habitual while you browse the web. Engaging in these behaviors can dramatically reduce the likelihood that you will be victimized by a clickjacking attack.

• Explicitly log out of any service you have logged in to when you are done. That log-out button is there for a reason: use it!
• Avoid providing your browser with “Auto-Complete” information for critical sites, such as your bank.
• Make sure you are running Flash Player 10 or greater, which mitigates this vulnerability for Adobe Flash content.

More resources to learn about clickjacking

• Hackademix.net – More clickjacking links to the OWASP presentation, the white paper, and a blog post showing several CSS-based exploits.

Translations of this article:

• Belorussian (thanks, Bohdan Zograf)
• Ukrainian (thanks, Alyona Lompar)

Here’s the summary of my argument.

Adding many “programmatic” features to the CSS language such as variables, macros, or flow control is a mistake. However, CSS‘s failure to simply encode visual relationships (instead of merely typographic properties)—a severe deficiency in the core language itself—requires the addition of delegation features. With the additional capability to reference an arbitrary element’s computed value regardless of its hierarchical context, CSS will be more accessible to both amateur and professional web designers, more capable, and will more forcefully promote the semantic Web and its ideals.

In this corner: CSS variables are harmful

Bert does a great job of summarizing the conclusion of his argument himself. In his essay, Bert says:

Adding any form of macros or additional scopes and indirections, including symbolic constants, is not just redundant, but changes CSS in ways that make it unsuitable for its intended audience. Given that there is currently no alternative to CSS, these things must not be added.

As we all know, one of the wonderful things about CSS is that the core language itself is remarkably simple. (What’s not simple is the spectacular way browser manufacturers have destroyed everyone’s hope that implementing CSS-based designs in the real world will ever be easy, but that’s a whole different can of worms.) Fundamentally, CSS‘s syntax can be explained with a mere three major components: property/value pairs, declaration blocks, and rule sets.

What this means is that CSS as a language is stupidly easy to learn. I think everyone would agree that it’s certainly easier to learn than, say, JavaScript or XSL. Now, that’s important because, without putting too fine a point on it, Bert mentions multiple times that CSS‘s “intended audience” are the diverse and likely relatively technically ignorant content authors that are responsible for the overwhelming majority of web pages on the public Internet today.

He makes the very good point that The value of the semantic Web isn’t defined by how well structured the best documents are, but by how well structured the vast majority of documents are. In other words, CSS needs to remain instantly useable and reusable to these untrained, amateur web content publishers for the benefits of self-describing documents (i.e., the semantic Web) to see mass adoption.

To wit:

reusing other people’s style sheets is more difficult if those style sheets contain user-defined names. Class names are an example. Their names may suggest why the author created them (assuming they are in a language you understand), but typically you will have to look at the document to see where they occur and why. Symbolic constants make that problem worse.

And, later:

For many people, style sheets with constants will thus simply not be usable. It is too difficult to look in two places at once, the place where a value is used and the place where it is defined, if you don’t know why the rule is split in this way. Many people are confused by indirection anyway and adding an extra one, in addition to the element and class names, has the same effect as obfuscating the style sheet.

Whether or not you believe Bert Bos is underestimating the average web designer, it’s pretty clear that these are really good points. Nobody wants CSS to be obfuscated, hard to learn, or hard to reuse. That’d just be crazy talk.

In the other corner: CSS variables are a real-world requirement

The more features you add to an application, a programming language, or indeed any software, the more difficult it becomes to grok it. As the Python people would say, the larger a language gets the more difficult it is to hold all of it in your head. Nevertheless, adding “features” is sometimes the only way to add capabilities, and I don’t think anyone in their right mind would argue that, once written, software should never change. (That’d just be crazy talk, too.)

In his opposing arguments, Matt Wilcox recognizes this when he says, Yes, the syntax should be simple, but the capabilities of CSS should not. What he’s alluding to without verbalizing it is the balance between adding necessary capabilities without unnecessarily growing the “size of the language.”

However, Matt says that modern web design methodologies (e.g., separation of concerns between structure, presentation, and behavior) dictate that CSS needs more capabilities than it currently has:

CSS lacks capabilities to allow truly flexible design, requiring layer upon layer of ‘tricks’ to accomplish certain objectives, requiring content to be structured ‘just so’ to achieve a display objective, or in the case of some designs proving instead to be completely incapable.

[…]

CSS’s positioning is a cludge. It’s a cludge because you can only position relative to the last positioned parent container. Well, that limitation in itself dictates that all positioning relies upon how the content is structured. And that means the presentation and the content are not truly separable.

To align CSS‘s capabilities with the requirements of real-world web design objectives, he says, CSS needs to be capable of describing relationships between semantically and structurally arbitrary but visually related elements.

Visual design is fundamentally about relationships between elements. For all of the artistic flourishes and creativity, it’s about relationships. ‘That yellow’ only grabs your attention because of its contrasting relationship with ‘that blue’. ‘This heading’ only works as a heading because of it’s exaggerated relationship to the size of the body text. […] CSS has no clue about relationships, period. And that’s why CSS as it stands right now, is not good enough. That’s why CSS without variables (true variables), without basic logic, without maths, can never be as flexible as we need it to be.

This is what web designers have been complaining about for (what feels like hundreds of) years. The fact that CSS has no capability to describe presentational relationships between elements in addition to directly describing an individual element’s presentational properties is a gaping hole that sorely degrades its ability to be a media-agnostic styling language. Every single web designer I’ve worked with has gasped at this omission, and though at first I didn’t understand why, the more I understood the principles behind graphic design the more I came to realize how fundamentally problematic this omission really is.

Adding delegation makes CSS easier for designers

As Matt eloquently stated, design is all about relationships. Good web designers create designs by constructing visual elements that have strong, often exacting relationships with other visual elements. There are many names and examples for this: visual language, visual hierarchy, the golden ratio, the grid, visual balance, the typographer’s scale, and so on.

What happens when the designer tries to define a relationship between elements? “How do I say that the whitespace between element A and element B should always be the same? How do I define element A’s height as half of element B’s?” These definitions, which are natural and necessary to the way designers work in both their mind and their mediums, are impossible to encode in CSS.

The closest you can get is declaring the same values to each element’s properties, not describing the relationship itself. This suffices only so long as these values are known ahead of time and are the same as one another, which severely limits the design possibilities we are capable of (without resorting to what Matt calls “tricks”). That’s why achieving simple visual effects are actually very complex and so, sadly, that’s where you’ll find the majority of indirection and obfuscation in CSS today. (I’m looking at you, faux columns.)

So who wins?

Both Bert Bos and Matt Wilcox have made some great points. Bert rightfully wishes to keep CSS lean and simple, even at the expense of some arguably beneficial styling power. Matt, on the other hand, argues that our needs as web designers have evolved faster than the technology to the point where CSS is too limited, fundamentally so.

The truth is, they’re both right. And they’re both wrong. Or rather, they are each taking a position that is too extreme. Bert’s absolutely correct when says that many of these proposed extensions are redundant and harmful, and yet Matt’s also correct that CSS lacks some fundamental capabilities that designers expect to be present.

Bert says that the CSS capabilities everyone’s asking for can be implemented using techniques that don’t rely on CSS whatsoever. These techniques, he says, make things like true CSS variables “redundant.”

There are examples of CSS with constants to satisfy all styles of programming, e.g.: David Walsh (in PHP), Tedd Sperling (in PHP), Digital Web Magazine (in PHP), Eco Consulting (in SSI), and Christian Heilmann (SSI and PHP).

Quite simply, he’s correct in stating that programmatic features need not be added to CSS proper to achieve desired results, but he’s incorrect in his apparent thinking that designers will be able to use these other tools to leverage CSS. Take, for instance, the probably more familiar (though not linked above) notion of using JavaScript to manipulate CSS values.

var x = document.getElementById('SideBar'); // get #SideBar element
var y = document.getElementById('MainColumn'); // get #MainColumn
var z = document.defaultView.getComputedStyle(y, '').getPropertyValue('height'); // get computed height of #MainColumn
x.style.height = ( parseInt(z) / 2 ) + 'px'; // set #SideBar's height 1/2 of #MainColumn's

This is an example of programmatic code that uses variables and expressions. It sets the element with the ID of SideBar to half the pixel height of the element with the ID of MainColumn. It does this by obtaining the MainColumn‘s height (at the time this code runs) and saving it in a variable, then performs some trivial math to half the value and use the result as the pixel height of the SideBar.

Doing this is currently impossible with CSS alone, yet it’s something that clearly belongs with whatever other “presentational” code exists and not in “programmatic” scripts that would otherwise be charged with defining “functionality.” As Matt states, using JavaScript to “script” solutions to CSS‘s shortcomings like this is not an acceptable answer.

CSS doesn’t have [basic logic or maths]. Nor is it the job of JavaScript to make up for this lack of abilities. JavaScript is about interaction behaviour, and what we are talking about here is pure display logic. Not interaction logic.

Moreover, the place designers expect to put code like this is, of course, into a CSS style sheet. The way designers expect to put code like this into CSS is by adding delegation features. Requiring designers to learn JavaScript (or any other programming language) to encode such design relationships is nothing short of ridiculous. In what world is that easier for untrained laymen to understand than CSS?

Adding delegation to CSS is worth the effort

One of Bert’s arguments against such additions to CSS is that implementations would become harder to create, and that we’ll (almost certainly) see more bugs.

extending CSS makes implementing more difficult and programs bigger, which leads to fewer implementations and more bugs. That has to be balanced against the usefulness of the extension.

Although I do agree with his statement that an extension’s usefulness has to be balanced against its potential costs, I think something so fundamental to design methodology as delegation greatly overcompensates for the cost of such implementation efforts. Moreover, if I understand Bert correctly and as he also discusses, the majority of implementations that would need to implement such delegation already have relatively complex internal structures to make the implementation effort somewhat easier:

There is no scoping [in proposals that only define global constants]. That means that an implementation needs a symbol table, but no stack. A stack would require a little bit more memory, but mostly it would make implementations more complex. (Although every programmer has, one hopes, learnt to program a symbol table with lexical scope during his training.) Constants in CSS are thus easier than, e.g., XML Namespaces, which are lexically scoped.

It is different for those CSS implementations that provide a CSS Object Model (an API for manipulating a style sheet in memory). Those implementations do need to keep track of scope in some way, because adding or removing a line of the style sheet can make a previously redundant definition become meaningful.

In order to use JavaScript to solve many of the shortcomings of CSS, as huge numbers of professional web developers do routinely, we use the very CSS Object Model whose prior implementation already exists for us to build upon.

CSS delegation doesn’t grow the size of the language

For the sake of argument, let’s simplify our requirement somewhat so that our somewhat contrived example of design intent is to create a relationship between the MainColumn and the SideBar elements such that they are of equal height. This is more informally known as “making columns.”

Here’s what a natural, hypothetical snippet of CSS would look like if the language supported delegation features such that it could encode visual relationships.

#SideBar { height: #MainColumn; }

This code theoretically says almost the exact same thing as the JavaScript shown earlier (save for the division, of course); it takes the computed value of the MainColumn element’s height property and applies that value to the SideBar element’s height property. In other words, “The SideBar’s (element B’s) height is always the same as the MainColumn’s (element A’s).” (Of course, this is a parse error in reality today.)

This extremely trivial example has some remarkably far-reaching implications, and yet there is really nothing radical about its syntax. Making this a reality significantly expands the capabilities of CSS without dramatically increasing the size of the language. This capability would not only beat the pants off “CSS tables,” it also potentially obsoletes the arguably misguided efforts of the CSS3 Advanced Layout and Grid Positioning modules, too.

We’ve long since abandoned table layouts because they force us to use presentational markup. That’s still what “CSS tables” force us to do, too. In other words, with display: table, the SideBar needs to be a child of the MainColumn element or, maybe worse and more likely, a child of a semantically meaningless wrapper element.

CSS positioning was introduced with the promise of freeing us from source-order-dependent styling, without which there is no hope of efficiently abstracting presentation away from structure. Moreover, abstracting presentation away from structure is the single most important prerequisite needed to improve document reusability and strengthen the semantic Web. Absolute positioning works, but limitations elsewhere in CSS mean its use is problematic for many designs, so in practice it doesn’t gain widespread adoption.

Here’s a theoretical solution to a two-column and a footer layout using CSS delegation with this semantic HTML:

<body>
    <div id="MainColumn">I'm the main column.</div>
    <div id="SideBar">I'm the right-hand sidebar.</div>
    <div id="Legalese">No one will read me.</div>
</body>

The CSS would look extremely familiar, possibly like this:

#MainColumn { margin: 0 25% 1em 0; float: left; }
#SideBar { width: 25%; min-height: #MainColumn; }

Using the same HTML, the same solution using the CSS3 Advanced Layout module would look something more like this, although to be frank I’m not certain I fully understand this syntax even after staring at it for months:

body {
    display: "a  b"
             ".  ." /1em
             "c  c"
             75% 25%
}
#MainColumn { position: a; }
#SideBar { position: b; }
#Legalese { position: c; }

Not only does there seem to me to be far more indirection in this method than there would be using CSS delegation, there is also an enormous increase to the size of the CSS language: a new (ASCII-art?!) value to the display property whose syntax is clunky at best. A similar story can be said of the CSS3 Grid Positioning module, which does lots more than just add a new (already complex) gr CSS unit.

The upshot is that the Advanced Layout and the Grid Positioning modules are doing some of the right things in many of the wrong ways. Both those modules add unnecessary complexity to CSS without giving designers a natural way to say what they mean. They do more to introduce obfuscation and indirection than simple delegation would, and they aren’t as broadly capable. Both of them try to solve a specific problem instead of dealing with fundamental deficiencies in the toolset designer’s have to work with.

Designers want relationships via delegation, not variables

Adding delegation such as that I’ve just shown is a natural, necessary addition to CSS because it is how designers create visual components—such as grids—in their designs. Variables (and constants, and macros, etc.), which simply reuse and modify pre-defined statements aren’t what designers care about. Adding them will bloat CSS without adding useful functionality.

“Okay,” you may be saying to yourself, “but delegation is itself a kind of variable, isn’t it?” Technically yes, however adding delegation resolves the core deficiency in the CSS language that designers need to use every day. Yes, it’s technically a form of variable, but that’s not how designers think of it. To say that one element’s visual properties is like another makes a variable only by creating a logical and visually appropriate mapping from the first element’s property to the second independent of markup, thereby avoiding indirection in the form of a variable name or other unfamiliar symbol.

Delegation like this doesn’t require the addition of anything other than what already exists in CSS. Class names and ID values are identifiers whose indirection people already have to deal with. Using them for delegation (to reference another element’s style) doesn’t increase the cognitive load any more than using them to reference HTML elements does. Though untested, the cognitive load might actually be even less since the CSS delegation’s references could be in the same (style sheet) file.

Moreover, delegation will increase the likelihood of document reusability by enabling style sheets to be more self-describing, more self-referential, in a similar way as good markup is. It satisfies a very fundamental need that designers have to define graphical relationships between elements. At the same time, it does so in a way that is natural to both their way of thinking and beneficial to the separation of concerns principle on which the “web stack” (the trifecta of HTML, CSS, and JavaScript) is based.

designing for the web is a lot less about making something dazzle and a lot more about making it work. The design decisions that matter pertain directly to the constraints of the materials. What form elements to use. What font sizes. What composition. What flow. Those decisions are poorly made at an arm’s length.

I’ve worked with many web designers in the past who only did abstractions and then handed over pictures to be chopped and implemented by “HTML monkeys”. It never really gelled well. The things that got strong attention were all the things that Photoshop did well. Imagery, curvy lines, and the frame. All the around stuff, never the it stuff.

In other words, to do great web design you have to design in the Web, not in some other medium for the Web. I mean, serious magazine firm employs designers who don’t understand how to work with page layout programs like InDesign. Why, then, do so many web design agencies employ designers who don’t know how to work with web technologies, or even how to use programs like Dreamweaver? It doesn’t really make any sense, and it’s no wonder that the resulting implementation is rarely top-notch work.

But if you’re a graphic designer who doesn’t know much about Web technologies, what are you to do? Well, as a first step, I think you should pick up my new book, Foundation Website Creation. It’s available from all good booksellers (and probably some crappy ones) as of today. The book is targeted towards all manner of web professionals, including graphic designers and website producers, who want to learn more about what it takes to actually implement a site.

If I do say so myself, the chapters on XHTML and CSS are exceptionally thorough. The book doesn’t try to turn you into an exceptional programmer. Instead, it will explain the foundational concepts you need to know to understand how XHTML and CSS actually work, and in so doing will enable you to use the tools you already know to solve problems and get things done.

I think this book will be an excellent starting point for lots of designers and other web professionals. However, it is not going to take you from zero to hero—no book can. That’s why I recommend that, after you read Foundation Website Creation and have a solid grasp of what the technology can do for you and how it actually does it, you next take a look at these excellent books:

• DOM Scripting by Jeremy Keith — if you’re a designer that needs to add a behavioral layer with JavaScript and Ajax to your pages, you need to read this book next.
• Mastering CSS with Dreamweaver CS3 – if you’re familiar with Dreamweaver and want to keep using it to create standards-based web sites, then I recommend you follow Foundation Website Creation with this book by Stephanie Sullivan and Greg Rewis to take your Dreamweaver skills to the next level.

As always, most of all, have fun. Because if you’re not having fun, you’re not going to make good web sites no matter what you know.

Note: As of this writing, the book listing on Amazon still publishes the wrong author list, which is very frustrating but out of my hands. At least the image of our book’s front cover lists the correct authors.

My co-authors on the book, called Foundation Web Standards Foundation Website Creation (you can pre-order now) and published by Friends of ED, an Apress company, are Jonathan Lane of Industry Interactive, Inc. and Joe Lewis, who blogs at Sanbeiji.com. I’m not going to say much more until after the book is released in late July.

For the eager, here’s the description of the book posted on the Friends of ED website:

Foundation Website Creation explores the process of constructing a web site from start to finish. There is more to the process than just knowing HTML! Designers and developers must follow a proper process to flush out goals and objectives and determine requirements both prior to, and during project development.

Large Web projects are rarely completed by a single person. Producers, project managers, designers, developers, writers, and editors all play critical parts in a project’s evolution. This book provides an overview of the entire process, and also shows project development from the perspective of these different roles. It introduces the key concepts and duties performed by every member of such a team, and gives you the skills necessary to tackle projects like a professional.

It’s quite exciting getting a book out, and it’s quite a bit more work than I’d have ever originally thought. That being said, it’s extremely rewarding. There’s a lot more work I need to do on it between now and the time it gets released to publishing, so, well…back to work I go.

Now you all know where I’ve been spending my time writing.

document.body vs. document.documentElement

In IE 6, in order to access the current width of the window in JavaScript you need to get document.body.clientWidth only if you’re in quirks mode. If you’re in standards mode, this property not only still exists, but it means something entirely different! It instead refers to the width of the body element.

This causes real trouble for some scripts when the value of the this variable seems to suddenly become frozen or fixed at a single value instead of changing appropriately on a window resize event. Instead of document.body.clientWidth, in standards mode, use document.documentElement.clientWidth. (Reference table at QuirksMode.org)

Internet Explorer crashes when attempting min-width

If you use IE‘s proprietary expression() syntax to script a CSS value, beware of calculating widths or heights that exactly match the value you’d like to set. If you do something like the following to set a minimum width on #someElement, IE will crash when you actually resize that element to be 500 pixels wide.

#someElement { width: expression(document.body.clientWidth < 500 ? "500px" : "auto"); }

Instead of doing the above, you should check for almost exactly the size you want, like so:

#someElement { width: expression(document.body.clientWidth < 501 ? "500px" : "auto"); }

However, the really important thing to keep in mind is that the minimum width you’re testing (501 in that second case) needs to be at least one pixel greater than the total content and padding width of the element. So if you have an element that needs to be no less than 500 pixels wide but also has 10 pixels of left and right padding, you need to check not for 501 pixels in width, but rather for 521 pixels in width. (Reference on CameronMoll.com.)

In some industries, such as construction (for example), people are very careful about what they do because they know how hard it will be to change something after the fact. In the digital workplace, however, people don’t seem to think as much about this sort of thing because it’s relatively easy to change things. After all, everyone’s dealing in bits and bytes at a fundamental level. However, if you take a higher-level look, you’ll see that many times things are not as easy to change correctly as you might think, and the costs associated with these mistakes and after-the-fact edits can be enormous.

Take a web site, for instance. (I bet you saw that coming.) After a web site is launched (and even before, sometimes), changes have to go back and forth between designers and coders, production and design, and back again. Many times so-called final versions are just the next revision and not actually set in stone, no matter what anyone says. For a web developer, all these changes can be really troublesome, however they also provide an opportunity for rapid, iterative improvement of your (X)HTML and CSS code.

In a recent project I worked on, I found myself faced with the challenge of positioning two columns of data that each had a different number of elements inside of them but that ultimately had to be the exact same total height. My production manager, who fell in love with floated layouts a long time ago, wanted to position the page using one column floated left and the other floated right, with their dimensions fixed so as to give them both room to fit inside their parent. This seemed perfectly logical to me, so I implemented it that way.

As the project moved forward, however, I realized that in our design changes to this kind of floated layout would require a minimum of editing two files. First, we’d need to edit the HTML source of our page to change the order of the content boxes inside the floated columns, and second we’d need to change the dimensions of the elements in our style sheets. Instead, reimplementing the design with absolute positioning would require edits to only one source file, the style sheet itself, where both the position and the element dimensions could be specified in a single CSS declaration.

With all the frequent changes the design department was making, this argument ultimately won everyone over, and the site uses absolute positioning for the design. The key concept to take away from this experience is that part of making things easy in the future is to design with change in mind, to be as flexible as possible from the get-go, but also to think about the actual implementations in such a way as to lower your edit-per-change ratio as much as possible. The fewer things you have to change, the easier it will be to change things moving forward.

The Grim Truth

Let’s face it. These days, any Joe-shmo with Microsoft FrontPage can call himself a web developer or designer. But web surfers can tell the difference between a professionally designed site and a site designed by your dentist’s brother’s roommate’s best friend’s boyfriend. To be professional, you have to design with web standards in mind, focusing on usability and accessibility. And it has to look good — really good.

The Tools You’ll Use

First, you’re going to need to stock your toolbox. Start with the basics. Learn how to manipulate page layouts with (X)HTML and CSS by reading Eric Meyer on CSS: Mastering the Language of Web Design. Occasionally, you’ll need a dash of JavaScript Design. Finally, learn what works best by Designing Web Usability : The Practice of Simplicity.

Building It Right

The Zen of CSS Design : Visual Enlightenment for the Web (Voices That Matter) is possible for you! Building professional web sites means Building Accessible Websites (With CD-ROM). No matter how good your design may be, it won’t mean anything if it doesn’t load quickly, so don’t forget to always Speed Up Your Site: Web Site Optimization. Then put it all together to create Bulletproof Web Design : Improving flexibility and protecting against worst-case scenarios with XHTML and CSS. But you’re not done yet! Help people find your site by giving it Search Engine Visibility.

Really Good References

While you’re doing all these things, don’t be afraid to let curiosity get the better of you. Expand upon the projects in the previous books by doing things differently, doing things your own way. As you tinker, you’ll come across situations in which you don’t know how to do something. For those situations, use the following must-have references to quickly look up information about a particular technology.

For (X)HTML: HTML & XHTML: The Definitive Guide, Fifth Edition
For CSS: Cascading Style Sheets: The Definitive Guide, 2nd Edition and CSS Cookbook
For JavaScript: JavaScript Definitive Guide

Helpful Bonus Books

Read The JavaScript Anthology : 101 Essential Tips, Tricks & Hacks to learn even more about what you can do with JavaScript and how to solve real-world problems with DHTML. Get more usability insight from Homepage Usability: 50 Websites Deconstructed and Don’t Make Me Think : A Common Sense Approach to Web Usability (2nd Edition). Arm yourself with an arsenal of Web Standards Solutions: The Markup and Style Handbook (Pioneering Series) to take on The Real Business of Web Design.

Learn all the Secrets of Successful Web Sites if you’re involved with larger-scale project management, or if you’re of the entrepeneurial bent, find out How to Start a Home-Based Web Design Business, 2nd (Home-Based Business Series) or How to Be a Successful Internet Consultant.

In brief, whenever CSS-generated content causes a line to reflow beyond the boundaries of its inline box (that is, whenever the text flows past a single line and on to two or more lines) and is then removed again, Safari’s rendering engine doesn’t know how to handle the situation and crashes the browser. This situation is esoteric enough that most site designs won’t have anything to worry about, but if you are trying to use such an effect in Safari then it’s important to be aware that you may end up crashing your visitor’s browser.

Rather than crash their entire browser (which certainly won’t earn your site any brownie points), hide the offending CSS rule from Safari by using the language pseudo-class filter or similar.

(It should be noted that the folks over at FiftyFourEleven are not folks whom I believe are using CSS improperly. The referenced article merely provides additional information for compression techniques.)

When I optimize web sites, utilizing HTTP compression techniques (especially with PHP) is one of the last steps I take and sometimes it isn’t even necessary at all. If your CSS is so large you think you need to compress it, then quite frankly, you’re not using CSS properly.

It’s very, very rare that even large web sites’ CSS files will ever get so big that they need compression if they are written properly the first time. (I’m talking like 25 kilobytes and up here, and even that’s not considered “huge.”) Why is this? Because good CSS should include a couple of distinct characteristics which cuts down on their size dramatically:

• High-level DOM selectors should be used to take advtange of CSS inheritance.
• Duplicated and default-declaration rules should be omitted and grouped (as should selectors).
• Shorthand properties and value replication should be utilized as often as possible.
• Use the cascade to supply global rules for alternative styles and medias (screen, print, etc.).

Finally, CSS is cached (or should be). That means it’s only sent down the pipe on the first request for it, and using modularized CSS by following the above guidelines means you can re-use these cached files over and over again in many different ways without using a touch more bandwidth.

Thus, it is always a bad idea to rely on compression rather than to do things right the first time. (Band-aids don’t actually correct technological problems.) Thinking that it doesn’t matter how much code you write because you’re going to compress it anyway is foolish (though frighteningly common), and can cause serious problems later on in the course of maintaining and updating or redesigning a web site.

Furthermore, some of the main reasons some sites take so long to show up on a user’s display has very little to do with bandwidth. For instance:

• Complex tables will tax a user’s CPU by forcing the browser to perform many calculations to configure the table’s display area, slowing rendering speed.
• To make matters worse, in many cases browsers can’t display any part of a table until the whole table has been processed. If your entire page is contained within one big table, then you’re going to make people wait for the entire page to finish being processed. (Ouch.)
• On the same note, really long pages can quickly turn into usability nightmares for other reasons, as users easily lose their initial context and relevance, so it is advised to limit the vertical length of most web pages for usability as well as optimization reasons.
• Page load time increases exponentially for each distinct object (like images, multi-media, even JavaScripts and style sheets) that you place on a page. Reducing the number of HTTP requests is far more important than compressing the content of HTTP transactions because a delay caused by network latency is indefinite.

So what have we learned? If you’re really that concerned with the bandwidth your CSS (or HTML) is eating up, I’m not going to tell you not to compress it, but I am going to tell you that you should probably be dealing with other, more pressing concerns. Let’s talk image optimization, for instance! That, however, is a discussion for another time.

The bottom line is that CSS was designed with bandwidth in mind. Using CSS intelligently drastically cuts your bandwidth use which saves you money and headaches because it reduces code bloat for both style sheets and HTML files. HTTP compression is great and useful, but not as a band-aid to fix a problem it can’t solve.

Much, if not most of that time was spent writing and editting new content, and beating down CSS bugs in Internet Explorer. Those of you who know my work habits are likely to be surprised by the fact that I could spend 14 hours dealing mostly with client-side coding issues.

Normally I can’t spend more than a few hours—at the most—dealing with CSS problems because browser bugs tick me off too much. (Ahem, MicroSucks.) Nevertheless, for some miraculous reason, I kept swatting bug after bug after bug this session and the enthusiasm just fueled more coding. Needless to say, I was very very productive last night.

I also didn’t sleep a wink, however, so now I’m dead tired. Here’s a short recap before my memories fall down behind the waterfall in my mind.

Last Night’s Call-a-thon and Digital Departure

• Last night I was Mr. Popular. I got literally countless phone calls (I can’t remember them all) from folks who wanted to chat it up. I spoke to a few Meetup group members, Danica, my parents, and others. Christine called and wanted to hang out today but she canceled this afternoon. (I didn’t mind, I’m exhausted.)

• Danica came over from about 8:30 PM to 10:30 PM so that she could give me back the apartment keys and transfer her digital posessions (computer files) off of my computers and onto her own. She also gave me a Moldy Peaches album to import into my iTunes Library. (Cool.)

  So that’s pretty much it. We said goodbye, she seemed sad, and I asked her to call me so I knew she’d gotten home okay. She did, and we said goodbye again. And that’s that; we are finally going our separate ways and have no more connection to each other whatsoever.

  I’m not even thinking about the future, but I do admit that remaining friends is something I’d probably like—if it were not emotionally draining. We’ll see what happens, but the path for right now is very clear: I’m trekking it solo yet again!

The Geeky Parts

• Back to the tech realm, I’ve implemented my dynamic relevancy message API on this blog. What does that mean for you? Probably nothing, but it does mean you’ll likely see relevancy messages change and grow in abundance over time. As always, use a modern browser to see the full effect.

• Still in the tech realm, I squashed a number of annoying IE CSS bugs on this blog with the somewhat-magical application of position:relative;. This means visitors using IE will finally get a near-perfect browsing experience, with no annoying vanishing backgrounds anymore.

• Also, Google SiteSearch has been implemented, so you’ll be seeing that on the top banner for the time being. It’s nothing special, just a way to make it look like you can do more than you can here. It might also make me some more money via clickthroughs, but that’s unlikely. (Oh, which reminds me, those ads on the right side of the window, yeah, if you click on those I get money. Don’t be shy.)

• A not-so-new but still interesting point of note is that I’ve started using MyBlogLog.com to keep track of which hyperlinks people are clicking on. This has been somewhat informative because it means I get to see which hyperlinks induce clicks and which don’t. Anchor text is important, and this is a useful tool to learn how you can manipulate the effect of a link.

Flickr Photos from the Past!

Finally, I’ve been wanting to get more value out of my digital camera. I haven’t been taking pictures, but backing up and transfering a bunch of Danica’s things last night inspired me to dig through some of my old photo collections to see what could turn up. Well, here it is:

• Here’s me almost a year ago, during last year’s Passover at my mother’s:

  

• Me at San Francisco’s Exploratorium with Danica during the Summer of 2004, on my trip to meet her family. Look at the face I’m making, I had so much fun there.

  

• Yeah, I was gonna eat that piece of toast. Obviously, my dinner plans were foiled.

  

• This is what happens to my face if I don’t shave.

  

Context and relevance are two of the most important aspects of effective communication. If the context of a message is not understood then the commuication will likely be disregarded, or worse—misinterpreted. If the message isn’t relevant to the topic at hand then it will be useless to everybody involved.

In order to ensure that a message is successfully received and has the desired effect, one must first ensure that the context for that message is properly set up and that the message itself is relevant to the subject matter.

An excellent example of a scenario where a loss of context and/or relevance can easily cause communication problems is receiving email messages. Surely everyone has recieved an email that they simply don’t know what to do with or why they’ve gotten it. (By the way, for some unbelievably insightful tips on composing effective email messages, read this article [via 43 Folders].)

The same thing can—and does—happen on the web. For example, let’s say you’re reading a page which has a link in its text to another page. You decide to follow the link but once you’ve arrived at the new page you find yourself staring at an enormous amount of other text that doesn’t have anything to do with why you followed the link in the first place. Suddenly you’re confused, you feel lost, and you quickly push the “Back” button of your browser.

What went wrong here? Context was lost; the destination page had no relevance to the source page. If it did, you couldn’t find it because it wasn’t clearly identified. This is a confusing and frustrating situation, and one that I’m willing to bet happens way too often on the web.

On my own blog, I frequently link to entries I’ve previously written. Sometimes these entries can be quite long, and I’m not always referencing the entire entry in my link. But by pointing the link to a specific “intra-page” anchor by using a fragment identifier and clearly marking the relevance of this information in both the link itself (with a descriptive title) and in the landing page (with what I’ve come to call a relevancy message), context is preserved and confusion is eliminated.

To see what I’m talking about in practice, check out my experiment pages. It’s a demo of the problem and relevancy messages in action.

CSS2 The Rescue

There’s only one problem left. How does one insert text into the landing page which will be viewable when someone follows a specially-crafted link to it, but not when they arrive at the page via any other link? Though it is possible to program this into your pages using PHP or another web scripting language, CSS level 2 offers a much simpler and maintainable solution: the :target and :before pseudo-classes.

When used in combination, the :target and :before pseudo-classes can be used to generate text on a page at a specific point in the document when your page is linked to in a certain way. By using an additional CSS2 function, attr(), we can also generate customized text for each landing spot within the document. Let’s take a look at each component separately.

The HTML You’ll Need

Let’s say you’re writing about apples. In your text, you link to a previous article you wrote about oranges. Your link in the article on apples might look like this:

<a href="oranges.html" title="Oranges have a thick, white pith beneath their skin." >oranges</a>

And your text in the article on oranges might look like this:

<p>[…] The skin of an orange is thick, porous, and varies in color from deep to light orange. There is a bitter-tasting white pith underneath the outter-most layer of the fruit's skin. […]</p>

In order to link directly to the paragraph mentioning the orange’s pith you need to insert a named anchor just after the opening paragraph tag where that content was written. You also need to append this name to the URI of the link, as a fragment identifier. The resulting HTML for the link might look like this:

<a href="oranges.html#skin" title="Oranges have a thick, white pith beneath their skin." >oranges</a>

The resulting HTML for the paragraph about oranges might look like this:

<p><a id="skin"></a>The skin of an orange is thick, porous, and varies in color from deep to light orange. There is a bitter-tasting pith underneath the outter-most layer of the fruit's skin.</p>

The CSS You’ll Need

Once the HTML is in place, you need to create a style rule to generate the text you’ll want to display before the paragraph. Your style sheet might look like this:

a:target::before { content: "Here's what I referenced with my link on the last page: "; font-size: larger; font-weight: bold; }

You can even take it one step further. By adding a title attribute with some helpful text in your named anchor, you can actually display that text (specific to the reference you’re making) instead of the generic “Here’s what I referenced…” text. The CSS for that would look like this, and it would display whatever you write as the title for each named anchor you use:

a:target::before { content: attr(title); }

Limitations

The major drawback to this technique is that you need to change the code of the destination document for it to work. Specifically, you need to insert named anchors (though you can also target any element by giving it an unique id), and you need to insert a style rule. (However, see below for another experiment that will let site owners allow people to get around this limitation.)

Another major drawback is that it requires a fully CSS2-compliant browser. That means Internet Explorer 5 and 6 (both Macintosh and Windows versions) will not show the special content on the destination page. They will, however, move focus to the point in the document at which the anchor resides.

Looking to the Future

I have been playing with this technique recently on my blog (can you find the links I’ve used this on? ;). The obvious benefit is creating a far more seamless transition from one page to another and maintaining the same context across web pages. This is invaluable for me and my readers in particular, since I tend to enjoy writing and end up writing far longer entries than I probably should. (Even though I use headings to divide my entries into logical chunks, it’s still good to have another trick up my sleeve to help usability!)

However, this technique is ripe for expansion. For instance, I have created another experiment to dynamically generate the content of the CSS rule based upon a variable in a GET querystring. (It uses three lines of PHP, and that link itself is a proof-of-concept.) This will allow people to write links that point to my documents and insert their own special relevance-describing blurbs in front of the fragment they’ve linked to. (Yes, I realize this may pose XSS security problems, I’m still just playing with the concept.)

Exploring all of this is a lot of fun. The crux of this technique relies upon accessible and clever hypertext copywriting to enhance usability when linking to web pages and referencing information across pages or, one day, sites. As is the case with most things Web, simple is better.

I’m very eager to hear about comments on this technique. Are there dangers I haven’t seen yet? Can you think of another way to use it that I haven’t mentioned here? Are you already using it on your own site? All feedback welcome. :)

This is a great example of how IE‘s inconsistent rendering behavior has long-lasting negative effects on the adoption of CSS not only by web page authors, but web browser authors. As Dave himself says,

So now I really have no choice. This is an example of where the CSS2 standard simply can’t be followed because buggy layout engines have set a bad precedent that the rest of us have no choice but to follow.

It’s a shame that Gecko does not do the right thing in strict mode at least, but I suppose they had no choice in the matter either.

This is reminiscent of back when Opera was beginning to look more and more like Internet Explorer, but at least it’s not a bug this time.

Hardware Countdown

My oldest machine, an ancient first-generation Apple iMac DV:SE (do you remember those?), obviously contains the CRT screen along with the computer hardware in one box. So for the most part I consider that one unit. I also have my laptop which falls under the same category, but then I have two PC towers, and I’m getting ready for yet another from my mother along with a G3 tower soon. All of them are headless.

I only have one stand-alone monitor. So that means up to four computers need to share one monitor. Since I’m planning on using at least one or two computers as dedicated servers, I’m not going to need those connected to monitors all the time. For instance, I could VNC in and look around on the rare occasions when I have to. The others, however, are probably going to need something more scalable. I don’t have the space or the money for more monitors, so the best solution here is undoubtedly a KVM switch.

Broken CSS Can Lead to Unuseable Sites

As I was browsing, I came upon KVM Galore, retailers of every kind of KVM switch imagineable. Unfortunately, when I arrived I couldn’t read any product description because the bottom two-thirds of each line of text was chopped off, disappearing behind a white background. Here’s a screen shot.

My first thought was confusion, but my second was to see if I could fix it. So I dived into the source and traced the problem to a <span></span> element that was pretending to be a block-level box. Their CSS had given the span a width, background and border, but no display property.

Without the proper display rule, CSS-compliant browsers treated the span as an inline element, which is obviously not what the designer had intended. So I created a local style-sheet of my own and fixed the problem for the duration of my stay on their site. Here is the style sheet I used:

.detspecs { display: block; }

Believe it or not, that’s it. That’s all it took to fix the problem. I was using Firefox to browse the site, but after a while I became curious about the other browsers. It turns out that the site looks like this on Firefox for Mac, Netscape on both Mac and Windows, and while it’s mostly better in Safari, nasty black lines cut into the text on that browser as well. Opera 7.5 on both Mac and Windows, along with Internet Explorer 6 for Windows and 5.2 for the Mac looked fine. I’ve emailed the site owner and hope that they will fix the problem as soon as they can.

This isn’t the first time an e-commerce site has had broken CSS. Not long ago I wrote about another savvy web developer who fixed the Sainsbury home shopping web site just like I did for KVM Galore. On the bright side, it’s good to see CSS being used more and more thoroughly throughout the online business world.

I still haven’t chosen a KVM switch yet as I’m still researching the topic. If anyone has any advice, I’d love to hear it.

Update: I just heard back from the site owner today (January 19^th), and am glad to see that the CSS has been fixed. Good job, KVM Galore!

Browsing my newsfeeds, I happened upon this post from Andy Budd which points to this Mac OS X Hints post regarding a CSS-savvy web developer trying to do some online shopping. Unfortunately for the online store owners, their pages are unusable due to a serious rendering bug caused by their stylesheets. But rather than shop elsewhere, Lee Noble fixed the problem using a quick user stylesheet applied via Safari.

I’ve said it before, and I’ll say it again: the Web puts the users in control, the way it always should be!

Two Forms of Centering in CSS

There are two kinds of centering that CSS can accomplish, independant of each other. One kind is center-aligning text, achieved through the use of the text-align property. The other is centering an entire block, and not the text within that block, inside its containing element. We’ll be talking about the latter.

Centering a Block-Level Element Using the Document Flow

In CSS, to center an element horizontally within its containing block its left and right margins must be set to auto. This will make the element’s left margin length equal to the length of its right margin, thus keeping the element in the center of its parent. For example, you might center your main content div like this.

div#content {
    width: 600px; margin: 0 auto;
}

(The width is necessary; it has nothing to do with being centered, but if you leave it out the div will be as wide as its containing block and will not have any margins to speak of. The margins are what cause the centering effect.)

This will work because the main content div is in the flow of the document. That is, its margins are “pushing against” their parent, so they affect the layout of the div.

Taking the Block Out of the Flow

But what happens if we take the div out of the flow, with, say position: absolute;?

div#content {
    width: 600px; margin: 0 auto;
    position: absolute;
}

Suddenly, we find that the div is no longer centered. This is because we’ve taken it out of the document flow, out from within its parent element, and now its margins have nothing to push against. So how can we center this element?

Centering the Absolutely Positioned Box

The trick is to use its positioning to center one edge of the div, and then use margins relative to its width to push it into center-alignment. Thus, you can center any absolutely positioned element that has a fixed width by giving it, for example, left: 50% and then adding a negative margin-left equal to half of the element’s width. (You could also use right: 50% and then use a negative margin-right value.)

div#content {
   width: 600px; margin: 0 0 0 -300px;
    position: absolute; left: 50%;
}

Now the content div will be centered horizontally in the browser viewport, and it will stay centered even on a window resize.

In other words, the border-box value to the box-sizing property makes the selected box use Internet Explorer’s non-standard box model. At least, it was non-standard until it became part of the CSS3 spec. The spec even notes this itself, saying “This is the behavior of width and height as commonly implemented by legacy HTML user agents for replaced elements and input elements.”

This is somewhat annoying, because this means that rather than fix their “Web browser,” Microsoft can now say that their browser supports this property of CSS. In the end however, I do see the necessity of the property for compatibility reasons, as much as that necessity (caused by one browser vendor’s lack of support for Web standards) bothers me.

The most direct application of this technique comes in the form of making two child elements who have borders and/or padding fit precisely within one larger parent element whose width is flexible. For example, making floated, columnar layouts.

So while taking all this in I took some time to familiarize myself as best I could with Firefox’s implementation, the -moz-box-sizing property, and its effects. Some of my observations:

1. Most interesting uses for three column liquid layouts (or more). Two column layouts can use a (more complicated) balancing of float: left and float: right to achieve a similar effect in a liquid layout, though a small, variable amount of space between columns is nearly unavoidable.

   Also, experienced designers usually keep a certain degree of whitespace in their layouts, making such tightly fitted floats largely unnecessary and/or impractical implementations for certain designs. (I.e., positioning would be a more appropriate solution.)

2. Border-boxes offer no help for linking the height of a box to the height of its neighbor. Considering this is the biggest failing of CSS-based columnar layouts to date, I would stick with an accessible table where absolutely necessary, which can be and often is sized just like a border-box.

3. When confronted with left-floated boxes such as in the case of a columnar layout, IE/Win versions that use the border-box method of calculating width and height will drop a tightly-fitted floated box below its neighbor on a window resize. This creates either a trippy experience or cause for frustration depending on your mood. Considering this property is at least partially intended to help IE/Win, that’s quite an embarassing thing to have happen, methinks.

4. All in all, I’m still not convinced of the necessity of this property, except to support IE. While it can certainly be a useful “option” when attempting to create (arguably simplistic) column layouts using strictly semantic markup and CSS, tables are still going to be necessary in some designs. In the situations where they are not, a combination of existing techniques can still be used to achieve any desired effect.

Furthermore, this certainly doesn’t help make CSS a more approachable topic for Web designers who are new to the technology. The single largest obstacle to CSS‘s widespread adoption are the many various and often extreme browser bugs and quirks present in the majority of browsers. When a CSS newbie begins writing some stylesheets, they are greeted with horrendous results thanks to these misbehaving browsers. I know of several Web design projects that have begun using stylehseets, only to abandon all but their most basic capability due to frustration on the designer’s part. Some CSS concepts are not easy to grasp for beginners, the box model being one of them, and I am not fond of the idea of presenting designers with yet more differences in the way their pages can be rendered.

Moreover, most CSS beginners I have encountered use a GUI such as Dreamweaver or GoLive to create their stylesheets. In this case, a question arises for the developers of these interfaces: how do I visually show which kind of box-sizing is being used for this particular box on the screen? Do I show a little icon in the corner of the box’s display? Do I hide it in a dialog box?

In my opinion, these interfaces are not very good for creating style sheets. There is currently no application whith which you can actually draw, with your mouse, a rectangle of padding onto an element. You have to type a number into the “Padding” input box and then select the unit you’d like to use from a drop down menu. Designers do not think this way. Coders and programmers do. But coders and programmers aren’t the ones who really need CSS. Designers do. And they need their tools and their web browsers to speak their own language to them.

However, I’ve also actually been using it to make my experience on the Web more my own.

Introducing Edit CSS

One especially useful option in the Web Developer Toolbar for the Firefox and Mozilla Web browsers is the “Edit CSS” option. You can get at it from the Tools Menu → Web Developer → CSS → Edit CSS or by pressing CTRL + SHIFT + E. This will show the browser sidebar and, if any exist, load the existing styles applied to the page you’re viewing in a large text-entry field.

To use the feature, simply start typing in some applicable CSS. On each keypress, Firefox evauluates your style rules and applies any changes as appropriate. In other words, you can edit the styles of any page you visit faster and easier than ever before, and your changes are displayed live, as you type!

I like this a lot, because it further develops the application of the philosophy that giving the user more control over his or her environment is a good thing. Here are some examples of how to start making this new power work for you right away.

Exercise Your Power

1. The next time you come across a web site whose entire textual content is centered on the page (we all know how annoying that is), open your Edit CSS sidebar and type the following:

   * { text-align: left; }

   This will immediately left-justify all text on the page. Now you can read with ease!

2. To further help readability on pages whose line lengths span the whole screen, add a suitable maximum width for your reading pleasure:

   * { max-width: 40em; }

   Now all elements on the page won’t be wider than 40 em’s which should be comfortable for most people. Of course, feel free to substitute your own value in place of mine. That’s the beauty of it.

3. If the author of the page you’re viewing has chosen a horrendously annoying shade of pink or yellow to display text in (often coupled with an equally unreadable choice of background color), just open your Edit CSS sidebar and type the following:

   * { color: black; background: white; }

   Now you have easy-to-read text and you don’t have to strain your eyes. Again, simply swap the values for white text on a black background to inverse the colors, or feel free to use your own preffered colors.

What if the page doesn’t change?

If the page you’re viewing hasn’t changed after typing these lines in the Edit CSS sidebar, then you’ve either mistyped something or another rule later down in the style sheet is overriding the one you just added. In this case, you can either go hunting for the stubborn culprit in the original CSS or try increasing the weight of your own rule by doing one of the following:

• Increase your rule’s specificity by adding html>body to the front of your selector (in my examples above, the asterisk (*) symbol is your selector). That is to say, your modified rule becomes:

  html>body * { text-align: left; }

• Make your rule !important by adding that text after the rule. Your modified rule, marked as important, would look like this:

  * { text-align: center !important }

According to the creators of CSS, one of their goals was to make the Web more customizable to the end user. Thanks to tools like Firefox’s Edit CSS option in the wonderful Web Developer Toolbar, this is finally an easily-achieveable reality!

Create Personal Stylesheet Preferences in Other Browsers

If you’re not using a Mozilla-based browser (why aren’t you?) and don’t have access to this extension, try writing your own style sheets with your specific display preferences in it and applying them through your browser software.

Your style sheet is just a plain text file which can be written in any text editor.

Safari on the Mac allows this by going to the Safari Menu → Preferences → click the Advanced pane → select Other… from the Style Sheet drop down menu and select your style sheet.

Internet Explorer for Windows also supports this technique but the option is a little more cleverly hidden. Go to the Tools Menu → select Internet Options… → click on Accessibility → check “Format documents using my style sheet” in the “User Style Sheet” section → click Browse and open your style sheet.

(Internet Explorer 5 for the Mac also supports this option but that browser is so bad, so old, so slow, so buggy, and so insecure that finding the option is left as an exercise to any reader who dares to still use it.)

Opera for Windows and Mac also let you choose your own style sheet. Go to Preferences (from the Opera menu on a Mac or from the Tools menu on Windows) → click Page Style in the left column → click Choose next to the text box that reads “My style sheet.”

Here’s a recommendation for what to put in your new personal style sheet. Remember, however, it’s your style sheet, so feel free to start with this but add your own preferenes as well!

/* make pages dark-on-light and use a big-enough text size */
body { background: white; color: black; font-size: medium; }
/* keep paragraphs narrow and left-justified */
p { max-width: 40em; text-align: left !important }
/* I want headings in the Times font */
h1, h2, h3, h4, h5, h6 { font-weight: bold; font-family: Times; }
/* show me what the access keys are! */
[accesskey]:after { content: "(Access key: " attr(accesskey) ")" }
/* show me which images are actually links */
a img { border: 2px solid blue; }

Try browsing the Web with your new stylesheet. I’d be very interested to hear how it goes. Which sites could you use your new preferences in without any problem? Which did you break?

ul, ul li {
    display: inline; list-style: none; margin: 0; padding: 0;
}
li:after { content: ", "; }
li:last-child:after { content: "."; }
li+li:last-child:before { content: "and "; }

Here’s what’s happening.

1. First they display the entire list and each list item as an inline element. This causes them to show up right up against any other text around them.
2. Then they add a comma and a space after each list item.
3. The last list item, however, gets a period and no space.
4. Finally, the word “and” followed by a space is inserted before the last list item if, and only if, there is a list item before it (it has a sibling).

There you have it. List markup that looks just like a normal paragraph, complete with proper punctuation! A great little tip that makes lists a whole lot more flexible!

Note that as of this writing this won’t work in Internet Explorer because it can’t understand the last three rules. Since it does understand the first, the result will merely be an inline box for the whole list, sans punctuation.

Some elements of the design, however, relied on dynamic scripting to style appropriately. The key thing here, however, is that I wanted to avoid accessing or manipulating style elements from within the JavaScript script. In other words, I wanted to ensure that all my style rules, the visual declarations for the presentation of these links, would be kept in the site’s CSS.

There were several reasons for this:

1. To keep presentation clearly separated from behavior and structure.
2. To keep the JavaScript unobtrusive and portable.
3. To ensure that both aspects, presentation and behavior could be easily updated or altered in the future.
4. To allow for various styling without touching the script.

Typically, a JavaScript script with a line similar to elem.style.property = 'value'; is used to create so-called “dynamic styles.” Unfortunately, this would not do for me.

So I fiddled and found that the best way to go about this was to simply tag links that I wanted to style by adding a word to their class name and then write styles for the selected elements inside my stylesheets. In effect, links in my page will be transformed from <a href="http://some.other.site/"></a> to <a class="external" href="http://some.other.site/"></a> So I sat down and wrote this little plug-and-play JavaScript to tag the links I wanted. Let’s go over it line-by-line. (If you’re antsy, here’s the whole script.)

First, we define a function named catchExternalLinks. Then we set a variable, extClassName, to hold the class name we’re going to add to the links. While not strictly necessary to hold in a variable, it does make for easy editing later. Don’t like the word “external” for a class name? Change it to something else.

function catchExternalLinks()
{
    var extClassName = 'external';

Next, we do some object detection. This is to ensure that the browser can handle what we’re going to ask of it. Browsers that can’t handle it won’t try to, which is good because it means visitors won’t see an error when they visit the site. They just won’t see the dynamic styling.

if (document.links && document.getElementById) {

Now that we know we’re talking only to browsers which can handle our instructions, we define a variable, h (for host), which will store the beginning of the web address that we’re at. On www.maymay.net, h now contains the string http://www.maymay.net.

var h = window.location.protocol + '//' + window.location.host;

Next, we need to gather all the links in our page. We assign the links array to the variable l.

var l = document.links;

We need to work with each link separately, so we loop through the links…

for (var i = 0; i < l.length; i++) {

…and assign the value of the href property to the target variable after turning the string toLowerCase text.

var target = l[i].href.toLowerCase();

We only want to work with real links, so first we make sure we’re not dealing with javascript: directives.

if (target.substr(0, 11) != 'javascript:') {

Then we search the target string of the link for the h string. If we don’t find it…

if (target.substr(0, h.length).indexOf(h) == -1) {

…then this link is an external link so we tag it as such by adding the extClassName to its className preceded by a space. We do this instead of using setAttribute() because this way we can keep any pre-existing values for the class attribute already in the link. The key here is to know that className accesses the class attribute of an element.

    l[i].className += ' ' + extClassName;}

Finally, after closing all our blocks properly, we set the catchExternalLinks function to execute onload.

            }
        }
    }
}
window.onload = catchExternalLinks;

Of course, as per the requirements for this script being as unobtrusive as possible, it won’t do anything to the style properties of the link. All it did was add a class value, so we’ll need to declare our styles in our stylesheet. In my CSS page, I write the following to display a little icon for these links.

a.external {
    padding-right: 15px;
    background: transparent url(extlink.gif) center right no-repeat;
}

The styling possibilities are really rather endless now. Since I can instantly identify external links via the class external, I can also write context-specific styles. For instance, I can limit my styles to only one part of the page with a selector such as

#main a.external { ... }

or I could write different styles for external links for the sidebar and a comment on my entry with

#sidebar a.external { ... }
.blogComment a.external { ... }

or any other styling I see fit. In addition, from the script, it’s very easy to test for links that meet a specific criteria, say, Google definition searches, simply by adding another if clause inside the main loop. Here’s a version that does just that.

All together, it goes like this:

function catchExternalLinks()
{
    var extClassName = 'external';  // the class to set for external links
    var defClassName = 'defSearch'; // the class to set for definition searches
    if (document.links && document.getElementById)
    {
        var h = window.location.protocol + '//' + window.location.host;
        var l = document.links;
        for (var i = 0; i < l.length; i++)
        {
            var target = l[i].href.toLowerCase();
            if (target.substr(0, 11) != 'javascript:') // only work on links that aren't JavaScript directives
            {
                // tag external links
                if (target.substr(0, h.length).indexOf(h) == -1)
                {
                    l[i].className += ' ' + extClassName;
                }
                // tag Google definition search links
                var anchor = l[i].childNodes[0].nodeValue; // anchor now contains the anchor text of the link
                var s = '?q=define:' + anchor;
                if (target.substr(0, target.length).indexOf(s) != -1) // use != to ensure that the string (var s) EXISTS in target
                {
                    l[i].className += ' ' + defClassName;
                    l[i].title = 'Definitions for ' + anchor + ' on the Web.'; // for the link tooltip
                }
            }
        }
    }
}
window.onload = catchExternalLinks;

Feel free to steal this snippet. Just remember to write your styles in a stylesheet that you connect to your page, or the script won’t have any noticeable effect. Of course, that’s the whole point. Enjoy! ;)