6

I have a website. I've been testing crossbrowser on my windows PC, and it looks good in all browsers, but on Mac in Safari it looks like the CSS is not getting interpreted right, or there is a critical javascript error.

When I look in the console cross-browser, the error log shows exactly the same. Chrome on mac interprets the site as intended, so why do I have a problem with safari?

It is the same across different computers, and iphone safari also shows the site wrong.

How is this possible and how do I debug?

gnat
  • 21,442
  • 29
  • 112
  • 288
Jakob
  • 1,025
  • 2
  • 9
  • 8
  • 1
    What happens if you spoof your user agent? – whatsisname Nov 03 '13 at 21:12
  • 1
    it would be useful if you post the CSS in question – aldo.roman.nurena Nov 03 '13 at 22:36
  • 6
    wow, nearly 40 separate JS and CSS sources. Have fun debugging that ;-) If unable to find the source of the problem (which you do not sufficiently describe in your question), just apply the standard debugging protocol: fork the source, and remove irrelevant cruft until you are left with a [**minimal, reproducible example**](http://sscce.org). – amon Nov 03 '13 at 22:43
  • 3
    what version is your safari on mac? latest on mac is 7; latest on windows is 5.1. – imel96 Nov 03 '13 at 22:44
  • 1
    Welcome to website development... different browsers, different versions, different platforms... compatibility hell. Just try to keep things simple and test on all necessary devices as often as possible. – Rocklan Nov 03 '13 at 23:27
  • "_so why do I have a problem with safari. It is the same across different computers_" Obviously, it isn't. Safari, just like all other browsers, comes in a variety of versions and has different behaviors on different platforms. – Ross Patterson Nov 04 '13 at 00:34
  • what version of safari on each os? safari for windows has been discontinued...i think last was 5.1 – albert Dec 19 '13 at 03:27

2 Answers2

13

I'd attempt to enlist the basic clues over browsers which provide the visual differences, based on my own experience (and efforts) in that direction:

  • The fonts. The browser uses fonts (via the font-family css property) to display text on the page. Most of these fonts are coming from the operating system, so here is a short list of what can go wrong with that:

    • The different operating systems have different font families pre-installed, and when a certain font is missing, it is silently substituted with another. Moreover, the font that is used for substitution may be a native to the OS and specific to that particular OS only.
    • A particular font with size of 10px for instance, can look larger or smaller as the same 10px-sized font on another operating system.
    • The font appearance is determined also by the clear type effect, which is supported in different manner under the different operating systems. This feature may be disabled by default or not available at all on some OS-es. For example, Windows XP has it disabled, and below Windows versions do not support it at all, as far as I know. Under XP, you can also enable the clear-type only for the browser, not the entire OS, if you use IE7 or above. The lack of clear type will make a font look pixelated, and thus quite different from their clear-type-enabled version. Furthermore, the clear-type itself can be fine-tunned for best appearance, so one's personal settings may also cause slight difference in the look-and-feel of the text.

  • The rendering engine. The browsers use engines of their own to display the website and execute scripts, called rendering engines. The most popular browsers today come with rendering engines each of their own:

    • Trident is used by IE
    • Gecko is used by Firefox
    • WebKit is used by Safari and Chrome and yet they render pages differently.
    • Presto is the engine that Opera used to ship with, now it has switched to WebKit.

    Each rendering engine may behave differently under different devices/operating systems. Chrome for instance, being a cross-platform browser, may show slightly observable differences under different OS-es, like Windows and Linux, even if both OS-es use the same browser version (also true terms of script behavior).

  • The browser version. The browser version is another important thing to look at. Why, you may ask. Here it is:

    • As browsers evolve, they are independently introducing new versions with individual patches for their rendering engine. Therefore, the latest patch for Safari's WebKit will likely be different than Chrome's most-current WebKit version.
    • One particular browser could come up changes that affect page display between its former and its current version. For instance Microsoft are deprecating many features from its Trident engine, so some IE7 display tricks and scripts will no longer work on the new IE11.
    • It is possible for an update to introduce a change that replaces the entire rendering engine, like is the case with Opera.

  • The client operating system. Besides the fonts and clear type effects, the basic styles of some HTML elements are provided by the appearance and the theme of the operating system - as pointed in the MichaelT's answer. Usually, this will affect the appearance of: buttons, combo boxes, scroll-bars, radio buttons and check-boxes, if not overridden by the page's styles. Older browsers, like IE6, may not support re-styling of these UI components, and they will appear as whatever the OS theme looks like.

  • Browser-specific code, hacks or spoofing. Last, but not least are the browser-specific hacks, which are practices that can be seen in css, javascript and html. These are done by web developers and designers to overcome some browser-specific issues and may cause display differences either accidentally, or on purpose. As mentioned by the first comment under the question, a developer or user might deliberately cause his browser to identify itself as another browser. Usually, it is a practice for developers to test how a website would look if viewed by a mobile browser while still working on a desktop PC, and some browsers have plug-ins that allow them to re-identify themselves as other known browsers.

Combine all the above and you will get a very comprehensive and wide range of factors that may cause a page to look (and even behave!) differently depending on the device, OS, browser, browser version and the page's own source code. And, I do not pretend to be exhausting all the possibilities.

Community
  • 1
Ivaylo Slavov
  • 790
  • 5
  • 16
2

The first consideration is that different versions of the same browser may have different rendering backend versions (Webkit in the case of Safari).

A look at wikipedia's Safari version history shows that 5.1.7 is using webkit version 534.57.2. Meanwhile Mac OSX Safari is running 7.0 for OS 10.9 and 6.1 for the latest version on 10.8. Realize that Apple does do a reasonable job at pushing updates, Safari 7.0 is running Webkit 537.71 and 6.1 is running Webkit 537.43.58. These are all different versions and will likely have some differences in rendering.

The next consideration is that the windowing widgets that the browser uses is different on differing operating systems. I've recently had an issue where Chrome (latest) on Linux renders <select> list one way and Chrome (latest) on Mac OS X renders it differently. Different windowing widgets.

You can get an idea of this differing widgets by looking at Styling single selection menu control option groups (optgroup elements) with CSS

This really boils down to You need to test every supported browser and operating system as a separate entity and debug it as such. The 'same' browser on a different operating system isn't the same.

The thing to do is look at what version of Chrome you are using, what version of webkit (if its one that is using webkit) is in use, and then dig into the change logs for webkit (and trac.webkit.org). You might what to consider trying to build a consistent version of webkit for both Windows and Mac and then see if you can find the issue in your code, or if not, log an issue with Webkit. Please note, that you really will need to look into creating an SSCCE version to work from - for yourself and if you hope to have anyone look into it to fix it.