Archives

“IE6 is the new Netscape 4. The hacks needed to support IE6 are increasingly viewed as excess freight. Like Netscape 4 in 2000, IE6 is perceived to be holding back the web.”

~ Jeff Zeldman, standards guru

Anyone who has worked with developing the presentation layer for web apps has become quite adept at creating workarounds in JS and CSS to try and give the user the same experience in IE6 that they’d have if they used an up-to-date browser. However, because of IE6′s non-compliance with W3C Standards, a ridiculous amount of extra work (i.e., hacks) is needed in order to get the page to render correctly in this most outdated of browsers. And, as Dietrich mentioned in a previous post, the problem is that these deviations from the standard end up becoming the standard and increase the amount of time required to write and maintain code.

After my recent post on Prism, the Mozilla-based site-specific browsing tool, a commenter pointed me toward Fluid, Prism’s Webkit-based cousin. After giving it a test drive, I’m impressed. Although it lacks the cross-platform appeal of Prism, Fluid already offers a nicer user experience than the project that inspired it.

Fluid’s advantages:

• Better preferences: Fluid offers a far more polished UI, including preferences that help Fluid integrate with Apple’s Spaces multi-desktop environment.
• Tabbed browsing: You can set Fluid up to launch secondary windows in a new tab instead of a new window. This greatly enhances the user experience of webapps with lots of popup windows. It also allows users to more easily open multiple screens of an application at the same time.
• Browse any URL: Prism spawns any URL that’s not part of the associated webapp in your default browser. So does Fluid, at least by default. But by changing your preferences for any individual Fluid instance, you can enable browsing to other URLs within that Fluid instance. Want to click on an outside link in a Gmail message? Now it won’t take you out of context and into another application.
• Less wonky Dock behavior: In the current version of Prism, when you create a new site-specific instance, Prism restarts the Dock and launches the application. Even then, the icon for the newly created instance remains the default Prism icon until you quit and restart that instance. Only then does the icon you picked – the site’s favicon or any arbitrary image – show up in the Dock. With Fluid, upon creation of a new instance, you get a dialog that lets you choose whether to launch your webapp immediately. If you do, it’s got the correct icon from the get-go.

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

500

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.

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:

O’Reilly has booked me to speak at Web 2.0 Expo, which runs April 22-25, 2008 at San Francisco’s Moscone West convention center. I’m in the process of changing the session title, so ignore what it says on the website. The new title will be something along the lines of Do Try This at Home: Ajax Bookmarking, Cross-Site Scripting and Other Web 2.0 Browser Hacks.

Regardless of the slug, my talk will focus on how to push the latest and greatest browsers to their limits by peering under the hood and finding the quirks, bugs, hidden APIs and partially implemented draft specs you can use and abuse in your Ajax apps. My thesis is that instead of waiting for the Dojo or Prototype or Moo folks to exploit all the hidden goodies in today’s browsers, you can go on a hunting expedition yourself if you have the right tools. With Firefox 3 and IE8 on the horizon, now’s the time to start hacking.

Ajax history management will, of course, inform much of my talk, thanks to my stewardship of Really Simple History. But I’ll also delve into cross-site-scripting hacks, offline storage and other on-the-bubble technologies.

My talk is scheduled for the final time slot on the final day of the conference: 04/25/2008 at 3:50 p.m. (conference schedule here). Any Agile Ajax readers who are attending the conference and plan to stick around till the bitter end should come and check me out.

Unless you’ve been stuck under a rock for the last week, you’ve probably heard about the IE8 Beta 1 release. My colleague Brian will have a post or two next week to dig under the surface and tell you what IE8 means to Ajax developers.

Technorati Tags: ajax, ie8

I found four more bugs and two more feature requests to add to yesterday’s massive, minutiae-laden post about the Firefox 3 bookmarks manager:

Feature request: It would be awesome if you could sort your bookmarks by specific criteria, then make that sort order permanent. This would work exactly like the iTunes "Copy to playlist order" command. As in Firefox 2, you can approximate this by sorting your bookmarks alphabetically, moving them to a new folder, and moving them back. Then, even when you revert back to the "unsorted" view, the bookmarks stay in alphabetical order. Of course, this is way less necessary in Firefox 3, which can remember different sort orders for different bookmark folders, thus obviating the need to wrangle some folders into natural sort and others into alphabetical sort by brute force. Still, it’s a nice-to-have.

Feature request: The Views menu in the top toolbar should be broken out into separate Show and Sort menus. This is commonly accessed functionality, and it’s really annoying to have a two-item menu where each item contains around 10 sub-items which can only be accessed by clicking the menu, moving down, moving right, then moving down again to locate the desired item.

Bug: If you accidentally try to move an item to the same folder it’s
already in, it will simply disappear. Thank god for command-Z,
otherwise I would have accidentally deleted a folder with hundreds of
bookmarks.

The endless hand-wringing over browser version targeting in IE8 illustrates what’s wrong with the web standards community. For every sane, rational discussion about the practicalities of future-proofing the web, we get a couple knee-jerk anti-Microsoft screeds and at least one accusation that A List Apart – the standard-bearer of web standards – has somehow sold out by signing on to Redmond’s plan.

First, a little background: Howls of protest echoed across the ‘net a few weeks ago when Microsoft announced that Internet Explorer 8 would implement a new type of meta tag to enable both forward and backward compatibility in web pages. Once IE8 is out, users will be able to target rendering of their pages to a specific version of IE so that changes to the rendering engine of IE9 (or IE10 …) won’t subsequently "break" those pages. Basically, from IE8, onward, Explorer will include multiple rendering engines and display individual pages based on the browser version targeted by this new meta tag. The markup will look something like this:

<meta http-equiv="X-UA-Compatible" content="IE=8" />

I have no interest in debating whether or not it’s "semantic" and "standards compliant" to include the name and version number of a specific user-agent in my markup. That’s already been debated to death (on the 200,000+ pages Google currently reports for the keywords "IE8 meta tag"). What I want to know is this: Will Microsoft’s move make my job as a web developer easier or harder? At this point, the jury’s still out, but I think the answer is probably "easier."

History repeats itself, first as tragedy, second as farce. — Karl Marx

I can remember the day, back in 1994, when I abandoned the Mac for Windows. It was a gloomy, overcast day when I made that bittersweet decision — I was a Mac and Unix nerd all through college — but after my twelfth or thirteenth crash of the day, I had had enough. Photoshop, Netscape, Secure Shell and Word were just not meant to run more than one at a time on Mac OS 7. Had I stayed with Apple through that rough patch I’m sure I would have been slimmer, sexier and happier, but NT 3.51 only crashed twice a day, so my hand was forced. I  ran out and bought a PC that very day.

Now I fear history may be repeating itself. Yesterday, I had Firefox 2 for linux crash 5 times, and IE7 for XP crash 7 times. The cause? Too many fat Ajax applications. Zimbra, the whole Google bestiary of applications, Yahoo Mail, etc.. These are all long running applications that I keep open for most of the day. Then all of a sudden the Browser is gone and I have to relaunch and login all over again.

I’m not alone in this. Colleagues and friends report similar problems with Safari/Mac, IE7/Vista, Firefox/Mac. I’ve even checked with a friend that runs the helpdesk for a large firm: reported problems with browsers are up. The only one who seems blissfully unaffected is the lone Opera nerd in my office. He just keeps chugging along with what seem like 200 open tabs.

The cause should be evident to everyone. We’ve taken what was first called LiveScript — a crufty embedding just good enough to validate a form or two — and we’ve abused it into being the foundation for a whole new kind of application platform. The browsers have just not kept up and the situation will only get worse with the accelerated proliferation of Web 2.0 apps.

Help is on the way, in the form of bytecode interpreters and vm’s for Safari and Mozilla, though the future of IE is still cloudy (still, there is a plan to bring Tamarin to IE). But if the new Browser version don’t arrive quickly enough, or if they don’t fully solve the problem of browsers crashing once an hour, then a mass migration to Opera may be the best we can hope for. At worst, content and application producers will opt for more stable non-Ajax alternatives such as Flash or Silverlight.

Ajax and the browsers it depends on are running out of time. If the notion spreads that it isn’t reliable, it will be as dead as the Java Applet, never to be heard from again.

There’s never been a better time to be a JavaScript developer. JS hit the big time with the advent of Ajax, and overnight client-side programmers went from being the redheaded step-children of the web-development world to front-and-center participants in the RIA revolution. Even if you’re working on a team of one, there’s a thriving global community of JavaScript gurus constanly pushing the language forward, working out browser kinks, demonstrating how to import concepts from other languages and computing paradigms, and otherwise inspire you. It’s a big change from 10 years ago, when you had Webmonkey and the David Flanagan book and a few cookbook-style compendiums of tips and tricks. This is seriously the golden age.

Working for the last couple of months on Really Simple History, though, I’ve become interested in the way specific techniques become the flavor of the month and quickly redefine how we conceptualize "good" JavaScript coding practices. Take, for instance, DOMContentLoaded. After the first version came onto the scene, within a matter of months we had many competing implementations of the basic concept that your scripts shouldn’t have to wait for window.onload to fire before getting down to business. Now, DOMContentLoaded is the de facto start point for many, many JavaScript applications. Heck, it’s even the basis of the entire jQuery event model. There’s nothing wrong with that, but widespread use of Ajax toolkits can conceal the fact that DOMContentLoaded is just a collection of hacks. It works, as long as our toolkits keep iterating one step ahead of the browser vendors. But do we really need it?

At Orbitz Worldwide, my previous employer, we implemented a first-rate unobtrusive-JavaScript architecture. (See it in action at Ebookers UK.) Everything was progressively enhanced from dumb markup. That meant our application worked just about everywhere. But it also meant lots of DOM parsing and initialization that couldn’t begin until window.onload. As our application grew, this caused enough of a UI flicker – form controls turning into widgets, links morphing into Ajax calls – that we needed to jump the gun on window.onload if we wanted a good experience for the majority of users … the ones with modern, JS-capable browsers. DOMContentLoaded made sense, and architect Nik Krimm pounced on it.

But for a large subset of websites, there really isn’t THAT much difference between window.onload and DOMContentLoaded. If you’re merely adding an unobtrusive behavior layer to a traditional, content-driven website, chances are that good old window.onload will perform just fine. There’s usually little reason NOT to use DOMContentLoaded. But unless you are developing a desktop-style webapp or implementing progressive enhancement on a foundational level, it’s not really necessary. And in certain cases, it just flat-out won’t work.

An enthusiastic beta-tester discovered such a case when trying to initialize RSH’s dhtmlHistory object from DOMContentLoaded. It broke, and I immediately knew why: RSH relies on the ability of modern browsers to auto-save form data for the life of a session. RSH uses a hidden textarea to cache serialized Ajax application state and render the back button useful again. Internet Explorer doesn’t repopulate the cached value of that textarea until an instant after window.onload. If you try to access that cache during DOMContentLoaded, it simply isn’t there. This is true of both IE6 and IE7. Therefore, you need to wait for window.onload.

I’m not really sure there’s any big conclusion to draw from this example. As I said, it’s just interesting to me that in the space of a year or two, DOMContentLoaded has become a de facto standard. As we pile browser hacks on top of one another to push the web forward, sometimes they’re going to conflict. Luckily, we can always peek past the curtains and figure out what’s  going on behind the scenes.

• Ajax
• JavaScript