A quiet revolution has taken place for Mac OS X Safari users, but I haven’t seen anyone celebrate it… and I’ve looked! There isn’t even a mention of this dramatic change in Safari’s powers on the Surfin’ Safari blog, where the open source team that’s evolving the WebKit rendering engine used in Safari announce new features and updates. Lately, this team has implemented a number of really amazing features from the CSS 3.0 specification, and each has been trumpeted with some eye-popping examples. But not a word about this.

Well, I for one am celebrating the upgrade with this article and proclaiming to the world that finally, at last, Safari is gaining parity with the other modern browsers in letting users perform WYSIWYG editing whenever the application calls for it. Mac users like me who have simply done without rich-text editing in their WordPress blogs and Gmails, bristling with an unfamiliar envy at the vast majority of users who take this functionality for granted by now, can finally save ourselves some typing and edit in our web browser with the same ease we do in a word processor.

Full article

Like many of you who develop on the Mac, I was amazed and very impressed by the WebKit team’s Web Inspector tool when it was unveiled in January. However, it was clearly not yet complete… two critical tabfulls of data were missing, which kept me turning to other tools—like the excellent Firebug for Firefox—when getting into a serious debugging session.

Well, tonight I was delighted to discover that the wait is over! On downloading a new build of WebKit today, I found that Web Inspector finally can provide those critical Metrics and Properties of each DOM element on my web pages. And boy, have they done a great job in the implementation! Every bit as cool and functional as the original bits, so I can now get all the details on any element of the page with a right-click of my mouse (control-click for some folks) and a simple selection of “Inspect Element.” Now come on Firebug fans, don’t you wish you could inspect an element that easily? Not that it’s hard with Firebug, but I always say, “Save a millisecond here and a millisecond there, and pretty soon you’ve saved a whole second!” (Just kidding… I never said that before.)

Full article

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.

Full article

I have been among the developers and observers who have praised Yahoo for the technical strength of their recently launched User Interface Library. In my tests for the Ajax/DHTML Scorecard project in March, Yahoo’s library was a clear “A” in its cross-browser credentials, and I was very impressed with Yahoo’s development team, which published clear and exacting browser standards for their library.

According to Yahoo’s own Graded Browser Support table, Safari is an A-graded browser, meaning it achieves the highest level of support possible with the Yahoo interface library. Clearly, the thought that went into this table is impressive, and the authors conclude the explanation that precedes the table itself with an appropriate quote from Tim Berners-Lee on the importance of cross-browser support:

“Anyone who slaps a ‘this page is best viewed with Browser X’ label on a Web page appears to be yearning for the bad old days, before the Web, when you had very little chance of reading a document written on another computer, another word processor, or another network.”

It is therefore highly disappointing and disillusioning to discover tonight that Yahoo has released a preview of its new, Ajax-enabled home page with support only for Internet Explorer 6.0 and Firefox 1.5. The only logic one can use to justify such a move is based on a totally PC-centric viewpoint, which argues that only Windows users are worth troubling with, since they comprise the vast majority of potential viewers. But this is precisely the viewpoint that must cease if Web 2.0 is to become the fertile melting ground for truly cross-platform interdependence that it wants to be. It’s simply not the viewpoint of any company that really cares about Berners-Lee’s vision or about the millions of users on platforms other than the virus- and malware-riddled mess that is Microsoft Windows today.

Full article

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 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.

Full article

As I mentioned in an earlier post, the whole Ajax/Web 2.0 thing that’s happened this last year reminds me vividly of the mid-1990’s. Back then, the web was brand new, it was exciting, everyone was learning how to build web applications, developers were totally turned on and creative, everybody was pointing out cool new apps and sites, and the potential of this new computing platform seemed unlimited. Leading the charge was a young company that built software for every operating system under the sun, and they clearly had a solid vision of where they were headed. During 1994-96, Netscape introduced one astonishing new client-side technology after another to what a web browser could do–tables, animated graphics, client-side imagemaps, frames, cookies (yes, these really were a vital improvement to the web client), and something they called Javascript.

Each of these technologies offered dramatic new ways of presenting information in a web browser, and developers who loved new gadgets glommed on to every advance, racing each other to see who could do the coolest things with these first. A lot of mistakes were made–a lot of really ugly eggs were hatched–but excitement and optimism were the buzz feelings. With Netscape in charge, you felt like you do when working as a protege with a master hacker: Does this guy ever stop pulling amazing tricks out of his sleeve?

One of the promises of Netscape’s vision was that the web–and, in particular, the web browser–could make one’s choice of operating system irrelevant. The web could level the computing playing field, since applications built for the web were applications for all, regardless of what OS you happened to prefer. What worked for NeXT, OS/2, Irix, Solaris, and Windows would also work just fine on Linux, Mac OS, Be OS, HP-UX, and BSD. The web browser could be the OS, and the only limiting factor in what you could do would be your hardware and connection speed. Microsoft’s lock on the computer desktop could be broken, and new competitors in operating systems and computers could unleash the full potential of the personal computer to improve our lives–both at work and at leisure.

Only, it didn’t quite turn out that way.

This article inventories the Ajax/DHTML toolkits now available and grades each from A to E on the degree to which they adhere to a cross-browser ideal. The good news is that if you want to build astonishing Web 2.0 applications in 2006, you’ve got a lot of fine Javascript libraries to choose from! And nearly all of the Grade A libraries are open-source, so you can build without shelling out a license fee for the privilege. The bad news is that some of the most prominent players in the field fall far short of that mark.

Full article

This is another horrible example of a company with blinders on. Google has been doing this lately, too. What am I talking about? Why, thinking it’s OK to release a new product without support for Safari or other KHTML-based browsers.

Full article

When I first read about Ajax last summer, it sounded too good to be true. After all, I was a web geek who was raised on Netscape Navigator, and for whom Javascript had always been the holy grail of great web applications. I had delighted with each new release of Navigator, excitedly diving into the new objects, methods, and properties as they were unveiled by Netscape. Indeed, Javascript was one of the major reasons to use Netscape in the mid-1990’s, since no other browser could touch it for providing rich client-side interactivity to web pages and applications.

Then, around the time that Communicator (Netscape 4) was released in June 1997, the storm clouds that had been forming from Microsoft’s threatening posture against Netscape began to be really troubling. When IE 4 was released that fall, it finally caught up to Netscape in Javascript support. Indeed, until then Microsoft had simply been copying Javascript in order to provide Netscape compatibility, as part of their strategy to win the market. But IE 4 was different. Microsoft took Javascript in a different, and incompatible direction. Thus began the great cross-browser incompatibility nightmare for Javascript lovers like me–a dark, stormy decade that lasted until the clouds began to part in 2005 with the emergence of Ajax.

Full article

Wow! This project really took me back a few years… and forward a few years as well.

Building this widget also took me back by confirming what I had read about Dashboard widgets–namely, they are really just little web pages that use transparency and run outside of a web browser. They can do more than web pages can do if you get fancy with them, and Apple has added some spectacular animations to Dashboard to make them look cooler than anything a browser can do, but… bottom line… if you know HTML, javascript, CSS, and graphics, you can build a Dashboard widget!

The project took me forward a few years as well, since I got a clear glimpse of what life beyond browser-based HTML will be like a few years from now. I was skeptical at first, but because of both the explosion of Dashboard widgets since May 1 and the amazing usefulness of many of them, I’m now convinced that this new way of getting web information is the future. It’s really the next step beyond Sherlock, and in some ways is just an extension of RSS and an easy way of leveraging web services on your desktop. If I needed any confirmation for my gut feeling on this, Yahoo provided it this week by gobbling up Konfabulator (before Microsoft could get to them, I’m sure)! (More on that later…)

Full article