2

This might not have anything to do with ExtJS, but I have to provide all information in order to get a proper answer :D.

I have an application that uses ExtJS 4.1 for displaying some grid panels.

When I run the application on localhost, everything looks as it should.

When I deploy the application on a remote server, the grids are no longer displayed as required in IE8: all the information is squeezed in the table, irrespective of the column alignment(the column headers are good, but the other cells are overlapping).

To make things more general:

The same application runs good on localhost(no matter on what computer), but when I deploy it on a server, IE8 doesn't display things as it should. This happens because of the CSS or JavaScript files(probably both related to ExtJS).

Why?

Josh Unger
  • 6,717
  • 6
  • 33
  • 55
Dragos
  • 2,911
  • 12
  • 39
  • 55
  • Sounds like a missing or old cached file(s) problem...either that, or IE is going into compatibility mode because its moved from local to intranet (I've seen that happen before--intranet policy defaults to compatibility mode for some reason). – Tim M. Jul 27 '12 at 10:05
  • @TimMedora How can I check this(the compatibility mode)? I am 100% sure that it is not because of some old files in the cache, since I have cleared it several times. – Dragos Jul 27 '12 at 11:07
  • Tools -> Compatibility View Settings – Tim M. Jul 27 '12 at 11:09
  • @TimMedora Yes, that was it. Thank you a lot. I've been struggling to find a solution for this for days. Please post an answer so I can accept it. Thanks again! – Dragos Jul 27 '12 at 11:17
  • @TimMedora What is more, how can I overwrite these settings from html from javascript? It would be weird to tell the whole company to make this change in order to view my app correctly... – Dragos Jul 27 '12 at 11:39
  • possible duplicate of [CSS renders differently on web server than on development environment](http://stackoverflow.com/questions/1867383/css-renders-differently-on-web-server-than-on-development-environment) – Quentin Jul 27 '12 at 14:04
  • I think the duplicate answer provides the correct solution for forcing the page mode (let me know if it doesn't). As a note, you can also change this setting using a group policy in Windows, so it doesn't have to be a user-by-user change. – Tim M. Jul 27 '12 at 18:22
  • @TimMedora If you are referring to the link provided by Quentin, it doesn't solve the problem. I already have ` ` in the `head` section. Any other suggestions? Please post an answer, I doesn't feel right to answer my own question with the information that you provided. – Dragos Jul 30 '12 at 08:25
  • Not worried about the rep, but added an answer with a little more detail. – Tim M. Jul 30 '12 at 11:19

2 Answers2

1

If it is IE8, check in developer tools document mode, it might be going to quirks mode.

zigzag.bond
  • 308
  • 3
  • 15
1

Per the OP's request to post this as an answer:

By default, IE runs with Compatibility View enabled for Intranet sites. The reasoning for this was probably that most intranet sites using IE were written specifically for IE, and thus would break when IE began adhering more closely to standards.

This potentially causes a difference between what is viewed locally versus on an intranet (and on the internet). This can be changed across the board with a Windows group policy; some organizations are receptive to this, some can't/won't make a change.

If declaring meta http-equiv="X-UA-Compatible" content="IE=edge" doesn't fix the behavior (as stated in the comments), I would start by checking that compatibility view actually is the problem.

Other Possibilities
I'm assuming that you have the correct doctype in place (e.g. HTML 5 or HTML 4 strict, though I believe others will work fine too). This works in conjunction with the "X-UA-Compatible" declaration.

Malformed markup can trigger Quirks Mode, which looks atrocious in almost any scenario. That's probably not the case, since it looks fine locally but it's easy to check. Make sure that your document is reasonably valid and--more importantly--that there are no leading characters before your DTD (which confuses the parser). Incorrect server code can cause data to be written to the response stream before the HTML, leading to this behavior.

Lastly, reduce the problem to its simplest form, i.e. find the most basic markup which causes the behavior. If this doesn't give you any insight, post the broken code in a JS Fiddle.

Tim M.
  • 53,671
  • 14
  • 120
  • 163
  • Yes, it is the "Compatibility Mode" that caused the issue. I will see what can be done about it. Thank you! – Dragos Jul 30 '12 at 14:27