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.

Getting semantic and DRY with microformats and Radiant CMS

I can now cross Microformats off my list of "technologies whose value I recognize even though I've never had the chance to use them in real life." Last week I created three hcards for the new Pathfinder website, one each for our Chicago headquarters, our New York office, and our head of sales. Now, if you've got a browser plug-in that can parse microformats, you can import our contact information directly into Outlook, Apple's Address Book or your PIM of choice.

A little background

Microformats, for those who don't immerse themselves in grassroots front-end technologies, are at the core of what's become known as the "semantic web." The basic idea is that by adopting a set of standardized markup patterns, we can create websites that are more easily parsable by both humans and machines. More from the "About microformats" page:

Designed for humans first and machines second, microformats are a set of simple, open data formats built upon existing and widely adopted standards. Instead of throwing away what works today, microformats intend to solve simpler problems first by adapting to current behaviors and usage patterns (e.g. XHTML, blogging).

The most popular and best-known microformat is the hcard, an HTML implementation of the standard vCard format used to store and exchange address and personal information in a wide variety of software applications. If vCards are basically electronic business cards that can be imported to or exported from your contacts manager, then hcards provide the same functionality in the browser.

Keeping up with Firefox 3: Six more bookmark-manager gotchas

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.

Keeping up with Firefox 3: Improvements, bugs and missing features in the new bookmark manager

I'm a trigger-happy bookmarker, likely to command-D any page that seems like it could be of use in the future. I've learned to live with my affliction, but the Firefox 2 bookmark manager doesn't exactly make my life easier. The problem? An interface that mimics the look and feel of a filesystem but deviates substantially from users' expectations about how a filesystem operates.

With Firefox 3 now in its third beta release, I recently spent some time determining how its completely overhauled bookmark manager stacks up. The verdict? I see lots of cool new features, but it's not a home run yet. I'm not sure whether the issues I saw were bugs, as-yet-unimplemented features, or poor design choices. Regardless, the Firefox 3 Beta 3 bookmark manager leaves several Firefox 2 annoyances unfixed and creates a couple of its own.

Keeping up with Firefox 3: The agony and the ecstasy of full page-zoom

I've been playing with the page-zoom feature in Firefox 3 Beta 3. Thanks to the hard work of the Mozilla folks, Firefox is now the third major browser (behind Opera and IE7) to support this feature. (Safari, of course, supports page zoom on the iPhone but not yet on the desktop.) I don't know whether to be elated or annoyed.

A little background: For years, browsers have allowed users to scale the font-size of any web page using built-in browser controls. The text would get bigger, but other page elements wouldn't. Increasing your font size wouldn't affect the layout of the page at all. If sites weren't careful about how they built their CSS, absolute positioning and fixed-width elements would conflict with the zoomed-up font sizes. The result wold be pages where the main content was readable, but navigational and chrome elements looked grotesquely distorted or in some cases disappeared into the seams of the CSS (see photo below).

Ajax, Browsers, Running Out of Time

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.

Unofficial Firefox 3 Beta 1 release for Mac and Linux

Occasionally, in-between the latest iPod rumors and stupid top-10 lists from Cracked, Digg coughs up the good stuff. Case in point: today's post about Firefox 3 Beta 1. So far it's only available for Mac and Linux, and the download directory includes the following "IMPORTANT NOTE":

These files are not release versions, they are just potential release versions. Use them at your own risk, without any of the warnings that we will be putting in the release notes.

To be honest, if you're here from Digg or something similar, we'd really rather you waited until 3.0b1 was officially announced, so the servers don't get overloaded and we don't have a bunch of extra work to do.

Because I'm a bad citizen - and because I didn't see the note till afterward - I downloaded the beta and installed it on my Macbook Pro. All my extensions, of course, got disabled immediately. Still, I'm already impressed with the interface improvements. The Places concept looks promising. The bookmarks manager is VASTLY more useful and intuitive. And the download manager, though a little iffy on usability, has some cool new bells and whistles, especially the ability to interact with your downloaded files from within the manager itself.

Also, strangely, dropdowns and other form elements now have the native Mac OS look-and-feel: rounded corners and all that jazz. Is this is new feature, or just something that was always there but hidden by my extensions?

Technorati Tags

• Firefox

More on Safari and the new Gmail upgrade

Over the weekend my Gmail finally got upgraded to the new version. (I know, I know, a week is hardly a long time to wait for a slow-rollout Google feature. But I'm impatient.) I have to say, the history and back-button support is AWESOME. It's funny that Gmail warns you in a huge red banner to disable Firebug. I, of course, kept it enabled and immediately began digging through the DOM of the new UI. As usual, most of the JavaScript is so obfusticated that it's hard to tell what's going on. Still, it's interesting to dig through layers and layers of iframes and nested divs and see how much DOM hackery is involved. Looking behind the scenes at any commercial-grade webapp is like taking a tour of a sausage factory.

Luckily, I have a strong stomach. I'm going to make it a weekend project to really dig in and learn how they're handling their history support. In a previous post, I wondered why the new Gmail is only available for Firefox 2 and Internet Explorer 7. Given my own experiences with Safari's history object, I shouldn't be surprised. With bookmarkable URLs and history management so central to the new Gmail UI, no wonder Safari has been left in the cold; it's simply too buggy in this regard to receive A-grade support. Safari users have been complaining to Google that it should fix Gmail for Safari even with the old UI. I think those complaints should be lodged at Apple, not Google.

P.S. Sure enough, leave Firebug open in Gmail for any length of time and your Firefox will slow to a crawl. My FF has been crashing a bunch this week, but I'm not sure whether it's Gmail or Firefox's own latest updates. Commenters, am I the only one seeing this?

• Gmail
• Google
• Safari
• Firebug

Songbird 0.3: Why aren't Ajax folks more geeked about "the Firefox of media players"?

Songbird, the open-source, Mozilla-based media player, received its 0.3 "developer pre-release" on Oct. 30. The UI hasn't changed much since the 0.2.5 "developer preview," but things continue to evolve under the hood. Better yet, the documentation and demos keep getting better. Check out the developer center for information about using XUL to build add-ons or using the JavaScript API to integrate your webapp with Songbird's media player.

If you've yet to experience Songbird, a little background is in order. The project is run by Pioneers of the Inevitable, a Bay Area company founded by veterans of Winamp and the Yahoo! Music Engine. Building on Mozilla's XULRunner platform and the VLC media player, Songbird aims to unite a web browser, a media jukebox and an online media player into a skinnable, extensible, open-source application. At this stage, the app is a long way from challenging the likes of Windows Media Player, let alone iTunes. But as it grows, it promises to cultivate the same kind of fervent user and developer communities as Firefox, Thunderbird and other Mozilla projects.

I first became aware of Songbird via a Boing Boing post. I'm surprised it hasn't generated more noise in the various Ajax feeds and news sources. With all the excitement about specialized browsers and desktop webapps, from Mozilla Prism to Google Gears and Adobe AIR, it seems like Songbird would be earning a lot of buzz. Maybe I'm just not hanging out at the right water coolers.

As an Ajax developer and huge music nerd, I'm looking forward to playing with the JavaScript API. It promises seamless integration between webapps running in the Songbird browser and the media player itself. Imagine iTunes, but instead of a built-in browser that only supports the iTunes store, you've got a Firefox clone that plays well with music vendors, P2P networks, MP3 blogs and any other internet music resource. Visit a music mag, for instance, and see all of its featured downloads automatically show up as a playlist in the media player (as in the Hype Machine example above). Visit an online music store and experience an iTunes-esque purchase experience. Indie-music brands such as eMusic and the aforementioned Hype Machine have already gotten on board. To see Songbird's API in action, compare these sites in Firefox and Songbird.

Songbird's add-on ecosystem is cool, too, especially for long-time Firefox developers. They can adapt existing add-ons with just a few tweaks. (GreaseMonkey, for instance, has already been ported.) But Songbird's API allows for more radical innovation than Firefox's add-ons. Instead of simply adding context menus and pop-up dialogues, you can rewire the entire UI of the media player. One example on the developer site shows how to replace the single play/pause button with individual play, pause and stop buttons. That's a trivial example, but a telling one.

I'm already salivating about the cool stuff I'll be able to do with add-ons:

Tag-parsing madness

Imagine Doug's AppleScripts for iTunes ported to XUL. Like a lot of people, I'm obsessive about my meta tags, and I can't wait to use JavaScript regexes to bend them to my will en masse. I'm also hoping that Songbird will record all of its meta data in the music files themselves instead of socking some of it away in the music library. With iTunes, if you decide to rebuild your library in another player - or even in a different iTunes installation - you lose things like star ratings and play counts. It's a real bummer.

Huge libraries

The flat XML database in iTunes scales horribly. Get above about 100 gigs of music and performance slows to a crawl. This problem has only gotten worse with the bloat of Cover Flow, Quicktime integration and all the other features I don't need. I have 450 gigs, most of it ripped from my huge CD collection, and I've had to separate it into four separate libraries (using Libra) just to get decent performance. That sort of defeats the whole "any song at any time" promise of the MP3 era. Enter SQL Lite, which is how Songbird stores its own media library. I've got high hopes that a relational-database back end coupled with open-source how-to will make Songbird the media player of choice for folks with enormous libraries.

Interface freedom

iTunes and its Smart Playlists are all about endless, automated mixes. But I'm an old-school mix-tape guy. At the end of each year, all of my friends usually get a four-CD retrospective of the year's best tracks as compiled by me. But with iTunes, it's excruciating to build a "source" list of possible tracks for these multi-disc epics, then slot the tracks into individual discs and experiment with sequence. You can only view one playlist at a time, so every time you decide to move a track from one playlist to another, it's a multi-step operation. Imagine an interface where I could see my "source" list and all of my target lists at once, and where drag-and-drop defaulted to a "move" operation rather than a "copy" operation. With XUL and JavaScript, I'll be able to build any specialized interface I want and swap it in for Songbird's default UI.

Sure, most of my needs are pretty specialized, but I hardly think they're unique. And that's the point of an extensible, open-source player. You're free to build the features YOU want to see and share them with others like you. That's a lot more productive than griping over at the iLounge forums about iTunes's shortcomings.

I know Songbird isn't the only open-source, component-based music player out there, but it is the only one that's drawing on the power of the Mozilla Foundation. Firefox has shown how disruptive the Mozilla community can be in the browser market, which, like the music-player market, is dominated by a single product. Songbird may not topple iTunes any sooner than Firefox topples IE, but it should provide a powerful alternative and perhaps put some competitive pressure on the folks in Cupertino. It was extremely shrewd of Pioneers of the Inevitable to hitch their wagon to Mozilla's. I'm definitely going along for the ride.

Songbird links

• Songbird site
• Songbird Blog: post on the 0.3 release
• Songbird Wiki
• Wikipedia entry
• Technorati tag

Songbird posts

• Boing Boing interview with Songbird architect Rob Lord
• Ars Technica
• C|Net
• Internetnews.com
• Alpha's Place
• Blog of the Vicious Beast
• Views of a Discerning Critic
• Current_
• Hardware Beyond the Hype

Technorati Tags

• Songbird
• iTunes
• Mozilla
• Firefox
• XUL
• JavaScript

Coming soon: Really Simple History 0.6 beta

Late tonight over at Google Code, I'll be posting a beta of Really Simple History 0.6 for testing. The goal is to elicit help from RSH users in chasing down any bugs I've failed to catch, then push out a stable release around Halloween.

I've tried to be as ambitious as possible with this release: full support of IE7/Win, Safari/Win, Safari/Mac, Opera/Win, Opera/Mac. I've didn't quite get there, but I got close.

Features in the new version include:

• Full support for IE7/Windows (though my only Windows machines use IE7 Standalone, so I need help testing on "real" IE7 installs).
• Full support for Safari 2/Mac (though I'm still trying to eliminate the "infinite loading" bug before I push out the beta).
• Partial support for Safari 3/Windows (hampered by bugs in the current beta version of the browser).
• Full support for cross-platform Opera 9.22 (though you may need to hard-code an image into your markup).
• A totally revamped test page that allows you to play with the library in your browser of choice and see how it works behind the scenes.

As always, RSH works beautifully in Firefox 2 for Windows and the Mac. I hope to give it a good shakedown on Linux browsers in the next release.

So what is Really Simple History, and why am I updating it?

An Ajax bookmarking and history-management framework originally developed by Brad Neuberg, RSH became my responsibility a little over a month ago. I tinkered with it for a few weeks, then finally camped out with it for most of the past week to get a release out.

This is the first time I've ever contributed in this manner to an open-source project. It's been a lot of fun, but it's also been maddening, as anybody who's ever dug into the bowels of cross-browser history management can tell you. Here's a sampling of what I've learned from RSH:

Safari is crazy

Plenty of people who've worked on Ajax bookmarking projects have commented about this, but it only becomes clear once you've actually seen it in action. Getting this thing to work in Safari 2 for the Mac took a wildly disproportionate amount of time considering its market share. I wouldn't have been able to do it without Bertrand Le Roy over at Microsoft, whose blog entry on the development of the .Net history manager pointed the way for both Safari and Opera.

As Le Roy and others have noted, the Safari 3 Windows beta is so buggy that history management is hopeless. You can enable the back button for Ajax apps, but once you use it, the forward button becomes disabled. I noticed yet another wrinkle in this behavior (skip ahead if you're easily bored):

Navigate to a non-RSH site - Google, for instance. Then travel to an RSH site, create some history entries via RSH, and use your back button. The forward button stops working: a known bug. Now keep hitting back until you get back to Google again. Suddenly, your forward button works again. Hit forward and land back in your RSH app. Magically, the forward button continues to work.

If I hadn't spent so much of the last week lost in Safari-land, this interesting behavior might be worth further investigation. For now, I'm just hoping the Safari 3 team fixes this before the final Windows release.

Don't try to retire document.write just yet

A couple of different RSH users suggested getting rid of Brad's original calls to document.write in favor of standard DOM methods for adding elements to your page. That approach worked for some elements, but not for others.

In IE, RSH writes a hidden iframe into the document and uses the location and history of that iframe to help it track application state. Writing the iframe with document.createElement works just great.

But for all browsers, RSH uses a hidden textarea to store the entire history stack behind the scenes. This powers one of RSH's coolest features: its ability to retain history even if you navigate away to another site and then come back to your RSH application. This works because modern browsers retain form-field values throughout an entire browser session. But they do so only for form fields that exist in the DOM natively - that is, exist in the actual HTML markup or get inserted via document.write get inserted into the DOM before it's finished loading. 

If you create a form element after your DOM is already loaded, the browser has no way to persist values in that element after you leave the page. Each time the page loads, even from the cache, you essentially create a virgin new form field. I'm therefore using document.write for the hidden textarea - and for the hidden form field I've added to RSH for Safari support.

UPDATE: As it turns out, it's immaterial whether you use DOM methods or document.write. The important thing is to use either method before onload fires. I ended up using document.write in the 0.6 beta because of SSH concerns and the fact that it's so much more concise. For more on this topic, see this subsequent post. 

Because of the way RSH is structured, these elements actually get written to the head rather than the body of your document. Still, it works, and it should only offend the most anal-retentive of standards geeks. After all, if you're hacking the browser 10 different ways from Sunday just to enable Ajax bookmarking, then inserting a bit of non-validating markup via JavaScript is hardly the worst of your sins.

RSH won't be hitching its wagon to [insert name of your favorite framework here]

A few users suggested rewriting RSH in Prototype so it would be more compact. I appreciate the impulse, but I think that defeats one of RSH's chief virtues: the fact that it's written in Plain Old JavaScript and doesn't lock you into any specific Ajax framework. It plays well with any library you want it to: Prototype, jQuery, YUI, whatever. (If it doesn't, please file a bug so I can find out why.)

A little JSON never hurt anyone

The one library that RSH does require is a JSON parser; it ships with the latest open-source version. RSH 0.4 included an earlier version of the parser in the same file as its native code; I've broken it into a separate file under the logic that many users will already be serving a similar library. RSH's methods don't actually call toJSONString or parseJSON directly; instead, I've provided bridges so that you can hack in your own JSON methods without having to modify the guts of RSH itself.

Future roadmap

I've got quite a punch list for the next release:

• Provide minified versions of RSH and JSON for download
• Make use of Crockford's module pattern for better encapsulation
• Add official support for Linux browsers, Safari 3/Mac and Safari 3/Win

That's the future. For now, I have to get 0.6 packaged up and ready for testing. Check Google Code late this evening or first thing tomorrow.

Technorati Tags

• ajax
• javascript
• bookmarking
• Really Simple History

Mash Note: Foxmarks bookmark synchronizer

All bookmark sync utilities are not created equal. Plenty of browser add-ons promise to keep your favorites in sync across computers, while Del.icio.us and its ilk host your links up in the cloud. For my money, though, if you're a Firefox user with a serious bookmark habit, nothing beats the free browser extension Foxmarks.

I'm the first to admit that I've got a problem with my bookmarks - all 3,000 of them (and counting). I do tons of research for this site and my other writing gigs. When I come across something useful, I hit Command-D automatically. (I'm just as bad with clippings in my RSS reader.) Every once in a while, I do a clean sweep: reading, filing, purging. But until I've extracted whatever piece of knowledge I need from a particular link, I want access to it from all of my workstations and Internet devices.

That's where Foxmarks comes in. When you set up an account and install this free Firefox extension on multiple computers, it keeps the bookmarks in sync across machines and backs them up to the Foxmarks server. When you bookmark something at home, then want to refer back to it the next day at the office, you're golden. And when you're away from your own workstations - say, in an internet cafe or on a mobile device - you can hit My Foxmarks, the webapp version of the service.

The Foxmarks browser add-on gives you some fairly coarse-grained control over how and when syncing occurs. If you set your preferences to sync manually, or only on shutdown, you may get stuck answering a series of dialogs as the server parses your changes. My recommendation: Enable automatic synchronization in the background. In earlier versions of the service, the sync dialogue would hijack your browser and hog your CPU, especially if you were digging around the browser's "Organize Bookmarks" screen. Such performance problems have now been reduced, if not eliminated.

As for My Foxmarks, it, too, has improved over time. The current interface uses the YUI and Ext libraries for a seamless, desktop-like Ajax experience. The UI offers both a folder-tree view and a paged grid view; you can access individual bookmarks' details from either view. There's even an iframed preview pane that can show you the target of a bookmark without leaving the Foxmarks site. And, of course, there's a scaled-down mobile version. All in all, it's a slick, well-designed experience.

Of course, there's always room for improvement. I find the built-in Firefox bookmark manager cumbersome, buggy and annoying. I'd love to see the Foxmarks team position My Foxmarks as a powerful, intuitive web-based replacement. To get there, they'd probably need to add inline editing, a more customizable interface, and perhaps integrated tagging. A trash bin for deleted bookmarks would also be pretty cool, as would the ability to batch-delete bookmarks without constant confirmation dialogs. Most browsers' internal bookmark managers - and most social bookmarking services - don't offer a very efficient or useful UI. It would be great to see somebody get it right.

I have no idea whether such features are in the cards, but Foxmarks's developers aren't resting on their laurels. Just yesterday, they announced a beta of Foxmarks 2.0, which promises to offer:

• Major changes on the server side, including much more efficient syncing.
• A nice tweak to the syncing process so that it preserves favicons across computers.

Pretty sweet!

Technorati Tags

• Firefox
• bookmarks
• Foxmarks
• YUI
• Ext

Really Simple History: Onwards and upwards

I'm excited to announce that I've heard the call and volunteered to tackle maintenance and stewardship of Really Simple History, Brad Neuberg's intuitive, lightweight Ajax history library. Brad developed RSH a couple of years ago, drawing inspiration from the Dojo Toolkit folks to deliver a standalone library that provides back-button and bookmarking support for Ajax apps in IE6 and various Gecko-based browsers. Since, then, many additional Ajax frameworks have implemented back-button and bookmark support, some of them drawing on Brad's work.

Meanwhile, Brad's been too busy with other projects to upgrade RSH for a variety of new and existing browsers: IE7, Opera, Safari/Mac and Safari/Windows. I asked Brad to let me take care of his baby for several reasons. For one thing, I've been an enthusiastic user of the library. For another, I've been wanting to get involved on a more formal basis with open-source JavaScript projects. But most of all, I believe RSH remains a great tool for folks who want a solution to the Ajax history issue without the overhead of a larger Ajax framework.

I'm currently working with Brad to migrate RSH to Google Code, get acquainted with the bug base, and start tackling the thorny issues surrounding Ajax history support in the 2007 browser landscape. I look forward to shamelessly pilfering the many fine solutions uncovered by a large community of developers since Brad's initial work. (Brad was kind enough to point me to this blog post from Bertrand Le Roy, which lays out many of the aforementioned fine solutions and thorny issues.)

In the meantime, I'd love to hear from RSH users about their hopes for the future of the framework. Comments, please, or ping me directly at bdillard (at) pathf.com. Thanks!

IBM's CoScripter: Greasemonkey for non-geeks

Think of all those annoying step-by-step processes you must learn and memorize to go about your daily online business: logging onto your bank site to check the balance on your savings account; filling out a tedious form; ordering prints of your digital photos. The elements of the UI are easy to understand, but the process itself differs wildly from site to site.

Now imagine a Greasemonkey-esque add-on that not only automates those processes, but shares the automations with everyone else. All you have to do is write the instructions in plain English, let your browser record the steps in real time, or search the existing archive for somebody else's previously recorded automation. Sold yet? Good, then meet CoScripter, a new Firefox add-on from IBM.

Alex Faaborg over at Mozilla Labs sums up CoScripter thusly:

What do you get when you mix one part automation, one part natural language interpretation, two parts programming by demonstration, and three parts online collaboration? If you stir all of these research areas together and toss in some XUL, you get one of the most innovative extensions for Firefox: CoScripter.

Jon Udell has kicked off a pretty interesting discussion of CoScripter as a mash-up of social networking and domain-specific languages. But I'm most excited about the technology for its grassroots potential. Like microformats, CoScripter has the potential to evolve into an "accidental standard" that proves the enduring power of the Open Web. I can foresee a future in which site owners coach newbies about their interfaces by releasing CoScripts instead of publishing big chunks of step-by-step instructional text. Of course, the technology's future ecosystem depends on how IBM licenses it. One less-than-promising sign: the onerous registration process and EULA I had to endure before downloading the add-on.

Nevertheless, as of this writing, 190 CoScripts have been submitted. Lots of them seem fairly limited in scope, but I'm sure that will change as the community grows and the technology matures. The add-on's handy Sidebar interface displays the "editor's picks" for most useful scripts. I'm particularly fond of Add your phone number to the national do not call list.

I wrote two of those 190 scripts myself, and my experiences highlight the strengths and weaknesses of CoScripter as it's currently implemented.

First off, I tried to automate the process of logging into popular blogging engine Vox and starting a post. The tutorials helped me figure out how to parameterize private data such as email addresses and passwords into a locally stored "personal database." That way, I can write scripts that work for me, then share them with anybody who sets up similar key/value pairs in their datastore.

The plugin did a pretty good job of recording my steps as I interacted with the browser. (Users of the open-source Selenium QA framework will feel right at home.) But the recording engine totally ignored my interactions with Vox's password field. Even after I manually scripted this step - in CoScripter's eminently simple natural-language syntax - I couldn't get the sequence to work. Still, I've saved it (Login to Vox and Compose Post) in the shared repository. Perhaps a smarter Vox user than me could get it running? Here's the source code:

              

• go to "http://www.vox.com/"
• enter your "vox login" into the "Member sign in"'s "Email:" textbox
• enter your "vox password" into the "Member sign in"'s "Password:" field
• click the "Sign In" link
• click the "Compose Post" link

          

Next, I tackled something much simpler: Read La Dolce Musto. I love this Village Voice column, but I always have to hunt for it on the busy homepage of NYC's alternative weekly. There's no landing page for columnist Michael Musto, and the site's layout changes weekly. My simple, two-step script hits the homepage and activates the first instance of the writer's name as a link. It worked for this week's issue, but I'll have to wait till next Wednesday to make sure it doesn't bomb out once the homepage rolls over.

Again, the source code:

              

• go to "http://www.villagevoice.com/"
• click the "Michael Musto" link

          

Given how difficult I found it to get a moderately complex script working, and how trivial my actual working example is, I can't say that CoScripter is going to set the world on fire immediately. Password fields seem to be a problem, and there's no ability to use conditional structures. I'd love, for instance, to be able to write a script that goes to Vox, logs me in only if I'm not already authenticated, then begins a post. It would also be great if I could build in timers, such as "wait x seconds," so that Ajax interactions or other slow-moving changes in state could be accommodated. I mentioned Selenium before, and its powerful syntax for writing test scripts seems like a model for future development. If CoScripter's engineers can expand the power of their DSL without losing its simplicity and ease of use, this add-on seems likely to earn a wide and enthusiastic user base.

[Thanks to the awesome Lamda the Ultimate for the original tip.]

IE6: The zombie browser

Paul Graham's much-dissected essay Microsoft is Dead offers some witty and perceptive analysis, but it sidesteps the fact that Microsoft's rotten corpse will take decades to decompose. In the meantime, we still live in a world where most people trawl the Internet with a Microsoft browser. I've already linked to Kevin Hale's perceptive essay On the Tenacity of Internet Explorer 6, and I've already covered Eric Meyer's useful techniques for taking advantage of IE7's power while continuing to support IE6. But I've got a few more links to add to Dietrich's and my back-and-forth about the state of JavaScript tooling. I regularly stop by the IEBlog the same way I keep tabs on the neighbors I don't really like but have to live near. They recently added a more in-depth post about Ajax View, a pretty cool profiler that they'd previously covered along with other IE development tools earlier this summer. In a previous post, I surmised that most front-end developers code for Firefox first, then put off their Safari/Explorer testing till the end. Maybe if IE tooling continues to mature, we'll see less of that.

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.

The awesome state of JavaScript development tools

Dietrich's post on the depressing state of IE develpment tools got me to thinking about the generally wonderful state of JavaScript tooling. Compared to just a few short years ago, we've got a wealth of productivity-enhancing browser add-ons, TDD frameworks and static-analysis tools at our disposal - most of them open-source. For those who want to get their hands dirty writing POJ, this is a golden era.

Like most developers, my code circa 1998 was filled with commented-out alert() statements. I spent way too many hours cursing IE4's inability to report accurate line numbers in its error dialogs. I relied heavily on Netscape's built-in debugger. Within a couple of years I had graduated to a primitive logging utility that spawned a separate browser window and output messages into it using simple DHTML. At the time, it seemed like a huge advance.

Then came the Firefox era, with its host of disparate add-ons. You could edit your CSS in the sidebar, selectively disable JavaScript and CSS, inspect the DOM .... Once again, the possibilities seemed endless. Now, thanks to Firebug, most of my grab-bag of browser add-ons are gone. Firebug is so powerful and wide-ranging that the only other add-on I use regularly is the venerable Web Developer Toolbar. Yahoo's new Firebug extension YSlow adds some really useful optimization benchmarks to the suite. When a plug-in begins to spawn its own plug-ins, you know you've got a winner.

I'd be interested to know, though, what kind of process UI developers use to debug their JavaScript. Most of us are using similar tools, but how are we using them? (That's an invitation to jump in on the comments, folks.) Every UI person I know develops prototypes in Firefox and Firebug, crossing his or her fingers that there won't be too many implementation-specific issues to tackle in the other browsers. Many rely on a logging utility - heir to that long-ago popup window - to grind away at any such browser bugs.

But beyond that kind of hunt-and-peck debugging, have we arrived at an industry-standard practice for client-side code maintenance? Who's doing true TDD with one of the flavors of JsUnit? Who's using Selenium to test their entire webapp in the browser? Who's picking apart the details of their syntax with Douglas Crockford's JsLint? Who's busting out Fangs or another accessibility test tool on a regular basis? The tools are out there. It would be interesting to know who's using them, and how.

When you're banging your head against a wall trying to figure out why a certain DOM element won't return the same node type from one browser to the next, it's easy to see why there are a hundred competing Ajax frameworks promising to solve all your cross-browser issues for you. Let's just remember how far we've come - and how important it is for real-deal UI developers to maintain the skills that they've honed for over a decade. The more trust we put in frameworks, the more helpless we'll feel when our code fails and we've lost the ability to figure out why.

Some Thoughts on Silverlight

I'm not going to dig into the how and why of Silverlight, or write an inflamatory article bashing Microsoft. What I do want to set down are some simple observations on Silverlight. All of us who design RIA's need to keep an eye on emerging technologies, especially if they're backed by the market clout of MS.

So, what is Silverlight, and why should you care? It's has been described as Microsoft's Flash, but that misses the point just a bit. First, from the MS marketing droids:

Microsoft Silverlight is a cross-browser, cross-platform plug-in for delivering the next generation of .NET based media experiences and rich interactive applications for the Web. Silverlight offers a flexible programming model that supports AJAX, VB, C#, Python, and Ruby, and integrates with existing Web applications.

Lovely. Cross-browser and cross-platform (Windows and Mac). File that away for future reference. For a better explanation, we can go to a report from Mix 07 from Miguel de Icaza (a mono project contributor):

Silverlight 1.0 uses a retained graphics system (a canvas) that exposes the internal structure to the browser DOM. It has no scripting capabilities built into it, all the scripting support is actually done by the Javascript interpreter in the browser and all changes are done by talking to a Javascript object exposed by the hosted Silverlight surface.

The scene definition is done using the XAML markup using a subset of the WPF primitives available in the full-blown WPF. Then the big announcement came:

The second edition was Silverlight 1.1, and this one is a different beast altogether. 1.1 extends the model by embedding a complete Common Language Runtime.

That's right, the dreaded CLR ;-), the JVM of the .NET world, in your browser. The CLR, of course, is supposed to support many different languages, and so VB, C#, Ruby, Python, Javascript, etc., etc., are all supposed to be supported eventually in Silverlight. With the Dynamic Language Runtime (DLR), scripts can even be embedded in the page and compiled at runtime. In venture capital there is a saying that "too soon is the same thing as wrong"; let us all shed a tear as Java applets are carted off to the dumpster. :-(

There's lots more research to do on this, but I have neglected the second question: why should you care? The obvious answer is that Silverlight doesn't just compete with Flash, but also with Ajax. Silverlight also seems to have more hooks into the browser (definitely some security research needs to be done there), so it is possible that it can be more of a complement to Ajax than Flash has been.

But looking beyond the next 12 months, it is clear that Silverlight will be part of MS's solution for Desktop RIA's, i.e. the emerging online/offline application space represented by Apollo/AIR, Google Gears, Firefox 3 (with it's embedded RDBMS), etc. Another thing that becomes clear is that language support and performance are likely to become more important, i.e. we need to be able to develop in more than just Javascript/ActionScript for the browser and Flash. And the performance of those browser runtimes needs to improve drastically to support the large and sophisticated client-side (ooh, the return of the fat client) apps that are likely to be developed.

GWT addresses some of those issues, as does the commercial product from Morfik. For performance, the inclusion of the Tamarin VM (kindly donated by Adobe) in future versions of Firefox will address some of the performance issues, but at the end of the day that is less than half the equation. If MS doesn't improve IE (where's the announcements about IE8?), Ajax apps will still perform like crap on over half of all browsers.

Last idea for the moment on Silverlight. Will OpenLaszlo target their framework to compile for Silverlight? Since they are the one group that actually targets their framework at more than one runtime (Ajax and Flash), they are well positioned to do the same for Silverlight. Stay tuned.




Technorati Tags: ajax, flash, silverlight, openlaszlo, mono

Alert: Security Update for Firebug

Joe Hewitt has released a security update to his excellent FireBug Firefox addon.

About an hour ago I received word of a 0-day security exploit that has been discovered and reported. I have just released a new Firebug (version 1.03) with a fix for this bug, and I recommend that everyone install it as soon as possible.

The update has been published to addons.mozilla.org, so you can get it by updating Firebug from the Firefox Add-ons window. Alternatively, you can install the update using the big orange button on the getfirebug.com home page.

Technorati : firebug, firefox, security, software update

2007 Predictions Coming True? - The Coming Browser Revolution

At the beginning of the year, I made a few predictions about Ajax in 2007. In particular, I predicted that

Microsoft and Mozilla will add new features to their browsers to extend Ajax support. These features will address things like cross site scripting (making it easier and more secure), security, widgets standards support, extensions of Javascript, etc. The browser will evolve into more of an application platform than it is now.

That doesn't really seem to be happening, from what I can tell, since Firefox 4 won't be available until 2008, and Firefox 3 is making only modest changes on the Ajax front. It's too soon to say anything about IE8.

InfoWorld has a breathless article about the revolutionary changes coming in Firefox 3. A careful reading of the article, however, shows that most of the really interesting changes are planned for Firefox 4, such as support for Javascript 2.

You can read the detailed feature list for Firefox 3 here, in the form of a Google Spreadsheet. It doesn't look like either of the two features -- web services as Mime-type handlers and SQL Lite for offline storage -- are in Alpha 2, but hopefully they'll show up in the next release.

What these two new features might look like isn't exactly clear from the planning documents, but they should take their direction from section 5 of the WhatWG specification on Web Applications 1.0.

The registerProtocolHandler() method allows Web sites to register themselves as possible handlers for particular protocols. For example, an online fax service could register itself as a handler of the fax: protocol ([RFC2806]), so that if the user clicks on such a link, he is given the opportunity to use that Web site. Analogously, the registerContentHandler() method allows Web sites to register themselves as possible handlers for content in a particular MIME type. For example, the same online fax service could register itself as a handler for image/g3fax files ([RFC1494]), so that if the user has no native application capable of handling G3 Facsimile byte streams, his Web browser can instead suggest he use that site to view the image.

At the simplest level, when a particular Mime type is encountered, a web application will be launched, instead of the usual desktop application. The feature list, however, states that Firefox 3 will Support web services as MIME type handlers. That sounds a little bit different from what the WhatWG spec provides.

All Ajax-enabled web developers should take an interest in browser standards and developments. The future of their profession depends upon it.

Technorati : ajax, firefox 3, sql lite, web services, whatwg

How to REALLY do Page Preview in Java with Embedded HTML Rendering

Note: the screenshots in the post are all generated by the JRex solution, not print screen.

So I had a reader call me out -- correctly -- that a HOWTO article should really contain some code, not just pointers and handwaving on how things might be done. So I've decided to make amends by following through on my article from two weeks ago on how to do page preview. Here are my experiences, some code, and -- once I've cleaned up the code -- a zip file so you can try your own hand at embedded HTML rendering.

So I tried each of the HTML renderers from my article in turn. The results were less than promising.

1. Flying Saucer: forget it. This thing barfs on anything but the most basic HTML. Putting Tidy or TagSoup in front of it didn't help matters much.
2. Cobra HTML Toolkit: slightly better. I could get www.google.com to render, but that was about it. Real world Javascript, CSS and XHTML all caused this puppy to tuck its tail and run for home.
3. JRex: since it's based on Mozilla, it actually does work and renders just about any page. But getting it to work is anything but easy. The end result I achieved gets me what I want -- images of rendered pages -- but there are some things about the solution that may make it unreliable and hard to scale.

The rest of this post is about my experiences with JRex. A few preliminaries: first, I developed and deployed this solution on Windows (XP and Advanced Server). It should be possible to do so on Linux (JRex runs there same there as on Windows). Next, the code is a bit of a hack. This was definitely a keep-hacking-until-it-works kind of effort. My hope is that someone else can come along and take this to the next level.

Hello World with JRex

The documentation for JRex leaves something to be desired, so the first challenge is installing the thing and getting it to run. I went with the binary download of JRex 1.0b1_dom3 from September 8th, 2005. You need the binary WithOutLog download and the jrex_gre dowload. Unzip the zip file into C:/jrex, then unjar the second download to a scratch directory. In the unjared material, find the file org\mozilla\jrex\jrex_gre.zip. Unzip this to C:/jrex/jrex_gre. Finally, move the file jrex.dll from C:/jrex to C:/jrex/jrex_gre.

Now we are ready to write a little "Hello World!" program, just to test if everything is working. The following is a minimal program that launches a browser window:

package test;

import org.mozilla.jrex.JRexFactory;
import org.mozilla.jrex.ui.JRexCanvas;
import org.mozilla.jrex.window.JRexWindowManager;
import javax.swing.*;

public class JRexTest {
    public static void main(String[] args) {
        try {
            JRexFactory.getInstance().startEngine();
        } catch (Exception e) {
            System.err.println("Unable to start up JRex Engine.");
            e.printStackTrace();
            System.exit(1);
        }
        JRexWindowManager winManager=(JRexWindowManager)
                JRexFactory.getInstance().getImplInstance(JRexFactory.WINDOW_MANAGER);
        winManager.create(JRexWindowManager.SINGLE_WINDOW_MODE);
        JPanel inner = new JPanel();
        JFrame frame = new JFrame();
        frame.getContentPane().add(inner);
        winManager.init(inner);
        frame.setSize(640, 480);
        frame.setVisible(true);
    }
}

Compile and then run with a JRE (otherwise under certain circumstances JRex may not link to the awt DLL):

      C:\Java\jdk1.5.0_08\jre\bin\java.exe -Djrex.gre.path=C:/jrex/jrex_gre text.JRexTest

Once we've come this far we're ready to move to the web side of things.

Preview Webapp

I decided to build a webapp that produces PNG image screenshots. My first thought was to simply build a servlet and use the headless trick to grab the output of the JRex components. There are a couple of issues that complicate matters, however:

1. JRex just won't run in headless mode. You have to have a display. On Linux you could use VNC.
2. With the complication of classloaders, etc., JRex won't run easily or cleanly in Tomcat, Jetty, etc. Therefore I decided to use a simple embedded web server. This of course has its downsides, as a good servlet container provides you with a number of advantages.
3. JRex is not a pure HTML renderer -- it is an application, that pops up dialogs, responds to user events, etc. There may be a way to just use it as renderer, but that documentation thing gets in the way again. As it is now, there is no way to tell whether the rendering was successful or whether the JRex component is stuck with a modal dialog telling the nonexistent user that the server was not responding.
4. JRex is not a real Swing/AWT component. You can't use a Graphics object to paint it to an offscreen image; all you will get is a blank page. We need to capture the part of the screen that corresponds to the browser window. That means that the browser window needs to be on top and of the size you want to image. It also means we need one display per preview server if we want to scale. (On Linux you could scale with multiple servers and multiple X displays such as VNC.)
5. We can only handle one request at a time per preview server as we only have one screen.

To solve the problem of the application server, I used the dead simple embedded web server NanoHTTPD. If you need something dead simple, this is a handy way to go.

On to the actual image creation. Our web page will be in a JFrame on the display. We need a way to capture that JFrame to an image. We do this in SwingImageCreator using screen capture:

   public static BufferedImage snapShot(Rectangle rect) throws AWTException {
      return new Robot().createScreenCapture(rect);
   }

   public static BufferedImage snapShot(JFrame frame) throws AWTException {
      Point pt = frame.getLocation();
      return snapShot(new Rectangle(pt.x, pt.y, frame.getWidth()+pt.x, frame.getHeight() + pt.y));
   }

The screen capture requires that our frame be on top. We do this in the PageRendererImpl class by calling frame.setAlwaysOnTop(true):

    public synchronized BufferedImage renderPage(String url) {
        try {
            createBrowser();
            navigation.loadURI(url, WebNavigationConstants.LOAD_FLAGS_NONE, null, null, null);
            frame.setAlwaysOnTop(true);
            try {
                Thread.sleep(THIRTY_SECONDS);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            BufferedImage img = SwingImageCreator.snapShot(frame);
            frame.setAlwaysOnTop(false);
            return img;
        } catch (Exception e) {
            e.printStackTrace();
            return new BufferedImage(DEFAULT_IMAGE_DIM, DEFAULT_IMAGE_DIM, BufferedImage.TYPE_INT_ARGB);
        }
    }

The method is synchronized to prevent more than one thread for accessing the screen (of which we have only one).

The first thing to notice here is that we use a hack, e.g. sleeping for 30 seconds instead of detecting via an event listener whether the page has rendered. The next is that we open a new browser window each time. Ideally we would know if there is a popup or some other issue with the JRex browser, but instead we just nuke it and create another browser. One other way we prevent unwanted popups is by creating the window manager in JRexWindowManager.SINGLE_WINDOW_MODE, in which mode the browser will not open other tabs or windows. Still, if you enter a URL that doesn't load, you get something like this:

The createBrowser method also creates the Navigator object that is responsible for loading the page:

    private void createBrowser() {
        if (frame != null) {
            // destroy and create anew
            frame.dispose();
        }
        frame = new JFrame();
        JPanel inner = new JPanel();
        frame.getContentPane().add(inner);
        mgr.init(inner);
        canvas = (JRexCanvas) mgr.getBrowserForParent(inner);
        Dimension d = Toolkit.getDefaultToolkit().getScreenSize();
        frame.setSize((d.width> BROWSER_WIDTH ? BROWSER_WIDTH :d.width), d.height - BROWSER_HEIGHT_DELTA);
        frame.setLocation(0,0);
        navigation = canvas.getNavigator();
    }

This solution certainly has plenty of warts, but it sort of works. It will take more time than I have to dig into the code of JRex and discover what can be done to make it a renderer instead of an app or to at least detect error conditions such as modal dialogs.

I'll clean up the code soon and post a link here to the zip file.

Technorati : java, jrex, page preview

Project Tamarin brings Adobe and Mozilla together on ECMAScript

It's already been reported elsewhere, but Adobe has just contributed source code for their AVM2 -- basically a virtual machine for executing ECMAScript -- to the Mozilla Foundation. The project is code named Tamarin, and there are already a number of misconceptions about it. First, it is not an open sourcing of Flash. Rather, it is just the piece that executes the Javascript. Firefox already has a piece that does this, code named SpiderMonkey. The idea is that Firefox and the other Mozilla products that make use of SpiderMonkey will have the goodness of Tamarin swapped or folded in. (See Brendan Eich's post on Tamarin for more details.)

Why is this good news? Well, having the Mozilla and Adobe folks collaborate on a core technology frees them up for doing other, more interesting work. Also, sharing an implementation between two big players strengthens the standard. And let's not forget that that there are lots of cool features in the AVM2 (Actionscript Virtual Machine). SpiderMonkey is an interpreter of Javascript. Tamarin compiles to byte code for a virtual machine which can then take advantage of Just in time compilation (JIT) ala the JVM. The performance of Javascript in Firefox 3 (I hope) will blow the doors off of the current version. Hopefully the improvements will also find their way into Rhino, the Java version of SpiderMonkey (or is SpiderMonkey the C version of Rhino?).

Technorati : actionscript, adobe, ajax, javascript

Whither Canvas?

This world is but canvas to our imaginations. -- Henry David Thoreau

First support for the WhatWG canvas element was announced by Apple in Safari, then it was included in Opera and Firefox. A little while back, Emil did a cool hack with VML to produce a subset of functionality as canvas for IE. There was a rumor that google would release this or some other code as its Canvas for IE solution, and it sort of has, landing with a thud over at sourceforge with a Google Code imprimature.

There have been no apparent developments since then. It doesn't seem to have been widely tested, is much slower than canvas in Firefox, and has enough differences and functional gaps to make integrating it with Javascript libraries that build on the canvas tag somewhat difficult.

There don't appear to be any plans to support canvas in IE7, but things can change quickly over there, apparently. So, do you support canvas in IE with an impressive piece of late night hackery like Emil's work, or is support for canvas just not there yet -- a really nice feature not supported effectively for 90% of the web browsing public?

I'm leaning toward the latter. What do you think?

Technorati : canvas, firefox, ie