I would like to have a list of browsers which don't support a website created based on .net.
Thanks.
ASP.NET web sites emit HTML, CSS and javascript (just like other technologies), and as such should be readable by ALL browsers. The technology used to host the site should have little impact on its consumption by browser clients.
The ony real concern is when non-conforming HTML or CSS is present and the web site doesn't render properly.
All of them support ASP.Net. More often you will need to look at the browser market share and all browsers mentioned in the report support ASP.Net very so you can be rest assured that your asp.net site will be usable for almost everybody on earth.
alt text http://marketshare.hitslink.com/chartfx62/temp/CFT0220_014339215AE.png
ASP.NET is server side, so your answer is any and every web browser.
Related
I'm a Mac person, web designer, trying to understand "Display intranet sites in compatibility mode" option with IE 11
I have client, an architecture firm, that used to host their OLD website (HTML site I didn't develop) in-house on their Windows server. When the Wordpress site I recently launched for them is hosted on a Ubuntu server in house.
The problem is several months after we go live one guy in the office when viewing with IE is seeing their portfolio pages display thumbnail images stacking vertically vs horizontally. When they turn Display intranet sites in compatibility mode off the thumbnails display correctly. Most people aren't using IE so its not surprising its just noticed now.
Here is an example of a portfolio page
They upgraded their workstations to Windows 8.1 and IE 11 shortly after we launched the new website.
I am a Mac person but I have not been able to recreate the problem with that IE/Win configuration with BrowserStack, nor have any of the people I know who have that version of IE/Win been able to recreate it.
If I recreate the portfolio page on my test site hosted by Bluehost - the clients see the portfolio pages correctly in compatibility mode.
So my question is what exactly is an intranet site in this environment? This website is not an inhouse only website its public - does intranet site refer to anything else besides a website like this one? I am sure there is information in house they can see via intranet only that's not public but is that why the setting is turned on? And why would it have to be displayed in compatibility mode?
Why would they need to have this compatibility turned on at all?
IE makes assumption about displaying intranet sites (http://someInternalSite/ vs. http://someInternalSite.myCompany.org). That assumption is that intranet sites work best in compatibility mode.
It makes the so called "smart" judgement by looking at it this way: Since the website is hosted in internal servers - there must be some corporate legacy applications developed on older versions of IE. And since IE is not perfect at maintaining proper fallbacks to older versions - thus its good to turn on the compatibility mode for the rescue.
To fix it either access the site with FQDN or uncheck a checkbox in “Compatibility View Settings”
More info of the IE "Smart Defaults" on this blog post: http://blogs.msdn.com/b/ie/archive/2009/06/17/compatibility-view-and-smart-defaults.aspx
I have upvoted the other answer, so i'm not really fishing for your vote. I just wanted to add the findings that i had this evening.
I have a state of the art HTML5 website, that works well in every browser. However, in my own local environment IE is messing thigns up like you said, and even worse. I was thinking it was a server issue as the html that was passed as a responsetext from my server was the right HTML. however, IE was parsing it to something different ( I usually think of IE as a great browser, but I really lost it)
this structure:
<header>
<div>
<div></div>
</div>
</header>
became this in the DOM:
<header></header>
<div>
<div></div>
</div>
<header><//header>
As you can see the whole DOM was parsed into something completely different and was not working, thanks to compatibility being enabled for the intranet. I did set the doctype, and validated my site on w3c, so that wasn't the problem either. The bottomline is, compatibility mode is something you want to stay away from as a developer.
I am designing an app that I want to run on both web and mobile web browsers. Obviously I need different layouts and views for both seeing that they have drastically-different size constraints for the UIs. I will obviously also need some kind of browser detection to figure out whether or not the request is coming from a web or mobile web client.
I have seen this solution implement is 2 ways:
Route HTTP requests differently depending on whether the detected client is web (send to www.example.com) or mobile web (send to m.example.com); or
Return different CSS sheets depending on whether the detected client is web (app-styles-web.css) or mobile web (app-styles-mobile.css)
My question: what are the pros/cons to each strategy and why? Subdomains seem like a bit unnecessary, seeing that you're going to have to have 2 different CSS sheets anyways, but perhaps they are becoming a "best practice" because they separate concerns? Thanks in advance!
A lot of the larger vendors tend to use a sub-domain because it allows the end client browser to be sure that they are redirecting to the correct version of the site. Consider today's dot-com giants - Facebook, Twitter, Yahoo, they all have their own compact mobile based sub-domains.
Consider the case that I use my smartphone to view a website - www.example.com. There's some code that detects my user-agent and redirects me to its mobile web equivalent sub-domain m.example.com. Tomorrow, I view the same website on a bespoke browser on another hand-set. This browser conceals the meta-data so that the user agent received at the code is not that of a smartphone. It'll now load the web-based version of the same website risking the fact that web-pages/CSS/JavaScript will render incorrectly. Fortunately, I know that there's a mobile web sub-domain of the same site so I'll hit my address bar to point to the correct sub-domain.
Finally, there are strong SEO implications, a sub-domain is treated as a completely different website so you may put yourself at a disadvantage if you'd just load a different view.
Few months back I too faced a similar conundrum. But I evaluated and thought of on all the above points that I mentioned and today I ended up having lots of happy customers :-)
If you'd like to play it safe, use the sub-domain approach.
I'm building a web app that uses a lot of CSS3 and session storage. My goal is to deny users of older browsers by redirecting them to a "we don't support your browser" page. I'm thinking of using an http module that looks at the incoming request. In the client page I would encode a hidden field that contains the user agent version.
I want this to work for both regular aspx requests and ajax requests to asmx files. What would a good method to do this be?
You may use HttpRequest.Browser property to detects browser type in ASP.NET and have a look at article by Scott Mitchell - Performing Browser Detection Using ASP.NET.
I don't think you would need to encode anything onto the page. Create a module that detects the browser, or the version of javascript the browser supports (for example), using the Http.Browser capabilities.
I am redesigning a web project that requires a lot of involved data entry. I would like to make use of ASP.NET's ajax functionality to improve the user experience. But a large portion of my user base is still using Internet Explorer 7, which has caused problems for us in the past when it comes to AJAX functionality. We cannot request they upgrade, and not supporting them is not an option.
Is there an effective way to disable AJAX functionality for those users on Internet Explorer 7 and provide the full ajax experience for users on more compliant browsers?
If you use Modernizr, it will accurately detect which browser you have, and set a specific css value in the html tag of the page. You can then use jquery (or just DOM api) to check the browser version and set a flag that disables your ajax.
I am trying to create a static HTML page which has a <form> which posts to a 3rd-party ASP.NET website.
Is this possible when the target website uses ASP.NET webforms?
This is absolutely possible. You can issue a POST to any website, anywhere. (Keep this in mind when you're designing an application that accepts POSTs from a web merchant such as PayPal ;-) make sure you know where the POST is coming from.)
Whether or not the website will accept your request, of course, is up to however the server-side code was programmed. If you're POSTing to an ASP.NET WebForms app and the app wasn't designed to accept third-party POSTs, then you're going to have a hard time making your POST parameters look like they came fro ma WebForms page. For example, the website will be looking for the encrypted viewstate, among other things.
You could use firebug or some other tool to sniff the POST data from the webforms app, and then replicate that data in your static HTML page .... it might work.
Do you have any programming control over the ASP.NET Webforms app at all?
check out this question:
How to POST Data to another web application (cross domain)
Let me know, if you need help with my implementation.