Tag: Safari

Posted on
by

So who’s next? Well, Opera 9 beta 1 is very close—there’s a pair of red squares that should be black, but that’s it. Neither IE7 nor Firefox 1.5 will have much in the way of Acid2-related fixes, though the trunk builds of Firefox show improvement, so 2.0 has a chance 3.0 might make it will pass (since 2.0 will use the same engine as 1.5).

Posted on
by

On Sunday, a development version of Konqueror passed the Acid2 test. In the comments, someone posted a screenshot of iCab also passing the Acid2 test.

I did a double-take. iCab? Das Internet-Taxi für den Mac? The browser with the nice “Make iCab smile” campaign to encourage non-broken HTML on websites but CSS capabilities that have rivaled Netscape 4 as little better than a bad joke? That has been in perpetual beta for years with no sign of shipping a final release?

So I did the only thing I could do. I downloaded the new beta and tried it. Not only did it nearly pass Acid2 (there was a narrow white line across the middle of the face) but it actually handled all the layouts on my own site… something which it had always failed at spectacularly before.

The WaSP Buzz posted a congratulatory note to both this morning. Strangely, iCab is the first browser available to the general public that passes Acid2. The up-to-date Safari is still sitting inside Apple’s development labs, and while you can download the source for the updated Konqueror, you’ll have to wait for KDE 3.4.2—or possibly 3.5—to be able to use it yourself without running a bleeding-edge desktop. Update: Apple has just launched CVS access to WebCore, putting Safari in the same situation as Konqueror: you can download and compile the latest source code if you want, but if you just want to grab an installer, you’re gonna have to wait.

Follow-up in 2024: I’m surprised to discover that iCab still exists, and is still developed — though in 2020 the author rewrote it so it uses macOS’ built-in web renderer (like Safari) and not its own engine anymore.

Posted on
by

Some potentially nasty browser security vulnerabilities found this weekend in Mozilla and in Safari. Both involve software update mechanisms. The Firefox one tricks the browser into thinking it’s installing from a trusted update site (the maintainers of updates.mozilla.org and addons.mozilla.org—the only trusted sites by default—have made some changes on their server to prevent the exploit from working). The Safari one takes advantage of the Macintosh tradition of automatically opening archives. This one just happens to unzip itself into the location where Dashboard stores its widgets.

IEBlog has weighed in with a balanced (i.e. non-fanboyish) comment on just who “us” vs. “them” should mean: responsible developers & security researchers vs. the malicious ones. It won’t happen—people are too hunkered down in their own trenches—and even with Mozilla, Opera and Apple collaborating on specs, I don’t expect to see much in the way of collaboration on security except in the actual open-source world. (Even then, I suspect there’s too much rivalry between Gecko and KHTML developers to do much collaboration.) Continue reading →

Posted on
by

Sometimes you want to know exactly what software people (or bots) are using to view your website. Sometimes all you want to know is which rendering engine’s quirks you need to cater to. To that end, I have here the ultra-simple browser detection algorithm. Just check the User-Agent string for each of the following words, in order:

  1. Opera — they spoof IE by default, so check here first. If they ever change this to something else, you’ll be glad you started here.
  2. KHTML — this will catch Safari, Omniweb and Konqueror. They mention Gecko, so if you need to treat them differently, check for KHTML first.
  3. Gecko — this will catch Mozilla, Firefox, Camino, Netscape 6+, etc.
  4. MSIE — this should Internet Explorer and anything else that uses its engine.
  5. bot, spider, crawler, or compatible — filter out robots and anything unknown.
  6. Mozilla — just about everyone uses Mozilla in their UA string these days, but the rules above should filter most of them out and leave only old-school Netscape.

Of course, Mozilla, Opera and Safari have put much more effort than IE into following the standards, so most of the time you can write your code using the spec and just build in work-arounds. The way I look at it, there are three main categories:

  1. Standards-compliant(ish) browsers: Gecko, Opera, KHTML
  2. MSIE
  3. Everything else

I write for group 1, work-around for group 2 (and sometimes other browsers in group 1), and figure that group 3 (with the exception of Netscape 4, which has a tendency to do things like make links unclickable or hide entire chunks of the page if it doesn’t like your CSS) should at least be able to figure out how the text and graphics break down. It may not look perfect in randombrowser, but it should at least be comprehensible.