This spring, the Orton Family Foundation decided to have us revise the site, to help address some functional concerns, adapt to feedback from users, and refresh the look and feel. (Under-the-hood, we also migrated from Zope to Pylons). A key part of the aesthetic for the new design was really pushing the book metaphor as much as possible. I wanted to share a couple of peeks into how we incorporated that mandate into the new design. (For another take on this project, check out this writeup).

For most pages, we ended up going with a very literal book metaphor:

For comparison, I’ve taken a shot of the original version.

We had a hard time making the homepage fit the open-book design, and ultimately opted for a very different layout:

The book metaphor carries over to the “stack” of almanacs, which are displayed edgewise. (For the sake of thoroughness, I’ve also posted the previous Community Almanac homepage).

Fun with Error Pages

Some of the most fun aspects of this project involved finding small ways to reinforce the book metaphor without being totally over the top, or working against the needs of an online application. Two of the pieces I’m particularly happy with are the error pages.

For the 404 (Not Found) page, we kicked around a couple of ideas, before hitting upon the idea of using the book image but with several pages torn out:

Once we’d come up with the design for the 404 page, the 500 (application error) page was a no-brainer:

Error pages in general don’t get a lot of design thought or attention, and these are probably the best error pages of any website I’ve gotten to work on. That’s not to say they’re the only interesting or cool element we’ve added to this relaunch – for bonus points, once the site launches this week, check out what happens when you turn the page.

In themselves, pieces like these are fairly minor. But nailing the details can help a good design become really great. We may not have been able to add every cool idea in this iteration, but I’m pretty proud of the work our team has done, and am excited to see it go live this week.

Current State of Affairs

Web folks are a clever bunch, though. If browser support for CSS won’t give us a way to target a particular element, a common solution is to make classes do the heavy lifting for us. Going through files to add class="text" to every text input is an all-too-common experience for web designers.

Adding the classes allows us to target elements on all browsers, but is labor-intensive and potentially error-prone. Moreover, if your site includes content (like comments or blog posts) which will entered by users, you have no easy way to ensure those classes are added appropriately.

A Glimmer of Hope

jQuery is one of several great javascript frameworks which have burst onto the scene in the past year or so. One of the reasons jQuery has gotten a lot of attention from web designers is the way it allows you to select elements – in many cases, jQuery selectors are identical to CSS selectors. jQuery is also extremely extensible. If there’s functionality you need which isn’t provided by the core framework, you can easily add it via a plugin (or by extending jQuery directly).

In the course of a recent project, I used jQuery to add a first-child class to some <li> elements in our top navigation, to shore up IE6 CSS support without having to alter the markup. After seeing how easy jQuery made that, I realized it’s be possible to write a plugin allowing any browser supported by jQuery capable of supporting all CSS 2.1 selectors. So I wrote SuperSelectors. It goes through your site’s stylesheets, dynamically adding classes to elements so that even IE6 can bask in the glow of properly supporting CSS selectors like ul li:first-child li:nth-child(odd) a:hover.

Pencils out

Before we can start to determine which elements ought to have classes added, we’ll need a way to access each stylesheet being used by a given page. Fortunately, the document.styleSheets array does exactly what we want. Unfortunately, we have to incur a little bit of overhead here. Since browsers will silently excise rules they don’t understand, we have to re-request the CSS files via javascript, and parse those for matches.

Now, the fact that jQuery supports CSS selector syntax comes in really handy. We can pass the matching CSS rules directly to jQuery, and add classes appropriately. Then, any browser supported by jQuery can properly target elements, even useful-but-not-broadly-supported CSS rules like ul li:first. All we need to do to have classes added to match any of the rules in our CSS is include jQuery and the SuperSelectors plugin, and add the following javascript:

$(document).ready(function() {
  $(document).superSelectify();
});

This is a great start, but some of us are maintaining sites with established conventions for element classnames. Maybe you’re working on an educational site, and the child is already reserved for another context. No problem. SuperSelectors will allow custom classes to be passed in, while still providing sensible defaults. You can override any (or all) of the default classnames. If you need to alter the class attached to child elements to be child-element, your javascript would just change to be:

$(document).ready(function() {
  $(document).superSelectify({childClass: "child-element"});
});

Attribution needed

What about special cases which fall outside the normal advanced selectors? Maybe we need to have styles applied conditionally, based on attributes. For example, maybe the links in your file download list should have an icon based on the extension of the file they’re pointing to. CSS 2.1 allows us to target elements based on attribute values – we can even match against substrings within the attribute value, which is a perfect fit for finding the file extensions of our links. The number of potential choices for attribute selectors alone is more than we can reasonably build into a single plugin, but fortunately SuperSelectors supports arbitrary selectors through the additionalElementHash attribute. This can be done with or without overriding the default classnames. A setup which addressed the file-type requirement mentioned above would look like this:

$(document).ready(function() {
  $(document).superSelectify({additionalElementHash: {jpeg: 'a[href$=".jpg"]', pdf: 'a[href$=".pdf"]', doc: 'a[href$=".doc"]', gif: 'a[href$=".gif"]', xls: 'a[href$=".xls"]', png: 'a[href$=".png"]'}});
});

A little more effort than the no-argument invocation, but that will enable matching almost any elements you can think of – you’re only limited by jQuery’s selector support, which is one of the best out there.

Hovercraftiness

It’s probably time to acknowledge the elephant in the room – specifically, the fact that IE6 only supports the :hover pseudo-selector for anchor tags. Through the years, there have been a variety of approaches to add this in, including Peter Nederlof’s whatever:hover. This is all well and good, but it’d be nice to be able to have one-stop shopping for all our CSS needs. Fortunately, jQuery makes it easy for us to add this functionality into Super Selectors. Declare your :hover rules normally, add an equivalent rule using the hover class, and SuperSelectors will take care of adding / removing the classnames from elements on mouseover.

Faster, faster

Things are really shaping up nicely. Any browser which jQuery supports can now use virtually any legitimate CSS selector, but we can still do better. If we know which advanced selectors our site will need to support, it seems wasteful to have to re-request all those CSS files, and then scan them for matches. In fact, on slow connections, or with sufficiently-large amount of CSS, users could see a page without the added classes for a fraction of a second, similar to the old Flash of Unstyled Content bug.

SuperSelectors makes it simple to avoid the unnecessary request/parsing overhead and display properly-classed markup right away. You just need to pass in all your selectors via the manualSelectors attribute, as a comma-delimited list. As with everything else, it can be used solo or in combination with any other arguments.:

$(document).ready(function() {
  $(document).superSelectify({childClass: "child-element", manualSelectors: 'div.example > ul, ul.sample li:first, input[type="text"], input[type="password"]'}});
});

For complex CSS needs, this may require a fair amount of work. However, this approach saves us from having to re-request and parse all the CSS files in use. Consequently, it will be much faster – especially for sites with large (or large numbers of) CSS files. Check out the example.

One caveat

SuperSelectors does a lot to help enable better CSS selector support across browsers, but it can’t do everything for us. We still need rules in our CSS which use the classes SuperSelectors will add.

Because Internet Explorer will discard the entire rule if it doesn’t understand one of the selectors, we do have to do a little duplication in our CSS. That means that, instead of

div.example > ul,
div.example ul.child {
background: #0f0;
color: #f0f;
}

You should write:

div.example > ul {
background: #0f0;
color: #f0f;
}

div.example ul.child {
background: #0f0;
color: #f0f;
}

In Closing

The goal of SuperSelectors is to make it possible for all of us to start using CSS 2.1 selectors in our everyday work. It doesn’t have CSS3 support (yet), but SuperSelectors will automatically benefit as jQuery adds support for CSS3 selectors.

You can download SuperSelectors as a zip or tarball. Github also hosts the official SuperSelectors repository, if you’re interested in helping make SuperSelectors even better.

The design for the new site includes two drop-down menus (for “About Us” and “Our Work”), and we went with an approach based on the classic Suckerfish menus. Pretty easy to implement, and looked great in our initial design passes. When I went to do some regression testing, I found that Opera was was badly misrendering the menus:

All other browsers were displaying the menus as-intended (even IE6, due to a quick little jQuery function to add the relevant classes on mouseover).

As I was playing with possible resolutions to the problem, I stumbled onto an odd fact. The problem only appeared when the nav was aligned to the right. Floating the nav to the right triggered the renderbug, as did positioning it to the right. Unfloated navs behaved correctly, as did ones which were floated or positioned left.

For launch, we went with a left-floated nav, but that prevents the nav from reliably being aligned with the right edge of the parent container (since font sizes can be adjusted independently of page zoom).

After launch, I did some digging to isolate the problem, and to write up a bug report for Opera. I also came up with a test case illustrating the issue.

The problem only manifests when the dropdown menus extend below the calculated bottom of the content within the <body> element. Since all the content on the TOPP site was floated, and floated elements are removed from the normal document flow, Opera effectively thought the pages were zero-height.

Somehow, floating or positioning the nav to the right is tripping up Opera’s redraw logic for the dropdown menus, if those dropdowns extend below the calculated bottom. Why right-floated or right-positioned elements trigger this renderbug, while left-floated or left-positioned elements behave correctly is still a bit of a mystery.

I’ve written up my test case and submitted a bug report to Opera. Opera unfortunately doesn’t have good transparency into their bug-tracking process, so I can’t link to my report, and folks can’t upvote the bug, but hopefully it’ll be fixed before too long.

­Problem Summary

An element needs to support partial transparency – either an img tag, or an element with the background-image property set via CSS.

Use When

The page still needs to support IE6, and has elements which should be transparent.

Solution

Use CSS transparency, with appropriate selectors.

Example

CSS

* html .pngfix {
zoom: 1;
behavior: expression((this.runtimeStyle.behavior="none")&&(this.pngSet?this.pngSet=true:(this.nodeName == "IMG" && this.src.toLowerCase().indexOf('.png')>-1 ? (this.runtimeStyle.backgroundImage = "none", this.runtimeStyle.filter = "progid:DXImageTransform.Microsoft.AlphaImageLoader(src='" + this.src + "', sizingMethod='image')", this.src = "transparent.gif") : (this.origBg = this.origBg ? this.origBg : this.currentStyle.backgroundImage.toString().replace('url("','').replace('")',''), this.runtimeStyle.filter = "progid:DXImageTransform.Microsoft.AlphaImageLoader(src='" + this.origBg + "', sizingMethod='" + (this.currentStyle.backgroundRepeat=='no-repeat' ? 'crop' : 'scale') +"')", this.runtimeStyle.backgroundImage = "none")),this.pngSet=true));
}

Note: this method is adapted from the approach documented at http://www.komodomedia.com/blog/2007/11/css-png-image-fix-for-ie/. It improves upon it by using zoom to trigger HasLayout in IE6, rather than relying on position: relative.

You can either add the “pngfix” class to all elements which need to support transparency, or add selectors in your CSS file to target your desired elements. Prefixing the selectors with * html ensures that only IE6 will process the rule, preventing more-capable browsers from trying to parse IE AlphaImageLoader idiosyncrasies.

Limitations

This approach will not support repeated background-images – Internet Explorer will stretch the background image to fit. This can still be useful if your background is a solid color and you’re just using transparency for an overlay effect. It will also still be suitable if your background-image is full-width and has no vertical variation (for example, if you’re using a background image to fake columns).

Due to limitations with the AlphaImageLoader functionality, this approach will not work at all for elements which need to have the background image positioned. If that’s behavior you need (and you have to support transparency for IE6), you should consider adding an extra element and positioning that instead.

Problem Summary

An element needs to be expanded to contain all child elements, one or more of which may be floated (and thus removed from the normal document flow). ­

Use When

The page contains floated elements w­hich should not extend beyond their parent element.

Solution

Use self-clearing floats.

Rationale

While the “use a float to contain a float” approach will ensure that all elements are appropriately contained, it can trigger other renderbugs which this approach avoids.

Example

CSS

.selfclear:after {
content: ".";
display: block;
height: 0;
clear: both;
visibility: hidden;
}

.selfclear {
display: inline-block; /* IE 7 */
}

.selfclear {
display: block;
}

* html .selfclear {
height: 1px; /* IE < 7 */
}

Note: this method builds upon the approach documented at http://positioniseverything.net/easyclearing.html.

I don’t always enjoy the midway point, when a misrendering issue stubbornly refuses to yield to my ministrations, but that “Eureka” moment where I manage to tease out what’s going on under the hood and come up with a solution – that’s gold.

As a result of the fact that Internet Explorer generally has the most rendering issues, I’ve gotten to be good pals with IE, in it’s various incarnations. When presented with a new renderbug, I sometimes feel like a sitcom parent catching a child with their hand in the cookie jar. “Oh IE you goofball, what mischief have you gotten into this time…”

I know, I know. I should get out more. Bear with me.

Roughly two months after the new Livable Streets site launched, one of my co-workers reported a renderbug where the sidebar was one pixel out of place. After doing some detective work, I discovered that this issue was exceptional in two respects:

1. It only showed up on Firefox 3. Earlier versions of Firefox were unaffected, as were Safari, Opera, and Internet Explorer (even IE 6).
2. It only showed up at certain horizontal resolutions. If you slowly resized the browser window in Firefox 3, you could watch the sidebar pop in and out of position.

Based on the now-you-see-it, now-you-don’t behavior of the renderbug during viewport resize, I was pretty sure this had to be a rounding bug of some variety. When I dug into the CSS, I found that every element that could conceivably play a causal role had width, padding, and margin set in absolute pixel values.

I created and discarded a bunch of different solutions. Everything I came up with was either extremely fragile, or triggered worse misrenders. All my test cases failed to isolate the problem, or point in the direction of a viable fix. I inspected elements using the great Web Developer extension. I added javascript to alert with element widths. At every step of the way, all elements reported the correct widths, yet I could trigger the bug at will by having an appropriately-sized browser window.

I began to jokingly refer to this renderbug as my “white whale”.

After a couple days of focused effort, with other projects starting to pile up, it became time to move on. I made a commit which fixed the worst symptoms of the misrender, but the underlying problem remained. I wasn’t happy about leaving the white whale out there, but couldn’t justify pushing off other front-burner issues to fix a one-pixel offset which affected a single browser, only at certain resolutions.

Fast-forward to last week. The market share for Firefox 3 has continued to climb. The design team has a bit of breathing room, and the white whale is once again in my sights. This time, though, I was able to identify the problem, and come up with a viable fix.

My initial reaction that this had to be a rounding error was correct, although I was looking in the wrong place by assuming the elements were being sized incorrectly. It turns out the the algorithms Firefox 3 uses for centering background images, can return different values from the ones used for centering contained elements. So, although all the elements on the page were sized in absolute pixels, the entire content area was being misaligned compared to the background-image (the background is centered on an element which is the full width of the viewport, so that at smaller browser sizes the dropshadow disappears and the content sits flush against the left side).

I created a test case demonstrating the issue, and went to post it to bugzilla, where I found multiple other users had already reported the problem. When I sat down to finish up this post, I found that the problem has already been fixed in the nightly builds, and should make it into production with Firefox 3.1.

Hooray for Open Source.

One common solution is to use the approach written up at A List Apart, which involves using relative and absolute positioning to make labels appear on top of the associated text input. That approach can be brittle when it comes to more complex layouts, however.

Another common solution is to use inline javascript for onfocus and onblur attributes. This has the advantage of being robust in terms of layout, and is the technique currently in use on several of TOPP’s sites (including four instances on the LivableStreets.com groups page):

This approach is not without drawbacks, though. Inline markup is never as elegant as listeners added via javascript, and can pose maintainability problems. It’s easy for multiple instances of functionally-identical inline javascript within a site to diverge, as users make one-off tweaks to handle specific enhancement requests. Additionally, password fields are problematic, as Internet Explorer refuses to allow modification of the “type” attribute for input elements which have been added to the DOM.

I decided a while back to write a plugin to address these issues. My goals were to provide a tool which:

• Allowed informational text to be added to input elements
• Was flexible enough to allow multiple ways to declare the text to be used, not just through referencing the relevant <label> element
• Would be as robust as possible, in terms of avoiding layout problems
• Would be easy for users to implement

Things are finally far enough along that I feel comfortable sharing my latest jQuery plugin, Inline Info.

Using the plugin

Note: this assumes that you’ve downloaded jQuery (http://docs.jquery.com/Downloading_jQuery) and the jQuery Inline Info plugin (http://github.com/chrispatterson/jquery-inline-info/tree/master). All examples can be used at the bottom of the page (immediately before the </body> tag), or set to fire with $(document).ready

When an element with inline info text loses focus, jquery-inline-info checks to see if the current value matches the info text, before resetting the value & changing the class. This is not normally case-sensitive, but this behavior can be changes by passing in the caseSensitiveMatch parameter:

$('#ex-field').inlineInfoTextify({caseSensitiveMatch: "true"}); //default is "false"

By default, jquery-inline-info will use the title attribute of each input element as the info text. If no title is defined, it will instead use the value of the relevant label element. It’s also possible to specify the info text to use, by passing in the inlineInfoText parameter:

$('#ex-field').inlineInfoTextify({inlineInfoText: "Some very helpful text"});

jquery-inline-info also adds a class to input elements, when they are displaying info text. This class is also customizable, by passing in the inlineInfoClass parameter:

$('#ex-field').inlineInfoTextify({inlineInfoClass: "my-custom-class"});

You can also pass in multiple selectors in a single invocation:

$('#ex-field, #ex-field-2').inlineInfoTextify({inlineInfoClass: "my-custom-class"});

or selectors which match multiple elements:

$('#ex-form input[type="text"]').inlineInfoTextify({inlineInfoClass: "my-custom-class"});

The look and feel of the notice is totally customizable through CSS, and I’ve included a demo in the github repository to show various invocations in action.

Questions? Comments? Enhancement requests to make things more flexible? Put ‘em in the comments. I’m definitely interested in improving things, and about supporting stuff folks need.

An example will probably help make the issue more clear.

The structure we’ll use is simple. A “container” div wth an explicit width will contain all our content. Each test case will be a “holder” div, which contains the paragraphs with negative margins to pull them beyond the boundaries of both parent elements.

In a standards-compliant rendering, elements can be caused to extend beyond containing elements, through the use of negative margins:

Internet Explorer, of course, plays by different rules. Let’s start by looking at IE6:

When no width is set for the holder div, the paragraphs with negative margins are shown to extend beyond their holder div, but are clipped at the edge of the container div. However, when we explicitly set the width of the holder div to 100%, the paragraphs are clipped at the edge of the holder div – they’re not allowed to extend past any of the containing elements (more correctly, the content does extend past, but it’s inappropriately truncated, as though overflow: hidden; were declared on holder divs).

The same results are obtained in our second result set. When we declare the width in pixels, the paragraphs are clipped at the edge of the holder div. When we explicitly declare the width to be auto (same as the default property for block-level elements), content is clipped at the edge of the container div:

With Internet Explorer 7, we get yet another curveball. IE7 does properly honor the negative left margin in all cases, regardless of whether (or how) we declare a width for the holder div. The right negative-margin isn’t so lucky. It still gets truncated exactly the same way as IE6:

It’s almost like the dev team created a unit test for left negative margins and decided they were all set.

To their credit, the IE8 team has fixed right negative margins, based on the current beta:

So, if your site has sizable numbers of IE users (which, I think, is most of us), be aware that negative margins can cause unexpected consequences. Explicitly declaring overflow: visible; on holder and container has no impact on the resulting page renders. For the LSN launch, I ended up using relative positioning to achieve the desired affect.

Have a different workaround? I’d love to hear about it. In the meantime, here’s the testcase I put together.

Aside: Skitch is Mac-only, but I’ve heard good things about Jing if you’re on Windows. I don’t know of an equivalent solution on Linux, unfortunately.

Skitch does a lot of things well, but one bit of polish which always pops out at new users is the “Click to Clipboard” functionality. Skitch provides lots of ways for you to share your images, and when you click in the appropriate field, the site copies all the data to your computer’s clipboard, and presents a nice confirmation that you’re ready to paste that elsewhere:

I decided to create a workalike function in jQuery, my favorite javascript library. I got a rudimentary version up and running a while back, building on the approach Jeff Larson wrote up, over at http://www.jeffothy.com/weblog/clipboard-copy/.

Today, I was able to get my workalike polished up and turned into my first jQuery plugin – it’s available at http://github.com/chrispatterson/jquery-clipboard/tree/master. There are still some pieces of polish I’m planning to add, but I’m pretty happy with it so far.

Using the plugin

Note: this assumes that you’ve downloaded jQuery (http://docs.jquery.com/Downloading_jQuery), the jQuery Flash plugin (http://jquery.lukelutman.com/plugins/flash/), and the jQuery Clipboard plugin (http://github.com/chrispatterson/jquery-clipboard/tree/master). All examples can be used at the bottom of the page (immediately before the </body> tag), or set to fire with $(document).ready

To add “click to clipboard” behavior to the element with an id of share-link:

$('#share-link').clickToClipboard();

To add “click to clipboard” behavior to all elements with a class of shareable:

$('.shareable').clickToClipboard();

clickToClipboard allows you to customize how long it takes for the notice to fade out, as well as the message used (for cases where you don’t want to use an image).

To have a slower fade effect, starting 1.5 seconds after the target element loses focus:

$('#share-link').clickToClipboard( {fadeoutLength: 900, fadeoutTimer: 1500}););

To customize the notice text:

$('#share-link').clickToClipboard( {clipboardText: "You're ready to paste!"}););

The look and feel of the notice is totally customizable through CSS. I’ve included a demo in the github repository, which shows how it might look with a background image. This is my first jQuery plugin, so I’m definitely open to feedback on ways to structure things better, or enhancement requests on how it be more flexible about supporting stuff folks need.

I’d seen http://24ways.org/2005/swooshy-curly-quotes-without-images a while back, and decided to improve upon it for the new Streetsblog site. In particular, the floated close quotes in Simon Willison’s approach will often leave a lot of whitespace.

The first version I’d done looked fine, and is what we launched with, but after a while folks found an odd renderbug. Internet Explorer (versions 6 and 7) would drop the quoted text down by about 2em, but only if the quote fit on a single line.

This week I was able to track down and fix the issue.

Here’s a screenshot of our launch CSS, as rendered by standards-compliant browsers:

Here’s a screenshot of our launch CSS, as rendered by Internet Explorer:

After a little digging, it became clear that the issue was IE inappropriately using the line-height for the opening quote for the entire blockquote, in those cases where the blockquote fits on a single line.

Lots of tinkering with line-height and vertical-align properties ensued – those have got to be the least consistent CSS properties I’ve run into for a while, and will probably be the subject of a later post.

Eventually, I ended up with something that worked in standards-compliant browsers:

And looks fine in IE7:

IE6 has an issue with line-height still – it will incorrectly indent the second line of text, to make room for the floated open quote (because IE6 ignores our explicit height declaration for that element):

That’s a tradeoff I’m willing to accept, in this case.

Markup for Better Blockquotes

<blockquote class="selfclear">
<span class="open-quote">&#8220;</span>
Fiction is obliged to stick to possibilities. Truth isn't.
<span class="close-quote">&#8221;</span>
</blockquote>

Note: The selfclear class is a variation of the clever method originally written up at Position Is Everything – used to clear floats without unnecessary markup.

CSS for Better Blockquotes

.selfclear:after {
content: ".";
display: block;
height: 0;
clear: both;
visibility: hidden;
}

.selfclear {
display: inline-block; /* IE 7 */
}

.selfclear {
display: block;
}

* html .selfclear {
height: 1px; /* IE < 7 */
}

blockquote {
font-style: italic;
color: #191f2f;
font-size: 1.3em;
line-height: 2em;
}

blockquote .open-quote,
blockquote .close-quote {
font-family: georgia, serif;
color: #6b707e;
font-style: normal;
font-size: 4em;
line-height: 1em;
}

blockquote .open-quote {
float: left;
height: 0.35em;
padding: 0 0.1em 0 0;
vertical-align: -60%;
position: relative;
top: -0.1em;
}

blockquote .close-quote {
vertical-align: -50%;
padding: 0 0 0 0.1em;
}

Replace the fonts and colors as needed for your design, and you should be all set!