Are there solutions to make IE interpret transitional pages the same as Firefox?

August 10, 2006 4:36 PM

When my website (http://www.shalom-bayit.com/index.php) is displayed in IE, the sidebar is broken. It appears below the document no matter what width I set. However in Firefox it displays like it should. I am thinking it has to do with the doctype declaration. This problem only existed when I added php code into the page and renamed it to a php file, thus having to change the doctype to transitional. Why does IE interpret transitional pages different than Firefox? Any ideas on why this happens, and what can be done to correct it?
posted by torpark to Technology (26 answers total)

"Why does IE interpret transitional pages different than Firefox?"

The eternal question.
posted by SirStan at 4:39 PM on August 10, 2006

It looks fine on my computer in IE (as well as firefox). I'll let others answer the tech question, though. :)
posted by bim at 4:39 PM on August 10, 2006

What does renaming the file *.php have to do with the doctype? Just change it back to strict.
posted by gleuschk at 5:03 PM on August 10, 2006

Could be a broken div tag in your main index template, or you could have an image somewhere which is outside the IE boundaries of the different elements on the page (this happens in my Wordpress blog all the damn time)
posted by Happy Dave at 5:39 PM on August 10, 2006

Before you go blaming IE or Firefox or any browser, did you check to make sure your page was actually valid against the doctype you're declaring? According to this, it's not; you should fix those issues and then test it out before debugging browser-specific issues.

(Not that IE doesn't have HTML-parsing bugs -- it has oodles of 'em -- but the biggest bang for your buck is going to be making sure your page validates against the actual spec, and only after that trying to validate it against IE's internal parsing model.)
posted by delfuego at 5:46 PM on August 10, 2006

According to the w3 validator, you've got an open li tag -- that's enough to make IE puke. FF often will happily just pretend the missing tag is there. Fix that and see if you still have problems.
posted by fishfucker at 5:46 PM on August 10, 2006

Nthing what everyone else says, and very glad they're saying it.

If you haven't validated your site, then there's no point even asking "why does X happen?" or blaming IE.

IE will still cause horrible annoying problems when your code is valid, but the key difference is, they won't be your fault any more, plus other people will have had the same problem and fixed it.

By the way, the CSS is invalid too... there's a closing comment tag but no opening comment tag in the textarea section, plus a bunch of other niggling things.
posted by AmbroseChapel at 6:06 PM on August 10, 2006

Oooh, oooh -- I just found out today that my blog does this too!

I am so glad you are telling him how to fix it. I will now google these computer-words you use and ponder your answers.

Viva AskMe!
posted by Methylviolet at 6:49 PM on August 10, 2006

You don't even want to know how badly your site displays in Safari. Worse than IE.
posted by Thorzdad at 8:01 PM on August 10, 2006

Result: Failed validation, 905 errors

Hoo-boy. Thanks, delfuego.
posted by Methylviolet at 8:21 PM on August 10, 2006

Response by poster: First off, the issue is definitely the extension not working with doctype. I can prove it simply. Here is the file validated when named with an .html extension, and here is the exact same file invalidated when renamed to a .php extension.

And further, there are no open li, the validator is misinterpreting, probably due to doctype.

So now that I have proven the validation is itself the issue, anyone have any better suggestions?
posted by torpark at 9:27 PM on August 10, 2006

Your "php.php" file is returning an error. I would double-check that URL before blaming the validator. You definitely have invalid XHTML in your "index.php" file. (The <br> tags are not closed properly.)
posted by mbrubeck at 9:41 PM on August 10, 2006

Response by poster: I know that php.php is returning an error. That is the point. It is the EXACT same file as html.html, which comes back valid. This means the validator is wrong, or discriminates against php extensions.
posted by torpark at 9:49 PM on August 10, 2006

Well, I tried to get a copy of php.php to run a simple diff against html.html, and I got a different file. So will the validator, presumably.

For what it's worth, when I use wget to grab http://www.shalom-bayit.com/php.php, what I get is this:

<br />
<b>Parse error</b>: syntax error, unexpected T_STRING in <b>/nfsn/content/shalom-bayit/htdocs/php.php on line <b>1</b><br />

So I'm guessing that although your file is valid xhtml, it ain't valid php.
posted by flabdablet at 10:58 PM on August 10, 2006

The HTML version has an XML declaration; that kicks IE out of standards mode (as it's expecting a DOCTYPE and is too stupid to keep looking).

In php.php the XML declaration is causing a PHP error, in index.php it's removed/ignored so IE is in standards mode. That probably explains any differences you've noticed.
posted by malevolent at 11:47 PM on August 10, 2006

I know that php.php is returning an error. That is the point. It is the EXACT same file as html.html, which comes back valid. This means the validator is wrong, or discriminates against php extensions.

Wow, where to start?

I don't think you're really understanding the difference betwen PHP, a dynamic scripting language, and HTML, basically a text file.
posted by AmbroseChapel at 6:23 AM on August 11, 2006

The page still fails validation. Six errors. Nearly there...
posted by AmbroseChapel at 6:25 AM on August 11, 2006

"I know that php.php is returning an error. That is the point."

No, I don't mean that the validator is returning an error. I mean that when I go to php.php, the only text is:

Parse error: syntax error, unexpected T_STRING in /nfsn/content/shalom-bayit/htdocs/php.php on line 1

You need to fix the error in that file before validating it.
posted by mbrubeck at 8:25 AM on August 11, 2006

Torpark, listen to what people are saying. Go to the following link, which is your actual html.html file (not the validation of it, but the actual page itself):

html.html

Now, go to this link, which is your php.php file:

php.php

Do they look the same to you? Nope, not to me either -- because when asked for the html.html file, the webserver is returning content, but when asked for the php.php file, the webserver is returning an error. Not the validator, not the web browser, but your webserver. So of course, when the validator asks for the exact same two files, it gets the html.html content to validate just fine, but instead of getting the php.php content to validate, it gets the webserver error instead and tries to validate it.

Add to this that your html.html file is a template, and not your own page that you've asked us to take a look at -- so whether or not it validates isn't really the point. If you want your page to validate, I repeat my suggestion: read the errors returned by the validator, fix them, repeat the validation, and continue fixing any errors until your page validates fine. Only then can you take a look in various browsers to see how it looks, whether it gets presented correctly, and what browser-specific bugs you might be encountering.
posted by delfuego at 8:53 AM on August 11, 2006

Oh, torpark, a few clues: you should do your best to understand what XHTML Transitional means -- what the differences are between XHTML and HTML, and what the differences are between Transitional and Strict -- to guide your fixing of the errors (and your creation of further pages). One thing that you're tripping up on a few different ways in this page is the use of block-level elements within inline-level elements, which you generally can't do.

Note that I don't say this to be pedantic or scolding -- I say it because most every browser out there has a few different page-rendering modes, one of which is known as "quirky" (and exists in an effort to assuage the programmers who developed apps that depend on non-standard, or quirky, browser rendering in order to achieve what they wanted). IE is pretty well-known for moving into quirky mode (or remaining in strict mode but behaving like it's in quirky mode for a given element, don't get me started) if it encounters errors like block-level elements where they don't belong.
posted by delfuego at 9:00 AM on August 11, 2006

Response by poster: Okay, I modified the page so it is valid. Problem is still there, any other ideas?
posted by torpark at 12:31 PM on August 11, 2006

Response by poster: Okay, the solution is simple. The issue was the CSS interpretation of widths/padding between IE and Firefox. Validation was ancillary to the issue, but important as a control. In order to control this, I had to use a different stylesheet for IE and Firefox. To implement different scripts, I first made the stylesheets, one for firefox the other for IE. I then inserted this javascript code at the head.

Thank you to those who kept with this, and withstood my stubborn misunderstanding about php. I had not realized that when apache served the php, it wasn't serving the file but php itself.
posted by torpark at 1:39 PM on August 11, 2006

So, just to sum up, you came up with an over-complicated, brittle solution which only works with JavaScript and then gave yourself best answer?

I feel you had the opportunity to learn a lot here and it didn't happen.

But oh well, the page is fixed. See you next time.
posted by AmbroseChapel at 4:16 PM on August 11, 2006

Response by poster: Have you come up with a less complicated and flexible solution? I already resolved the issue with validation, and the difference was merely between interpretation of CSS. Perhaps you have a universal way to make CSS interpreted the same, or a much better way of directing browsers to different stylesheets. I came up with a common CSS solution, but the alignments didn't appear the same on both.
posted by torpark at 9:51 AM on August 12, 2006

Torpark, between the lack of understanding of XHTML vs. HTML, webserver behavior, validator behavior, and now just in looking at your CSS, I'm starting to think that you don't know much about web development or how stylesheets work. (Assigning two different paddings and two different widths to your sidebar in the same CSS declaration?)

To reply to your query "Have you come up with a less complicated and flexible solution?" -- about 1,000 webdesigners have done exactly that, through CSS element declarations that allow IE to see a style that other browsers don't, or vice versa. I'll leave it in your hands to use something like Google to find them. One or two hints: star hack, Holly hack.
posted by delfuego at 2:43 PM on August 12, 2006

Best answer: Success, in a single style sheet. Delfuego was correct, and yes I don't know much about development or the inner workings of stylesheets, that is why I am asking this question. I find it pretty likely that others know little more rudimentary design and css, and would also like to know this solution.

The solution was even more simple than I thought. I changed the system back to work with a single CSS file. The only difference was that IE added a margin to the sidebar float for some reason. So the solution was to use the Holley Hack. The Holley Hack allows you to add CSS code which is only parsed by Internet Explorer for Windows, by prefixing the code with "* html". So my solution was adding this after the sidebar style:

* html #sideBar {margin-right: -1px;}

Of course, my page had to meet validation first.
posted by torpark at 8:25 AM on August 13, 2006