Surfin' Safari

Front Page  -  Technorati

Zeldman writes about a Safari bug in his blog. I investigated the problem and have it fixed.

For those who want to add to a list of known issues, the problem is that Safari collapses margins through bottom borders (oops). This means an example like this:

<div style="border-bottom:1px solid black">
<p>Foo</p>
</div>

will put a bottom margin outside the div! Again, oops. The fix has been made.

Wah.

I just read Jason Kottke's article suggesting that Sherlock and Safari merge. Yes, I know, the rest of you probably read it two weeks ago, but, hey, do you want me spending all my time reading blogs or should I fix some Safari bugs every now and then? ;) Anyway, I also read John Gruber's rebuttal on Daring Fireball.

After thinking about the RSS issue in previous blogs it seems that applications like Watson and Sherlock provide a similar service for the Web that RSS does. Again, just like NetNewsWire, they present information to you in a more streamlined fashion, and again, you only fall into the browser when your interest is piqued (or in the case of some of the services, when it's time to buy).

Moreover in the case of some of these streamlined services, unlike news/blog feeds, some of these actually do feel "geekier" to me than the corresponding user interface you might have been presented with had you just gone to the Web site directly.

I wouldn't mind discussing how to tightly integrate applications like NetNewsWire and Sherlock with browsers, but at this point I think both should remain separate applications.

One really good point several people brought up in response to my previous blog about RSS and Web browsers was that many feeds contain only article excerpts.

In other words RSS feeds seem to break down into two categories: feeds that contain only short excerpts of articles and feeds that contain entire articles. It does seem like integration makes less sense if the majority of feeds fall into the first category.

Then the RSS aggregator becomes useful as a filtering mechanism, with the Web browser being used only to view the articles that you ultimately decide to read. In this mode it seems like HTML display is hardly even a requirement for the aggregator application, since you basically just want to speed-read the excerpts from the RSS file and only go into the full blog if you decide that it's worth following up on.

Of course if RSS is going to contain the full blog entry, or if XHTML ever became popular as a syndication format (thus inspiring people to just use their blog pages as their syndication files as well), then some of the things that I said in my previous blog might hold true.

Now that I've started using NetNewsWire to read blogs, I find it frustrating to be constantly switching back and forth between NetNewsWire and Safari. This led me to wonder: should RSS capabilities and browsing capabilities be merged into a single "uber-browser" application?

Do news readers like NetNewsWire and Feedreader contain functionality that should be absorbed into browser applications like Safari, Chimera or OmniWeb? Or is the opposite true? Should some minimal browser functionality be incorporated into NetNewsWire?

OmniWeb already contains a very nice bookmark scheduling/updating mechanism. Imagine if you could bookmark an RSS XML file and have a browser transparently present it as a folder in your bookmarks, complete with an unread count and child items that represent blog entries. This mechanism would mesh nicely with bookmark scheduling/updating schemes that exist already in browsers.

Or consider the other direction. NetNewsWire could instead embed a rich HTML control and manage the display of blog entries for you. One idea I had about blog entries in NetNewsWire is the idea of applying user stylesheets to blog posts so that you could format the blog entries according to your own chosen templates. In effect you could pick the "blog theme" to apply to the HTML snippet pulled out of the RSS file.

Another idea along those lines would be allowing authors to somehow specify links to author stylesheets that could be loaded and applied when a snippet is read from HTML embedded inside RSS. Then the author's look could be preserved without having to go back to the original blog Web page.

Yet another irritation is how difficult it is to subscribe to feeds. I'd like to be able to click on an RSS file link in a browser and have it automatically pass that off to my news application. One click should be all it takes to get me subscribed, whether that click happens in a mail app, a Web page, or inside NetNewsWire itself. A protocol handler would work for this. I think of this as being somewhat similar to the "view-source:" protocol supported in many browsers, i.e., you could just say "rss:original-url" or "feed:original-url" and have the appropriate application configured to handle feed subscriptions.

Tabbed browsing has a role here as well. The same person who voraciously devours news feeds is the same kind of person who loves being bombarded with lots of information, and tabs provide one with a means of efficiently handling a lot of information. This makes Chimera's ability to open URLs sent from other applications in tabs very cool, and might help obviate the need for an application like NetNewsWire to build tabs into its own display.

I've heard a lot of people state that RSS and news aggregators are for "geeks" and "blogging enthusiasts," but I simply don't believe that to be true. It should be possible to make an application for managing a large amount of information flow that is accessible to mainstream users. Browsers are trying to make information easier to manage with smarter bookmarking systems and page management capabilities (tabs), and news readers are emerging that (in effect) push new information to you in as it's posted and allow you to switch rapidly between different information sets as well.

There is also an eerie parallel one can draw on the editing side between conventional Web page editors and the need for specialized blog editor applications. Mozilla has MozBlog for this purpose. Should personal blog management become the domain of a specialized application, a sort of uber-editor that can handle HTML editing/publishing but also blog management/publishing, or should it remain as a Web application like Movable Type that you use a browser to access?

Turns out Eric Meyer's Pure CSS Popups demos didn't work quite right after all. Oh, sure, I fixed the :hover effects so that stuff actually started showing up, but oh my was it not laying out correctly.

The bug turned out to be another one of those frighteningly basic ones. I was mightily embarrassed when I found it. Positioned and floating elements inside blocks with inline children were actually being added to the line. So basically all positioning was busted if you put a positioned element inside a block with inline children.

It's all better now though (crosses fingers).

I spent all day today reworking :hover in Safari. I fixed the repainting problems that exist in v51 when using :hover with positioned elements. I also now have Safari working flawlessly with Eric Meyer's Pure CSS Menus. I haven't tested them yet, but I'm fairly certain that Safari will also now work with his Pure CSS Popups demos as well.

I keep receiving emails from people trying to build applications using WebCore. People are asking me for help or advice on implementing the bridge inside WebCore.

I don't know why people are trying to do this. It should be obvious from looking at the code that WebCore and JavascriptCore are incomplete, and that there are other pieces required in order to build an application around the Safari engine.

If you're trying to embed the Safari layout engine right now, stop it! :) Don't try to build code around these two components.

Update:: Quoted from ADC: "In addition to providing the best web browser for Mac users, one of the goals of Safari is to provide a fast and efficient HTML rendering engine for Mac application developers. Apple is actively
preparing a Safari SDK that will be available later this year."

In other words, all good things come to those who wait, so be patient! :)

Mike Shaver and Chris Blizzard respond to Paul Festa's anti-Mozilla ranting on news.com. Just goes to show you, boys, you have to be careful what you say in your blogs, since you never know when someone is going to come along and quote you out of context in order to satisfy some obsessive need to bash Mozilla.

In the "Did you know Safari could do this?" category comes the following tip. Safari supports an extension for examining the preferred stylesheet set and for setting the current active stylesheet set, so if you want to swap between sets of sheets in Safari, you don't have to loop over all of them setting the disabled property. You can get and set the selected set using an extension on DocumentStyle called selectedStylesheetSet. You can examine the preferred set through preferredStylesheetSet.

document.selectedStylesheetSet = 'alternate1';

We now have XML limping along in Safari. We are treating application/xhtml+xml, application/xml and text/xml as XML files and sending them into the XML parser (expat). If there's any other MIME type we should be supporting, let us know. Now that we can finally see XML, we have to update it to deal with other fixes we made to the KHTML engine, like making XML processing instructions that load stylesheets delay render object construction (to avoid the flash of unstyled content you'd see otherwise), and to fix our XML component so that it doesn't eat whitespace (so that preformatted text will work in XML).

I've just finished merging KHTML's new table code (over in the KDE tree) back into Safari. It fixes a lot of bugs with auto layout tables, especially the way extra width is distributed among cells. Yes, Ben, it fixes your blog. Yes, Joe, it fixes yours too. The new code also supports fixed table layout, so the eight of you out there that actually use fixed tables can now rejoice. ;)

Mark writes that he has discovered a way to hide CSS from Safari. He's called it the Safari Spacer Hack. While it's neat that people finally found a bug in the parser that afflicts only Safari, it's just that: a bug, and relying on these bugs in what should be a standards compliant parser is wrong.

Here is a proposal for a way to include Safari-only CSS:

@-konq-only { .... }

Here is a proposal for a way to hide CSS from Safari:

@-konq-end;

The former would be a special block (similar to @-konq-quirks for quirks mode rules in UA sheets) that other browsers would ideally ignore. The implementation of this feature would naturally depend on other browsers ignoring @ directives that they don't understand. Can anyone confirm this?

The second idea, @-konq-end, would be used within a style block or within an external stylesheet to signal the end of the sheet to Safari. It would then ignore anything that followed @konq-end;.

Thoughts?

In response to comments made on Jan 8 on memeufacture.com about the site misrendering. I've narrowed it down to a basic fundamental problem. Whenever text can't fit on a line with a float, KHTML (Safari's version at least, maybe this has been fixed in Konq) shoves the text down past *all* floats. In memeufacture's case there is a horizontal float stripe across the top and another vertical float stripe down the side. What's happening is that rather than just placing the objects right below the horizontal float stripe, the text is being shoved all the way past the vertical stripe as well.

I've filed a bug. This probably affects a fair number of weblog sites (you guys love your floats), so I'll try to address it soon.

Before sending email, please be aware that I'm not going to comment on future Safari releases (i.e., when they will be, what they will be called, etc.). I am also not going to comment on questions about when particular UI features are going to be implemented, so please - for the love of God - stop asking me if/when UI feature "X" is going to be implemented in Safari.

In Should Safari be intentionally buggy?, Mark brings up the need to have a way to hide CSS from Safari. However all of the suggestions that I see involve ways to include Safari-only CSS, which seems to be the opposite goal. I suppose people want both. I'm certainly open to the idea of a special way of indicating Safari-only CSS, as long as it is in no danger of violating standards and can be done in a reasonable fashion. It seems like finding a way to hide CSS from Safari is more problematic, and it also seems like this would be the more common case.

By the way, Mark, your blog is now fixed in Safari (this is problem #2 on your list). Those who care can bring up khtml/css/html4.css in WebCore and move the -konq-flow-mode properties in the rules for UL, OL, MENU, and DIR into the quirks block at the bottom of the stylesheet.

FWIW, we have also addressed problem #3 and #5-#7 (this was a bug in our image renderer and is not a bug in KHTML), which means #1-#3 and #5-#7 have all been fixed. You keep filing, we'll keep fixing. :)

Blogger Pro blocks Safari. I wonder what UA check they do. It must be more sophisticated than simply looking for the word "Gecko" in the user agent string. Blogger, if you're listening, you can treat us just like Mozilla. We will work. What do you think I used to post blogs on the Mac before you started blocking it? :)

I started looking into these CSS issues today. The first issue on Mark's list is that outside list bullets inside an li with text-align: right (either explicitly specified or inherited) are not positioned next to the text content. I think we're off to a good start, because I believe that Safari is not only correct on this test case, but that every other browser is rendering that page incorrectly.

I refer you to paragraph 7 of section 12.6.1 of the CSS2 spec. Essentially since the bullet should be positioned relative to the line box, text-align is not going to have any effect on its position. It will be just outside the line box. To achieve the rendering effect you desire, you should just set list-style-position to inside.

[Update: Boris Zbarsky informed me that the language I referred to is no longer present in CSS2.1. Thus the positioning is now ambiguous, so it's sort of left up to the browsers to decide how to position. I will, however, note that the CSS3 Lists draft does clarify this situation in favor of Safari's interpretation.]

On to issue #2, which is much more obviously a bug. :)

The issue with VersionTracker's front page has been addressed. The page is actually malformed, and we had to improve our error handling code to deal with the malformation. (A stray div wrapping random table cells inside a table.) Note that this was not a bug in Konqueror but was a regression in Safari only.

A number of people have commented on Safari's UA string, which is as follows:

Netscape 5.0 Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-us) AppleWebKit/48 (like Gecko) Safari/48

The portion of the UA string that seems to be stirring up controversy is the portion that says (like Gecko). The reason it is there is that in order to work with real-world DHTML sites you have essentially two options: you can claim to be MSIE or you can claim to be Gecko. We found that any other choice that we tried led to a significant portion of DHTML malfunctioning. You would not believe (well, maybe you would) how much DHTML exists out there that works only with MSIE or Gecko, and that uses proprietary extensions of each to accomplish the DHTML effects.

Had we released a browser with a UA string that did not superficially match either MSIE or Gecko, users would have downloaded Safari and experienced many malfunctioning Web sites. If anyone thinks that would have been a good idea, please step forward in your blog and explain why. I'm willing to listen.

Our solution was a compromise. We produced a user agent string that is different from Gecko's and easily distinguishable if you choose to sniff for it, but that at this time will pass most UA checks that sniff for Gecko. It may be that enough sites will start sniffing directly for our string that we can drop the "(like Gecko)" from our user agent string, but I'm not optimistic.

We chose to be more like Gecko than like MSIE because we wanted to be lumped into the standards compliant category, because fundamentally we are committed to supporting DOM 1&2, CSS1&2, and enough proprietary MSIE extensions and Gecko extensions (innerHTML, createContextualFragment, offsetWidth/Height, etc.) that we could be placed in a similar category.

That's all from my end. I welcome constructive feedback on this issue.

As reported on numerous blogs, Safari can't run the CSS1 test suite. This had to do with missing support for <object type="text/html">. We have fixed this issue and are now able to run through the suite. Thanks to the many bloggers who pointed out the problem.

Various members of the Flash community have been reporting low frame rates when using Flash in Safari. I'm pleased to report that we have corrected the problem. The issue was not in WebCore, so I can't post a patch, but the issue has been addressed.

You can check out this article on Slashdot that outlines one approach. I'll just add that if you want to avoid copying the frameworks, you can set DYLD_FRAMEWORK_PATH instead, and then you can leave Safari.app alone. Thanks for saving me some time by writing this article! :)

Just a little update to let you know that we have Safari working at 96dpi now.

Eric Meyer writes in his blog:

Meanwhile, I've heard credible rumors that Apple, while it was working on Safari, filed Bugzilla evangelism bugs so that the Standards Evangelists at Netscape (of which I'm one) would get the sites to fix their code to work with Gecko and other standards-compliant browsers. This would then, they apparently hoped, get the sites working in Safari as well. If this turns out to be true, I'm going to be furious; just the idea that it could be true makes me angry. I don't mind helping out Apple. I'm a Macintosh guy and have been for more than a decade now. I do mind being tricked into doing their work for them. Hey, guys, what's wrong with saying, "We're both working on standards-based browsers, so let's work together to get sites to support standards?" You know, being honest? How about that? Anyone think of that?

This is a ludicrous claim and is completely without merit. I challenge you to either retract this statement or back it up with hard facts. As far as I know, I am the only member of the Safari team to have ever filed a bug on the evangelism component in Bugzilla, and the only bugs I can think of that I did file were discovered while using Phoenix or Mozilla. As an example, I pointed out wsj.com's broken "Netscape6" check in the user agent and filed an evangelism bug. I still develop for Phoenix and use it on Windows. Should I avoid filing bugs on Mozilla that if fixed will make Gecko work with more Web sites simply because my email address ends in "apple.com"?

Scott Andrew writes in his blog:

Word is trickling in about the new Apple browser called Safari, which was apparently announced at Steve Jobs' keynote at MacWorld SF. The rendering engine is built on something called KHTML, which may be the KDE library of the same name. Apparently built for speed, the Apple page boasts of support for XHTML, DOM, JavaScript and Unicode, but provides no details as to the level of support (according to the docs, KHTML itself only supports DOM Level 1 and CSS 1, so I don't hold out much hope) for these technologies.

KHTML supports much of DOM level 2 and CSS2, including the DOM level 2 event model (e.g., mutation events too!) and rich selector syntax (even a little bit of CSS3 selectors). In addition we have added and fixed CSS support in a number of key areas, including partial support for min/max-width, better support for z-index (including support for auto z-indices), and better support for the CSS white-space property.

A patch has been posted to address issues with visual Hebrew support. We are examining the patch (especially since it involves Apple-specific #ifdefs), so stay tuned for more details. The patch is here.

I will be providing instructions shortly for how to run a modified Safari with WebCore or JavascriptCore changes, so watch this space.

I will be responding to other bloggers' comments on Safari as I discover them. This first response is to some of the comments raised on diveintomark.org.

Initial attempt to load my home page failed; it downloaded the page instead. The user-agent sent by the browser is Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-us) AppleWebKit/48 (like Gecko) Safari/48; my server is picking up on the word "Gecko" and assuming this is a Mozilla derivative, and sending my site with a MIME type of application/xhtml+xml, which Safari apparently can not handle. I’ve fixed the error on my end, but if this has already happened to you, you will need to empty your cache (under the "Safari" menu) and try again.

XML support (sent as one of the XML MIME types) is not present yet in Safari, since the Qt component used for XML parsing has not been ported yet. This means that XHTML1.0 will work as tag soup (if you send it as text/html like wired.com does), but true XML support is not there yet in the beta.

My home page now renders, but only partially. None of the links on my navigation bar show up. Konqueror is the only other browser that exhibits this behavior. (This makes sense, since the two browsers are based on the same rendering engine, KHTML.) This was the one known bug I decided to ignore in my redesign six months ago. Guess it’s time to finally work around it.

Narrow it down to the smallest possible HTML snippet, and send me the source (hyatt@apple.com). I'll take a look.

According to Matthew Haughey, Safari defaults to 72dpi rendering of type, instead of 96dpi. All other modern browsers on all platforms default to 96dpi. This means that any site that uses relative font sizes (or no font sizes) will display 25% smaller in Safari than in any other browser. (Mac users had this problem 5 years ago, when Netscape 4 defaulted to 72dpi rendering, and fonts were displayed 25% smaller than IE 4 for Windows.)

I believe that Chimera does not use 96 DPI, and that our rendering, although unlike Gecko and IE on Windows, is actually fairly similar to Chimera in this regard. At the moment we are using 72 DPI, although much of that decision has to do with problems we're wrestling with over Cocoa NSFonts handling DPI for you (internally), which meant that at 96 DPI, we had larger errors between "px" and "pt" sizes. In order to simulate 96 DPI correctly, we will have to apply a correction ourselves.

It's out. Download it here. Yes, I am a member of the Safari team at Apple. I work primarily on the WebCore, the open source portion of Safari that contains KHTML (as well as the implementation of the Qt subset required to support KHTML). In future blogs I'll be talking about some of the changes and architectural improvements that we made to KHTML and explain those in more detail, but for now I'm going to get some much-needed sleep. :)