Part of the reason that Opera has the PDA-rendering features is that they are one of the leading browser makers for smartphones and such. Indeed that market (along with other embedded browsers) is their main business. Combine with the ability to view any page as a text-only page (via a style sheet) or as a high-contrast page and Opera becomes a must-have tool for the serious web developer.

But of course, this hype does have its positive aspects, as many webmasters (especially here in Germany, where Firefox has a usage share near 30%) do standardize their pages.

But unfortunately, this causes a concentration on two browsers, not on one - which isn’t as bad as it was, but as you said some websites don’t work with other browsers than Firefox and IE, which is as bad as if they only worked with IE. Some websites simply don’t want to work with Opera & Co., even if they could. I don’t know why they don’t, but that’s not nice in my opinion.

Some things to add to your statements about Opera: As someone said before, Opera tried to be mostly standards compliant since its birth. Well, Opera’s programmers tried, most of the time But the important thing is, that Opera never - in contrast to Netscape and IE - tried to be better than their competitors with dirty tricks like adding some non-standard codes or interpret code from their rival knowingly wrong. OK, they had serious problems with some valid code. But they always wanted a web which anyone could access with any browser.

If this sounds a bit like statements from a fanboy, you’re not far away I bought Opera as it was in version 7.54, and I’ve never regret this.

One thing more to add: You can save more than one entry per field with wand. Just enter your second entry (like a second user name or a second email address) and let wand save it. When you then hit Ctrl+Enter (well, I don’t know what this is on Mac), Opera asks you which entry you want to enter.

And of course you should take us Europeans seriously

Best regards,
Sebastian

PS: Sorry for my sometimes weird English. Should be better as it is

Yeah, and speaking of world domination… as the Anonymous poster who followed you makes clear, Microsoft clearly dominates at the moment and has his brainwashed minions running around naysaying everything that doesn’t fit into the MS “world view.” To even have a chance of breaking through that kind of FUD, you’ll have to hold your nose and get WebKit to run on Windows, a la Firefox.

Nice article, I thought I’d clear up a few things about the WebKit project for you. First, autofill doesn’t work in WebKit.app because WebKit has switched from an NSTextField-based implementation to a more cross platform one. This has broken autofill since Safari doesn’t know how to talk to the new text fields. This will be remedied with a newer version of Safari. And just to make sure you don’t think this change was a mistake, the new text field code allows styleable text fields in WebKit (WebKit also has styled buttons now).

Second, OmniWeb 5.1 is so slow in the JS tests because it uses a very old version of JavaScriptCore. Try the new 5.5 sneakypeaks (http://www.omnigroup.com/ftp/pub/software/MacOSX/.sneakypeek/), which use a newer version of WebKit than even Safari does, and you’ll see that it’s much faster.

Finally, as you noted, the WebKit team is currently pushing hard towards making WebKit more cross platform. There is even a Windows test browser that you can compile called Spinneret (not nearly complete though). They are trying to make as much of the code base portable as possible, not just for Windows and Linux, but to make it easier to port to platforms like Nokia’s S60 cell phone. Quite simply, they’re on a quest for world domination.

Just cosmetically, the vertical line that you can see through this transparent comment reading area is rather distracting.

Also, G4- and G5-optimized Firefox builds can be found here. They’re a bit more peppy than the official Firefox build, but still not as lean and mean as Camino.
http://www.beatnikpad.com/archives/2006/04/19/firefox-1502

Tim, you’re obviously a Cocoa guru and one of the reasons the Mac has such great software. Learning Cocoa is on my wish list, and I’ve starting thumbing through a few books on Objective C and Cocoa. Got the new xCode the other day and am determined to make the time to do some more reading and experimenting this weekend! What you say makes sense now, but I’m glad you also view it as a bug. If I understand the technique correctly, it means you can’t select and drop in the same window… which is, of course, what most people would want to do on a web page. I find I can select in a different window and drop into the text field that has been previously selected, just as you and Niklas have said. It’s a workaround, but a pretty kludgy one.

Wacko, thanks! I was almost ready to take the offending sentences out. After all, I did write them in the heat of the moment, and they aren’t absolutely necessary in order to make my point. But still, I agree that in this case people are just being “knee-jerk” offended.

Reid, I completely agree that the Mac market share is larger than the sales numbers indicate, and that there are many old Macs out there still running OS 9 and earlier. One thing, though. The numbers I used in the article weren’t based on sales data… they are both from web server logs as reported by Net Applications. Their data report that 4.3% of the site visitors are using a Mac (this covers all possible versions of the Mac OS, not just OS X), and they also report that 3.3% of visitors are using Safari. That’s how I got to my conclusion that 75% of Mac users are running Safari.

Garrett, actually, when you rearrange the Safari Stand tabs in the sidebar, your actions also move the horizontal tabs. At least, it does that for me. Stand has another way of doing this, too, though it’s a bit hidden. Right-click on the Safari toolbar and open the Customize pane. Drag the little “gear” icon to your toolbar. I find this little icon to be very useful. Take a look at all the stuff you can do here:Copy URLCopy TitleCopy Link HTML TagCopy Link as Markdown (I haven’t tried that one!)Show Page Info (this is similar to, but better than, Safari’s “Activity” window)Related Cookies (this is a submenu showing you all the cookies this site is reading from)Sub Resources (this is again a little like Page Info, but you can select any of the page resources and load them into a new tab), and finally Arrange Tabs. This brings up an interface devoted solely to rearranging the tabs, after which you dismiss the sheet and return to your regularly scheduled browser window).Oh, and I’ll give SafariTidy a try… thanks for the tip! I’m sure that at least two of the errors are for the two IE hacks I’ve still got in place. In fact, having Opera and Firefox continually reporting those errors to me is one reason I decided to forego even more IE hacks this time around. Those aren’t my site’s errors… they’re there because I was trying to feed something special to IE!

Jeff Schiller, I don’t think we have any arguments worth arguing about. If you’re coding to standards, and the site doesn’t work in Safari, I agree it’s Safari’s fault, not yours. And if you are doing that, then you should have no worries that your site won’t work in Safari. Yes, Safari has its share of bugs, but no more than the others. I assume that if a reader writes to you with information about a Safari bug, you’d try to get enough information from her to make a fix. It’s not ideal, but I recommend that Windows developers without access to a Mac pay a visit to iCapture (http://www.danvine.com/icapture/), BrowserShots (http://browsershots.org/), or BrowserCam (http://www.browsercam.com/) to get a screenshot of a questionable page in Safari. Browsercam also offers a for-fee service where you can log in to a remote computer (various, Windows, Mac, Linux) for half an hour to test something. I’ve done this frequently to quickly see how something looks in IE6 or IE7.

Chris, absolutely Safari’s testing tools generally suck. And there’s no documentation for them that I can find. Enabling the debug menu isn’t hard if you’re a developer, but what to do with some of the lame-looking tools you get isn’t so easy. The JavaScript debugger is practically useless. I have a link in the article to Web Inspector, which as I say is brilliant. If you’re doing Ajax and DOM scripting, it gives you 50% of what you need to debug your code. But what works for me is to run Opera for its JavaScript error console, Firefox for Firebug, and WebKit for WebInspector, testing in all three as I go.

Opera Lover, sorry if I got anything about Opera wrong. I am definitely a newcomer to the Opera “community.” My statement was based primarily on the fact that Opera 8 so hopelessly screwed up a number of CSS elements of this site, when no errors were being reported. Opera 9 seemed to wave a magic wand over my site and fixed everything! (Except for opacity… I have to do a special workaround to keep Opera from leaving elements at less than 100% opaque after a fade-in effect. But no biggie.)

And finally, Anonymous… thanks for the followup. You make some very good points. Designing accessible websites is actually pretty hard. There are definitely some parts of this site, for example, that just won’t work without JavaScript. (But nothing really essential.) I’d like to look around and see if someone has cooked up a good script to deal with that… it would just mean rewriting the script in PHP if an anti-JavaScript visitor is detected. It’s OK… there will always be people who think JavaScript is evil, just as they might think cookies are evil. As I see it, those technologies are here for us to enhance the web experience, but shouldn’t be used to exclude anyone. In my day job, being responsible for managing a public organizational website, I would never take the kinds of design risks that I do here on Mars.

I don’t think that %market share and %user base are analogous as you assume. There’s a lot of background chatter on the web about macs being used for years longer than your typical dell - less computers sold because less computers junked for new. I wouldn’t be surprised if the amount of mac users browsing the web is twice that market share number, or more.

As others have pointed out, you can drag into a TEXT field as long as it’s the field with keyboard focus. This turns out to be due to the fact that TEXT fields are implemented using NSTextField whereas TEXTAREA fields are implemented with NSTextView.

An NSTextField (generally used for single-line text entry) actually doesn’t handle any editing, either by typing or by drag-and-drop! When you click on one, an instance of NSTextView (the “field editor” in Cocoa terms) is drawn in place of the NSTextField and handles all the editing. When you tab away, the NSTextField is updated with the new text and the field editor is removed. (If you’ve tabbed to a different text field, then the field editor instance is reused for that new text field.)

This is a holdover from OpenStep. It’s normally invisible to the user, except when it comes to dragging text where it fails miserably. I’ve asked Apple to fix this (perhaps by having a “field drop editor” instance of NSTextView in addition to the “field editor” which could be used for handling drags) but so far they haven’t. (Although they did fix one particular instance.. I used iChat as an example in my bug report, and they’ve implemented a workaround in iChat to deal with this. iChat will make its NSTextField active as soon as you drag anything into it, thus causing the field editor to handle the drag.)

On that off chance that anyone at Apple reads this, the bug is in radar with problem ID 3494372, filed November 25, 2003. It was closed and marked as a duplicate shortly after.

If anyone’s curious about the Cocoa field editor, see http://developer.apple.com/documentation/Cocoa/Conceptual/TextEditing/Tasks/FieldEditor.html

In the case of Safari and other WebKit browsers, this may be moot once the support for CSS-styled text fields goes in.. as in that case it won’t be using NSTextField anymore. See http://webkit.opendarwin.org/blog/?p=51

Thank you for the article, Leland. It was very enlightening and in no way offensive. I’m always eager to learn about different ways of doing things as well as different ways of thinking. I guess others are not as open minded.

Since Macs reputedly have a longer useful life, or at least a longer purchase cycle, than the average PC, the installed base of Macs is likely greater than 3.3%. I’d wager there are still a significant number of Mac users out there running IE on older hardware/OS combinations.

I also really like SafariStand. But with regards to it being able to rearrange tabs, that only counts for the tabs in its own vertical sidebar. It doesn’t do anything about Safari’s standard horizontal tab bar, save for adding the feature that lets you easily go back and forth between tabs by just pressing comma and period. I’ve grown so used to that that whenever I sit down at a Mac that doesn’t have that installed, I find myself furiously pounding away at the comma and period keys, wondering why the tabs aren’t switching…

Different browsers. Different environment.

Actually, Leland, I did read the article and what you said is “when they fail to include Safari in their compatibility testing, they are basically thumbing their nose at Mac users. In my world, that’s not just a nasty thing to do, it’s also illegal.”

I code to standards, and then I work around IE problems. But I do not include Safari in my compatibility testing. Why? Because I have a PC with Windows installed. I can freely install Linux to test on Konqueror, but to test on a Mac I either have to buy a Mac or buy the MacOS and run it in an emulator like QEMU. So far, I have done neither. Am I committing a crime? Mac users have at least FOUR browsers they can choose from that should work (Opera, Firefox, Camino, Seamonkey) so that’s why I feel justified in my current process.

Actually I would love to test in Safari, because I’d like to see what their level of SVG support in the nightlies are like (this is my current area of research). If someone wants to point me to the best way of doing that on a PC, I’d be delighted.

Great article btw, except for the “illegal” crack…

As soon as Ajax enters the picture, it’s a whole new ballgame. I find developing for Safari difficult because it has no JavaScript debugging capabilities. You have to enable a console via a hidden preference and the error messages it spits out are less than helpful. So you’re basically limited to debugging via alert(), which sucks.

I’ve seen screenshots of a DOM inspector in the works for Safari, but that really only helps with troubleshooting layout bugs.

Also — as far as I know, Safari doesn’t have a rich text editor component as Gecko and IE do. That’s an increasingly useful thing to have as web apps get more sophisticated.

{{For that matter, it’s perfectly usable without style sheets AND Javascript.}}

For the bulk of your page, that’s true… have you ever tried to view the comments without javascript…?

(don’t tell me… freedom of speech only applies if you’re using a modern browser!! )