Can someone please explain the difference between IE8 browser mode and document mode in simple terms?
What causes the browser mode to change?
What causes the document mode to change?
If a user changes the mode(s) via developer tools, does the change remain even if the page is refreshed?
I am asking this because we are doing some IE8 testing here, and different people have different combinations of the modes, and i want to try to figure out how this is happening.
From this article on the IE8 blog, entitled How IE8 Determines Document Mode
The Developer Tools settings override all Document Modes for pages displayed in a tab.
The X-UA-Compatible meta tag and then header override Compatibility View Settings and the doctype unless the X-UA-Compatible value is EmulateIE7 or EmulateIE8.
The user’s Compatibility View Settings override the Microsoft Compatibility View List.
If none of the above rules apply, the doctype determines whether the webpage renders in IE8 Standards, IE8 Almost Standards or Quirks Mode.
So from that we get the following answers to your questions:
Q. What is the difference between browser mode and document mode in simple terms?
A. Browser mode is set in the developer tools to emulate different IE browser version behaviors while document mode is defined on the web page to tell IE to render the site differently for compatibility purposes.
Q. What causes the browser mode to change?
A. The user changes the browser mode in the dev tools.
Q. What causes the document mode to change?
A. The Doctype and the X-UA-Compatible meta tag and header set by the web developer.
Q. If a user changes the mode(s) via developer tools, does the change remain even if the page is refreshed?
A. The Browser Mode will stay, but if you change the Doctype and X-UA-Compatible, they will go back to what is defined on the page.
UPDATE: As Adrien Be points out below, IE9+ adds the ability to change the document mode in the dev tools via a setting which will persist on refresh.
See your answer in this page.
The documentMode property returns the mode used by the browser to render the current document.
IE8 can render a page in different modes, depending on the !DOCTYPE or the presence of certain HTML elements.
This property returns one of following values:
5 - The page is displayed in IE5 mode
7 - The page is displayed in IE7 mode
8 - The page is displayed in IE8 mode
9 - The page is displayed in IE9 mode
Note: If no !DOCTYPE is specified, IE8 renders the page in IE5 mode!
Browser Mode: Specifies the user agent sent by the browser to the Web Server. Rendering differences can occur if your JavaScript or back-end code renders differently based on the user agent string. For example, you may see JavaScript that checks navigator.userAgent. (Mozilla/5.0 (compatible; MSIE 8.0...) This value is also used to to process conditional comments ([if lte IE 9], [if gt IE 8], etc.). The Emulation tooling in IE 11 does not have a browser mode. It has a user agent drop-down instead.
Document Mode: Specifies the rendering engine used to process the markup. This is typically where we see rendering issues and browser incompatibilities. The original goal (for better or worse) was website owners could choose a document mode for their site via a meta tag. In IE 11, the emulation tools are less confusing.
Testing:
If your goal is to emulate an old IE8 browser, you should change both browser mode and document mode. The emulation is not perfect, so a more thorough option is to download free test VMs from Microsoft where you can test with a *real" version of IE 8, 9, etc.
What causes these values to change?
The Browser mode will not change. (Unless you change it in Dev tools.) It is set before making the request to the web server.
The document mode can change based on web server response. It can be changed via a X-UA-Compatible HTTP response header, the doc type, meta tags, Intranet sites, markup issues, etc.
There is a little button in top left , in IE dev tools -> emulation (tab) that says "Persist emulation settings"
see this :
"Settings persistence and reset
A Persist Emulation settings icon is added to the Emulation tool. This will maintain your current emulation settings until specifically disabled, allowing you to work, close the browser, and come back with your emulation settings intact. To its right is a Reset Emulation settings icon, which quickly resets the tool back to default values."
Related
I don't know why my firefox Responsive Design Mode view doesn't look like it is presented in MDN ?
MDN view:
My view:
I am using firefox 53.0.2 on PC.
There are (at least) two preferences controlling whether the old Responsive Design Mode UI or the new one is shown:
devtools.responsive.html.enabled needs to be set to true => Directly controls whether the reworked UI is displayed.
browser.tabs.remote.autostart.2 needs to be set to true => Controls whether multi-process Firefox is enabled and the new RDM UI obviously doesn't work in single-process Firefox instances.
To check whether the multi-process mode is enabled, go to about:support and ensure that the value at "Multiprocess Windows" says "Enabled".
Those preferences can be changed via about:config.
Note: Once you enable the multi-process setting, add-ons that don't support this feature like e.g. Firebug won't work anymore.
My team have a legacy project where we use the X-UA-Compatible tag to garantee Internet Explorer render the page in Compatibility View Mode since we need to support IE7 and beyong.
<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7"/>
It works in IE but the Page Inpector in Visual Studio 2013 render the page like it renders in IE with standard Document Mode instead.
We can only troubleshoot the problem with this compatibility in place since it does not occur in standard mode.
There is any configuration or hack to make Page Inspector renders the page in Compatibility Mode?
No there is no hack or configuration to make Page Inspector renders the page in compat mode.
My company uses an application from a third party vendor, therefore we have no control over the source code. The site has compatibility issues in IE10 (only) due mostly to the rendering of Javascript, as well as in other browsers (Safari, Firefox, Chrome).
Since we DO have control over our server, I asked our Hosting team to add a custom HTTP response header in IIS as follows, based on some Googling I did.
In the Name box --> X-UA-Compatible
In the Value box --> IE=EmulateIE9
Now I'm wondering if IE=9 would've been preferable, and if that would apply to other browsers besides IE.
So my questions are, specifically:
(1) What is the difference between content=IE=9 and content=IE=EmulateIE9 ?
(2) Would using content=IE=9 force browsers other than IE to render as IE9 ?
(3) I've seen an additional attribute for Chrome=1. Does this actually work ?
The html-5.com provides this definition, so it sounds like this tag would NOT work outside of IE, but I've seen so many other references to the Chrome=1 that I'm wondering otherwise.
X-UA-Compatible is used to indicate to an IE browser which version of the rendering engine should be used to display the page. This metatag does not affect other browsers such as Firefox and Opera, which in general attempt to avoid bloating the size of the browser code by displaying web pages only one way according to established standards (Supporting multiple rendering engines presents some major challenges, especially when content rendered by one engine accesses embedded content rendered by a different engine).
Thanks!
The difference between using IE=9 and IE=EmulateIE9 is that using IE=9 forces standards mode for IE9, while EmulateIE9 will respect the DOCTYPE to determine standards or quirks mode. See this link for more details (although it's a little dated): http://blogs.msdn.com/b/askie/archive/2009/03/23/understanding-compatibility-modes-in-internet-explorer-8.aspx
See Daniel's answer for 2 and 3, but the short version is that this has zero effect on other browsers.
We have a pretty big web page with a bunch of javascript. When loading it in Firefox/Chrome, the page gets loaded gradually. First the html that already is received is rendered and shown and then the javascript gets executed.
Internet Explorer 8 however waits until the request is completely received and its javascript executed before it shows. This gives the impression that the application is unresponsive for a short period.
We have one laptop on which IE8 loads the page like Firefox/Chrome and we've been searching for a setting on IE8 to indicate that it doesn't have to wait until all javascript is executed before showing the page or part of it.
Does anyone have a clue if there is such a setting and where it can be found? We checked that the Chrome frame for Internet Explorer is not installed.
Update:
For more clarification, as #Thariama points out in the comments I also thought that IE8 always waits to render the entire page but seeing this laptop render it I am pretty sure that it loads the 'Firefox-way'. The laptop had half the RAM and CPU power a comparable desktop had and it looked and feeled faster (because of the rendering).
I ran into the same issue today when trying to determine why IE8 would render incrementally when loading from localhost, but wouldn't when loading from an intranet server.
The fix is to tell IE which rendering engine to use. I prefer to always have it render using the latest engine available.
<head>
<meta http-equiv="X-UA-Compatible" content="IE=edge">
...
The reason it was happening is because when loading from localhost IE was rendering with the IE8 engine in standards mode. When loading from the intranet, IE defaulted to rendering in compatibility mode using the IE7 engine. The IE7 engine would pause until the whole table was loaded before rendering, but the IE8 engine would render the table incrementally.
To check which mode IE is in for a particular page, hit F12 to pull up the developer tools, and in the menu area there's a "Browser Mode" which tells you which rendering engine it chose, and "Document Mode" which indicates quirks mode or standards mode.
I was recently tasked with resolving an IE8 page rendering issue in a legacy webapp (without changing much server-side code). I wrapped the largest sections of the page in textarea elements (on the server-side) and used JavaScript to extract their contents, remove the textareas and insert the html where the textarea was... it worked out nicely... it even seems to load faster in modern browsers.
If people use IE and it always does that, they've gotten used to this 'unresponsive' idea, whenever I zap open IE to check for compatibility, I just accept the fact that all pages look 'unresponsive' for a while.
It's part of IE, people that live in ignorance are used to that, they won't click away.
Not as much a solution to your problem, which is probably not there as telling you it's not that much of a problem. I don't think there is a way to give a browser instructions to adjust its rendering model for you though, and there shouldn't be, users should be able to adjust rendering models though, but not sites. Those things are a gateway to virus.
I have a dot net nuke site that I have written a custom module for. It a form that users fill out to submit information - no big deal.
On the form, I use the Ajax and the Ajaxoolkit for validation, and a calendar popup. I enable/disable controls based on form data.
Everthing works well in every browser/OS combo that I have tested EXCEPT IE7/Vista.
The page renders with most of the lables and conrols invisible. The controls are there and you can even enter data, you just can see them.
Here is a link: http://www.gpusbc.com/test/tabid/76/Default.aspx
I develop on a Win XP machine with IE7 and FireFox and there are no problems.
FireFox on Vista has no problems.
FYI this doesn't work in IE8 on Vista in regular or in compatiblity mode. This is incredibly weird because the controls are there you can click in them but your textboxes for example if you type you don't see the data.
What I've found is that if you remove the float:left style which is inherited from the .aaInput class that all of your inputs become visible. I also removed your display of
block. Do this on both the labels and your inputs and you should be good.
I tested this with IE8's developer tools in both IE8 mode and compatibility mode.