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.
A Little Browser History
Since its debut in June 2003, Apple’s Safari web browser has had a hard time gaining respect among web developers. This has a little to do with its Mac OS X platform restriction, but it’s mostly because of incompatibilities in its underlying rendering engine that have taken its developers a long time to correct.
From the beginning, Safari was incompatible with a fairly large number of websites, but most of this was because those websites were poorly designed to work only in Microsoft’s Internet Explorer browser. Apple encouraged its users to report bugs, through use of a convenient toolbar button in Safari, and I’m sure its developers’ energy was consumed with bug fixes for the first year of its life—when they weren’t implementing novel functionality like a built-in RSS reader.
After Firefox 1.0 was released in November 2004, interest in that browser slowly began to turn the minds of developers away from pure IE compatibility to a more cross-browser mindset based on open standards. Thus, in 2005-06, Firefox began to eat significantly into IE’s market share, to the point that no one could ignore Gecko compatibility anymore. Most Windows-based developers are surprised to learn that the share of Safari also rose dramatically during that time (from 1.5% to 4.5%), though remaining at a much lower level than Firefox (which rose from less than 4% to more than 13%). In mid-2005, Apple open-sourced WebKit, the core rendering engine used by Safari, and since then, interest in—and respect for—Safari has steadily increased. (Note to those who know… the underlying HTML rendering engine in Safari is actually called “WebCore”, but it’s a distinction that would simply confuse this history and provides no useful information. If you want to learn more, here’s a nice, brief summary on the Apple developer website.)
Part of that newfound respect is due to the WebKit team’s vigorous pursuit of web-standards compliance, and this improved compliance with standards dovetailed perfectly with the shift away from developers’ reliance on IE’s non- and sub-standard implementations of CSS and JavaScript. Thus, by the time Ajax became a buzzword in 2006, consensus in the web developer community was strongly aligned with adherence to standards, and Safari was by then just as standards-compliant as the Mozilla browsers and Opera… and in some cases more so. (Safari was the first browser to pass the Web Standards Project’s Acid2 test in 2005.)
Safari Remains “contentUnEditable”
And yet, many developers continued to grumble about problems dealing with Safari in discussion forums and blogs. When pressed for the reason, it nearly always boiled down to one of two things:
- The developer hadn’t worked with Safari in at least a year, or
- The developer was frustrated at not being able to deploy a web-based rich text editor that would work in Safari.
As far as number 2 is concerned, you can count me among the developers who’ve had that little problem. I’ve worked on development teams to build several Intranet systems for web content management over the years, and early on, we just had to give up on Mac users. Ironically, the scripting functionality that lets a developer make any element of a web page editable with WYSIWYG editing controls originated with Internet Explorer, beginning in 1999. After a fair amount of public nose-holding, the Mozilla team incorporated the Microsoft specification into its browsers fairly early on, and most projects developing rich-text editors for browsers were able to achieve Mozilla compatibility several years ago.
Yet still Safari lumbered on with little or no acknowledgment of the admittedly non-standard (but still vital) “contentEditable” property. And so the browser continued to receive scorn, even as it was leading the browser pack in other areas of standards compliance and functionality. It’s true that Apple incorporated what turned out to be very buggy support for contentEditable in Safari in late 2004, starting with Mac OS X 10.3.9. But this implementation was apparently so unreliable that it probably just angered developers who tried to use it more than it impressed anyone. (To find out just how angry, try Googling the phrase “Safari contentEditable” some time…) Fortunately, the new implementation appears to me as a user to be the real thing!
The Wait Is Over!
So it was with a great deal of surprise and delight that I awoke one morning a couple of weeks ago and realized that the long wait was finally over! On one of the Apple rumors websites, I read that a key feature of the latest beta release of Mac OS X 10.5 (”Leopard”), is support for rich-text editing in Safari 3.0 that’s fully compatible with the “ContentEditable” specification.
But that isn’t the really exciting part for me personally. Since Safari 3.0 is simply incorporating the latest build of WebKit, I surmised that WebKit itself was probably now capable of handling standard rich-text-editing duties on the web. Perhaps all of those sites that couldn’t be made Safari compliant because Safari didn’t properly handle ContentEditable might now be opened to me without reaching for Firefox, Camino, or Opera!
At first I assumed that I’d have to turn on some silent default in WebKit to make this happen, as I did with the resize-textarea CSS 3.0 feature. Not the case. The latest WebKit nightly build can handle WYSIWYG editing with nothing more than a download.
Well, that’s not completely true, but only because many websites and WYSIWYG editing tools are hard-coded to not let Safari or WebKit use their tools. But nearly all of these can be “spoofed” into thinking WebKit is IE 6.0 or Firefox, and will then open their toolbox for me to use. About the same number of sites are built correctly—that is, to identify whether a given web client recognizes a given DOM property, rather than merely asking for its name and number—and would let me edit content with no spoofing at all. Among the badly coded pages is WordPress’ administration area (at least through version 1.5), and among the well coded sites is Google’s Gmail.
Not Something To Brag About . . .
For Mac users, this is huge news. We like to think our platform is the best there is, and that Apple is way out in front on new technologies and usability standards. But in this case, the Mac has been way behind for a long time, and it will be very pleasant to put this behind us.
I first started researching WYSIWYG editing tools in late 1999, and even though Safari and Mac OS X didn’t even exist then, finding WYSIWYG editing tools that would work on the Mac has been an ongoing struggle and source of embarrassment.
How could Apple have ignored such core functionality for so long? That’s a rhetorical question, but it’s a clear demonstration of the fact that Steve Jobs and the brilliant folks at Apple aren’t flawless by any means. I think I was on the early side of recognizing the key value to web-based content management of letting end users edit content using tools that mirrored what they were used to in a word processor. It was clear to me that if you want to spread use of the browser in an organization as a tool for managing content on your website or in a database, you have to give them something more than a course in HTML and a good book.
Given their druthers, they would return to Microsoft Word every time to do their editing. And why not? Why should a nontechnical user struggle to piece together an HTML table for her data, or be forced to type code to tease a bullet list out of her content, when this problem had already been solved in the computer interface? Of course, they shouldn’t, and support for WYSIWYG editing in the browser clearly had no champion at Apple for a long time.
The only other end-user technology that Apple, unfortunately, remains way behind the curve on is video screen capture. I hope someone there realizes that static screenshots no longer suffice for many purposes, and that the screencast is a tool of immense strategic importance for marketing and education uses in the 2007 World Wide Web. Yet Mac users still don’t have a free tool for simple video capture, as Windows users do. But the purpose of this article isn’t to grouse, so I’m not going to grouse further on this subject here. 
Some Evidence for the Skeptics
For those of you who simply aren’t happy unless you can see what I’m talking about, as well as those who require physical (or at least visual) evidence of what I’m saying here, I’m providing a few screenshots that you can peruse at your leisure.
For the web developers out there who have built websites that shut Safari users out by name and number, now is the time to fix your site so that it asks the browser whether it understands the ContentEditable property. This will let folks like me who are using the nightly WebKit in, and will let the hordes who upgrade to Leopard see what they’ve been missing once Apple releases it. It will also let users of the WebKit-based shareware browser OmniWeb enjoy the new trick. OmniWeb incorporates WebKit code faster than Safari in most cases… or at least, on a different schedule… and the latest release supports WYSIWYG editing just as WebKit does. OmniWeb is the only WebKit-based browser I could find that does, however… the rest appear to use the core built in to Mac OS X 10.4 (”Tiger”).
For Mac OS X web users who’d like to start using Writely, Google Spreadsheets, and WYSIWYG editing in tools like WordPress and Gmail while staying in Safari or OmniWeb, by all means download the nightly WebKit browser or the latest OmniWeb release and start living life a little more fully!
From the Genii Software’s comprehensive list of web-based WYSIWYG editors, which they have been maintaining in recent years after “the list” started at the University of Bristol, I quickly tested the following tools which had online demos and were listed as supporting IE and Firefox but not Safari. Here’s a summary of the results when testing with WebKit (latest nightly build):
Free or Open Source:
- ConceptRTE. Worked when spoofed as IE 6.0.
- Cross-Browser Rich Text Editor (RTE). Worked fine without spoofing.
- FCKeditor. Couldn’t spoof.
- CMSimple. Worked fine without spoofing.
- TinyMCE. Worked fine without spoofing.
- Through The Web Rich Text (WYSIWYG) Editor. Worked fine without spoofing.
- whizzywig editor. Worked fine without spoofing.
- Xinha. Couldn’t spoof.
Commercial:
- Ektron eWebWP. Worked when spoofed as IE 6.0
- Rad Editor for ASP.Net. Worked fine without spoofing.
- WYSIWYG PRO. Couldn’t spoof with a recent enough client, but it’s clearly spoofable based on what happened when I spoofed as IE 6.0.
