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.
Related
I have worked on a chrome plugin for one of the cloud based product. For The Chrome we have used third partly JS libraries like BackboneJS etc. Now I have to design a Firefox Extension, I am trying to figure out how much code we can reuse. Apparently spending few hours with Mozilla Developer site it seems like for Firefox Extension we have to use XUL for the UI. Not sure if we can use the html and javascript functions from Chrome App for the Firefox Extension, or what would be the approach to estimate the effort. My Understanding is that we have to do it from the scratch since like Chrome in FF we dont have concepts like background page etc.
There is nothing inherent that prevents you from implementing a UI in HTML/JS. You might have to wrap it in an XUL <iframe>, or <browser> (potentially other elements) within a <window> (Firefox will open pure HTML).
The key issue regarding extensions is that they execute in an elevated security context vs. webpages. As such, they have the ability to affect a much larger range of things in the browser and on the users system. When <iframe>, or <browser> elements are used, they have a property type which defaults to having the contents operating in the elevated security context. The default value is type="chrome" which makes the content opened be in the extension's higher security context.
Additional docs from MDN regarding security concerns with opening content in <iframe>, or <browser> elements which is not sourced from your extension distribution: Security best practices in extensions and Displaying web content in an extension without security issues
As to your JavaScript: You should be able to re-use a significant amount of it. At a minimum, the logic. Obviously, there will be more significant differences in how you accomplish interfacing to the aspects of the browsers which are not covered under standards documents (e.g. DOM manipulation should be very close, just as it is for webpage JS).
I have developer toolbar, any other tools I am missing ?
I am not doing any fancy graphics/html 5.
I have just been told I need to a support ie8; so want to know if I need to test in both, or just ie8.
Have used ms superpreview, but this is only good for static sites - I am developig a large data driven jsp website. and as far as I can see there is not any easy way to test on both ie6 ie8, without using a separate machine (albeit virtual).
edit
Will ietester remove my standard ie install (I want to keep developer toolbar). ietest will enable me to test under both, and then develop usign developer toolbar in whichever is my browser (ie6/ie8)
IE6 one of the most dumbest browser and biggest pain for both designer and developer. There is no guarantee that your site will work in both IE8 and IE6. As for checking you can use the IE Tester software which is free. Some even say that we should stop considering IE6 :)
You'll need to test in both. IE6 renders pages in a vastly different manner than IE7 or IE8.
Definitely not. If you need a page / site to work properly in IE6 then develop for that. More often than not a page that works in IE6 will work in everything else.
IE6 in particular is terrible with it's calculations regarding spacing, especially where padding is involved.
Test in both browsers on all systems possible.
Simple answer: NO.
you will need to test in all browsers you support as they all have differences to some degree.
IE6 is terrible at rendering css correctly.
you can use a tool called IETester to view your site in multiple version of IE although you wont have developer toolbar support. The other solution is to have different version on an windows image in a virtual machine.
The best way to develope a site is to develope it in a browser with the best support of css. (firefox, chrome, etc). Once you have done that then start adding browser specific fixes for browsers which do not display correctly.
Have a look at this article for how to setup your css file structure CSS
IE6 doesn't support HTML5 and CSS 3. In essence, your IE8 markups may not render well (in fact, many won't work at all) on IE6 (unless you do some CSS hack for IE).
If you want your system to work in both IE6 and IE8, test your system on both browser versions and make visual adjustments (CSS, HTML markup, etc.) accordingly.
Short answer: You cannot just code in IE8, you will need to test in IE6, too.
It's a very strange request to start coding only for those two browsers. Are you absolutely sure that's what you want? For example, what about IE7 or IE9? If you DO want to make your site as compatible as possible, in as many browsers as possible, you should make your site Standards Compliant (e.g. HTML 4 or XHTML).
Even if you don't, it's definitely where I'd start if I was going to focus on just IE6 and IE8. Unfortunately, IE6 will still likely give you trouble, but making your HTML/CSS standards compliant will make it easier a lot to ensure compatibility with IE8.
Tip to remember in IE6: If things aren't lining up exactly the way you imagine, it might be a carriage return in your HTML (yes, IE6 doesn't always ignore them *facepalm*).
Edit: Ah, corporate logic. I see.
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 am having my first foray into website design and I am learning a lot. I am also now seeing why web developers are not a huge fan of developing for Internet Explorer. Nothing seems to work how I expect. However, since the website has to work cross-browser, I am spending time looking at it in Firefox, Chrome, and IE. Something that is very non-obvious to me, however, is how to tell where problems lie in the website.
For example, the layout of one of my pages forces a footer to the bottom of the page. It looks great in Chrome and Firefox, but there's something broken in IE that make the footer align to the right (and cause a horizontal scroll to appear). I have played around with the code, but nothing really is responding to how I want in IE (even though it does in other browsers).
Are there any tools that can help "debug" the problems on a web site so fixing it is more than just a trial-and-error approach? Thanks.
One of my favorites that works in all browsers is X-Ray. You simply stick the link on that page into a bookmark and it loads some external JavaScript on top of the page you're testing. It reveals a bunch of parameters about the DOM object you click on, as well as its hierarchy in the model.
As for your specific footer problem, I would look to a potential lack of clearing of floats and divs that are wider than their parent containers somewhere up the line.
There are frameworks like GWT, ext-js, YUI which hide a lot of the browser bugs from you. But today (near the end of 2009), there still isn't a good, realiable way to narrow down browser issues and to fix them.
PS: I'm collecting tools that help during debugging here: Which tools do you use to debug HTML/JS in your browser?
I assume you have checked that your code is valid, with
HTML validator, for example: W3C Markup Validation Service
CSS checker, for example: W3C CSS Validation Service
And, of course, you should have correct doctype in your html file. Without doctype, some browsers go to quirks mode to emulate bugs in old browsers.
A cross-browser JavaScript library, like jQuery and its UI components, can be very helpful in avoiding idiosyncrasies between browsers. Microsoft provides the IE Developer Toolbar, it's not quite as easy to use as Firebug, but can still be very helpful. A Just-In-Time debugger like MS Script Debugger or Visual Studio are also a time saver.
I like Firebug for Firefox
and IE8 has Developer Tools from the tools menu and IE Developer Toolbar for older versions.
Chrome has similar tools from the page menu.
All of which allow you to see elements on the page as they are rendered in their specific browsers, which I usually find very helpful in debugging browser specific problems.
What are the main differences (if any) between the box models of IE8 and Firefox3?
Are they the same now?
What are the other main differences between these two browsers? Can a web developer assume that these two browsers as the same since they (seem to) support the latest web standards?
The Internet Explorer box model has been "fixed" since Internet Explorer 6 so long as your pages are in standard compliants mode.
See: Quirks mode and Internet Explorer box model bug.
Until I learnt about doctype declerations getting IE to work properly was a real PAIN, because IE runs in "quirks mode" by default. So having a standards mode doctype will eliminate a whole bunch of the most painful CSS problems.
I would never assume that any browser renders a page exactly the same.. always test!
Even though they support standards, there are plenty of variations between different browsers and even different versions. FF1 renders differently to FF2 which renders differently to FF3.
You also have to remember that each browser has their own JavaScript engine which again, will cause some scripts to work and other to fail.
You can ofcourse reduce these differences by using CSS and JavaScript frameworks which have been developed to support multiple browsers.
However, you still must test in all browsers. There will always be something that doesn't quite look or behave right.
Things that will always differ between the two (and other browsers) are default values (font sizes in headings, for example). The way they achieve default visuals is often different, as well, such as whether or not they use padding or margin to achieve the indentation in bulleted lists.
Something quite positive that I just noticed is that IE8 finally fixes IE's handling of margin: 0 auto for block elements that you want horizontally centered in their respective parents.