Surfin' Safari

Front Page  -  Technorati

We have successfully switched to selecting the appropriate fonts when rendering to the screen (vs. rendering to a printer). Safari still antialiases everything, but at least the same fonts are being chosen as with other Cocoa apps that use AppKit.

One small step on the road to consistency... :)

WebCore 68 is available for download here for those who are curious. The most significant changes to the code from v60 to v68 are the new CSS parser and the new inline box model (which also involved a split of RenderFlow into RenderBlock and RenderInline).

Made some serious progress last night and today on Safari's float handling, especially when floats are mixed up with positioned elements. With all of these fixes macromedia.com's pages render correctly. Woo hoo!

John Gruber writes about antialiasing again. It's an interesting read.

I finished the residual style fixes today. All of the code that I wrote to fix up tag misnesting and to reopen tags across paragraphs works like a charm. I deliberately implemented this code to only execute when in quirks mode, so standards mode pages will not get fixed up implicitly if they use bad HTML.

Proud of myself, I then went through my bug list. All of the pages were fixed except for one. Perplexed, I cut out the relevant snippet and pasted it into a local Web page. It worked! I loaded the page online. Nope, didn't work. I brought it up in Mozilla and WinIE, and the page looked just fine.

Confused I downloaded the entire page to disk. Still didn't work in Safari, but it did work in Mozilla and WinIE! I kept reducing the page until finally I noticed that it had an XHTML doctype.

An invalid page, horribly invalid (two body tags, misnested font tags) , was using standards mode in Safari and Mozilla! Even more mind-boggling, Mozilla actually still applies residual style quirks in strict mode. I couldn't believe it!

Maybe I'm taking a hard-line stance here, but I view fixing up tag misnesting as a horrible quirk that should not be implemented in standards mode. If you don't behave strictly when in standards mode, how will people ever write valid HTML?

I hope that Mozilla's behavior is just a bug.

One of the most critical HTML quirks is a problem that has not yet been solved in KHTML. Consider the following tag sequence found in a real-world screenplay on the Web:

<b><p>Bob:</b> Look out! It's behind you!</p>
<b><p>Carol:</b> What is?</p>
<b><p>Alice:</b> Run!!!</p>
<b><p>Monster:</b> Grrrr.</p>

And so on. This real-world page sends Safari into a nosedive, because it's essentially nesting bold tag after bold tag. Safari allows a paragraph inside a bold tag (as do most browsers in quirks mode), and so it happily builds up a tree thousands of bold tags deep.

Another common example of tag misnesting is the following:

<p><font>I am in a special font, but now the paragraph is closing.</p>

KHTML will currently close up the font tag, and then the following paragraphs won't have the font applied. This is a sensible approach to deal with what is effectively a misnesting of tags, but unfortunately, it's not what Netscape did in the old days, and it's not what WinIE does now.

The problem is that some style (this font) is left over at the close of the paragraph, and this style needs to be reapplied when you open the next paragraph. This residual style can't be lost or forgotten if you want to properly handle tag misnesting.

Another name for this problem is the "Tag Soup" problem, i.e., how do you handle complete garbage HTML. I tend to view the "Residual Style" problem as being a specific subset of the more general "Tag Soup" problem.

Ian Hickson has a a great blog in which he talks about how the various browsers handle this problem.

I am planning on adopting the Mozilla approach to solving this problem, which is to reopen tags that aren't closed properly at the close of a block. I'll also be attempting to identify examples like the first one above, and notice that inline tags got closed in a different scope, i.e., in a deeper block level. This close will be honored, and then I'll immediately close up the inline when you return to the same scope.

It's a shame that so much time has to be spent dealing with invalid HTML, but if you want to work with the real-world Web, you don't have much choice.

Maciej fixed the infamous cookie bug last night, so PHP-Nuke sites will now work properly. Quoting Maciej:

I have a fix for the infamous PHP-Nuke login bug. It should be in the next release. Here's the short version: the Netscape cookie spec says when a cookie comes from a URL like "http://www.foo.com/user.php" and no path is explicitly specified, then the path should default to "/user.php". However, it actually needs to default to "/", because that's what all real browsers do. Don't you love the web?

Another bug bites the dust! :)

Tantek blogs about how Safari messes up his CSS presentation slides. The bug actually is with the following:

<style media="print">...

FWIW, this is issue #5 under "CSS Importing Bugs" on diveintomark's list. It is now fixed.

John Gruber writes about antialiasing in Safari in his blog. The difficulty with antialiasing is that it is ultimately subjective, i.e., people have wildly different opinions regarding what fonts look good antialiased (or not so good).

For example, to me the Geneva example at the end of John's blog entry looks better in Safari than Camino (much better). It's all subjective. None of the antialiased examples look bad to me at least.

That said, what I am investigating is implementing the CSS3 font-smooth property. This will provide author-level control of AA on a site as well as enable users to have control via a user stylesheet, e.g., you could say:

body {
  font-smooth: never;
}

You can also specify cutoff points for AA, e.g., say that only 12px or bigger fonts will get AA, e.g.,

pre, tt {
  font-smooth: 12px;
}

Zeldman writes about a couple of Safari issues. The first issue is Safari's limited support for the title attribute. We're going to dump our implementation in the status bar and just use a tooltip-style implementation instead (and yes, we'll pick up support for acronym and abbr at the same time). This was sort of an intermediate hack to just get something out there for title attributes on links only. We'll dump it once we do the full TITLE support in a tooltip.

Second, the question about .ico files. The .ico file format actually contains multiple bitmaps, which can have varying color depths and sizes. The engine rendering an .ico has to make a decision regarding which ico to use, and this can get pretty complex, e.g., do you take the 32x32 in 16-bit color, or the 16x16 in 8-bit color? The former results in a scale, but the latter is a lower color depth. A naive decoder will simply use the first .bmp encountered inside the .ico, even if it's an inferior color depth.

Safari just uses the Cocoa NSImage object for displaying .icos, and I suspect that the decoder may be pretty naive about its selection of the appropriate bitmap. In my opinion, color depth should be highest priority. In other words you should try to find a .bmp with matching color depth for your screen first, and then prioritize 16x16 above other sizes only after the best color depth has been determined).

I will look into this issue in Cocoa and see what we're doing right now.

I've seen a lot of comments in various Mac forums where people have claimed that "Dave Hyatt said he doesn't like tabbed browsing!" or "Dave Hyatt hates tabbed browsing!" I find these posts perplexing, because I never said any such thing, and of course the opposite is true. I love tabbed browsing. I implemented tabbrowser in the Mozilla trunk. I implemented tabbed browsing in Chimera. I implemented the version used in Phoenix. Given how many times I've implemented it, I'm amazed that people would think that I am not a tabbed browsing devotee.

That said, I wanted to express some of my thoughts about the various UI decisions one has to make when designing a tabbed browsing system.

Target Audience

I think the most important question you have to answer before designing a multi-page system is "Who is my target audience?" In the case of Phoenix the target audience is experts and power users. I do not believe that tabs serve any useful purpose for novice users, because novice users don't ever use multiple views of Web data. They just browse from page to page.

The classic novice user Web setup is to have Windows IE maximized with the sidebar open. That kind of user simply doesn't need tabs. Tabs are total overkill for what that person wants to do with his/her Web browser.

That is why I think ideas like this, although extremely pretty, seem to be targeting an audience that IMO doesn't exist. A power user doesn't want thumbnails, since they wouldn't be easily distinguishable anyway once you opened several tabs, the overflow mechanism for such a system would be clumsy (or would use too much space, scrollbar anyone?), and you lose too much horizontal real estate. Sure, it's got a neat initial "whizzy" factor to it, but it's simply not as usable or as scalable as the classic tab strip model.

Bookmark Groups vs. Folder Options

This is something I've implemented three different ways in Phoenix, Mozilla, and Chimera. In both Chimera and Mozilla the bookmark group is a special entity that you have to make by taking a tab snapshot. I now hate this idea. The implementation is to just have a tagged special folder that when clicked loads all the bookmarks in tabs, a sort of one-click clustered loading. This complicates bookmark management and viewing, since you now have this third kind of entity along with regular folders and bookmarks.

I much prefer the system we came up with for Phoenix, which is borrowed somewhat from Opera. In this system, folder submenus pick up an extra "Open in Tabs" menu item, and you can just load any folder's children in tabs. No special new kind of bookmark group, and no special means required for creating bookmark groups. You just work with folders and can now load a single page of a group by drilling into a folder, or load all the pages in a group.

With the Chimera way, you'd end up having a Blogs group, and then you'd also have to bookmark individual blogs for when you didn't want to load the group. You had needless replication that is avoided by just making the operation available on folders instead.

Replace vs. Append?

When doing clustered loading, we took two approaches. One can be seen in Mozilla, and I personally hate it. The other can be seen in Phoenix and is my favorite choice. Mozilla actually appends the tabs loaded by a bookmark group to the end of the tabbed list. This means that if you click first on a News group and load tabs 1-5 and then click on a Blogs group, you'll end up with new tabs 6-10.

In Phoenix, you replace instead, so the News tabs go away and are replaced by tabs 6-10. The argument for append is basically that you end up with potential data loss in that you may lose access to the previous tabs by closing up some of the ones you replaced, e.g., if the second group has fewer tabs than the first. This is of course a solvable problem, though, and doesn't justify changing the default behavior to append.

Position of Tabs inside the Tab Strip

Chimera centers tabs within the tab strip. Everyone else puts them on the left. The only reason Chimera does this is because I couldn't figure out how to use the normal tab widget to make the tabs be left-aligned. Center-alignment for a dynamic tab system is of course awful, since for every tab you open, all of the tabs move.

It's much better to avoid moving all of the tabs around when a single new tab opens, and left-aligning the tabs inside the tab strip makes for a much less jarring experience.

Where do new tabs open?

A highly debated issue with tabs is "Where should new tabs open?" NetCaptor and the old Chimera (in early versions) use the following model. If you click to open a link in a new tab, then the new page will open just to the right of the current tab. Links will continue to open to the right if you keep opening them, so you may have a setup like this:

1 2 3 4

where 2 is the active tab, and you then open three more links from 2 and end up with:

1 2 7 6 5 3 4

The advantage of this approach is that similar pages stay together. The disadvantage is that the opening of new tabs is more jarring, since you do an insertion in many cases rather than an append.

A disadvantage is that you have to read the pages from right to left in order to preserve the original order. Because of this, when you *close* tabs, this model dictates that you move to the left.

You do have the advantage that when you finish with the child links, you conveniently end up back at the original document as you close up tabs.

The second model, and the one I favor (used in Phoenix, Chimera, and Mozilla now) is to always open new tabs on the far right. Usability testing at AOL showed that this was far and away what users expected to happen, and it lends a smoothness to the tab opening process, since you never move any other tabs.

You also get to read links from left to right instead of right to left, e.g., the previous example would result in:

1 2 3 4 5 6 7

In this model, in order to be able to browse the links you open effectively, when tabs are closed you need to move to the right. Note that when you finish with child links, you don't end up back at the previous page in this case, but in the common case, you do. Note that by far the common case is to simply have:

1

and that you'll open a few links, end up with:

1 2 3 4

and still end up back at 1 once you close up. The ability to easily read left to right, and to not shuffle the tabs around on the tab strip when you open new links more than makes up for the edge case where you may not end up back at the parent tab.

Close Boxes

I actually prefer Galeon's behavior here. Phoenix and Mozilla offer close boxes for the tab strip, but this UI frankly stinks, because the user expectation is that clicking on the X will actually close up the entire tab strip. In effect, the X should map to the "Close Other Tabs" command, but instead it maps to "Close Selected Tab." This is utterly confusing, and at least Chimera avoids the problem by not having a close box at all.

The right way IMO to do this is to have a close box for closing up the tab strip itself in the same place Phoenix and Mozilla have it, but to also have close boxes on the tabs themselves (the way Galeon does it). With this model, it's clear what the different close metaphors are, and you don't end up with user (even power user) confusion.

Background vs. Foreground

Despite the inconsistency with opening links in new windows, I strongly support the default in Phoenix, which is to open links in new tabs in the background by default. This option should be overridable with a modifier key (SHIFT in Phoenix) and also the default should be controllable via a pref. Phoenix, Moz and Chimera all have the same pref and modifier key, but only Phoenix defaults to background loading by default.

It's really interesting just how many different choices have been made by tabbed browsing implementers. Pick the browser that implements the system you like best I guess. :)