My, we've come a long way in browser choices since 2005, haven't we? It's been a very heady time for programmers who dabble in the lingua franca of the World Wide Web: HTML, JavaScript, Cascading Style Sheets, the Document Object Model, and XML/XSLT. Together, this collection of scripting tools, boosted by a technique with the letter-soup name "XMLHttpRequest," became known as "Ajax." Ajax spawned an avalanche of cool, useful, and powerful new web applications that are today beginning to successfully challenge traditional computer-desktop software like Microsoft Word and Excel. As good as vanguard products like Goodle's Maps, Gmail, Documents, and Calendar apps are, one only has to peek at what Apple has accomplished with its new MobileMe web apps to see how much like desktop applications web software can be in 2008.

That this overwhelming trend toward advanced, desktop-like applications has happened at all is the result of the efforts of determined developers from the Mozilla project, which rose from the ashes of Netscape's demise to create the small, light, powerful and popular Firefox browser. The activity of the Mozilla group spurred innovation from other browser makers and eventually forced a trend towards open standards that made the emergence of Ajax possible.

This article starts with a brief history of web browsers and then jumps into a look at the feature set of the four primary "modern" web browsers in 2008. The comparison of browser features begins by listing the core features that all these browsers have in common. The bulk of the article lists in detail "special features" of each browser and each browser's good and bad points, as they relate to the core browser characteristics. Following that, I present some recent data on the comparative performance of these browsers. The article concludes with recommendations I would make to organizations interested in making the switch from IE6 in 2008.

Full article

This release fixes a problem with the uninstaller, and is otherwise the same as 1.9.0. (Note: Today’s update fixes the error in yesterday’s release, which inadvertently still had the 1.9.0 installer. Sorry about that!) The uninstaller now runs a new utility, GraphicsToggle, after running the installer/uninstaller, and this takes care of making sure the Leopard graphics are fully restored. See the documentation included with the download for more information about GraphicsToggle.

Full article

This unexpected journey into the realm of transparent user interfaces has taken me much further than I ever imagined. It's been almost a year now since the first inkling of the idea rattled my brain, which led to the first release of Crystal Clear for ShapeShifter in mid-February.

Thanks to the Cocoa InputManager SetAlphaValue, I was led, Pied-Piper-like, into the enormous and strange world of Objective-C and Cocoa during the summer. I'm finally surfacing from that expedition and have brought a souvenir of my travels into the strange, terrifying, and glorious realm of Cocoa.

Each computer user will have to decide for themselves just how much transparency they can stand while working at their Mac. I was surprised at the amount of loathing that was expressed towards Leopard's newly translucent menubar last month. But I don't think it's indicative of any permanent flaw in the concept. Quite the contrary, in fact: If anything, Leopard's toying with translucency is too much of a baby step, on the one hand, and smacks of me-tooism with Vista, on the other.

Very briefly, the premise I'm proposing is that our computer monitors are essentially glorious light sources, much like the ones that shine through windows in our houses and automobiles. Just as we do with those windows, there are times when we want to bask in the beauty shining through, and other times that we prefer to close the blinds to avoid glare. On the computer, we already know how to close the blinds. I'm suggesting that there's a world of beauty awaiting computer users who can enjoy the light as well.

Full article

On the Unsanity website this week, a heated discussion broke out regarding some problems Leopard users were having with an older version of the company’s Application Enhancer (APE) module. What ensued both there and across the web–wherever those “blue screens of death” were discussed–was a revival of the ongoing argument about how “safe” APEs are. Most of the writers also bundled InputManagers and SIMBL (Simplified InputManager Bundle) plugins into the mix, which just pissed off the developers who know how different APEs are from those beasties. Meanwhile, developers of APE haxies and InputManagers have had to continuously address legitimate concerns about the security of their products and their impact on system stability, and so they’ve tended to become a bit defensive even in constructive arguments. I was so distressed by it all that I was moved to write the following lengthy entry on Unsanity’s forum. It turned out to be an article I’ve been meaning to write for a long time now, and for this Mars report I’ve spent some time cleaning it up and adding information to it. I hope it adds something mostly positive to the debate about the value of these kinds of system enhancements. At the very least–if you have the patience to wade through my overlong prose–you’ll be rewarded with a list of 30 “system enhancements” that I use (or have used), which try to explain why I find them so useful and necessary to my Mac Life.

Full article

Since releasing of Crystal Clear and VacuumMail earlier this year, my download traffic has overridden my .Mac account ... and twice (so far) I've had to upgrade my account to accommodate the bandwidth. I don't mind that, nor do I mind the additional traffic on the Mars Downloads pages. What I do mind is the time it takes me to keep those pages updated! In fact, it takes so long I haven't been able to keep them in sync with the new stuff I was making.

I've been a pro webmaster for, well, a long time... since 1994, in fact. So keeping a couple of simple pages updated shouldn't make me break a sweat, right? Damn right! Problem is, the Download pages started as an experiment with Apple's iWeb software last year, and iWeb and WordPress don't mix well. To help them get along, I devised a simple checklist so all I'd have to do was:

1. Generate the raw HTML from iWeb
2. Massage the HTML by
   1. Tweaking a few CSS styles,
   2. Doing a few search/replaces,
   3. Doing a bit of reformatting, and
3. Plopping the iWeb HTML in the WordPress template, and
4. Moving the iWeb graphics and other files to the server.

At least, that's how I thought it was going to go. As it turns out, the convoluted HTML and CSS code that iWeb generates invariably causes problems when running inside Mars. This means each update can turn into a 2-3 hour scavenger hunt, with each contestant (Me, Me, and Me) trying to find a lost px in a huge block of unreadable code.

So last week I vowed to find another way, and I think I have. The end solution means more work up front in generating the site to begin with, but should make it very easy to rearrange, add, or rewrite content or images on those pages.

Full article

A lively discussion and exchange of information occurred recently on Hawk Wings, the blog site mostly devoted to news and resources for users of Apple’s terrific Mail program. A colleague at work sent me a message on Tuesday, excited when word on Hawk Wings started circulating about a “vacuum” process available for SQLite databases that appeared to dramatically speed up Apple Mail. He had tried the recommended vacuuming and definitely noticed peppier Mail performance. One thing led to another, and before I knew it, I’d become engrossed in developing and polishing up an AppleScript utility to automate a periodic vacuuming of my Mail, which I’m of course dubbing VacuumMail.

As the Hawk Wings discussion unfolded, we learned that Mail maintains an SQLite database called “Envelope Index” in your ~/Library/Mail folder, which gradually grows as the number of emails in your mailbox does. Natively, Mail performs no optimizations on this critical database, which contains pointers to all of your mail that become fragmented and somewhat disorganized over time. At the office, my Envelope Index file was over 100mb, and at home it’s about 30mb. SQLite offers a “vacuum” command that rewrites the Envelope Index, optimizing and reorganizing it for faster access. It sounds a bit like what happens when Mac OS X defragments your hard drive periodically.

At first, news of this function took the form of a shell command you can run in Terminal. It was quite interesting and exciting to see how the Mac users reading of this learned more about it as information was shared, and the command itself became more concise and precise as the day went on. Other users discovered that SQLite offers an “autovacuum” process that can do vacuuming without prompting, and I’m sure that’s a great thing as well. However, we also learned that vacuuming is a more robust and thorough optimizing of the file, since it actually analyzes and rewrites the whole thing, whereas autovacuuming acts only on a certain recent portion of mail pointers. The basic Terminal command turns out to be:

sqlite3 ~/Library/Mail/Envelope\ Index vacuum;

Full article

Like most geeky Mac users, I delight in the little "easter eggs" I discover from time to time as I use my Mac. It's especially satisfying when I stumble across something cool about apps I thought I knew... even mundane little apps like TextEdit. This article describes how I learned to use TextEdit as an HTML editor (!!) It's the first in a planned series I'll be publishing to share and preserve my personal Mac OS X "easter eggs." I've already got a long Edgies note that's full of little tips and tricks on topics like Pages, Quicksilver, contextual menus, PackageMaker, and DevonThink Pro, as well as more on TextEdit.

I originally published this particular tip on MacOSXHints last summer, and I always intended to republish it here... but, well, I'm only now getting around to it. MacOSXHints is a great resource for Mac users, and I search its archives frequently. However, as a purveyor of tips, it's a bit limiting, since you can't include images or movies in your writeup, and you don't have much control over how it's presented. One of the main reasons I purvey tips, by the way, is to try to counteract the drivel a Google search often dredges up. For example, I searched again today to see if anyone had published this useful tidbit about TextEdit and couldn't find it anywhere... for the most part, Google gave me articles like this one on About.com, which just don't tell the full story.

Full article

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

If you’re a Mac user who’s wandered in to this article and don’t know what Growl is yet, you might want to stop by that essential open-source project’s home page to get acquainted. Once your Mac starts Growling, you’ll understand how fitting it is that Apple’s naming all their OS X releases after large cats.

If you’re a Windows user, you’re still welcome to read up on Growl and why it’s become a standard component of so many Mac users’ desktops even though it’s still only at version 0.7.4. If you find Growl cool, too, you know what to do.

This article isn’t about Growl, though. It’s about Growl displays—the part of Growl you actually see when an event occurs you’ve asked to be notified about. You see, like many other cool apps nowadays (Adium, Synergy, Menuet, etc.), Growl is “skinnable.” Part of the fun—and the utility—of Growl is that users can customize the appearance of different kinds of alerts. In fact, Growl provides you with an astonishing degree of control over your customizing, and this flexibility is one of Growl’s coolest aspects. Using the Growl Preference Pane, you can:

• Set a default Growl style as your starting point.
• Customize certain aspects of each Growl style. Some styles let you set different attributes for up to 5 different priority levels.
• Assign a default style to each different application that’s registered with Growl. (Here’s a growing list of Mac OS X applications that now include support for Growl event notifications.)
• Override the default for any specific notification event, or for a given event priority.

With so many options, it’s no wonder that Growl users collect Growl styles like some Mac users collect system icons or desktop pictures!

Growl notifications can take several forms: Email, speech (using the Mac’s built-in vocal chords), or visual displays. The visual display types are roughly broken down into two kinds:

1. Displays you build with AppleScript or xCode (those with the extension .growlView), and
2. Displays that are basically just little web pages (those with the extension .growlStyle).

It’s the latter type I want to briefly shout about today.

Full article

The title of this article is deliberately provocative: I don't know the answer to the question, and I don't really care. But having been there with Firefox many times, all I can say is that Safari plugins like SafariStand make me grateful that I don't have to find out. I've found it much easier to utilize and keep track of one plugin rather than keeping, say, six or more in sync and up-to-date.

Our culture is generally dominated by a "more is More" attitude, so that the browser with the most plugins is believed by definition to be the best horse to bet on. This is the same argument some Windows users have made for years with respect to their choice of operating system: I want to use the computer that has the most software to choose from. This argument is proven empty when you actually sit down and compare the quality of Mac software in a given functional category versus that of Windows software (don't take my word for it: Actually do it yourself sometime), and that emptiness carries over to the issue of browser plugins. Certainly, there are some software categories that you legitimately need access to a Windows PC for. But if you notice, nearly all such categories cover business, rather than personal, requirements, and they're for very narrow fields of interest indeed. The only personal software category where the Mac actually lags Windows is gaming, and I predict that the gap in gaming titles won't be nearly so large a year or two from now as it is today.

As far as the supposed dearth of plugins for Safari in comparison with Firefox, SafariStand is an excellent case-in-point. There are other excellent multifunction Safari plugins (Saft, PithHelmet, Safari Extender, for example), but I'm highlighting SafariStand because it's not only great, but also free. After all, if a Safari user finds they are starting to buy plugins, they really should consider paying for a browser that has dozens of plugins already built in, like OmniWeb. Being the cheapskate I am, I like free things, and SafariStand is one of my favorite freebies for Safari. Besides, most Firefox plugins are free, so it seems only fair to restrict this plugins conversation to those that Safari users can add without paying extra.

In this article, I'm going to focus on just a couple of the best bits from the latest SafariStand beta, which are just too wonderful to remain obscure from the Safari-loving hordes. But very briefly, here is a list of the main functions that SafariStand adds to Safari. To gather these functions into Firefox would require the gathering of a half-dozen or more separate plugins, each of which would have to be authorized and kept up to date, etc.

1. Option to restore your last workspace, or any of the pages you had open, on launch.
2. Add sidebar with thumbnail tabs.
3. Customize search engines available in the standard Google search form.
4. Automate "find" function without having to type Cmd-F.
5. Add color labels to your bookmarks.
6. Enable site alteration, customizing allowable plugins, images, JavaScript, style sheets, and more for any website.
7. Colorize the HTML source window, and make it editable.
8. Reorder tabs in a window (this is a native feature of Firefox and will be one in Safari 3.0).
9. Use the "Stand Bar", a floating palette with searchable bookmarks and history, as well as customizable SafariStand folders and RSS feeds.
10. Configure your "Bookmark Shelf," a floating palette that lets you build and access saved "workspaces," which are lists of sites you open up in a browser session and want to save for later use.
11. Access one of the best "Page Info" stores now available for any browser.
12. For any site you're visiting, easily see a list of all the cookies the site has set, examine their contents, and/or delete one or more of them.

Full article

Although I’ve been developing websites with MySQL for over 7 years now, until recently I had almost always used phpMyAdmin to manage my databases. phpMyAdmin is such an excellent web application and makes managing MySQL so easy that the only time I strayed was when it wasn’t available on the host server (which was very rare). When I needed a desktop MySQL client, I had turned to YourSQL, which I determined a couple of years ago was the best for me when connecting to MySQL from Mac OS X.

For various reasons that I won’t bore readers with here, I found myself needing a Mac desktop client for MySQL again recently, so I took the opportunity to review the market once again. What surprised me most, I suppose, is how many options there are for Mac OS X users who do a little light database work. (Caveat: I am by no means a database administrator, and my knowledge of SQL and MySQL is merely sufficient to develop web applications—meaning, I can build tables, relate tables, and build queries for those tables. The tools reviewed here are from this use case alone.) In the course of testing, I tried out nine different database apps:

1. Aqua Data Studio
2. CocoaMySQL
3. DBVisualizer
4. iSQL Viewer
5. MySQL Query Browser
6. PGnJ
7. RazorSQL
8. SQLGrinder
9. YourSQL

Full article

In our modern, interconnected, always-on age, knowing one’s IP address comes in real handy at times. Knowing your IP address isn’t quite as important as knowing what time it is, but it helps to have an IP clock handy when you need it.

I’ve dabbled with quite a few solutions to this problem over the last few years, and there are a large number of decent IP clocks available… most of them for free. In my IP ramblings, I’ve ruled out solutions that work only in the Dock and ones that put an IP address right in your menubar. I don’t use the Dock that much anymore (between Quicksilver, ClawMenu, Dashboard, and menubar widgets, I don’t need it), except in its application switcher form. And IP addresses printed directly in the menubar take up too much valuable space and are invariably ugly.

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

I admit I was skeptical when Yahoo took over Konfabulator last year.  Apple had released Dashboard for Mac OS X 10.4 (”Tiger”), which had some clear advantages over the old Konfabulator widget model.  The first time or two I tried the Yahoo widgets, I was singularly unimpressed not only with the performance of the widgets but also with their quality. They reminded me of why I had never been impressed with Konfabulator, although I’m sure Konfabulator’s wanting money for their product had something to do with that, too.

Also there was Yahoo! itself… a company that until the last 12 months or so had been growing more conservative, more commercial, more corporate, and less fun than the Yahoo I started loving 10 years ago. Not only that, but Yahoo appeared to be less and less friendly toward the world’s Mac-minded minority. I had grown so disenchanted with Yahoo mail that I finally gave up last summer and packed my bags for the terrific IMAP mail service called Fastmail. So it was a bit of a surprise when Yahoo wandered into territory that originally had been 100% populated by Mac-type aliens. Clearly, the visionaries had regained some influence at the company, as other recent smart moves testify (see all the cutting edge Yahoo goodies at the Yahoo Developer Network).

So, when I downloaded the Yahoo Widget Engine (YWE) 3.0 in December, I was pleasantly surprised to notice that things had changed quite a bit.  Setting it aside until last month, YWE 3.1, the latest release as of this writing, confirmed my first impressions. YWE widgets are now very well behaved, for the most part, and take no more system resources than Dashboard widgets do.  Plus there are actually some widgets that don’t have good Dashboard counterparts.

But finding more great widgets isn’t the only thing that’s made YWE a standard part of my desktop.  What I really admire is the YWE implementation of widgets, which has firmed up my longstanding view that Apple needs to modify the Dashboard concept to make it more flexible, if they want Mac users to truly embrace widget-dom.  The particular traits I admire are nothing new… they were standard in Konfabulator, and there’s one application for Mac OS X called Amnesty that will emulate the concept. I have stubbornly refused to pay the $20 that Mesa Dynamics wants for Amnesty, especially now that I use YWE, which does most of Amnesty’s tricks for free.  So what exactly are those tricks?

• Run widgets like normal applications outside of Dashboard
• Easily change a widget’s “window level”–meaning, where it resides starting from the desktop itself up to a window that floats persistently above all regular windows, with several layers in between.
• Ability to lock a widget in place
• Ability to set transparency for a widget.
• Ability to access widgets–and their preferences–from a handy menubar item.
• Ability to stop and start the widget layer as the need arises.

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

With growing interest and amazement, I read the back-and-forth argument between two long-time, highly respected Mac nerds yesterday on the subject of Mark Pilgrim’s decision to abandon Mac OS X for Ubuntu Linux. John Gruber is simply one of the best Mac writers there is, and regardless of what he has to say on a particular subject, you have to admire the elegance, precision, and logic of his writing. So when Gruber raised questions about the wisdom of Pilgrim’s move in a recent blog post, his large readership weighed in, and Pilgrim responded, you can be sure that a great many Mac users like me paid attention.

As usual, I agreed with nearly everything Gruber had to say, and the couple of niggles I have are not worth mentioning here since they would distract from the purpose of this article. And what is that purpose, you are wondering? Before I get to that, let me briefly summarize (if I dare) the exchange so far between Gruber and Pilgrim.

1. Pilgrim has become fed up with Apple’s “closed”-edness. After 22 years as a sophisticated, high-end user, he’s decided Apple’s “closed” ecosystem of software and hardware is too closed for him. His primary concern is that the integrity of the data he stores in that ecosystem is at risk, because Apple doesn’t always document its data formats and doesn’t respect for long the proprietary formats it develops for storage. Pilgrim feels jerked around from one closed format to another and is tired of the data conversions and consequent data loss they inevitably entail.
2. Gruber is surprised and a bit incredulous that Pilgrim would have suddenly been bitten by this bug. He agrees that closed formats aren’t good for long-term archival purposes, but questions whether losing his iTunes metadata and other format problems is worth chucking his expertise with the Mac operating system for something completely different. He points out that a good backup strategy is part of the solution to preserving precious content. He also devotes a large part of his response to criticizing the Mac blog writers who had knee-jerk reactions against Pilgrim’s decision, and who cited old “Mac is better than Windows because…” arguments without realizing the advances Windows has made since Windows XP (or 95, or whatever). Gruber argues against black-and-white thinking in general and for the very reasonable position of respecting other people’s choices even if you don’t agree with them.
3. Pilgrim replies that Gruber missed his point and reemphasizes that his feeling “closed in” by proprietary formats has been coming on for a long time. Apple’s decision to abandon the widely used and understood mbox format for Mail was just the last straw. He feels betrayed that Apple switched formats in Tiger without informing its users, without providing them a way to back out, and without documenting the new format.

So why do I want to wander into this disagreement between two Macintosh heavyweights I don’t know, but greatly admire and respect? As I read their separate articles, I saw something with my Martian eyes that may not be clear to them. What I saw wasn’t an OS switch story, but rather a love story.

Full article

3. Use Real Productivity Applications To Get Work Done Faster, Easier

As inventors of new tools have done throughout human history, the visionaries who designed and built the first personal computers saw them as tools that would provide an immense boost to human productivity. And they weren’t just thinking about business productivity, folks. They were also thinking of personal productivity: Getting more things done faster so we’d have more leisure time.

Today, in our Microsoft-Windows dominated world, we use the term “productivity application” to refer to Microsoft Office, and we think of the personal computer as a business tool. (Quick: Do a Google search for that term–”productivity application”–and see what you get.) But has Microsoft Office provided us with more leisure time? Of course not. Microsoft Office is a business tool that replaced prior, non-electronic tools like the typewriter and pencil. If it has enhanced productivity at all (and that is arguable), the productivity gain has come in the form of more output per worker… not more leisure time for the individual. In any case, whatever productivity impact Microsoft Office and its ilk had on the business world was completed many years ago. Yet even for businesses, productivity didn’t stop with improving our ability to prepare reports and memos, or compile numbers in spreadsheets, or do overlays for a presentation in PowerPoint.

Productivity goes up whenever you can suddenly do a task in less time than before, either at home or at work. Since its beginnings with the original Apple computer, Apple has appeared to be pursuing a vision that steadily expands the personal computer’s potential to save you time… to do complicated things simpler. Apple’s operating system recognizes that this kind of productivity gain begins with the simplest interface to the computer: Finding things, opening applications, printing, opening documents, organizing information, and the like. As a result of this vision, Mac OS X has two built-in features that are simply lacking in Windows, and they enable “productivity” applications that are truly the envy of the Windows world:

Applescript and Application Services.

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

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.

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