Because Safari’s CSS support is pretty good, there is less need to do this deliberately than is true for (pre-WebCore) OmniWeb and iCab. However, there are things that hide CSS from Safari whether you want them to or not. Some techniques for hiding CSS from beta version of Safari were fixed in subsequent release versions. The canonical summary of CSS-hiding or filtering techniques can be found at dithered.com. There does not appear to be any technique that hides CSS from Safari alone, or passes it to Safari alone. In general, some combination of Mozilla-family browsers and IE will behave the same as Safari in response to certain filters.
OmniWeb version 4.5 is based on the same WebCore engine as Safari, and should be considered along with Safari 1.0 in terms of its standards support.
There are some differences between OmniWeb 4.5 and Safari in terms
of font handling. For example, on a fairly standard Panther system, the
cursive
font-family keyword defaults to Zapfino in OmniWeb
4.5, but Apple Chancery in Safari 1.2.
Safari is Apple's branded web browser based on the KHTML rendering engine. The KDE organisation documents CSS support in Konqueror, which uses the KHTML engine. However, Apple have made some changes and improvements to the engine which means that Konqueror's features cannot be assumed to apply to Safari. Properties that have been assumed to be supported in Safari based on the Konqueror documentation or statements by Safari developers are marked with an asterisk. Properties that are marked as OK without asterisk have been personally verified by CodeBitch using at least one standard test page from the W3C, MacEdition, Richinstyle or David Baron’s site. Mark Pilgrim has compiled a list of specific bugs, along the lines of MacEdition’s Bug Guide for IE5/Mac. The most obvious problems are listed below: see “Safari: standards support gaps and other issues” for more information.
Prior to v60, Safari did not support tooltips, for example as defined using atitle
attribute. This was fixed in build
60; your title attributes can now be seen in the status bar, if the
user
has configured their browser to show it.
Safari had some issues with borders in the early beta versions, with dotted borders being drawn as dashed and in the wrong place. This test page demonstrates some problems with zero-width dotted or dashed borders. These issues were fixed in a build subsequent to v60.
Safari supports the content
property
in the context of :before
and :after
pseudoelements, but only text strings and images are supported in beta
versions, not attributes or the arbitrary inclusion of text files. This
was fixed prior to the release of version 1.0. In addition, before and
after text on block elements like paragraphs, or list items, was on a
different line to the main text. This would probably be ok as the
default behaviour, except that you can’t force them to display inline
using the display
property. Some examples are available in this test page. All
of these problems were fixed prior to the release of version 1.0.
Safari does not style form elements using CSS, but instead presents them in default Aqua styling.
Several important bugs were fixed between the original beta release and the beta released on February 12, 2003 (v.60).
Safari failed some W3C tests of forward-compatible parsing, including the following:red
to be quoted in rulesets, as in color : "red"
;text-decoration:
underline ridiculous
; This page was compiled by CodeBitch and hosted by MacEdition, based on analysis of the CSS1 and (some of the) CSS3 Selectors Test Suites provided by the W3C, Eric Meyer’s CSS2 Test pages, CSS2 Test pages provided by Richinstyle, and CodeBitch’s own tests of CSS compatibility, with added information from pages provided by Johannes Koch, Albin.Net, Ian Hickson and David Baron. Some information was initially drawn from other compilations of bug information for Safari, and from the Konqueror documentation, but all such information has been independently verified by CodeBitch.
No warranties are given on the correctness of this page, since this depends both on the correctness of the tests and correctness of my interpretation of the tests. All reasonable efforts have been made to ensure accuracy. Corrections, clarifications and updates for new versions of these browsers will be gratefully appreciated. Thanks are due to Matt McIrvin, the rest of the MacEdition staff, and numerous dedicated web developers with Macs, who have sent comments, diagnoses and screenshots.
Last Modified: 15 November 2003 (9:30PM AEST)