Agile Ajax

Developer's Notebook: Find computed styles in IE, Firefox, Opera or Safari

At my recent Web 2.0 Expo talk, I exhorted developers to get comfortable outside the Firebug/Firefox safety zone. By rotating between Opera, Safari and even IE as our primary development environments, we can really get to know those browsers - and perhaps learn to utilize their non-standard features. Switching things up, however, can inhibit productivity until you learn your way around each browser's tools.

To that end, I offer these step-by-step instructions for finding computed styles in all four A-grade browsers. I chose the display of computed styles as my "debuggers are cool" use case because it's an obscure but useful feature for CSS debugging. Most of the time I can debug styles by looking at my debugger's snapshot of the current cascade for a given element. But sometimes that's not enough. If I've assigned a value of "inherit" to the font-family of an element, then the cascade snapshot won't tell me what font is actually applied to that element. (Not being a designer, I often can't tell the difference between various sans-serif faces, especially at small sizes.) Luckily, computed styles can give me the information I need.

As these examples demonstrate, debugging tools have come a long way in the last couple of years. Let's make the most of them for all of our UI-layer needs.

Internet Explorer 8 and DebugBar

IE's JavaScript debugging tools have finally matured, but its CSS ones lag behind. Even IE8, with its built-in debuggers (under Tools > Developer Tools), won't show you computed styles. Luckily, Jean-Fabrice Rabaute has crafted DebugBar, an plugin for Internet Explorer 5+ that adds all sorts of useful tools. Install DebugBar, fire up your version of IE and choose View > Toolbars > DebugBar to make the plugin visible. Then click the "DebugBar" icon in the resulting toolbar to open the DebugBar sidebar. You'll see two tabbed panes, one below the other. Choose the "DOM" tab on top and the "Comp. Style" tab on the bottom. In the upper pane, you should see a target icon with the caption "Drag target on document to find element." Drag the icon anywhere on an open web page and you'll see computed styles for the corresponding element in the bottom pane of the sidebar.

Alternate approaches to IE6 and transparent PNGs

Who knew IE6 and transparent PNGs could inspire so much discussion?

When you're churning out tips and tricks on a regular basis, you quickly learn to state things like this:

"I had Problem X, and my solution was Y given constraints Z."

... instead of this:

"The only way to solve Problem X is Y."

I was reminded of this lesson last week, after I posted a series of beginner-level tutorials about overcoming some of IE6's shortcomings with jQuery. My two-part piece on transparent PNG support got picked up by the kind folks at Ajaxian, and boy did the comments come. Between the two sites, we've heard from 20 people so far. A few were from the usual cranky haters. (Thanks to whoever felt the need to write, "Is this year 2001? IE6 png transparency? News on Ajaxian? Good heavens..." instead of just moving on to the next post.) But the rest provided lively debate and some valuable alternative approaches to the problem.

For review, here are the posts (with comments):

• Part 1
• Part 2
• Ajaxian cross-post

And here are some of the various approaches suggested:

Hacking transparent PNG support into IE6 with IE PNG Fix, CSS and jQuery (part 2 of 2)

For the recent redesign of the Pathfinder web site, we made extensive use of transparent PNGs to layer rounded corners and other curvy shapes on top of a non-contiguous background that mixes a black-and-gray gradient with a wallpaper-style repeating logo. Transparent PNGs are the only way to achieve this visual effect using semantic, standards-based markup and CSS - but IE6 doesn't support PNG alpha-channel transparency.

Yesterday, in Part 1 of this piece, we showed you how to install Angus Turnbull's IE PNG Fix on your server to correct this IE6 shortcoming. Today, we'll show how to overcome one use case not covered by Turnbull's script using a couple lines of CSS and JavaScript.

As we explained yesterday:

There is, however, one drawback to Turnbull's script: It can't account for PNG background images with a background-position other than top left. It will restore the alpha-channel transparency to such images, but it will reposition them to top left, potentially making your designs look even worse than they would have with an ugly gray halo where the transparency should be.

Hacking transparent PNG support into IE6 with IE PNG Fix, CSS and jQuery (part 1 of 2)

Yesterday's post showed how to hack the :first-child pseudo-class into IE6 with jQuery and CSS. Continuing with that theme, today and tomorrow we'll show how to enable transparent PNG support in IE6 (so your rounded corners don't look like the ones in this picture).

Today, we'll look at an awesome open-source script that will cover 90% of your needs. Tomorrow, we'll cook up some custom jQuery-flavored JavaScript to cover the corner cases.

As with many of my recent posts, my use case is the new Pathfinder web site, which launched last month. We took a pragmatic approach to implementing our new visual design using web standards. We practiced progressive enhancement globally, resorting to hacks and trickery only in browsers that aren't fully standards-compliant. (To be honest, that includes most modern browsers, though IE6 is the biggest problem child by far).

Our game plan went like this:

1. If possible, implement the desired look and feel across all browsers using only CSS and semantic markup.
2. When necessary, serve browser-specific styles using CSS filters.
3. Don't deploy non-semantic markup just to achieve a specific visual objective in non-standards-compliant browsers.
4. Instead, if only junk markup will achieve the desired visual effect in non-compliant browsers, inject that junk markup via JavaScript.
5. The result is a site whose visual fidelity suffers only in non-standards-compliant browsers with JavaScript disabled.

Hacking the :first-child pseudo-class into IE6 with jQuery and CSS

IE6 continues to define the lowest common denominator for our JavaScript and CSS strategies. IE7 may finally have edged past its younger sibling in terms of market share, but as of late 2007, IE6 still commanded commanded close to a third of the market.

For the relaunch of Pathfinder's website, we wanted our code to be standards-compliant and forward-looking, but we didn't want things to fall to pieces in IE6. We therefore used a variety of strategies to achieve a high degree of visual fidelity between IE6 and newer, better browsers. When CSS hacks and filters wouldn't provide us what we needed for IE6, we resorted to one of two strategies:

1. Use JavaScript to create the desired visual effect so that only JavaScript-disabled IE6 users would see a less than perfect rendering.
2. Just accept a degraded visual experience in a seven-year-old browser with declining market share.

Luckily, strategy No. 1 worked in most cases. Often, a single line of jQuery and a couple of CSS tweaks would create the desired look and feel. This was the case with one of IE6's most annoying shortcomings: its lack of support for CSS's :first-child pseudo-class.

GWT: DOM and Opacity

One thing missing from the DOM class in GWT is the ability to set element opacity in a browser independent way. You do have DOM.setStyleAttribute, but in IE you set the opacity by squeezing a alpha(opacity=val) into the filter, where in most other browsers you set the opacity style attribute directly.

If you take a peek into the prototype library, you'll see all sorts of cruft around setting opacity, such as supporting Konquerer, etc., but in the world of GWT, we just have to support a few browsers (IE6+, Mozilla, Safari, Opera). I had a need for a kinder, gentler opacity when I started developing GWTaculous, my pure GWT port of the Scriptaculous effects library. I implemented my own DOMX class to support those extended DOM operations I needed.

 

Developer's Notebook: Forward-thinking CSS float-clearing

The art of float-clearing - getting containers to honor the height of floated elements inside of them - has slowly evolved over the past several years as Safari has taken over many Mac desktops, IE5/Mac has atrophied, IE7 has slowly caught on, and our use of CSS filters has improved. I'd like to share a slight variation on the state of the art that I believe makes for much cleaner markup. But first, a little background.

How we got here

Several years ago, Tony Aslett of csscreator.com convinced us to stop using clearing our floats using this sort of junk markup:

<div id="container">
   <div id="rail" style="float: left;"></div>
   <div id="content" style="float: left;"></div>
   <br style="clear: both; height: 0; visibility: hidden;">
</div>

His solution, popularized on Position is Everything, convinced us to use pure CSS to solve the problem:

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

.clearfix {display: inline-block;}

/* Hides from IE-mac \*/
* html .clearfix {height: 1%;}
.clearfix {display: block;}
/* End hide from IE-mac */

<div id="container" class="clearfix">
    <div id="rail" style="float: left;"></div>
    <div id="content" style="float: left;"></div>
</div>

The advantage, of course, was that you didn't have to litter your markup with extra <br /> tags that would eventually become totally useless once the state of the art changed.

Where we are now

For sites that have dropped support of IE5/Mac and adopted support of IE7, the recent concensus on float-clearing has been something like this (using the same markup as above):

/* float clearing for IE6 */
* html .clearfix{
  height: 1%;
  overflow: visible;
}

/* float clearing for IE7 */
*+html .clearfix{
  min-height: 1%;
}

/* float clearing for everyone else */
.clearfix:after{
  clear: both;
  content: ".";
  display: block;
  height: 0;
  visibility: hidden;
}

And now, a slight refinement

Which leads me to a technique used at Orbitz, my previous employer, to apply the same methodology with even less impact on the markup itself. Instead of declaring a single clearfix class and then applying it to countless containers inside their XHTML, the Orbitz UI team uses a grocery list of CSS selectors, like this:

/* float clearing for IE6 */
* html #container,
* html .classThatNeedsToBeCleared,
* html div.anotherClassThatNeedsToBeCleared,
* html #someDiv .someClass .yetAnotherClassThatNeedsToBeCleared{
  height: 1%;
  overflow: visible;
}

/* float clearing for IE7 */
*+html #container,
*+html .classThatNeedsToBeCleared,
*+html div.anotherClassThatNeedsToBeCleared,
*+html #someDiv .someClass .yetAnotherClassThatNeedsToBeCleared{
  min-height: 1%;
}

/* float clearing for everyone else */
#container:after,
.classThatNeedsToBeCleared:after,
div.anotherClassThatNeedsToBeCleared:after,
#someDiv .someClass .yetAnotherClassThatNeedsToBeCleared:after{
  clear: both;
  content: ".";
  display: block;
  height: 0;
  visibility: hidden;
}

<div id="container">
    <div id="rail" style="float: left;"></div>
    <div id="content" style="float: left;"></div>
</div>

The idea here, of course, is that each time you have another container that needs to be cleared, you add browser-specific selectors for it to each of the three blocks above. Suddenly, there's no need to apply a utility class to a zillion different nodes in your HTML. Instead, you apply the same CSS rules to a bunch of atomic CSS selectors. Voila: float-clearing with absolutely no impact on markup. Presto: a solution completely centralized in a single block of CSS code, so that it can be changed in one place as the browser landscape evolves.

(Props to Gena Wilson, Orbitz's CSS headmistress extraordinaire, for constantly synthesizing elegant solutions like this one.)

Final side note: As long as folks are going to keep griping about missing items from their CSS wish list, could we please just eliminate the need to clear floats altogether? I know that the need to clear floats isn't actually a bug, according to the WC3, but it should be. I can't think of a single time I've ever _not_ needed to clear my floats. Can you? Tell me in the comments.

CSS 3: Multi-column Layout vs. Advanced Layout

My colleague Sholom Sandalow's post about multi-column layout in CSS 3 drew a lot of comments and remains one of our most popular articles two months after publication. Folks are obviously hungry for discussion about the future of CSS. Yet there's still a lot of fuzzy logic out there about where we're headed.

Viewport dimensions still matter

Lots of pixels have been burned in the discussion of changing viewport specs. But most of the people talking about the advent of very large viewports are probably designers with Mac Cinema displays - NOT average users. As market penetration for super-wide resolutions grows, so will market penetration for portable devices with resolutions at or below the old-school 640x480. (And I'm sorry, iPhone designers, but reading a full-width web page on a tiny screen isn't actually all that easy on my eyes. I'd much rather see media-appropriate layouts than tons of pan-and-zoom.) My point being: Assumptions about your audience's screen resolution have always been at odds with the idea of the Open Web. They still will as user-agents proliferate and diversify. As CSS evolves, it must continue to offer us tools to make content attractive and readable on a variety of resolutions and devices.

Multi-column text isn't a panacea

I also just don't get the excitement over multi-column text in the browser. Again, this goes back to assumptions about the viewport. One commenter uses this page as an example of good multi-column type that mimics the eventual CSS 3 spec. Yet on Firefox/Mac and IE6/PC, it's ugly, unreadable or both when you resize your browser to less than 500px tall or 1250px wide. How is this good design?

The main disadvantage of single-column text - that it's hard to read when the columns are too wide - can easily be solved by strong design skills and smart use of existing CSS capabilities. And the main advantage of multi-column text - that it makes more efficient use of space - ignores the fact that a browser is not a piece of newsprint. Ultimately, print-style columns work in some situations and don't work in others. They are neither a universal solution nor an antidote to bad web design. They are simply an additional tool in our CSS arsenal - one useful mostly in print stylesheets. It's nice that this basic layout feature is finally coming to CSS, but it's hardly the most exciting part of the CSS 3 roadmap.

Advanced layout: Finally, something to get excited about

No, my favorite CSS 3 spec is the Advanced Layout Module. (Thanks to my buddy Zack for alerting me to its existence.) This "concept album" exploring advanced layout strategies recently received its first refresh since 2005 (discussion here). For anybody who's ever struggled with CSS layout, there's a lot to love in this proposed templating system. Basically, the spec calls for a new type of display that combines the best aspects of table-based and float-based layout but provides far more flexibility than either. Of course, implementation is a far-off dream, and many aspects of the proposal haven't yet matured. But the Advanced Layout Module proves that the standards bodies are attempting to tackle the big picture of CSS layout rather than the little details.

In the meantime, several frameworks and techniques have emerged to tackle the problem of cross-browser, grid-based layout. Notable examples include the following:

• YUI Grids
• YAML (Yest Another Multicolumn Layout)
• Blueprint CSS
• Switchy McLayout: An Adaptive Layout Technique

I'd be interested to know who's using these tools, how userful they are, and whether they provide the same advantages as JavaScript/Ajax frameworks - that is, less time spent reinventing the wheel and more time creating great websites and webapps. As always, weigh in on the comments.

Cognitive Load, Portability and the Superiority of Client-Side Frameworks

The recent introduction of TrimPath Junction got me to thinking about Dietrich's widely read post on Cognitive Load and the Superiority of Server-Side Ajax GUI Frameworks. GWT's big advantage is that it mobilizes armies of Java programmers to write browser-based applications without having to learn JavaScript. This is clearly of enormous benefit to organizations with lots of Java programmers, few client-side resources, and a burning desire to build powerful webapps. Yet for the similarly huge army of client-side programmers out there, GWT is pretty useless. Why learn a foreign language just to have it translated back into your native tongue?

I haven't yet had a chance to play with TrimPath Junction, but it sounds pretty cool. Using the open-source Helma framework, it offers Rails-style MVC scaffolding in a JavaScript syntax that executes the same code on the client and server. Basically, it's RoR meets Adobe AIR for JavaScript programmers. I hope to give it a test drive soon.

Server-side JavaScript has been around for ages, but it's never really become a common development model. I remember writing ASP Classic apps in server-side JScript back at the turn of the millennium and having people wig out on me. "Why not write in VBScript like everyone else," they'd ask. My answer: "Because I can save time by running the same validation libraries on the client and the server ... and because I can write the entire app in one language." I obviously have no argument with Dietrich's thesis on cognitive load. It's just that my brain features a JavaScript compiler, not a Java one.

GWT is a great piece of engineering that keeps getting better; just check out the new non-beta 1.4 release. But I think there are a lot of advantages to frameworks that mobilize the JavaScript masses to write front-to-back webapps. The same cognitive efficiencies can be achieved, plus client-side programmers already know all the pieces of the UI puzzle. Ask a room of Java developers how to build accessibility and usability into standards-compliant XHTML and CSS. Nine out of 10 wouldn't have a clue.

The other big advantage to developing UI code in its native language is that you can port it to any server platform. With GWT and similar frameworks, you've got to rebuild much of your UI from scratch if you want to change course in mid-stream. With purely client-side frameworks such as Prototype, jQuery, YUI or MooTools, switching libraries may entail rewiring some of your code to a new API. But switching server platforms, from J2EE to .Net to PHP to RoR, can be done without much work at the UI layer. "The right tool for the right job" is a truism for a reason. Pure client-side development of UI code allows for the development of reusable components whose only dependency is on the standards bodies and browser vendors who control JS, CSS and HTML. GWT and its peers are useful for some teams and some projects, but they're not the only answer to webapp development.

An Event Apart Chicago: Day 2

Tuesday saw the conclusion of An Event Apart Chicago 2007, the two-day web-development conference from the folks at A List Apart. Here's my sequel to yesterday's day-one overview. I'll be back Friday with analysis and afterthoughts.

Jeremy Keith, author of "Bulletproof Ajax" and "DOM Scripting," led the day. His topic? "Be Pure. Be Vigilant. Behave," wherein he outlined the concepts behind "Hijax," the application of progressive enhancement to Ajax functionality. A staunch proponent of unobtrusive JavaScript, Keith warned against throwing web standards out the door when developing Ajax functionality. His examples demonstrated how to separate behavior from content and presentation by abandoning such outmoded techniques as the javascript: URL pseudo-protocol. His most extensive example showed how to code a graphical widget for the assignment of star ratings so that it would degrade gracefully into a standard HTML select box in less capable browsers. After discussing the difficulty of making XHR functionality play nicely with bookmarks and the back button, Keith acknowledged that his parting message - when in doubt, leave XHR out - was a bit of a copout for the author of an Ajax manual.

Next up was Luke Wroblewski, a Yahoo product designer whose resume includes work on the original Mosaic web browser. Wroblewski covered "Best Practices for Form Design" using exhaustive research from his forthcoming book on the subject. In case study after case study, he demonstrated how simple choices in the design and deployment of HTML forms - from the widths and alignment of inputs and labels to the placement and visual differentiation of cancel and submit buttons - can cut the time it takes to complete them in half. Wroblewski's most persuasive argument, however, was conceptual rather than technical. He made a powerful case that because forms are barriers between users and the things they want to do - buy your product, join your site or begin creating content - you should make them as easy to get through as possible. This central thesis added considerable weight to his many practical how-tos.

Accessibility advocate Derek Featherstone closed off the morning with "Accessibility: Lost in Translation." Featherstone looked at how markup choices can make a site transparent to assistive devices - or render it totally opaque. Using real-world examples from Amazon and other sites, he demonstrated how screen-reading software actually parses markup. His live examples proved that the lack of semantic markup and the absence of ostensibly optional HTML attributes can render a site worthless for disabled users. Featherstone then went beyond the basics, explaining how source order - the sequence in which nodes appear in your markup - can be used to enhance accessibility. By placing your central content first, then positioning chrome above it with CSS and providing jump navigation to skip past inessential modules, you can achieve the presentation you want for typical users without shortchanging disabled ones. In another example, Featherstone examined the ways in which meaning can be encoded in the color and position of elements on the page - and how to replicate that meta-data in a way that disabled users can understand. As with many of the other speakers, Featherstone's examples argued persuasively for the continuing relevance of web standards.

After lunch, CSS expert Eric Meyer again took the stage, this time to explore "The State of CSS in an IE7 World." Using the recent release of Microsoft Internet Explorer 7 as a springboard, Meyer illustrated the concepts that have governed the changing of the browser guard for more than a decade. His overall premise was that developers need to use their own server logs to gauge when support for an older browser can safely be dropped for their site. For most of us, IE6 isn't going away anytime soon, so we need to get creative if we want to harness advanced functionality. To that end, Meyer delved deeply into the details of IE7 techniques, filters and hacks. He praised the browser for the strides it makes over IE6's CSS engine in such areas as child selectors, adjacent sibling selectors and attribute selectors. His real-world examples demonstrated how such functionality adds power and elegance to our code. To cope with IE6's continuing market share, Meyer advocated the use of Dean Edwards's IE7 compatibility script, a JavaScript library that adds IE7 capabilities to older versions of the browser. The take-home message was that older browsers may take a long time to die out, but creative programming techniques can harness the future of CSS now.

The final two sessions for AEA Chicago 2007 were a little offbeat, which was a relief after 10 technical sessions in the previous 32 hours. In the highly anecdotal "Selling Design," ALA publisher Jeffrey Zeldman used stories from his own long career to illustrate best practices for handling difficult clients. His thesis was that collaborative work requires us to deal with a wide range of other people, so we should hone our ability to influence our collaborators - and pick good clients to begin with. Agency owner Jim Coudal closed things off wittily with "Dealing With the Both of You," a slide-free presentation about the crossover between personal projects and professional work-for-hire. Coudal assembled a number of satirical short films to drive home his point: Because most web developers are curious and easily bored, we should strive to marry passion with professionalism whether our clients are external or ourselves.

CSS considered harmful by Ajaxian commentators?

There's a super-entertaining comment thread/flamewar going down at Ajaxian in response to Dion Almaer's recent editorial on The Future of CSS and the end of 3.0. Almaer has lots of interesting and perceptive things to say about the maddeningly erratic way in which new standards make their way into general use. But the vast majority of commentators jumped at the chance to sound off on some of his minor points:

CSS is great for simple web style. CSS is awful for layout. Rich Ajax apps need layout. You spend the majority of your time trying to get CSS working correctly!

Of those four assertations, there's not a single one I can fully endorse. IMHO, current implementations of CSS are _pretty good_ for simple web style, but they're not great. (See the comments for many examples: rounded corners, varied fonts, etc.) They're not great for layout, either, but if you take the time to learn the tricks - and account for spotty browser implementations - then you can develop attractive, robust and usable UIs using CSS. As for whether rich Ajax apps need layout, well, yes. But what kind of layout is open to considerable interpretation. Just because the first few generations of web designers kept trying to apply the same old print paradigms to the browser doesn't mean it was right. The same goes for the current wave Ajax frameworks and the desktop-app layout paradigms some of them attempt to implement.

The assertation that bothers me the most, though, is the one about the time it takes to get CSS working properly. As with any code executed in the browser, CSS is subject to the quirks and peccidillos of browser vendors, operating systems and ever-mutating standards. Still, once you account for the major differences in execution environment, it's not that hard to come up with a single global stylesheet that can zero out built-in styles and browser quirks to offers a more or less blank canvas for cross-browser CSS development. CSS authors may not release their design frameworks under open-source licences the way JavaScript authors do. But that doesn't mean they don't exist. Just peek under the hood at a big, forward-thinking consumer webapp or pick up a Jeffrey Zeldman book.

Regardless of what _I_ think, the thread at Ajaxian provides an interesting vox populi. As can be expected, comments range from wholehearted endorsements of Almaer's position to finger-wagging about the importance of web standards to chest-puffing from people who've mastered the tricky art of CSS layout and don't have much sympathy for those who haven't. I'm fascinated by the way participants in these conversations let their personal investment in a certain skill set lead them to make sweeping generalizations about entire swaths of the software-engineering world. Just because you know how to make a site look a certain way using tables, or floats, or XSLT, doesn't mean that that's the only way, or that the Internet won't eventually cough up a much better way than any of the above.

The fact is, any programming language or development framework can be improved, and there's lots to both love and hate about the CSS specs and the various imperfect implementations of them. It's _so_ far from the all-or-nothing proposition that many of the commentators would have you believe.

Dealing with client-side technology is frustrating for anybody who's used to having complete control over their execution environment, or a stable platform at all. The reason the pace of change is so glacial on the client side is that standards take time to develop; vendors take time to implement them; and a variety of market forces contribute to how well and how quickly they're implemented. Nobody said the Open Web was easy, but it's vastly preferable a host of closed-off, proprietary formats controlled by individual vendors and immune to grassroots innovation.

Any developer who's lived through successive generations of client-side technology knows that things have only gotten better with time. It's hard to imagine that standards won't continue to improve, no matter how painfully slow the process.