when I run my site on for example: /localhost/Test then the box-model and table borders/padding/spacing etc... looks normal.
Example IE9 Box Model OK localHost: http://www.flickr.com/photos/cenesam/6243269622/in/photostream
When I run the same test site on: /my computer name/Test then IE9 goes wacky and the box-model increases padding / spacing etc...
Example IE9 BoxModel NOK Computername:
Url: http://www.flickr.com/photos/cenesam/6242752657/in/photostream
Does anyone recognize this behaviour and knows how to deal with this?
I've included 2 sample pictures to show the visual problem. One is with localhost one is with computer name.
Any ideas are much appreciated.
Thanks,
Joost
Finaly found the answer somewhere on the web.
Spudley (thank you!) pointed me to the right direction. This meta tag was definitly the answer!!
But what is important that IE NEEDS this tag to be the FIRST one in the Head section. My site uses a theming engine which parses the styles in the head tag and therefore it was not working.
Now I'm overriding this in web.config (webserver section) by:
<httpProtocol>
<customHeaders>
<remove name="X-UA-Compatible" />
<add name="X-UA-Compatible" value="IE=Edge" />
</customHeaders>
</httpProtocol>
And now it finaly works again.
Thank you all for thinking with me!
Check the developer tools window (press F12) to see what rendering mode is being used.
IE has config settings which can cause it to fall back into compatibility mode in certain circumstances. One of those circumstances is when it's run on a "local intranet site" (which includes localhost).
Go to the IE Tools menu, and pick the "Compatibility View Settings" to change the config on this.
To force the site to load in the correct mode regardless of this setting, you can include the following meta tag in your HTML <head>:
<meta http-equiv="X-UA-Compatible" content="IE=Edge" />
Hope that helps.
Have you included an html doctype in the page? Ie9 modifies its behavior depending on the value of the doctype and/or meta tags.
http://www.google.com/search?hl=en&q=ie9+doctype+site%3Amicrosoft.com
Check for the "compatibility view" icon in the URL bar (the "broken page") and look if clicking (i.e. "activating" it) changes something.
Display the menu bar (right-click -> menubar) go to extras -> compatibility view preferences (like this, i got the german version here) and remove the "intranet" checkbox.
Related
<link href="~/Styles/Site.css" rel="stylesheet" type="text/css" />
I have added only one(above) stylesheet in my page. I have buttons as menu and there CssClaas is set to mbt. If I remove CssClass="mbt" from a button tag, I will see that button totally with no style.
<asp:Button ID="mHome1" runat="server" Text="Home" CssClass="mbt"
PostBackUrl="~/Default.aspx"/>
But I have already removed mbt from Styles/Site.css. I have no mbt class in my whole project now, but still its effect is there. I have tried to rebuild project and restart visual-studio, but its effect is not going any way. How? Why?
Have you tried to clear your browser's cache? Maybe the stylesheet file is cached.
With most browsers, you can force a reload of all files by clicking Shift-F5 or Ctrl-F5.
In my experience, I had the most cache-related problems when using Google Chrome.
In Internet Explorer, there is a useful option (in Internet Options -> General tab -> Browsing History -> Settings) where you can tell the browser to check for newer versions of files every time a page is loaded. This setting can be especially useful while developping a web application.
In firefox, you can find the settings in the Options dialog, under Advanced -> Network.
Try deleting, then re-uploading the css.
clear the browser cache. Ctrl + Shift + Del
I'm trying to make a web application using asp.net 4.0 and VS 2012 and for some reason my style sheet declarations are stock to the first version of the site were they weren't inside a folder. now that they are inside a folder, the declarations are still rendering and pushing to the browser as:
<link href="global.css" rel="stylesheet" type="text/css" />
Whereas they should be (and are inside VS):
<link href="style/global.css" rel="stylesheet" type="text/css" />
I really don't know whats going on, am I doing something wrong? I have built, rebuilt, and clean the solution as well as pressing the refresh button (the button, f5, control f5 in IE9, Firefox, and chrome) fifty times.
I had a similar issue. It was a browser caching issue. In IE go to Tools | Internet Options | General Tab. Click on Browsing history "Settings". Set it to "Check for new version of stored pages" to "Every time I visit the page".
This may be due to caching in the browser. What I do when developing web sites is disable the browser cache. Then every time it will load the modified files.
In Google chrome you can use Incognito Window when testing your changes.
Just before I thought I would restart, I tried renaming the style sheet. This solved it for me. Appears to be some caching problem indeed.
I have an MVC3 (razor) site published to IIS7 locally for testing purposes.
When I access the site via "localhost" it looks different from when I access using the IP address or machinename?
I have cleared my cache and re-loaded the pages to confirm and they still appear the different. The CSS must be loading to give the correct fonts/colours etc, although ":hover" elements appear to load much slower?
I am using JQuery/JQueryUI on the site if that helps identify the problem?
Any ideas?
Edit: More info
The titles, labels and table definition are build from ViewBag.Title, or looping through rows in a ViewModel - nothing clever, just standard MVC3/Razor stuff.
The same css file is used for every page, and F12 in IE8 shows the correct css has been loaded.
Title/subtitle font sizes/colours are correct, just their positioning is out?
Table border appears thicker?
Positioning generally seems a little "out", but I can't understand why there is this difference?
Can a firewall/AV package strip out positioning?
The same css file is used for every page, and F12 in IE8 shows the
correct css has been loaded.
Developer Tools should show that IE is not using the same "Browser Mode"/"Document Mode" between the two instances of the site, because that's the problem here. IE defaults to different modes depending on if you're using a machine name or not (amongst other things).
Adding this to your <head> should sort out the problem:
<meta http-equiv="X-UA-Compatible" content="IE=edge">
I had a similar issue, where the sizes differed from the local development site to the one on the production server. Turned out that I forgot the zoom level to 90% when viewing the development version... This answer helped me realize that: https://superuser.com/questions/315448/different-font-size-between-localhost-and-remote-server-in-firefox
I had exactly similar issue in IE11, I used this code
<meta http-equiv="X-UA-Compatible" content="IE=11">
And now whether its localhost or my machine name, the page always rendered nicely.
Just wanted to add, that if you use HTML5 tags (nav, header etc.) IE8 will render different on localhost and remote host.
If you add:
<!--[if lt IE 9]>
<script>
document.createElement('header');
document.createElement('nav');
</script>
<![endif]-->
Then the IE8 will show the same on local and remote host.
I have a Favicon and in my page I have something like:
<link rel="shortcut icon" href="favicon.ico" type="image/x-icon" />
This works fine. But inspired by the book "Ultra Fast asp" I am trying to remove all the small bits that are not necessary. I read a lot about browsers looking for favicon.ico anyway. (People complaining about 404 errors if they do not have a favicon).
So I was wondering: what is the use of the link if the browser looks for it anyway. It is "dead wood" -> so can I just remove this link completely or am I missing something.
thanks for your ideas,
Pleun
Using the explicit link syntax allows you to use different icons on different pages, and to have icon support on the browsers that do not automatically download the favicon.ico that is in the root of the site.
If you only ever use one icon on a website and don't care about browsers that do not automatically download the root icon, the links are not needed.
As long as your favicon is in the root of your website (ie. /favicon.ico), then yes you can drop this link. The link allows you to change where you want to store your favicon.
The standard specified by W3C uses the link tag rather than automagically look for the file in the root, but all major browsers will support both ways.
The Wikipedia article about favicon is a good overview of the possibilities and the browser support.
So here's an interesting conundrum.
I have a page, default.aspx. It has a LINK tag to a stylesheet, located in the CSS subfolder:
<link type="text/css" rel="Stylesheet" href="Css/Logon.css" media="all" />
The folder structure is as follows:
[Root]
[CSS]
[Images]
[Logon]
No big surprises. (Our default.aspx page is our logon page. Again, no big surprises.)
Here's the problem. If you launch the page in IIS, the page renders beautifully. CSS loads, fonts appear, everything is positioned appropriately, and lions are laying down with lambs.
If you view the page in WebDev, the stylesheet isn't loaded. Since it specifies all the images, fonts, and positioning, everything is black on white, in Times New Roman, slammed left against the window border. Dogs are chasing cats in circles and causing traffic accidents. Chaos ensues.
Why? How do I fix it? What information do I need to provide to reach a happy conclusion?
P.S. I am aware of the URL differences between running it in IIS and Webdev, but the differences don't seem to make much sense to me, due to one simple fact: the path to the style sheet is relative to the location of the default.aspx page. The stylesheet isn't being loaded at all. I can see this because there's no font styling at all.
My recommendation would be to use Firefox to load the page. With the Firebug add-on installed you can view the requests for the CSS files in the Net panel. This will allow you to at least see the path that is being used for the CSS file.
If you have not used the network monitoring feature in Firebug before you may want to go here:
http://getfirebug.com/network
We eventually discovered the cause of this problem using Fiddler: HTTP 401 (Unauthorized). A little more research uncovered that we needed to add explicit <location/> entries for the stylesheet, and all the images it referenced, to our web.config file.