Search:

Safari: standards support gaps and other issues

Safari is, by and large, a browser with pretty good standards support. However, it has a few missing features, a few bugs, and a fair few things that are correct according to the spec but aren’t the same interpretation as other standards-compliant browsers. This page discusses the first two categories of issues: things that Safari should be doing but isn’t, or tries to do but does incorrectly. See also “Safari Surprises” for the third category of issues that are correct, but might not be what you expected.

HTML issues

Safari supports most HTML 4.0 features.

Form elements

• Safari does not support the legend element.
• Like Opera, Safari does not style input elements like radio buttons and text input fields, instead using the default Aqua look and feel. Some people feel that this is a justifiable decision, while others disagree.  Safari does style form items like label and (as previously mentioned) fieldset.

Text elements

• Safari’s early versions did not support the title attribute on links or other elements such as acronym. This is an important accessibility feature. It was added in later release versions and is supported, for example, by version 1.2.
  

CSS issues

• Safari supports CSS1 with few glitches. For more information on  specific bugs, see Mark Pilgrim’s Safari site. For more information on CSS support in general, see the MacEdition Guide to CSS2 Support in Mac-only Browsers. Here are some known glitches with test cases
• Setting border-width in compact notation can result in borders showing even when their widths are set to zero. [test case].
  
• Some elements of CSS2 are not supported, including desirable properties such as min-width, min-height, max-width and max-height, as well as less-used ones like cursor.
• As with all other known browsers, Safari does not support some of the more obscure reaches of CSS2 that did not make it into CSS2.1, such as text-shadow.
• Safari supports advanced CSS features like content with :before and :after, at least for text strings and picture inclusion, but not for attribute extraction using the attr() syntax, or inclusion of arbitrary text files [test case]. However, it should be noted that Safari renders these in a different way to Mozilla-based browsers:
  • Before and after text on links form part of the clickable link in Mozilla, but not Safari. Turning off the text-decoration on the before and after text turns it off for Safari, but not for Mozilla, because it is part of the (underlined) link.
  • Before and after text on block elements like paragraphs, or list items, is on a different line to the main text. This would be ok by the spec, which states: “If the subject of the selector is a block-level element, allowed values [for the display property on before and after text] are 'none', 'inline', 'block', and 'marker'. If the value of the 'display' has any other value, the pseudo-element will behave as if the value were 'block'.”. However, setting the before and after text to have the property display:inline doesn’t fix the presentation.
• Safari supports most CSS table styling, with the following exceptions:
  • does not support padding arround the table element (or variants such as padding-top).
  • does not support border-collapse, border-spacing,row-span or column-span – but to be fair, only Mozilla supports border-collapse properly (Windows IE provides partial support) and no browser appears to support row-span or column-span.

For more information

• MacEdition Guide to CSS2 Support in Mac-only Browsers (covers Safari), or abridged version to compare with browsers that are not exclusive to the Mac.
• Safari Surprises: the things that Safari does right, but different
  
• Mark Pilgrim’s Safari site
• The weblog of Dave Hyatt, lead developer on the Safari team. Contains postings on bugs recently fixed in internal builds.

Go to MacEdition Home| Read Latest CodeBitch Column | View CodeBitch Column Archive