Why do PCs display Mac produced web sites different? I just finished a school web site and when viewing it on a PC (IE and Netscape v7.2) it looks different. But on a Mac (IE; Netscape v7.1, 7.2; Safari; Firefox; Camino) it looks like my intended design. This brothers me because the client is a PC person and he has final approval. I end up explaining that the two systems read html differently, am I correct? If you would like to check the site out, www.ecsv.org. Comments please on this and feedback on the site would be welcome. Thanks
Got a tip for us?
Let us know
Why do PCs display Mac produced web sites different?
- Thread starter Dane D.
- Start date
- Sort (Likes)
This has nothing to do with PC vs. Mac. It's all a question of how each individual browser (IE for Windows, IE for Mac, Safari, Netscape for Windows, Netscape for Mac, Firefox, Mozilla, etc... and different versions count as different products) interprets HTML code and renders it to the screen. This can be expressed in many ways, from HTML being interpreted differently (sometimes with horrendous results) to images appearing brighter or darker to fonts appearing incorrectly.
So, the question you have to ask yourself is: What browser will the intended target audience be using? If they're going to mostly be using IE, then you need to make sure it looks correct in IE. And yes, this means you will need to make sure that he understands that things may appear differently or incorrectly in other browsers... it's possible that you may be able to work around the differences by coding your pages differently. Perhaps using a simpler form of HTML coding will eliminate some of the problems.
Still, it's good that you found this out BEFORE the site went live.
So, the question you have to ask yourself is: What browser will the intended target audience be using? If they're going to mostly be using IE, then you need to make sure it looks correct in IE. And yes, this means you will need to make sure that he understands that things may appear differently or incorrectly in other browsers... it's possible that you may be able to work around the differences by coding your pages differently. Perhaps using a simpler form of HTML coding will eliminate some of the problems.
Still, it's good that you found this out BEFORE the site went live.
Not really... I'm working on a web site now for an artist, and he keeps commenting that some of the images look darker for him than they should... and he's using a Mac. Part of this might have been that he was using Netscape for the Mac (insert finger into throat and hurl)... when I got him to try Safari, he commented that it looked much better. Same web site, same images, different browser = different (read: better) result.tech4all said:
The reality is that there's nothing you can do about people who have their monitor's brightness control or color temperature turned up too high or down too low.
Yes it is true. Macs come default with a target gamma of 1.8, while PCs (well Windows anway) is 2.2. You can see what the difference is like by going to System Prefs -> Displays -> Color and click on Calibrate... then switch back and forth between the two gammas and you can see what the difference is like.tech4all said:
OK, now that you have succeeded in making a single browser web site, now you need to work on making a cross-browser site.Dane D. said:
Some random thoughts:
You are at the mercy of the web browser when it comes to font sizes. This is one use for Cascading Style Sheets, to define font size more accurately.
You have a number of photos of people: I assume they were taken in the school? Since they are identifiable individuals, you would be best to go and get a model release from each one of them, to prove you had permission to display their likeness. http://www.dpcorner.com/all_about/releases.shtml
You're using a strange combination of table layout and a bit of CSS positioning, that's messing you up some in the Message from the Director and Feature Page on the home page. Stick with one or the other. Since you can't control 100% how the tables are going to size ('cause you can't control the font size), it's dangerous trying to position something relative to the page, when it has to match the table content.
I realize you are probably leaning on GoLive for the layout. This will be problematic for you as you hit (now) the problem of debugging it.
Here's something you probably don't want to hear: I would recommend going back to the drawing board and redefining your table layout. Yup, ditch GoLive's layout and work the page structure out by hand. You can use the same graphic and text block components. Painful the first time, but you'll have a much better understanding why your page works or doesn't.
Woo Hoo - just hit the Community Education page - now that's a jarring transition. Do I guess that the Comm Ed is an older page, not your work? Hope so, I REALLY don't like that page.
Your logo and your sidebar navigation buttons jump around from page to page. Do everything you can to make the positioning of these elements rock solid across all pages. When you get to Career Fields, you introduce another nav bar across the top and a wider left hand nav. Could you do anything to make this more consistent?
Think of the potential viewers, they are international. Could you put a bit more info onthe home page to clarify where the school district is and to whom your site is addressed? It took me a while to figure out that ECSV means East Canton Sandy Valley. Without MapQuest, however, I still don;t know where in the world you are.
The color representation of photos is not my concern so much as the position on the page of the elements.
"Your logo and your sidebar navigation buttons jump around from page to page."
That is not the case here, I have tested this site out on 3 different PCs (OS '98, 2000 and XP) and 4 different Macs (OS 9.2.2 , OS 10.2.8 and 10.3.8). What I see on PCs is the position of elements is NOT where I want them but on all the Macs the page is true to my intended layout.
I did not produce the external link of Community Education, that was done by the school.
You are right in that I rely on GoLive to produce the site, because my background is print media using programs such as Photoshop, Illustrator and QuarkXPress to produce printed media. This is my first website and the ability to see the page as I work is want I like. Right now the use of CSS is daunting, I look at that and my head is swimming.
"Your logo and your sidebar navigation buttons jump around from page to page."
That is not the case here, I have tested this site out on 3 different PCs (OS '98, 2000 and XP) and 4 different Macs (OS 9.2.2 , OS 10.2.8 and 10.3.8). What I see on PCs is the position of elements is NOT where I want them but on all the Macs the page is true to my intended layout.
I did not produce the external link of Community Education, that was done by the school.
You are right in that I rely on GoLive to produce the site, because my background is print media using programs such as Photoshop, Illustrator and QuarkXPress to produce printed media. This is my first website and the ability to see the page as I work is want I like. Right now the use of CSS is daunting, I look at that and my head is swimming.
Welcome to the real world. I would take a chance and also say that your code does not validate. If it did you would have a higher chance of cross browser comptability. Like someone said above it has nothing to do with PC vs. Mac, so you need to get over that one. It's all about how the browser renders the HTML you provide. Don't blame the OS.
Tables are still used to lay out sites? 
Design sans tables using CSS 2.0: Thous shall not use tables to layout a Web site!
Design sans tables using CSS 2.0: Thous shall not use tables to layout a Web site!
Actually, quite a few web sites are still laid out using tables... for one thing, tables are consistently handled by most web browsers, whereas CSS is still kinda up in the air. Tables, implemented properly, allow almost infinite precision with respect to positioning.AlaskaAUG said:Tables are still used to lay out sites?
Design sans tables using CSS 2.0: Thous shall not use tables to layout a Web site!
And didn't you get banned a while back, Chanoc? I see from your other posts (esp. concerning the late Pope John Paul II) that your attitudes certainly haven't changed.
Unfortunately, it's not important whether the site works for you, it's important that it works for your audience.Dane D. said:
I'm still a believer in meat and potatoes, solid table construction... even there it's difficult to tell how different browsers will handle things. Test, test, test,
Hmmm. A learning experience here for allAlaskaAUG said:Tables are still used to lay out sites?
Design sans tables using CSS 2.0: Thous shall not use tables to layout a Web site!
Besides the gratuitous topless Playboy ad (Animated ads are supremely annoying)...
The page referenced has a problem with the text of the news items running past the bottom of the blue box they are "in". This would possibly be a demonstration of the superiority of CSS over tables.
It's also impolite to send someone to a PDF download without indicating it in the link ("About Chad").
There is a link "_Major_site_revision_using_CSS2_" that you'd expect to take you to a diary-type page about the revision. Instead it goes to a page at W3.org. The link should have been structured "Major site revision using _CSS2_" Links need to give the viewer information about their relevance.
There is a news entry 03.01.05 with no link, and black against dark blue BG. This combination is unreadable. It also frustrates the viewers expectation of a list of links.
The Image of the Day is dated Dec. 2000. Best not to set up an expectation that cannot be delivered on.
You're right, ChicoWeb, the page does not validate. Cleaning it up certainly shouldn't hurt.ChicoWeb said:
However, I will add that pages can validate perfectly well at validator.w3.org and be nonetheless poorly respected by MS browsers due to what I think is a lack of full CSS implementation even in IE6, but I'm no expert.
Piling on here, you just have to test on the browers themselves to be sure.
Yes, when calibrating the screen, one of the choices is gamma:tech4all said:
1.8 = standard MacOS gamma
2.2 = TV/PC gamma
2.2 is of course "darker" than 1.8
Clean up the code
Others have noted that your code doesn't validate, and I think that is your problem. You are using deprecated tags that get rendered differently in different browsers.
Don't rely on your WYSIWYG editor to produce good code. It won't, no matter which one it is--some mess up less than others, but they all mess up. You have to proofread and correct the code your editor creates.
I think you should clean up the code to valid XHTML 1.1 if you can, XHTML 1.0 Transitional as a fall-back. That means get rid of all those font tags, for one thing. You can also get rid of that table and use CSS2. You'll end up with cleaner code that is easier to maintain and well worth the trouble of doing it.
It is not possible to get a web site to look exactly the same on all browsers, but it is possible to get close enough that it doesn't matter. My advice is write to standards, not to browsers, but be circumspect about what isn't supported.
For instance, IE does not support position:fixed. For my menuing system, I specify div#nav with position:absolute, and then I respecify it with html>div#nav as position:fixed. It's valid to define the same thing twice; the browser takes the last one. In the case of IE, it does not understand the child operator, so it never reads the statement with position:fixed. The result is that in IE, the menuing system scrolls up with the text, while in other browsers it stays put. (I could do the same thing in JavaScript and have it work on IE, but it would jerk up and down while the user scrolls. That's a solution that's worse than the problem.) It's not the same on all browsers, but it is equivalent.
I have a web site in XHTML 1.1 (over 700 pages) that looks pretty much the same in all browsers except, of course, Netscape 4.
One hint: if the doctype is incorrect or it is not on the first line, IE goes into quirks mode. To keep IE in standards mode, make sure there are no linebreaks before the doctype. The XML prolog is optional; leave it out. If anything has to come before the doctype, run it together on one line.
Others have noted that your code doesn't validate, and I think that is your problem. You are using deprecated tags that get rendered differently in different browsers.
Don't rely on your WYSIWYG editor to produce good code. It won't, no matter which one it is--some mess up less than others, but they all mess up. You have to proofread and correct the code your editor creates.
I think you should clean up the code to valid XHTML 1.1 if you can, XHTML 1.0 Transitional as a fall-back. That means get rid of all those font tags, for one thing. You can also get rid of that table and use CSS2. You'll end up with cleaner code that is easier to maintain and well worth the trouble of doing it.
It is not possible to get a web site to look exactly the same on all browsers, but it is possible to get close enough that it doesn't matter. My advice is write to standards, not to browsers, but be circumspect about what isn't supported.
For instance, IE does not support position:fixed. For my menuing system, I specify div#nav with position:absolute, and then I respecify it with html>div#nav as position:fixed. It's valid to define the same thing twice; the browser takes the last one. In the case of IE, it does not understand the child operator, so it never reads the statement with position:fixed. The result is that in IE, the menuing system scrolls up with the text, while in other browsers it stays put. (I could do the same thing in JavaScript and have it work on IE, but it would jerk up and down while the user scrolls. That's a solution that's worse than the problem.) It's not the same on all browsers, but it is equivalent.
I have a web site in XHTML 1.1 (over 700 pages) that looks pretty much the same in all browsers except, of course, Netscape 4.
One hint: if the doctype is incorrect or it is not on the first line, IE goes into quirks mode. To keep IE in standards mode, make sure there are no linebreaks before the doctype. The XML prolog is optional; leave it out. If anything has to come before the doctype, run it together on one line.
Just because sites are still laid out using tables doesn't mean it's the right thing to do. Tables were never intended to do positioning of elements other than rows and columns of type. Over the past decades, web designers have bastardized the table to make it do things it shouldn't be used to do.clayjohanson said:
That is where CSS positioning comes in. CSSp is *intended* from the beginning to be used for placment of elements. Thus, it is a much more efficient, accurate, and ideal way to control this facet of your web design. In a perfect world, tables are still allowed, except only for what they were meant to do, *act as a table of information*.
As an aside, CSS 2.0 renders properly in all modern browsers. And no, IE for PC or Mac is not considered a modern browser.
IE and modern browsers
Use tables only for tabular information.
Meanwhile, there are three main problems with IE and CSS, and you can easily fix two of them.
The first problem is that IE does not support position:fixed. The second is that IE does not support the :hover pseudo class with tags other than the anchor tag, and the third is that the previous version of IE got the box model wrong, so that padding and borders come out differently than on other browsers.
1. There is no cure for the first problem. You have to code around position:fixed, using a technique like I suggested earlier (specify the element with position:absolute, then respecify it with position:fixed using the child operator.)
2. You can cure the second problem by adding a behavior statement to your style sheet that implements an HTC file that makes IE support the :hover pseudo class on all elements. The technique is very simple, you can learn the technique and get the HTC file from the book "More Eric Meyer on CSS," by, well, Eric Meyer. The behavior statement is not standard CSS, but it fixes IE and other browsers ignore it, so why not.
3. The third problem stems from the fact that Microsoft misunderstood the box model in (Windows) IE 5. They fixed it in IE 6. IE 6 has a quirks mode that emulates the legacy behavior and a standards mode that gets the box model right. If you write your code with a valid doctype on the first line of the file, you will be in standards mode and the borders and padding will render the same as in other browsers. That means no linebreaks before the doctype.
If you implement the HTC file and code so that your page is rendered in standards mode, both simple to do, you shouldn't have much trouble getting things to look the same in IE as in other browsers.
I'd like to add that browsers don't render tables as quickly as a layout that is positioned with CSS. Tables are harder than CSS, the code is harder to maintain, and they aren't rendered as fast as CSS. The only reason for using tables for positioning is ignorance of CSS, really.michaelrjohnson said:
Use tables only for tabular information.
IE is about five years behind in terms of supporting standards, so it is quite right to say that it is not a modern browser. That may change, however. Microsoft's Visual Studio 2005 suite does XHTML 1.1 by default. So that may indicate better standards support in IE 7 which is due out about the same time. I speculate that users will adopt IE 7 as fast as they did previous versions, which means the majority of IE users will be at version 7 within a year or so.michaeljohnson said:
Meanwhile, there are three main problems with IE and CSS, and you can easily fix two of them.
The first problem is that IE does not support position:fixed. The second is that IE does not support the :hover pseudo class with tags other than the anchor tag, and the third is that the previous version of IE got the box model wrong, so that padding and borders come out differently than on other browsers.
1. There is no cure for the first problem. You have to code around position:fixed, using a technique like I suggested earlier (specify the element with position:absolute, then respecify it with position:fixed using the child operator.)
2. You can cure the second problem by adding a behavior statement to your style sheet that implements an HTC file that makes IE support the :hover pseudo class on all elements. The technique is very simple, you can learn the technique and get the HTC file from the book "More Eric Meyer on CSS," by, well, Eric Meyer. The behavior statement is not standard CSS, but it fixes IE and other browsers ignore it, so why not.
3. The third problem stems from the fact that Microsoft misunderstood the box model in (Windows) IE 5. They fixed it in IE 6. IE 6 has a quirks mode that emulates the legacy behavior and a standards mode that gets the box model right. If you write your code with a valid doctype on the first line of the file, you will be in standards mode and the borders and padding will render the same as in other browsers. That means no linebreaks before the doctype.
If you implement the HTC file and code so that your page is rendered in standards mode, both simple to do, you shouldn't have much trouble getting things to look the same in IE as in other browsers.
