MAC Browsers and Compatibility with Windows Browsers

[jhardman]

Well of course.
The User-Agent header greatly effects what is sent to the client.
All I had to do was change this:

User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; InfoPath.1; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30)

to this:

User-Agent: Mozilla/4.0

And the http response sent back munged up html without any css script

So is it .NET causing the problem or IIS?

And is there a way to change the default data that is sent for different user-agents? Could we get it to send the same info for safari that it sends to ff? and if so, who should we ask to get good instructions?

Jared

[HEX]

Ok, so where I say "IIS", replace that with "VWD"

The test server you linked us to was running IIS6 when it served up the page though.

Thanks, appreciate your comments. Wasn't being picky, just ignorant about what you said I'm unexperienced. However, what I did was set Page.ClientTarg et="uplevel" (alias for user agent mozilla,etc.) in the test page load event and then did some more testing. That made no difference. Tryed test with two menu controls, one with sub menu, one without. Both went to wrong position. Then, I tryed with just the menu with no submenu by itself. Again wrong position. However, ran that through W3C and this time the code to Safari was Valid! It no longer had the aforementioned "absmiddle" mentioned earlier in this thread. So that probably is a red herring.

I keep noticing Class info in the code being sent which has an absolute position which could take the menu to the position where it ends up, but that goes to all the browsers and isn't referenced in the new page. I wonder if for some reason Safari is using that.

<style type="text/css">
	.Menu2_0 { background-color:white;visibility:hidden;display:none;position:absolute;left:0px;top:0px; }
	.Menu2_1 { color:#990000;font-family:Verdana;font-size:0.8em;text-decoration:none; }
	.Menu2_2 { color:#990000;background-color:#FFFBD6;font-family:Verdana;font-size:0.8em; }
	.Menu2_3 {  }
	.Menu2_4 { padding:2px 5px 2px 5px; }
	.Menu2_5 {  }
	.Menu2_6 { padding:2px 5px 2px 5px; }
	.Menu2_7 { background-color:#FFFBD6; }
	.Menu2_8 {  }
	.Menu2_9 { background-color:#FFCC66; }
	.Menu2_10 {  }
	.Menu2_11 { background-color:#FFCC66; }
	.Menu2_12 { color:White; }
	.Menu2_13 { color:White;background-color:#990000; }
	.Menu2_14 { color:White; }
	.Menu2_15 { color:White;background-color:#990000; }

</style>

So, I guess I'm back at the Safari ballpark. I was relying on ASP with auto detection and browser definitions to do the right thing because the default was suppose to only send valid transitional code. However, there is no Safari definition and it probably uses default definition and maybe that explained the 'absmiddle" rendering.

So now, if the code is valid transistional and client target was no help am I looking at Safari as the culprit? Or, probably some other thing I'm ignorant about?

Any thoughts?

Thanks

[HEX]

STANDBY. I moved the code for client target to page preint and it made a difference. Have submitted to browershots and am awaiting results to see if this clears up the whole matter or just another step forward.

 Protected Sub Page_PreInit(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.PreInit
        If InStr(Request.ServerVariables("http_user_agent"), "Safari") Then
            Page.ClientTarget = "uplevel"
        End If
 End Sub

[HEX]

The browser shots look good. Maybe a slight difference with the MAC screens. Next will put the code into my real pages with menu controls, and see what I can get.
Still don't fully comprehend why this is necessary for only Safari. Who really has responsibility for this issue, ASP, Safari, or ignorant me?

Thanks to all contributors on this for their expertise and patience thus far. Will post results.

[HEX]

That did it. Everything looks as expected now. It's mind boggling to have to put code in pages that have a menu control just for Safari. I'm too inexperienced to grasp the reason why this is the case. Not sure who is not compatible with who. Who owns responsibility for this kind of thing?
It seems to me, from a Newbie viewpoint, that this stuff has a long way to go to get sensible.
If someone wishes to point out the rationale for this issues behaviour, this ignorant individual would love to hear it.

[jhardman]

It is not Safari's fault. "Valid code" is decided on by the world wide web consortium ("W3C") and all browsers are supposed to interpret this the same. However, back when Internet Explorer was passing up Netscape as the most popular browser about 10 years ago, those two purposefully introduced new ways to handle the code. They both became very non-compliant on purpose. This made a big headache for programmers, and many decided they would have to write different versions of the page for different browsers. This was a big hassle, and the non-compliance of IE is one of the reasons ff is now the most popular browser.

The reason behind the current problem, is the browser routing mechanism probably doesn't recognize safari (as I said, it is a throw-back to a standard practice 10 years ago, and Safari hasn't been around that long) and who knows what it is being sent. The best practice now is to not use browser detection, and just send every page valid code. I would suggest you turn off browser detection, or add safari to some list of browsers that can handle good code, but I am glad you got it to work, regardless.

Jared

[HEX]

It is not Safari's fault. "Valid code" is decided on by the world wide web consortium ("W3C") and all browsers are supposed to interpret this the same. However, back when Internet Explorer was passing up Netscape as the most popular browser about 10 years ago, those two purposefully introduced new ways to handle the code. They both became very non-compliant on purpose. This made a big headache for programmers, and many decided they would have to write different versions of the page for different browsers. This was a big hassle, and the non-compliance of IE is one of the reasons ff is now the most popular browser.

The reason behind the current problem, is the browser routing mechanism probably doesn't recognize safari (as I said, it is a throw-back to a standard practice 10 years ago, and Safari hasn't been around that long) and who knows what it is being sent. The best practice now is to not use browser detection, and just send every page valid code. I would suggest you turn off browser detection, or add safari to some list of browsers that can handle good code, but I am glad you got it to work, regardless.

Jared

Jared,

My thanks for your efforts and the explanation. However, even in this case the last test had a validated page by W3C but the code sent somehow goofed Safari.
I guess this stuff is still evolving and I've got a lot of learning to do. My thanks also to the contributor Plater who directed the solution and Banfa who made me aware of Browser Shots. That's a nice aid.
Until the next snake bites, cheers.

[drhowarddrfine]

Please be aware that having a validated page in no way assures you of having a page that does what you want. Validation only means you are using the correct syntax, element and attribute combinations. Your page can still look wrong, especially when a browser doesn't handle the markup properly.

[HEX]

Please be aware that having a validated page in no way assures you of having a page that does what you want. Validation only means you are using the correct syntax, element and attribute combinations. Your page can still look wrong, especially when a browser doesn't handle the markup properly.

Thanks for your help. Recognize that, however if the page renders OK and validates OK elsewhere (other browsers), then what is the standard approach or is there one? Just experience to know where to shine the light?

Thanks again

[drhowarddrfine]

I haven't followed this thread since it looked like it was an asp problem. All browsers have some little quirk all its own and the fixes are usually well known. If this truly is a Safari issue, then Google may be your only friend, along with searching the Apple web site.

I wish I could help more but don't own a Mac and only use browsershots to test my sites and waiting for that would take forever. But I will try and find some time to look at it deeper so watch this space in case I find it.

[HEX]

I haven't followed this thread since it looked like it was an asp problem. All browsers have some little quirk all its own and the fixes are usually well known. If this truly is a Safari issue, then Google may be your only friend, along with searching the Apple web site.

I wish I could help more but don't own a Mac and only use browsershots to test my sites and waiting for that would take forever. But I will try and find some time to look at it deeper so watch this space in case I find it.

Thanks, your suggestion is a good one as that is probably what I should be doing. I'll snoop around also. Then, I will get back here if I find anything. I have since noticed on searches there are entries describing problems with Safari and the ASP menu control, but nothing states who really owns the problem, just efforts to fix. I apparently haven't been alone in this issue.

Thanks again.

[jhardman]

Thanks, your suggestion is a good one as that is probably what I should be doing. I'll snoop around also. Then, I will get back here if I find anything. I have since noticed on searches there are entries describing problems with Safari and the ASP menu control, but nothing states who really owns the problem, just efforts to fix. I apparently haven't been alone in this issue.

Thanks again.

Let me briefly point out a pet peeve. You keep using the term "ASP" incorrectly. ASP does not have a menu control nor is it supported by .NET. You are using a different technology called "ASP.NET". The two have a similar foundation, run on the same servers, and have some cosmetic similarities. Besides that they are not very similar, and shortening the name "ASP.NET" to "ASP" will continue to confuse people (the experts trying to help you, other newbies trying to get answers, etc). ASP.NET is a higher-order programming language full of added features and functionality that the user doesn't need to think about or even know about. ASP is a relatively bare-bones scripting language that simple yet powerful and inspired M$ to create ASP.NET.

And while I'm complaining, one of my main complaints about .NET (and higher-order languages in general) is it takes control out of the hands of the programmer. I will not deny that it makes programming easier and faster in many cases, but for programmers who want to retain tight control over exactly what the result is, .NET makes this very difficult with built-in "features" that you neither asked for nor want. The current problem is probably caused by one of .NET's "features" (I don't think your server will route browsers automatically, although it isn't inconceivable).

Anyway, if you're still around, I might have time to check your new page Saturday or so.

Jared

[HEX]

Let me briefly point out a pet peeve. You keep using the term "ASP" incorrectly. ASP does not have a menu control nor is it supported by .NET. You are using a different technology called "ASP.NET". The two have a similar foundation, run on the same servers, and have some cosmetic similarities. Besides that they are not very similar, and shortening the name "ASP.NET" to "ASP" will continue to confuse people (the experts trying to help you, other newbies trying to get answers, etc). ASP.NET is a higher-order programming language full of added features and functionality that the user doesn't need to think about or even know about. ASP is a relatively bare-bones scripting language that simple yet powerful and inspired M$ to create ASP.NET.

And while I'm complaining, one of my main complaints about .NET (and higher-order languages in general) is it takes control out of the hands of the programmer. I will not deny that it makes programming easier and faster in many cases, but for programmers who want to retain tight control over exactly what the result is, .NET makes this very difficult with built-in "features" that you neither asked for nor want. The current problem is probably caused by one of .NET's "features" (I don't think your server will route browsers automatically, although it isn't inconceivable).

Anyway, if you're still around, I might have time to check your new page Saturday or so.

Jared

Thanks for your comments. The first entry in the thread stated the issue dealt with ASP NET 2.0. Subsequent entries had the same reference or it was implied. Apologize if I confused folks by abbreviating to ASP later on in the thread. Assumed all would be read and understood what stuff the issue was about. No need to pursue anything further and thanks for your assistance.