dive into mark

I’ve downloaded and installed Safari. This review is mainly for web designers who need to support this new browser. It is in no way a judgement on Apple. All browsers have bugs, and all web designers need to know about them.

Update: Safari test cases showing the various CSS and other rendering bugs (and successes) discussed below.

• 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.
• 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.
• It does not center my hr separator.
• It can not render a single page of the W3 CSS test suite. Not due to CSS problems, but because on each page it gives this error: Plug-in not found. This page “xyz” has content of MIME type “text/html”. You do not have a plug-in installed for this MIME type, so this content can not be displayed.
• It has problems rendering many of the examples on CSS/edge.
• It is probably susceptible to many of the same CSS tricks used to hide stylesheets and CSS rules from Konqueror 3. See Will the browser apply the rules?
• Update: confirmed, it is susceptible to the Simplified Box Model Hack, Fabrice’s Inversion, and the star html bug. It is impervious to all other CSS hacks listed on that site.
• Update 2: it is susceptible to Tantek’s inline high pass filter.
• It incorrectly places the TFOOT (table footer) section above the TBODY (table body) section. This bug can be seen at Will the browser apply the rules?. The table (which ironically lists CSS hacks) contains THEAD and TFOOT sections showing browsers and versions; Safari renders both before the table body. (More thoughts on this bug, and a simple TFOOT test case.)
• It correctly renders position: fixed elements.
• It renders all styles of bullet-proof rounded corners correctly.
• It does not render floats with negative margins correctly.
• It correctly renders the numbered code listing experiment.
• Bughouse demo. It appears that Safari shares a bug in IE6 and Opera 6, where a floated element will wrongly honor the height of a contained float.
• It appears to render nested absolutely positioned boxes correctly, but it has issues with nested relatively positioned boxes.
• 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.)
• According to Todd Fahrner, the problem is not that safari defaults to 72dpi logical resolution. The problem is that it records the user font size in units that vary with logical resolution: points. Apple seems firmly stuck on the idea that 1px=1pt (actual display res be damned), and that font sizes are properly specified in points, period.
• It does not display title attributes in any way. Most browsers display them as tooltips when you hover over a link with a title.
• The bookmark manager is quite elegant; it looks like iTunes.
• The browser application itself does not support tabbed browsing.

Dave Hyatt (one of the developers of Safari) responds to this review by asking for test cases. Coming up! First test case: float:left div followed by text-align: right div containing list items. This is why my right-hand navigation isn’t showing up in Safari; it’s positioning the right-aligned list items incorrectly.

Michael Hanscom notes that the previous paragraph triggered another bug. I’ve added it to my master list of Safari test cases.

Reviews elsewhere:

• Mena Trott: Initial reactions to Safari.
• Todd Dominey: Safari, New PowerBooks.
• TheMacNews: Apple launches new browser named Safari.
• Insanely Great Mac: Apple’s Safari goes on the Browser War hunt.
• MacNetJournal: Let’s go on a Safari.
• codepoetry: Safari: First Look.
• Matthew Haughey: Thoughts on Apple’s new browser, Safari.

§

Respond privately

I am no longer accepting public comments on this post, but you can use this form to contact me privately. (Your message will not be published.)

§