One of the many challenges of building a usable black theme for Mac OS X is making it work with web pages. If you use Safari, the buttons, scrollbars, and other interface widgets on web pages get their marching orders from the system's graphics files—the same ones that regular applications use.

So, if a web page has a pushbutton, the button will by default take on the style of the active theme. If you're running Crystal Black, this means that the button inherits the Crystal Black style. We like this.

Color for the button's text, on the other hand, gets its marching orders from the browser's default Cascading Style Sheet (CSS) file—which, naturally, makes the text black, and therefore unreadable on top of a black button. We don't like this.

On first glance, the solution seems to merely design a special CSS file for Crystal Black and make Safari use it. And that does work for many web sites and many buttons. However, many folks who design web pages like to fiddle with the CSS style for their pages' buttons, and such fiddling means that there's nothing "mere" about designer a Crystal Black style sheet.

Further, many Mac applications these days have views that are simply embedded web content using Apple's WebKit framework. The practical implication here is that Mac apps don't know how to read a Crystal Black CSS file, so Crystal Black must do some fiddling under the hood to avoid having unreadable buttons in such web views.

Then there's Safari itself. I really wanted to theme the Web Inspector—the incredibly useful built-in website viewer/debugger/designer assistant—with the Crystal Black look and feel, but it wasn't immediately obvious how to do this. I assumed that the tool was just a part of Safari, and therefore built with classes and widgets from the Cocoa AppKit (which is the framework all Cocoa apps are built with). However, when I began to inspect the Inspector, I discovered that everything contained within its borders was simply web content: HTML, CSS, JavaScript, and images.

In other words, the Web Inspector tool is nothing but an intricate, sophisticated, and extremely well designed web page!

Having built a Crystal Black CSS file for web pages in general, and with my past expertise in CSS, I attacked this challenge with relish! It reminded me of the time I realized that Dashboard widgets are, at their core, nothing but little web pages (as are simply apps for the iPhone). In tackling this one, the main question was, How should the various elements look? And the hardest part was inspecting the various parts in of the Inspector in great detail to determine which CSS rules governed their default appearance and behavior.

As I discovered, the WebKit has a a sub-framework called "WebCore," which in turn has a folder of resources specifically for the Web Inspector. In the Inspector folder, among other things, is a suite of CSS files that handle different aspects of the Inspector's design and behavior. Of these, the primary one I needed to tweak was called simply "inspector.css."

Besides controlling the usual attributes of a web page—document elements, text elements, image elements, layout elements, form elements, and so on—this style sheet applies various advanced CSS properties that serve the purpose that in years past would have been handled by many individual images. As I've described this CSS 3.0 magic previously, there's no longer a need for using graphics and JavaScript to add box shadows, rounded box corners, borders, gradients, and reflections to your web pages.

Naturally, since the open-source WebKit project was initiated by Apple, and since that project zoomed ahead of all other browser engines in developing new ways to design with CSS, that's how the Web Inspector is built. This approach—using a command syntax rather than images to design a user interface—is one that Apple has been adopting for its desktop applications. In recent years, Apple has been adding new classes and methods to the AppKit that make it a trivial matter to build a window frame, a border, a toolbar, or a button using code rather than individual graphics. 

While this is a logical and efficient approach, it also presents challenges for theming Mac applications, a challenge that Crystal Black is often unable or unwilling to overcome. (The story of all the challenges in building Crystal Black are described in this article.)

Not so with the Web Inspector, fortunately.

The Inspector does use a few images in its design, but most of the toolbar, separators, and section headers are built with CSS gradients. Very cool indeed!

This bit of Crystal Black will eventually be bundled with the whole theme, but for now I offer it as a free download. Admittedly, the audience for such software is small—you have to like Crystal Black, and you have to be a regular user of the Web Inspector—but it might be of interest to others who are curious about how such things are done.

One caveat in viewing the screenshots... The scrollbars that appear, as well as the HUD window style, are part of the overall Crystal Black theme and are not part of the Web Inspector theme itself.

Enjoy!

Update 4/18/11: The full Crystal Black 1.0 theme is now available from the Crystal Black website.

Installing Crystal Black for Web Inspector

The download contains a small application that you can use to install—and to uninstall—the theme. Simply double-click and select "Install" to apply the theme. Or select "Uninstall" to restore the default CSS files and graphics.

After installing or uninstalling the theme, you'll need to quit and restart Safari for the theme to take effect.

Crystal Black for the Web Inspector (Download file is 1.0MB)

Classy is an online application that takes a URL and parses it into a very useful list of all the CSS classes and IDs on the page. It breaks the classes down to show what HTML elements they're tied to, and does the same with each ID. Besides using the website version, you can also add Classy to your browser toolbar and run it on any web page you happen across.

Classy isn't a replacement for tools like FireBug or WebInspector, but it's a highly useful supplemental tool that gives you a quick overview of a web page's CSS structure that you can't easily get with those tools.

My only quibble is the author's assertion that enteprise reliance on Microsoft Office means unequal time for Macs. He points out that OpenOffice is a viable alternative but makes no mention of Apple's own terrific iWork suite, which is quite compatible with the basic aspects of Microsoft Office. Likewise, he fails to acknowledge Apple's effective collaboration suite in the form of iCal, Mail, iChat, and Address Book. Perhaps it's because those aren't cross-platform. However, even if that's the case, since they are able to interoperate with Office, they should be considered by businesses seeking to support their growing numbers of Mac users.

A lot has happened in the world of web browsers and CSS 3.0 since I wrote this article last summer at the time Safari 3.0 became available as a public beta. Besides WebKit/Safari, Opera, iCab, Konqueror, and Firefox have all made progress in adopting CSS 3.0 specifications, the next generation of the W3C's Cascading Style Sheets standard.

However, the WebKit team continues to lead the pack, as they have since I first contemplated this article over a year ago. In the last 6 months, that team has not only adopted more of the CSS 3.0 specs ahead of the others, but they have proposed several exciting new specs of their own, which the W3C is taking up as draft recommendations.

In addition to updating the state of CSS 3.0 in WebKit/Safari, I've also added some new demos for the Backgrounds section of my CSS playground at the end of the article.

Here are the CSS 3.0 features I wrote about in July 2007:

1. Box-shadow: Yes! Add drop shadows through CSS!
2. Multi-column layout: Can we really do this now? With HTML?
3. Resize: Give JavaScript hacks a rest and let users relax when typing input on web pages.
4. Rounded corners: The corners of any
   element can be made round to any radius you specify.
5. Colors with transparency: There goes another ugly hack from way back!
6. Background image controls: Remember how great it was when you could add images as well as colors to an element's background CSS style? Well, it's about to get a whole lot better!

And since then, WebKit and Safari 3.1 have adopted the following bleeding-edge CSS features:

1. Adopted last October, WebKit introduced its first take at CSS Transforms, which it has submitted to the W3C for consideration. With CSS Transforms,
   s can be scaled, rotated, skewed and translated... all without using JavaScript!
2. Announced at the same time is the equally exciting implementation of CSS Animations. At the moment, the only type of animation that's documented and demonstrated on the WebKit blog is based on CSS Transitions, which let you define how an object or attribute changes over time from one state to another. Using this specification, you can now program many kinds of animations with CSS alone.
3. Also in October, WebKit added the CSS Web Fonts feature, which lets designers beam fonts to users through CSS and HTML, approximating the capabilities of PDF in a much lighter-weight form.
4. Then, after a lull, things started to heat up again last month, when Apple released Safari 3.1. Safari 3.1 incorporated all of the CSS 3.0 features WebKit had pioneered earlier, plus it added a bunch of things the WebKit team hadn't blogged about. Chief among these was support for CSS Attribute Selectors. This is something of a holy grail to advanced web developers, since it opens up a whole world of possibilities for using the Document Object Model (DOM) to build better web interfaces. When released, WebKit was the first and only browser to fully support this geeky, but highly practical feature. (Some of the other browsers have implemented partial support.)
5. And then, just today, WebKit added support for CSS Gradients to its portfolio. Gradients are not yet a CSS 3.0 specification, but they are part of the HTML 5.0 spec. No doubt Apple's implementation will be referred to the W3C for consideration. (This is the only new feature in this list that as yet works only in the latest WebKit nightly build.)

This article lists the CSS 3.0 features that were first available in Safari or the nightly WebKit browser. Besides listing them, I've tried to keep up with what the features can actually do for me as a web designer, so each feature is accompanied by a demo or two and some explanatory notes. Since some of the features are a bit complex, and almost totally lacking in documentation from either W3C (which only lists the standards, not the implementation details), Apple, or the WebKit team, I've had to experiment to discover what some of the attributes do.

Fortunately, a forward-thinking group of techno-weenies is keeping a close eye on the emerging details of the CSS 3.0 implementations, and they have done some experimenting of their own. Since they're in the same boat I am (actually, they have a much better boat!), it's not surprising that I'm finding ambiguities in the way they've built some of their demos. Still, it's the closest thing to documentation that I've found, and I highly recommend that anyone interested in learning more about CSS 3.0 pay a visit to the terrific CSS3.info website. In fact, you'll find links to their pages throughout this site.

Following CSS3.info's lead, I'm organizing the (at this time) CSS 3.0 available in Safari into four categories: Borders, Background, Effects, and User Interface. These correspond to the W3C draft modules for CSS 3.0. The fifth tab in the navigation control below gathers the CSS 3.0 specifications that have been implemented by Safari and at least one other major browser. As you browse through these up-and-coming features, I think you'll understand my excitement about the benefits they offer to web graphic- and user-interface designers.

In the first release of this article, I only had demos for the section on Borders. Today I've added demos for CSS Backgrounds, and I plan to continue experimenting with the rest as time permits. In the meantime, as mentioned before, do pay a visit to CSS3.info for their demos of each, or follow the links to demos at the WebKit site. I hope you're inspired to take up a keyboard and pound out some experiments of your own!

Apple - Support - Downloads - Safari 3.1

This update brings in all the latest standards implementations and innovations in the open-source WebKit project, plus a few interface enhancements as well. The Windows version gets some important updates too. From Apple’s tech document on Safari 3.1:

Performance

• Improves JavaScript performance

Standards

• Adds support for CSS 3 web fonts
• Adds support for CSS transforms and transitions
• Adds support for HTML 5 <video> and <audio> elements
• Adds support for offline storage for Web applications in SQL databases
• Adds support for SVG images in <img> elements and CSS images
• Adds support for SVG advanced text 

Developer

• Adds option in Safari preferences to turn on the new Develop menu which contains various web development features
• Allows access to Web Inspector
• Allows access to Network Timeline
• Allows editing CSS in the Web Inspector 
• Allows custom user agent string
• Improves snippet editor

Other

• Double clicking on the Tab Bar opens new tab
• Includes URL metadata when images are dragged or saved from browser
• Opens Download and Activity window in current Space
• Supports trackpad gestures for back, forward, and magnify on MacBook Air and compatible MacBook Pro computers
• Shows Caps Lock icon in password fields

SEEdit XHTML Editor Covers CSS and Javascript Functions As Well As Website Management

Originally downloaded 4/9/06. Having grown disillusioned with Dreamweaver over the last few years, I haven’t used it in a long while. But I’m also not pleased with using BBEdit “Bare Bones,” either. This looks like a nice upgrade from BBEdit’s built-in HTML/CSS tools and may be just what I’m looking for. It also has link-checking and Javascript coding tools that BBEdit doesn’t have, but it works as a BBEdit plug-in or on its own. At only $30, it’s way more affordable than Dreamweaver and may be a real bargain.

Update 10/14/06. SEEdit is now updated to version 5.0 and redubbed “SEEdit Maxi”.

Update 2/20/07. In a pique of naming confusion, the latest SEEdit Maxi is now referred to SEEdit Maxi 2007 and has no numerical version number. In testing the latest version tonight, I’ve finally concluded that SEEdit Maxi’s not the one for me. Even though the newest release is a dramatic improvement in user interface, as well as adding several very useful new features, over the version released just last October, it still has enough annoying traits and missing parts to keep me away.

Annoying trait #1 is its tendency towards window proliferation. SEEdit Maxi, like BBEdit before it, seems to think that the more windows you can open for the user, the better. I disagree. In my mind, the best Mac OS X applications are marvels of ingenuity that tuck discrete features in drawers or sliding compartments, or various other nooks and crannies that a modern Mac app is capable of. Part of the reason SEEdit doesn’t take advantage of these is that it’s a Carbon application, using the Mac’s older application framework rather than the new one Steve Jobs brought over from NeXT, called Cocoa. Since SEEdit doesn’t have a Windows counterpart, I can’t imagine why the developers aren’t rewriting this app in Cocoa…

Annoying trait #2 is that SEEdit doesn’t have a visual table editor. That’s one of the main things I really need to do visually, and I can’t in SEEdit.

Bottom line is that SEEdit is a great value if you’re not bothered by some of the things that bother me. At only $29, it does a huge amount… right up there with Dreamweaver, without the WYSIWYG editing capability. For a few other notes on SEEdit, see my short list of pros and cons below.

If you’d like to see some screenshots of SEEdit, the developer provides a slew of them here.

One final note: SEEdit is still available in a freeware version, which is quite similar to the shareware one but lacks a variety of features that are explained on the downloads page. SEEdit “mini” is only available for private or educational use.

Version as tested: 2007 r4.

Version as tested: 1.3.0.

Update 10/6/06. My comment from late January turns out to have been a major understatement. Style Master makes CSSEdit look like a toy, to be honest. It has so much power and so many functions that its interface struggles to retain the simple intuitive grace that Mac OS X software is famous for. And I have to say that it does succeed. Although it takes longer to get to know than a simpler tool like CSSEdit, the study is rewarded with the kind of power that will carry you through the toughest style sheet tests.

Style Master pitches itself as the right tool no matter what your skill level with CSS, and I suspect that may be true. Being myself way past the beginner stage, it’s hard to evaluate it from that perspective. However, certainly Style Master has a plethora of “wizards”—as well as tutorials, references, and other resources—that would be great for getting you started on a CSS-based website. There are entire website templates as well—all using CSS instead of HTML, of course—as well as starter kits for blogs based on WordPress, Movable Type, and Blogger. Specific wizards walk you through setting up basic style sheets, page-layout style sheets, and stylesheets for page components like breadcrumbs and tabbed navigation.

The company that makes Style Master, Westciv, appears to have only one line of business—CSS. That line has two components: One focuses on training courses (which are available for sale), and the other focuses on Style Master (the tool component). As such, making CSS accessible to beginners is an important facet of what Style Master tries to accomplish.

Still, they understand that there are by now many designers and programmers who have intermediate and advanced CSS skills, and Style Master is chock full of goodies for them as well. Need to see the generated CSS for a given website? No problem—You can load the site into Style Master and have a look. The “Get Info” function, always available for any selected CSS statement or page component, has four tabsfull of info:

1. Info: This pane shows syntax and usage information.
2. Compatibility: What browsers support this element/attribute/function?
3. Style: This is where the computed style shows up. StyleMaster shows you the value of every CSS property that’s set for the selected element.
4. HTML: Here, you can peruse the HTML source code for the selection.

Style Master amazed me in several ways as I tested it out. I’m not going to go through a comprehensive look at all the interface features… just at the ones that impressed me the most. To start with, I learned how Style Master can import a style sheet from any website… pretty essential if you want to jump in and work with the CSS code for an existing website. I did have to refer to the documentation to learn how to do this. By default, Style Master can import web pages from your hard drive, but by setting up a website in your “Preview Options” pane, it will load any URL, thereafter displaying the style sheet it reads.

One of the first power features I was impressed with was the way Style Master can format your style sheet rules. Even if it imports a scrunched, optimized set of styles (as it did with mine), you can select Edit/Format Style Sheet, and Style Master will reformat the rules so they’re readable, using formatting you define in the Preferences window. This was marvelous, but what really did it for me was the realization that StyleMaster has the ability to always upload an optimized version to the website. This lets you work with a human-readable version in StyleMaster, but let the browser read a much smaller version when it downloads your web pages.

Another power feature I know I’m going to enjoy is Style Master’s ability to identify “orphan” rules. How many people besides me learned CSS by adding rules until something worked the way we wanted? Given browser differences and general CSS quirks, quite often the rules just wouldn’t work the way they were supposed to… so you might leave a declaration in place whether it was needed or not. This kind of behavior can really lead to style-sheet bloat, and Style Master’s ability to sniff out unused rules should help shrink that back.

After I’d played with the software for awhile, I discovered a very useful option in the “Statements List” drawer, which you can optionally display on the left-hand side of the StyleMaster window. By default, this drawer lists all the CSS statements defined in a given style sheet. (The order of display is configurable.) However, when you have a style sheet as big as the one for Musings from Mars, that becomes a very long, scrolling list. Fortunately, Style Master will jump to or highlight statements that are contextually relevant when you select something in the preview pane. But even better, you can toggle a setting in the drawer’s “gear” menu that tells Style Master to only show statements relevant to your current selection. This is a very powerful way of filtering that list into a usable length.

Working with Style Master is like watching a really talented dancer. Everything is done in a smooth, coordinated fashion, and with a grace that delights and satisfies. Select an element in the stylesheet code view, and Style Master will also select the relevant CSS statement from the Statements list. If you have Style Master’s handy visual CSS-builder tool open, it will automatically switch to show the right pane and display the selected values. Meanwhile, if you have the “smart” preview pane open, Style Master will highlight the HTML element that’s using the rule you selected. The same thing happens if you select an HTML element in the preview pane or a CSS statement from the Statements list. Given all this coordinated action, it’s really quite hard to get lost.

A couple of other features that will keep me using Style Master are its good FTP support, so you can download and upload files from within Style Master, and its ability to create CSS statements from selected HTML. This latter feature requires a bit of an explanation. Basically, it means that you can import an HTML page that has no style sheet and ask Style Master to create one based on the formatting it finds. Is that cool, or what? You can do this on a micro level also… that is, select a portion of an HTML document, and you’ll find a contextual command in Style Master to make “New Statements from HTML.”

Style Master will continue to surprise me, I think, as I get to know it better. And I’m convinced I’ll have to fork over the dough to get it, too! At $60, it’s quite a bit more than the $25 CSSEdit (which I bought last year), but I expect I’ll be relying on it quite a bit more than I rely on CSSEdit these days. I expect I’ll still find the need to call upon the marvelous XyleScope now and then, but I may not need it quite so often.

Version as tested: 4.5.

Since my original report on the browser and platform compatibility of some 50 Ajax JavaScript libraries in March, the market has continued to produce new toolkits at a rapid pace. I recently finished grading all (but one) of the 8 libraries added since March, and I’ve revisited the scores of another 8. With that, the time seemed right for a report on how Ajax library developers are doing at achieving cross-browser, cross-platform compatibility in the tools they’re giving us–tools which programmers around the world are using to hammer out their unique vision of Web 2.0.

I’m very pleased to report that the trend is moving strongly toward full compatibility. Of the eight new libraries, a full five of them achieve top grades of “A”. That’s a much higher percentage of the total than in March, and of the three non-A libraries, only one was a D (D+ actually). One was graded C+ and the other B. Of the revisited libraries, I was able to raise grades for three–Backbase, ICEfaces, and MochiKit. Only one library had a lower grade (Rico, down from A- to B), and the rest were unchanged.

Only two of the 8 new libraries have commercial licenses you’d have to pay for, and in one case you are really only paying for the IDE. Three of the new libraries require a java server architecture in order to be happy, one would prefer Cold Fusion, and the others are pure client libraries that are agnostic with respect to the application server. One library was added just a couple of days ago (Jitsu), and I haven’t had time to review it yet–but you’ll find it summarized here with the rest. Only one of these 16 libraries is DHTML with no Ajax controls–Uize. Even without Ajax, however, I think you’ll find Uize to be one of the most interesting here–especially in terms of visual richness.

Here is a tabulation of the results for this group:

All of the notes about these libraries are now included as part of the original article, but I’m presenting the brief writeups about each one here as well, since some of these may be new to you. The libraries are presented in the same order as the preceding table–the new libraries first, and then the revisited libraries.

One other general observation I can make before getting into the details… It’s clear that the Ajax application market is splitting into two camps, pretty much the same two that have dominated application development teams since the dawn of the client-server era:

1. Those who like, need, or want a visual development tool and a minimal amount of actual coding (in Ajax, this also means preferably as little JavaScript coding) as possible,
2. Those who prefer to code with a text editor or equivalent, with as much control over the actual code as possible.

In general, the commercial tools lean toward the former approach, while the open source libraries lean toward the latter. The commercial products also tend to favor proprietary server-side components, either in the form of an actual server or in the form of the data formats delivered by their own GUI IDE tool. It’s probably as a result of their use of proprietary components that the scores for the commercial products are, by and large, much lower than the open source products in terms of platform and browser compatibility.

Finally, a quick note about the lengthy table on Microsoft Atlas: Atlas is the only one of the many libraries I’ve tested that doesn’t seem to understand that if a control or link causes a page refresh, it isn’t Ajax. In that case, it’s just a synchronous server connection like we’re all used to. One of the aspects of Ajax that makes it special is the ability to design a user interface that doesn’t disappear on you just because you entered some data or made a selection in a form. Web users have become accustomed to the page refresh as normal behavior, since it’s what all web applications do. Linking from one page to the next is just the web norm and has been since the web was born.

Don’t misunderstand me to be saying that Ajax is meant to put an end to the page refresh. It’s not, and I’m not. I’m merely saying that Ajax provides the technique to allow seamless contextual changes to a persistent user interface, where that’s appropriate… As it’s often described, Ajax lets you make web interfaces more like the interfaces of desktop software, which don’t do page refreshes. What we now call Ajax is a new tool that user interface developers can work with in order to improve usability as they continue on their quest for that Holy Grail of usability: Providing a truly intuitive web interface. Eliminating the page refresh is one of Ajax’s signature features, and the presence of a page refresh means it ain’t Ajax.

Many of the Atlas controls require a page refresh to get the job done, and therefore I have counted them as “not working.” Yes, some of them “work”, but not as Ajax controls, and that’s what Atlas is supposed to be providing. I have no idea what techniques Microsoft engineers are trying to use in Atlas, but I do know that by and large the controls Atlas provides are extremely pedestrian and have been available since DHTML was new. Why these simple DHTML behaviors would cause a page refresh in modern browsers like Firefox and Safari–and why they don’t work at all in Opera–is a complete mystery to me. By all means, visit the Atlas site and judge for yourself.

Note that nowhere in late June could I find a statement that Atlas is a “preview” or “beta” product, which was the excuse many Atlas defenders used when I pointed out some compatibility issues back in April. In April, the reference to “preview” release was on a page linked to the Atlas home page, but if such a statement exists today I couldn’t find it. My purpose here is not to “bash” Microsoft or any other developer, and if I seem to dwell on Microsoft’s weaknesses here, it’s only a reflection of the company’s dominating position in computing. Every action Microsoft takes automatically receives a great deal of attention, and many people who look at Atlas may have no idea how weak it is compared with most of the competition. In this field, not only was Microsoft late to the game, but they are entering with very few chips. The chips may appear large and shiny, but if you look closely, you’ll find they are quite thin–and actually hollow on the inside.

Once you try out the Atlas demos, be sure to also visit the many A-rated toolkits in this list, as well as in the full list from the April article. I think you’ll find that the A-rated libraries not only provide superior compatibility across browsers and platforms, but also embody amazingly innovative thinking and offer some truly elegant, mind-opening approaches that will get your wrists itching to get typing. I’ve tried to point out each library’s noteworthy features in the library summaries, but I’m sure I missed some. If you know of a particularly cool feature of your favorite library that’s not mentioned here, by all means let me know!

Frankly, the hard part about settling on an Ajax library these days is getting over the yearning to try all the great ones out! I’ve personally been doing nearly all of my Ajax experimentation with Prototype and Script.aculo.us, but I really want to set them aside if time permits and try jQuery, Dojo, and MochiKit, all of which I find appealing for one reason or another. Did anyone say “kid in a candy shop?” That’s truly what delving into these wonderful JavaScript libraries has been like for me.

Ajax/DHTML Libraries New to the List

Echo 2

Grade: A
Server Required: Java
License: Commercial

Google Web Toolkit

Grade: A-
Server Required: Java
License: Open Source/Free

Jitsu

Grade: Not Yet Rated
Server Required: .NET/Mono
License: Open Source/Free

jsLINB

Grade: A-
Server Required: None
License: Open Source/Free

Neuromancer

Grade: C+
Server Required: ColdFusion
License: Open Source/Free

Uize JavaScript API

Grade: A-
Server Required: None
License: Open Source/Free

Zapatec

Grade: A
Server Required: None
License: Commercial

ZK

Grade: D+
Server Required: Java
License: Open/Free

Ajax/DHTML Libraries Revisited Since March

AjaxFace

Grade: E
Change from Previous Grade: No change
Server Required: Proprietary
License: Commercial

Atlas

Grade: D
Change from Previous Grade: No change
Server Required: Proprietary
License: Commercial

Backbase

Grade: B
Change from Previous Grade: Up
Server Required: Proprietary
License: Commercial

Dojo

Grade: A
Change from Previous Grade: Unchanged
Server Required: None
License: Open/Free

ICEfaces

Grade: B+
Change from Previous Grade: Up
Server Required: Java
License: Commercial

MochiKit

Grade: A
Change from Previous Grade: Up
Server Required: None
License: Open/Free

Rico

Grade: B
Change from Previous Grade: Down
Server Required: None
License: Open/Free

Tibco General Interface

Grade: E
Change from Previous Grade: Unchanged
Server Required: Proprietary
License: Commercial

In a case demonstrating that you can’t be sure your Ajax/DHTML website will truly be cross-browser just by including one of the toolkits that are known themselves to be fully so. From my own experience, even if you use Prototype, you’re likely to pick up a few odd JavaScripts along the way to include in your site. Or, you might take a stab at writing a function out of the blue. Either of the latter two steps can get you in trouble if you’re not careful.

Today’s case is an Ajax/DHTML “tutorial” which has been advertised on a couple of websites that a lot of folks in the Ajax community rely on for good tips and pointers. Unfortunately, the only thing the script is a good example of is cross-browser carelessness, or perhaps simply cross-browser “couldn’t care less”-ness on the part of the developer.

In mid-April, Max Kiesler blogged about a Wordpress “shelf” script that he described as a “nice tutorial on how to build a sliding shelf in Wordpress,” with a pointer to the website. Naturally, since I’m a WordPress guy myself, I thought this could be useful! Much to my amazement and dismay, on arriving at the suggested site I realized that this “shelf” is totally out of order for WebKit-based browsers (the most prominent of which is Safari for Mac OS X). I blogged a brief complaint and noted that a reader had already left a comment with the Asymptomatic.com owner letting him know it wasn’t working in Safari. I’m pretty sure I also wrote a note to Max Kiesler, but it was through his online form, and I never heard back about it.

Click on the screenshot thumbnails if you want to see how the “sliding shelves” look in Safari and WebKit.

Kiesler subsequently included this guy’s tutorial twice in his continuing roundup of Ajax Tutorials, the concept of which is great, but the execution of which needs a little more editorial oversight to ensure that only Ajax representing industry best practices are promoted. From the feedback I’ve received to my own article grading 50 or so Ajax/DHTML toolkits on their adherence to a cross-browser, standards-based approach, I’m pretty sure most developers believe we should be writing standards-based code these days.

The terrific Ajax-themed website Ajaxian.com promptly picked up both of Kiesler’s “tutorials lists” that had pointers to the Symptomatic’s problematic WordPress script, so I’m sure with the popularity of WordPress, that script has been passed around far and wide by now.

In the meantime (about a month), has the script’s author attempted to fix the problem? Unfortunately, no. I tried again today, and just as before, the sliding “windows” are simply static content in Safari. They’re weirdly nonfunctional in the latest WebKit nightly build as well.

Looking at his code, I see he’s using Prototype, along with moo.fx, which he talks about at length in the tutorial. Both of these are A-graded JavaScript toolkit, and I use Prototype myself… a lot. But Prototype alone won’t save you, my friend. Not when you also include a half-dozen third-party scripts and a dollop of homemade code that isn’t anywhere near Prototype. I can only assume that those other scripts are what’s making these “shelves” stick so.

You know, Tim Berners-Lee blogged recently in support of a standards-based Web. Quite eloquently, I thought. When I wrote in an earlier article that the web was built by folks who believed in open communications and complete interoperability between different OS’s and browser platforms, I didn’t have a good quote to back me up. Now I do. From the guy who actually wrote the World Wide Web software–on a NeXT machine (from which Mac OS X is descended, by the way)–here are some thoughts I hope we can all try to live by as Web 2.0 matures:

When, seventeen years ago, I designed the Web, I did not have to ask anyone’s permission… The new application rolled out over the existing Internet without modifying it. I tried then, and many people still work very hard still, to make the Web technology, in turn, a universal, neutral, platform. It must not discriminate against particular hardware, software, underlying network, language, culture, disability, or against particular types of data…

It is of the utmost importance that, if I connect to the Internet, and you connect to the Internet, that we can then run any Internet application we want, without discrimination as to who we are or what we are doing… The Internet is increasingly becoming the dominant medium binding us. The neutral communications medium is essential to our society. It is the basis of a fair competitive market economy. It is the basis of democracy, by which a community should decide what to do. It is the basis of science, by which humankind should decide what is true.

Let us protect the neutrality of the net.

Those of you who are devoted to promoting best practices for Ajax and Dynamic HTML (DOM Scripting, nowadays), please keep this in mind, and try to make sure the scripts you are offering for others to emulate are truly worth of that trust. Unfortunately, as cool as WordPress Shelves look in IE, Opera, and Firefox, they leave a large majority of the Mac OS X user community out in the cold. And for no good reason.

The script’s author points as his inspiration to another example of sliding shelves, from Shaun Inman. Those work beautifully in all browsers, but it looks to me like he’s using MovableType instead of WordPress. Otherwise, perhaps Shaun would be willing to prepare a WordPress plugin for sliding shelves. Failing that, whoever is promoting scripts like this needs to take the time to make sure they work. Otherwise, bad scripts like this become a building block to a really bad, balkanized Web 2.0.

And I don’t think anybody involved in this exciting technology wants that.

I’ve been writing for some time now about the kinship between Apple’s Dashboard Widgets and web pages. I’ve recently written a time or two about Ajax and the various wonderful dynamic HTML (DHTML) JavaScript libraries that are now available to web developers. And when I first starting compiling the lists of available Ajax/DHTML JavaScript libraries, I was planning to grade Apple’s Widgets library along with all the rest. In explaining why I didn’t, here’s what I wrote last month about Widgets and DHTML pages:

It’s interesting that 2 months after an Adaptive Path essay coined the term “Ajax,” Apple released Mac OS X 10.4 “Tiger”, with its amazing and powerful dashboard widgets system. Within a couple of months, there were over 1,000 widgets available on the web, and these little babies were capable of completely replacing (almost all for free!) a number of system utilities, menubar items, and whole applications on the Mac. I’m tempted to think that awareness of Apple’s widgets helped promote awareness of, and interest in, what could be accomplished with rich Ajax/DHTML toolkits. After all, widgets are simply little Ajax/DHTML programs running in a special layer of Mac OS X called the Dashboard… They use exactly the same technologies as all of the Ajax/DHTML libraries, and in fact you can run them inside of Safari outside of the Dashboard.^*

And so, it was fitting that when I finally found time to work on xCuts, a widget I’d been planning to build since last summer, I decided to use one of the leading Ajax/DHTML toolkits rather than Apple’s own, for most of the widget’s functionality. Having done most of my recent DHTML web work with Prototype and its light-hearted, freewheeling sidekick, Script.aculo.us, I naturally turned to those libraries to help me out.

Whenever I use script.aculo.us, I invariably get carried away and overdo the cool effects. (Witness this website!) But I do only use the effects when you’re supposed to–namely, as a visual cue to the user that some page content has changed. Without this visual cue, content can change so fast and smoothly on an Ajax page that users may not realize anything has happened… especially if they’re expecting the link they clicked to cause a page refresh that never comes. As an example, consider this link, which replaces this paragraph with different text stored on the server.

See what I mean? Even though your eyes were actually on the content that changed, the difference was so subtle you might have missed it. Now take a look at the lists of articles and news items in my navigation panels in the sidebar. Without Ajax, one list would give way to another so similar-looking that you might not notice. On the other hand, if you add an effect or two to the change, it’s impossible to miss. For example, try this link, which replaces this paragraph with another one from the server.

Now, having said all that, my primary failing is in going overboard with the effects. Rather than one simple yellow-fade, I prefer a yellow-fade combined with a slide-down, or perhaps a slide-down combined with a scale-up. But hey–don’t blame me! Blame that elvin genius Thomas Fuchs, who keeps thinking these things up. Why, just this week he published an article explaining how to do custom effects, as if the ones that come with script.aculo.us aren’t enough! If you’ve looked at this library, you know that what I’m saying is true. In addition to some powerful Core Effects (opacity, scale, moveby, highlight, and parallel), script.aculo.us comes with a series of Combination Effects, which are built using the core ones. In fact, it’s the “Parallel” core effect that makes this magic possible, allowing a developer to mix and match the core effects as much as their time and imaginations permit.^**

But that’s not all! I haven’t even mentioned the possibility of using Callbacks, Transitions, and Effect Queues to fine-tune your effects… As much as I’d like to, I don’t have time right now to go into a full tutorial on the script.aculo.us effects, but fortunately, the script.aculo.us wiki is bursting with useful demos, reference documentation, and sample code to study. I usually start at the wiki’s All Pages view, which links to pages describing all the script.aculo.us functions, most of the relevant prototype functions, and all the demos and other documentation as well.

So I approached building the new xCuts widget as if it were basically a little web page that uses prototype and script.aculo.us to work its Ajax magic.^*** Besides the animation, effects, and basic Ajax server calls, the widget incorporates the very popular live search form, which is my first implementation. It was actually surprisingly easy to build using prototype’s Ajax.Update function. Speaking of the search, the input element implements Apple’s HTML extensions, which were actually developed as part of Dashboard but can be used on any website as well. Using them, you can surprise Safari-toting visitors to your website with nice, rounded search forms… you know, the ones with the little magnifying glass filling one end and the spiffy focus, blur, and clear bits Mac OS X users have come to expect from native Cocoa apps. Though they are non-standard, these extensions do no harm to other browsers and merely enhance the web experience for WebKit users.

In addition, at the last minute I found the great DOMinclude library from Chris Heilmann, which came in handy to add the “i” supplemental information about certain shortcuts. Here’s a case where DHTML (Chris would prefer we start referring to it as DOM scripting, and he has a point, but habits are hard to break…) can come to the rescue: How can you present a lot of information on a keyboard shortcut in a compact space? There are always trade-offs in such a design, but I try to focus the user’s attention on the primary bits of info and provide secondary info in an opt-in format of some kind that doesn’t detract from the presentation or otherwise draw too much attention to itself. As I saw it, I had three options:

1. Squeeze the “other info” data column in either a third column of the lists, or as a second paragraph in the second column. The first option ended up squeezing the first two columns too much, which seemed silly since only a few shortcuts need the third column. The second option mingles the “other” info column with the “action” column, which may not be appropriate in many cases. It also makes the whole list longer than necessary.
2. Use DHTML to slide in the “other info” data as a new row, just beneath the row for its shortcut. This would have been an effective choice, but was going to take a bit more custom programming and would have caused the whole column to shift up or down a lot, which seemed a bit ungainly.
3. Use traditional DHTML tooltips. Searching for a tooltip I liked is what led me to Chris Heilmann’s elegant solution. Before finding it, I was spending way too much time considering all the permutations of possible scripts, time that also involved learning how the script’s code was implemented and ensuring it was compatible with the other JavaScript functions in the widget. I ultimately bookmarked a handful of “tooltip” scripts that made the final running, but decided DOMinclude was perfect for my needs here. Besides its unobtrusive JavaScript foundation, I like the way it emulates the visual appearance of Apple’s Dictionary service.

Another spoonful of “syntactical sugar” I threw into the pot was Justin Palmer’s CSS event:Selector script. On Mars, I have been using Behaviour.js to enable unobtrusive, CSS-event-driven JavaScript functions, but then a month ago a leaner, more powerful script appeared that immediately synched with my brain. As Palmer says, event:Selectors are better integrated with Prototype, so the corresponding event rules require fewer “words.” In addition, they are more flexible, and presumably faster as well. So, I decided to try his script out in building xCuts rather than Behaviour, and I have to say it has an excellent aftertaste! As soon as time permits, I’ll rewrite the CSS Behaviour-style rules on Mars as event:Selector rules. The transition is easy, since, as Justin notes in his blog article, “Behaviour was the inspiration for event:Selectors,” and as such it adopts a similar syntax.

For convenience, I did use the Apple libraries for the flip animation and for the scrollbar and drag animations. Of those, the only one you really need the Apple libraries for is the flip animation, although the JavaScript cube animation script that Kava.net published recently could possibly be a replacement if you’re willing to accept a more jaggedy visual. Another area that prototype and script.aculo.us aren’t particularly strong in is scrollbars… they have no native function for them. On Mars, I’ve cobbled together a thin scrollbar for the navigation “panes”, but I went with a native OS scroll function in the “News Article” window that materializes in the middle of the page because it allows mousewheel scrolling and is much simpler to implement. I could do that with a Dashboard widget, too, but in this case native scrollbars can kind of ruin the look.

One small note is that as I got the widget built out I wanted users to be able to copy and paste from it if they chose. Looking around, I noticed that nearly all Dashboard widgets only had text-selectable sections in form fields. That’s because the onmousedown function that lets you drag widgets around the Dashboard also prevent the widget from understand a “copy” style mouse drag. I finally found one or two widgets that overcame this, and a quick visit to the Apple Dashboard docs revealed that the proprietary CSS code that implements the drag function is DOM-element-specific. In other words, though most developers seem to go with the default example code Apple provides, which applies the “-apple-dashboard-region” style to the whole face of the widget, you can instead restrict the region to whatever parts of the widget you want to be draggable. Cool.

For a back end, I had originally hoped to use Core Data, but I just didn’t have the time to learn how to access Core Data with JavaScript, and Apple doesn’t provide any roadmaps. Core Data would be ideal for this, but instead I fell back on existing skills and just set up a MySQL table and wrote a PHP page to access and format the data. Because of this, you won’t be able to use the widget when you’re disconnected from the Web. I still hope to transition it to Core Data in a future update, mostly for the learning exprience. On the other hand, with the database maintained remotely, I can easily continue to update the data source without having to publish new versions of the widget. Particularly in the first few months–when I have a lot of data I still want to add–that’s probably a good thing!

So… what did I use to build this widget? Gather round, and I’ll share this secret with you. Shhhh!! Here it is:
Find a widget you like, and use its code as a starting point.

As I pointed out last summer, one of the best things about building widgets is also one of the best things about building web sites: It’s all open-source code, and most developers release under free and open licenses that don’t make you feel like you’re stealing if you borrow a function here or there. That was certainly the case with one of my favorite widgets, SeeSS, a great CSS reference widget. Besides being at my fingertips when needed, I love this widget because it curls up into a tiny ball when you’re done, taking very little screen space. I also admire its overall layout and the fact that you can resize it as needed. By the time I was done, there really wasn’t very much of SeeSS left, but it was a great way to jump-start my work and gave me a nice framework to build from.

Tools? Definitely Widgetarium from Gandreas Software. I used this program for my first widget last July, and it has grown seriously more powerful since then. First of all, Widgetarium is great because you can start a project by choosing “File/New Project from Widget…”, after which you simply browse to any widget on your system, and select Open. Widgetarium automatically builds a new project for you from the components of that widget, including all image files, scripts, other source code, and–most conveniently–the XML .plist files without which the widget won’t work in Dashboard. After that, you can start tinkering with the code as you please without, of course, affecting the original widget.

Next, this tool still has that nice transparent window in which the widget builds, so you can stop and restart it all without leaving Widgetarium. As before, it has nice graphics tools for building pieces of the widget, but now you five tools instead of one. Besides the basic Panel Maker, you get a Button Maker, an Icon Maker, a “Roundie” Maker, and a slicing tool that lets you chop a panel into smaller pieces. I still export all the pieces to Photoshop for fine-tuning, and use Photoshop for the overall graphic design of the widget, but unless you’re extremely picky, the graphics tools in Widgetarium will give you a nice jump start on assembling the images you need. (You know, I’m seriously thinking of testing out other graphics editors since Adobe’s taking so long to get Photoshop Intel-ready. Anybody else thinking along those lines?)

New to Widgetarium is a truly useful JavaScript debugger, which has the usual stop/breakpoint features that let you step through the JavaScript code one function at a time. While doing this, the debugger provides a wealth of information on the variables and the DOM environment you’re working in. In fact, if anything the wealth is a little too much, and without a search feature it can be hard to find the variable you’re looking for. Still, this is a big improvement. In addition, there’s a console panel under the widget area that provides useful error messages, and you can toggle between that and a panel that lets you actually enter an interactive JavaScript session with your widget… testing different DOM calls, CSS properties, and so on, as part of debugging.

Just as useful is the DOM tree Widgetarium provides. Here, once you navigate down to a particular node, you get 4 panes of info about the node:

1. Attributes: The node’s ID and all other attributes (like attached events) visible in the HTML source code
2. Value: Only for text nodes, this contains the displayed text
3. Style: The node’s CSS style as defined in the project’s style sheet(s), and
4. Properties: I invariably find this the most interesting pane. Here you’ll find the node’s offsetParent, its parentElement, and its top and left offset measures (see screenshot).

If you’re developing JavaScript in Firefox,you can get this information in Mozilla’s DOM Inspector, but frankly Widgetarium’s interface is a heckuva lot more useful. What you get in the DOM Inspector is the same kind of thing that Widgetarium’s Debug window provides: Anything and everything, and good luck focusing on what you’re trying to find.

Even better than Widgetarium is the WebKit team’s Web Inspector, which presents the DOM and its nodes and styles in an incredibly compact, useful interface. The only problem with Web Inspector is that it isn’t finished. For now, it provides the Attributes, Value, and Style information you get from the other tools (including the “computed” style that’s so important in debugging), but not the Properties information. Web Inspector has two panes that stand empty as “Not finished” for now: Metrics, and Properties. I can’t wait to get them! Just like Mozilla’s Inspector, WebKit’s highlights the elements you select as you navigate, but Web Inspector has a far superior search interface. If you’re used to the Mozilla DOM Inspector search tool, you’ll be blown away by what you can do in Web Inspector.

Which brings me back to Widgetarium. One of the most glaring weaknesses–which I’ve pointed out to the developer, and he’s working on it–is the inability to search in either the DOM tree or the JavaScript debugger. This means, for example, that each time you want to find a node in the tree you have to manually traverse its parent nodes. Not a problem once, but unfortunately Widgetarium crashes often enough that you find yourself doing this walk way too often.

In my use, one of the things that crashed Widgetarium most reliably was trying to use the powerful “Symbol Browser.” How I wish I could have made use of this little puppy, but alas Widgetarium crashed every time I tried. I know it works with other widgets (the screenshot is from the MacUpdate widget), and I can see it would be very useful. What Symbol Browser does is the sort of thing you can do in TextMate and Eclipse in searching across your code base: Namely, Widgetarium compiles a list of all the functions, variables, properties, and methods used in your code, and you can find instances of whatever you’re looking for across all your files. If, like me, you have multiple, interrelated JavaScript files, this could be a real timesaver! The tool not only shows you the lines of code in a search-list format, but also brings up the full source code in a third pane when you select a given line. (Note: Click on the Symbol Browser thumbnail graphic to see the full screenshot.)

All of the Widgetarium editing screens have four useful features in common:

• A pulldown menu showing all the JavaScript functions (or CSS styles, or HTML elements, etc.) defined in the file, which you can use for quick navigation
• A pulldown showing various options for auto-indent, code-folding, syntax-coloring, line-numbering, and so on.
• A quick “go to line number” search, and
• The ability to split panes–as many times as you could possibly want! There are times I’d like to be able to bring another file into one of the split panes, but that wasn’t possible

The editing environment in Widgetarium is good, but not great. To improve it, my primary suggestion to the developer is to implement a single tabbed window. I find navigating among four or five open source code windows a bit tedious, especially after getting used to tabbed editing in BBEdit, TextMate, Eclipse, etc. Still, I no longer find myself using Widgetarium for some things and BBEdit for others, like I did last year.

There are many more useful features to Widgetarium, which I don’t have time to go into detail about but want to just mention here to whet your appetite (assuming you have one by now):

• Customizable syntax coloring
• Customizable key bindings
• Built-in lint and syntax checkers
• Incremental search option (should be the default, actually)
• Screenshot export options
• Image files viewer
• Top-notch documentation
• Full suite of embedded JavaScript and Dashboard reference material from Apple, the w3c, and elsewhere,
• Built-in extensions for working with audio, speech, AppleScripts, data from Spotlight, the Mac OS X clipboard, the file system, and more.

If it sounds like I’m a Widgetarium fan, you’re right… I am. And if the developer continues to improve this tool, pretty soon I won’t have any quibbles with it at all! At $50, I’m more than glad I shelled out the bucks last summer.

It’s hard to believe I could have so much to say about this simple little widget. As usual, I meant to sit down for an hour and found myself writing for four instead… All without even talking about the widget’s functionality! I guess you’ll have to figure that out for yourself! I hope you find it useful and enjoyable, and please let me know if you think of a good idea for improving it.

But most of all, have some fun building your own Ajax/DHTML widget!****

* Yes, I know that widgets can incorporate many native Mac OS X technologies that web pages can’t–like AppleScript, Core Data, file system calls, Core Image, and so on–and some of them do. But they don’t have to, and most of them don’t.

** And of course, down below, holding the whole structure firmly in place, is prototype.js, which provides the foundation that makes extending and combining JavaScript functions possible.

*** Both libraries were updated to new versions during development, but xCuts 1.0 is behind one or two releases (it uses prototype 1.5.0_pre0 and script.aculo.us so the 1.5.3). I’ll be updating xCuts soon to bring it up to the latest (prototype 1.5.0_rc0 and script.aculo.us 1.6.1).

**** If you want to build for Windows or for a browser other than Safari, check out Yahoo’s free Widget Engine, or Opera’s spanking new
Widgets API, which you can check out in the Opera 9 public beta.

Back in early March when I first released the Ajax/DHTML Scorecard, rating all of the existing Ajax/DHTML toolkits against an ideal cross-browser scale, I rated Atlas an “E.” So, the good news for Microsoft fans is that Atlas is actually better than that. But not by much.

On April 4, I rescinded the original score after some readers correctly pointed out that I was treating Atlas differently from the other toolkits in the shootout. That’s because Atlas was simply vaporware in early March, and there was nothing to test. As I explained in an update to the article, the “E” was based on Microsoft’s past conduct in the cross-browser-support department. Here, they had been very bad big boys. Microsoft is the reason that we have to worry so much about cross-browser support today, so it stood to reason that their entry in the Ajax field would continue their past strategy of steering all users to Microsoft products and away from alternatives.

Though I was skeptical Microsoft had changed its stripes, one writer assured me that

In general Microsoft’s strategy with .NET is to require Windows on the server, but to be 100% browser compatible on the client. .NET components configure themselves automatically for the available browser features ( i.e. CSS levels, javascript dialects, or css/js disabling). While I’m still in the early phases of researching Atlas, it seems that this style of browser support has continued.

And so, I began testing with an open mind, especially after an Ajax blogger raved about Atlas in an article that was picked up by the No Fluff, Just Stuff RSS feed that I follow. (I’ll have to remember to ignore future articles by Brad Abrams, whose blog after all is hosted by msdn.com…)

Since Abrams was celebrating the release last week of the Atlas Control Toolkit, which includes 9 online demos of different Atlas controls, I decided to start my testing there. Unfortunately, Atlas failed on the very first control, the “Cascading Drop Down.” Though it worked in Firefox on Mac OS X, it failed in both Safari 2 and Opera 9. After going through three or four of these, Atlas was batting a very low score, and I decided to keep track of results more scientifically.

The end result? Of the 9 Atlas controls very publicly celebrated by Microsoft this week, here’s how Atlas rates:

• Firefox, 8 of 9 controls worked
• Safari, 4 1/2 of 9 controls worked
• Opera, 3 1/2 of 9 controls worked

I don’t think you can count this as cross-browser support, folks.

Because the vast majority of the controls worked in Firefox, I’m counting that as almost-full Firefox support, giving the Atlas toolkit a “D-”.

Now really, with all of the A-rated toolkits available to you, why would you choose Microsoft’s if you care about cross-browser compatibility? There’s no good reason to do so. Especially with the status of IE 7 so out-of-focus, and Vista even blurrier. The only reason to do so is if you don’t care about cross-browser compatibility and are married to a Windows server or Windows developer tools. Anybody who really cares about cross-browser, cross-platform support for the next generation of web applications will avoid Atlas like the lovely but deadly Siren it is.

Test Results
As I kept detailed notes on my tests of Atlas, here are the results. For each control that didn’t work, I’ve included one or more screenshots of the broken control. Also included are the detailed JavaScript error messages generated in Opera. I’m including these not only to show the error message, but also as a hint to those of you JavaScript gurus who haven’t experienced the wonder of these little gems yet. Far better than what’s available in Firefox or Safari, the Opera message gives you an invaluable backtrace that pinpoints the source of the error. If you know of a better JavaScript error log than this for any Mac browser, please clue me in.

Cascading Drop Down

Firefox | Safari | Opera
Screenshots: Atlas Control | JavaScript Error

Collapsible Panel

Firefox | Safari | Opera
Screenshots: Atlas Control | JavaScript Error

Confirm Button

Firefox | Safari | Opera

Drag Panel

Firefox | Safari | Opera
Screenshots: Atlas Control | JavaScript Error

Hover Menu

Firefox | Safari | Opera
Screenshots: Atlas Control | JavaScript Error

Popup Control

Firefox | Safari | Opera

Reorder List

Firefox | Safari | Opera
Screenshots: Atlas Control | JavaScript Error

Textbox Watermark

Firefox | Safari | Opera

Toggle Button

Firefox | Safari | Opera
Screenshots: Atlas Control in Firefox | Atlas Control in Safari

For the last control, I gave Atlas only one-half credit in Opera and Safari since for some reason Microsoft couldn’t get those browsers to display the nifty thumbs-up/thumbs-down graphic that Firefox and IE users enjoy. Why this should be hard is beyond me… it’s just a graphic, after all! Also, the only failure that Atlas suffered in Firefox was for the Reorder List control. Here, the drag/drop function worked, but once I dropped a list item, the whole browser had to refresh in order to register the new list order. Hate to tell you, Microsofties, but that ain’t Ajax.

I also noted that besides the broken Ajax controls, the Atlas website failed Opera visitors on other fronts… most notably, the tabbed interface on the Atlas home page can’t be navigated in Opera 9. And finally, unlike nearly every other toolkit on these lists–even those that rate D or E–you can’t even use Atlas JavaScript controls unless you’re using Windows on the desktop and on the server. Try to download the “samples”, and you get “AtlasSamples.msi”, which I couldn’t crack open on my Mac OS X system. Presumably, this is an ASP.NET file of some kind, although Ajax is based purely on open standards of JavaScript, CSS, XML, and HTML. Again, this bundling is simply an attempt to make you use Windows systems for your Ajax-enabled websites. Why do this, when there are dozens of extremely able frameworks that give you more freedom? Heck, even nearly all of the commercial frameworks on these lists open the source code for anyone to leaf through.

In conclusion, although Atlas has some nifty DHTML/Ajax controls, that is true of virtually all of the A- and B-rated toolkits. There’s something to like about most of these, and there’s a fair amount of picking and choosing to do when deciding on a toolkit. My point is that because you now have so many great tools at your disposal, there’s no reason to accept less than full browser/platform compatibility as one of the criteria for deciding which to use. Just because Microsoft is the 300-pound gorilla of IT doesn’t mean its nicely packaged toolkit should turn your head. Take a closer look… this is one beautiful Siren that will eat you alive if you get too close.

P.S. I want to thank the author of the very nifty JavaScript widget DOMinclude for making this available! DOMinclude is a wonderful, unobtrusive DHTML control that lets you make any external content a DOM “popup” just by adding a class to its anchor tag. This was perfect for the screenshots and JavaScript error snippets I wanted to include with this article.