Tag Archives: Safari

On broken HTML

From time to time the idea is put forth that Opera (and Firefox, for that matter) needs to start dealing with bad code. There are two problems with that view:

  1. Opera already deals with quite a bit of “bad code” (but there’s always room for improvement)
  2. Just dealing with bad code isn’t enough: you have to deal with it the same way someone else does.

#2 is the tough part.

The rules for dealing with good code are, for the most part, specific. If you encounter well-formed HTML, you can be reasonably sure you know what the author meant. But there are very few rules for dealing with bad code. Trying to "deal with it" means trying to guess what the author meant, and sometimes different assumptions are equally as likely.

Example:


<p><b>Here's some text</i> and here's some more.</p>

Did the author close the non-existent italics by mistake, meaning to close the bold? Or did he open bold by mistake, intending to open italics? Or is the closing italics tag left over from copy-and-paste? Depending on what assumptions the browser makes, it should display it as:

Here’s some text and here’s some more.

Here’s some text and here’s some more.

Here’s some text and here’s some more.

And that’s just a simple example. It gets wilder when you throw in issues like inline vs. block elements. A paragraph should never appear inside a tag for text formatting, like bold or italic. By all rights, starting a new paragraph (or more precisely, ending the previous one) should also revert to plain formatting. But a lot of old pages expect the formatting to continue into the next paragraph, because way back when, a P tag was a double-line break, not a container.

Now, suppose that Browser A always makes the first assumption, and Browser B always makes the second. If someone tests their code in Browser A, and it happens to be what they want it to do, they won’t necessarily notice that their code is broken. The result: the site looks wrong in Browser B, and the page author — who thinks the page is fine, since he tested it in Browser A — blames Browser B.

Multiply that scenario by millions of pages and you have a large chunk of the web as we know it today.

So the solution isn’t just to “handle bad code.” It’s to handle that bad code in the same way that the dominant browser handles it. And since there’s no document you can look to for guidance, that means taking every possible chunk of bad code, running it through the other browser, and seeing what it does to it.

And there are a lot of ways to break code!

Even Microsoft did this back when IE was new. At the time, lots of people were writing broken code and testing it by seeing whether it looked right in Netscape. So IE had to make the same assumptions Netscape did on certain things. Once IE became established, they diverged.

Some relevant articles:

This post originally appeared on Confessions of a Web Developer, my blog at the My Opera community.

IE/Mac: The Final Nail

The WaSP is reporting that Microsoft will end support and cease distributing Internet Explorer for the Macintosh at the end of January. It’s been about eight months since the latest version of Mac OS X shipped without IE, and almost three years since Apple launched Safari.

While there is an “end of an era” feeling to this, it’s kind of like losing the last veteran of World War I. It’s of more historical significance than anything else. When Microsoft released IE5/Mac, it was hailed as the most standards-compliant web browser available. But Microsoft abandoned it years ago.

Fortunately, not only is Safari a worthy successor, but there are other options as well. What’s great about the web browser field these days is that the major players are constantly improving their offerings and working toward greater compatibility. And soon any website that wants to cater to Mac users will no longer be able to fall back on “Just use IE!” They’ll have to test in Safari, and of course the easiest way to build a website that works in IE/Win, Safari, and Firefox (the two defaults and the major alternative) is to start with standards-based code in the first place—which improves compatibility with even more browsers. Users get more choices, and websites get more users. Everyone wins.

Acid2 Timeline

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).

Going on Safari

Safari LogoA few days ago I noticed that while Safari accounts for about 2.3% of traffic to this site, Mac OS accounts for 4.4%. Since Safari only runs on Mac OS X, that means that just over half of Mac users visiting this site* are using Safari.

I realized that the detail page pulls out Mac OS X, which makes up 2.8%…but MSIE doesn’t say whether it’s running on Classic or OS X. Fortunately IE 5.2 is OS X-only, so we can add in that 0.6%, leaving us with an estimated 3.4% on OS X and 1% on Classic.

So, to the extent that these stats are reliable…

  • Nearly one fourth of Mac users visiting this site are still running an obsolete version of the OS.
  • 65% of Mac OS X users are using Safari, with only 20% on Internet Explorer.

Anything more detailed is going to require going through the logs myself or writing my own stats script, so I have no idea how the remaining 15% breaks down.

*All of hyperborea.org.

iCab beats Acid2?

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.