In the past few years, Adobe Flash has become more than an annoyance that some of us have kept in check by using "block Flash" plugins for our web browsers. More and more, entire web sites are being built with Flash, and they have no HTML alternative at all! This goes way beyond annoying, into the realm of crippling.

I had noticed the trend building for quite awhile, but it only really hit home when I realized that Google, of all companies, had redesigned its formerly accessible Analytics site to rely heavily on Flash for displaying content. This wouldn't be absolutely horrible except for the fact that Google provides no HTML alternative. I tried to needle the company through its Analytics forums, but only received assurance that yes, indeed, one must have the Flash plugin running to view the site.

Keep in mind that content like that on Google Analytics is not mere marketing information, like the sales pitch on the Analytics home page.

Those of us who are disturbed by the trend need to be a bit more vocal about our opinion. Hence, I'm starting a "Just Say No To Flash!" campaign, with its own web page, graphics for a banner, and the CSS and HTML code to deploy it on your own web pages.

I've mentioned this to some of my family and friends, and they often come back with: "So, Why should I say no to Flash?" I admit that as a power browser and a programmer geek type who, shall we say, makes more efficient use of the web, I'm more keenly aware of the ways that Flash is chipping away at the foundation of web content.

In the beginning, it seemed harmless: Flash was an alternative to animated GIFs, and an easy way to embed movies on web pages. But then advertisers wrapped their meaty mitts around it, and that's when Flash started to be annoying. However, one could block Flash in the browser, as part of a strategy of shutting out obnoxious advertising.

But publishing content via Flash is just wrong, for a number of reasons.

Full article

It's still somewhat difficult to get a handle on exactly what is meant by the "Semantic Web," and whether today's technologies are truly able to realize the vision of Tim Berners-Lee, who first articulated it back in 1999. From what I've read, I think there's general agreement that we aren't even close to being "there" yet, but that many of the ongoing Semantic Web activities, technologies, development platforms, and new applications are a big leap beyond the unstructured web that still dominates today.

There is a huge, seemingly endless amount of work being done by thousands of groups all trying to contribute to making the Semantic Web a reality. In my few weeks of research, I still feel as though I've just stepped my toe into that vast lake of semantic experimentation. Partly as a result of the many disparate projects, however, it does become rather difficult to see the entire forest for all the tiny trees. That said, these thousands of groups do appear to be working more or less together on the basis of consensus-based open standards, and they have set up mechanisms to keep everyone abreast of new ideas, solutions, and projects, under the general leadership of the World Wide Web Consortium (W3C)'s Semantic Web Activity.

As a starting point for exploration into this topic, the Wikipedia article that describes the Semantic Web Stack is quite good. Among its good overview and many useful links, the article includes the original conception of the Stack as designed by Berners-Lee.

Besides cataloguing the sheer number of different projects all tackling different aspects of building a Semantic Web, it's important to distinguish ongoing projects from those that expired years ago—a distinction that's not always readily apparent to those peering in from the outside. Even excluding these, there are far too many projects to read up on in a few weeks, so this snapshot is necessarily incomplete. But after having the content reviewed by some Semantic Web experts, I'm confident it includes all the most significant threads of this new web, which, as Berners-Lee envisioned it:

I have a dream for the Web [in which computers] become capable of analyzing all the data on the Web – the content, links, and transactions between people and computers. A ‘Semantic Web’, which should make this possible, has yet to emerge, but when it does, the day-to-day mechanisms of trade, bureaucracy and our daily lives will be handled by machines talking to machines. The ‘intelligent agents’ people have touted for ages will finally materialize.

In my tour of the Semantic Web as it exists today, it's interesting to note that most of the projects are geared not toward machine-to-machine interaction, but rather to the traditional human-to-machine. Humans being by nature anthropocentric, the first steps being taken toward Berners-Lee's vision are to build systems that are semantically neutral with respect to human-to-human communication. Once we can reliably discuss topics without drifting off into semantic misunderstandings, then perhaps we can start teaching machines "what we mean by" ...

This paper is an attempt to assess the current state of today's steps, while compiling a list of resources that would prove useful to someone thinking about building a Semantic Web application in 2009.

Full article

Full article

Looking back,This is an update to the article I wrote last summer, when Safari 3.0 was first released. In the 9 months since then, a lot has happened, and I wanted to try to keep this info up to date. 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.

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: Any
   can be made round.
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 new ones:

1. Adopted last October, WebKit introduced its first take at CSS Transforms, which it has submitted to the W3C for consideration. With CSS Transforms, <DIV>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.
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 support this geeky, but highly practical feature.
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.

Full article

Full article

Full article

Full article

Full article

Full article

Full article

Full article

Full article

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

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

Full article

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

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

Full article

Full article

Full article

Full article

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.

Full article

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

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