Relative Positioning in Internet Explorer

Javascript switching document into quirks?

[jmacjm]

Hi all,

I've had a look on Google and can't find an answer to my problem, so sorry if it's already been answered.

I've recently been working on [makelifegobang.com...]

The problem lies with the details for the email capture form. In Firefox and Chrome, it displays fine.

If I look at it in Internet Explorer, for some reason the headline text, name and email labels and the submit button have all moved up.

While tweaking the template, I added relative positioning and moved those elements up around 30px. Doing this has made it display correctly in Firefox and Chrome, but unfortunately, has Internet Explorer has killed it.

I'm sure that the solution is simple - I just need to know how to apply css positioning details only to Internet Explorer.

Any help is much appreciated.

John

[pokra]

Is this the case for all version of IE?

[jmacjm]

Have no idea. Only tried it on two different computers. Does the problem appear on your computer?

[alt131]

Hi jmacjm [webmasterworld.com] and welcome to WebmasterWorld :)

The ideal is to resolve (or avoid) the problem that is causing the issue, however you can use conditional comments to send styles only to ie. The very first result in g* (quirskmode) provides a good explanantion.

I expect the reason pokra is asking about ie versions is because you don't want to "adjust" the versions that are already behaving correctly. I've had a quick look in ie6-8 and only ie7 seems to be an issue.

[penders]

The default document mode appears to be IE7 for some reason? So, even displaying in IE8 it reverts to IE7 standards (by default) and doesn't display correctly. (The 'Name:' and 'Email:' labels appear to be moved to the right, not up?) If I force IE8 standards the page displays OK for me.

Why is it defaulting to IE7? I see no META tag or header to suggest this? Why is IE7 a problem?

[jmacjm]

This is weird. I just checked in IE8 again, and its back to normal, though I haven't changed any settings. Now, the text is a little crowded and the name and email labels are to the right.

How do I check how it displays in IE7 and IE6, without reinstalling IE?

As far as resolving the problem goes, I'm not sure how to do it. Before I added the relative positioning, the elements were all 30px lower.

Any ideas?

[alt131]

The default document mode appears to be IE7

Thanks for that penders - that was the report the first time it loaded, but I thought it was me having messed with my settings earlier.

@jmacjm - based on what penders and I have observed, if the page is now displaying as desired then you are in ie8 mode - and earlier were in ie7. Have you been changing the html as we speak? Otherwise you need to investigate why the document is switching from ie8 to ie7.

You have several options for testing older ie. The best way is to run the natively, but you can get workable results from the "Internet Explorer Collection" - which gives you individual browsers. Others prefer "IE Tester" which gives you all versions in a shell.

To resolve the problem, you answered the question yourself - why have the elements been "pushed" 30px downwards in the first place? Look for padding, margins, etc.

[jmacjm]

Nope, haven't touched the HTML or CSS since more than 12 hours ago. Not sure why it would be switching.

Any idea why the document would be switching from ie8 to ie7?

I'll check tonight (at work right now) for padding,margins,etc. Had a look last night before I applied the positioning but obviously, didn't find anything.

[jmacjm]

Ok, I fixed the original problem. It ended up being a padding setting I'd overlooked in the wordpress css file.

But now, IE is giving me more problems. The text is in the right place, but it's not displaying correctly. The line-height is too small, and its cutting off the bottom of the bottom line.

Also, "name" and "email" as well as the field where you enter details are to the right. I could fix it with css positioning, but this would screw up the display in Firefox and Chrome.

What I need to do is apply positioning settings only to IE (I'm pretty sure its only version 7). How can I do that? I'll be searching on Google and will update the thread if I get it working.

[jmacjm]

Or, how can I make the blog display primarily in IE8 version? If I do that, what happens if someone visits the blog using IE6 or IE7?

[alt131]

Hi John,

It sounds like you're just dealing with the usual consequences of using a cms - lots and lots of over-engineered code so that problems arise as soon as you make changes. Just work through the issues one by one.

Good to see you are finding solutions yourself, but do pause to read the posts made by others - as I said in my first post, use conditional comments to send css to ie only.

Rather than adding more and more controlling code (eg position) to fix the issues with the email and name, find out why they are behaving that way.

If line-height is a problem, adjust it. You can use the ie developer tool bar to see what it currently is, adjust until it looks right, and then make that change in the css.

Again, rather than trying to control everything by "making" the page show in ie8 mode, I'd suggest trying to find out why it is switching. One thing that will trigger a switch is recovering from errors - validate your code and see if that removes the issue.

[jmacjm]

Hi,

I've just checked it all in IE Tester.

The display problems are in IE5, IE6 and IE7.

I've been doing my best to read the other comments, but as far as HTML/CSS coding goes, I'm definitely an amateur, so some of what you say is passing over my head.

I'll check out the conditional comments and see what I can do. As far as figuring out the issue, I'm not sure I'd be able to. It's displaying in Firefox and Chrome, so why shouldn't it display in IE? I'm not sure how to go about finding the answer when it's a browser compatibility issue. Hence, I'd rather apply "conditional comments" to IE 5, 6 and 7.

I've had a look for how to apply code to IE but I'm finding it difficult to get a clear cut answer as to how to do it.

I'm told that this works for IE7:

<!--[if IE 7]>
<link rel=”stylesheet” type=”text/css”
href=”someFileName.css”>
<![endif]–>

Can I do the same for 5 and 6, by simply changing the number?

Thanks for your help.

[alt131]

Hi John, just because you are an amateur doesn't mean you have to aim for a lower standard ;) Ask if anything "passes over your head".

Recall you have two issues and the critical one has not been dealt with: That is that your users must be able to use the form. For me, it was useable in ie6 and 8 (don't forget 9 - which I can't test). So only ie7 is critical. I did not test ie<6 as unless you are in an environment where they are prevalent you are unlikely to see them, so not worth worrying about.

The styling is secondary. This is not print. Users will be surfing with their settings that over-ride your styles, only have browsers partially open, and more, so accept variations. The question is what range of variations to accept, and there are so many browser versions, platforms and devices it is impossible to test and code for them all. What you are talking here are legacy versions, and most coders only give them limited time as they are on their way to being non-existent. Ask yourself whether the slight display variation makes enough of a difference to be worth the time and effort.

The reason for browser display variations is historical - some of those versions pre-date the current standards. Other browser/versions did not conform. There are no 100% conforming browsers as we speak, and contrary to the fashionable view, it is not just internet explorer. The reason I have been suggesting you go back to your code and locate the cause of the issue is because once you do that it is frequently possible to code to avoid "compatibility issues".

If you are posting to other forums, I expect you will receive lots of advice suggesting this or that snippet to "fix" the problem. However, as you are discovering, the more code you add, the more code to break. The regulars in this forum also know those "fixes". Just many of us take the approach that the best help for a starting coder isn't fancy code - rather understanding code enough to avoid them.

<!--[if IE 7]>
<link rel=”stylesheet” type=”text/css”
href=”someFileName.css”>
<![endif]–>
Can I do the same for 5 and 6, by simply changing the number?

Yes. Search on "conditional comment" as already suggested, and the page I mentioned - at quirksmode - will be near the top. That has a good explanation and examples of how they work. However, I note the example is a link to stylesheet - presumably one for ie. That sounds easy, but it will block all other downloads until complete. So if it is necessary to send to ie, I would use the conditional comment to send the styles rather than link to a separate file.

[penders]

There is some JavaScript in your page which specifically targets IE and adds additional CSS classes to some of your form elements...

var IE = /*@cc_on!@*/false; 
    if (!IE) { return; } 
    if (document.compatMode && document.compatMode == 'BackCompat') { 
      if (document.getElementById("af-form-826551486")) { 
        document.getElementById("af-form-826551486").className = 'af-form af-quirksMode'; 
      } 
:

Could this also be triggering IE7 standards?!

alt131... I'd suggest trying to find out why it is switching [from IE8 to IE7 standards]. One thing that will trigger a switch is recovering from errors - validate your code and see if that removes the issue.

As alt131 suggests, this needs to be resolved. Since currently IE8 is NOT rendering properly either since by default it (for some reason) is reverting to IE7 standards.

[jmacjm]

Critical Issue
- Users must be able to use the form.

I can use the form on all versions of IE. However, the field to enter the details is slightly out of the white box, which may make is confusing or difficult for some users.

So I'll forget the styling for the moment. It looks fine anyway. But I need to make sure the field of the form sits in the white box, as that's a usability issue and seems to affect all version of IE (5,6,7 and 8, haven't been able to check 9). I wouldn't worry about it, but as statistics show (both publicly available ones and my own website stats), around 40% of people are using IE so fixing it will pay off.

Moving forward, I'll see if I can use a conditional comment to drop the fields of the form a little lower so they sit in the white box. That's the clearest solution I can think of. Do you agree?

Haven't posted on any other forums either. I chose this one because it frequently comes up in the SERPs and generally has good info. I'm stoked with all the help you've already given me. And I've definitely realised that adding more code is only a band-aid solution. The simpler I can make it, the better.

[jmacjm]

As alt131 suggests, this needs to be resolved. Since currently IE8 is NOT rendering properly either since by default it (for some reason) is reverting to IE7 standards.

I don't care which version it displays in, so long as the form works and isn't confusing (see above).

[penders]

Yeah, would agree that if it works then that is what matters. It doesn't have to look the same in every browser.

Must admit to being very interested to know what is triggering IE8 to display using IE7 standards, since if it used IE8 standards it would seem to be fine. Your conditional comment only needs to target IE7 and below for this reason. (If you hit F12 to bring up the developer tools you can change the document mode that is used... Quirks, IE7 or IE8)

Yes, you can certainly use a conditional comment as a quick fix.

[jmacjm]

Ok, finished. Wasn't hard, but very fiddly. I've inserted conditional comments where needed, and had tweak to get it to look right. But its worked - the form is now functional and easy to use, in all versions of IE.

Thanks for all your help!

[alt131]

Must admit to being very interested to know what is triggering IE8 to display using IE7 standards, since if it used IE8 standards it would seem to be fine. Your conditional comment only needs to target IE7 and below for this reason.

Penders, I agree, and that is the interesting part of this code problem. Also, there are issues with ie8 in ie7 mode which aren't corrected by a conditional comment for ie7, while sending adjustments for ie8 also changes the rendering for ie8 in ie8 mode - which may render the form unusable for those users. jmacjm pleased you have a "fix" via conditional comments - but this is the reason penders and I are concerned about the document "switching " between modes.

As I understand that javascript it checks to see if the document is in quirks. If it is, the script writes in additional/other class names that adjust for quirks/strict rendering differences. So it should not trigger quirks mode, and like you I can't see anything in the document that would be causing it either.

The document has invalidities that won't be helping, but curiously a straight copy/paste of the document (including the code invalidities) does not trigger the "switch" when run locally. However, invalidities are not always logical, so my first "guess" would be to eradiate them as the source of probable erratic behaviour. Any other ideas?

[SuzyUK]

It's displaying fine (IE8 Mode) for me locally too, but in IE7 standards when viewed via browser - this suggests, to me anyway, a previous site version or server level setting of IE7 standards. - (PS: I also checked that my "intranet" settings are the same as normal browsing, so it's not that)

I checked the Compat View list [msdn.microsoft.com] and this site's not on it, which suggests it's maybe the server level it's been set at, I think the best way to troubleshoot or "fix" the mode switching is probably to force IE8 (or edge) via the X-UA-Compatible header [msdn.microsoft.com] as it takes precedence over any previous setting.

<meta http-equiv="X-UA-Compatible" content="IE=edge">

[alt131]

Good spotting Suze - just checked - and it certainly looks as if the server has been configured to send emulate ie7. Not sure if that was the case before - both penders and I noticed the page was in ie7 mode on first load, but switching - hence my thought that the html errors may be one course of the problem.

John, I realise you worked hard to get this to work, and had to learn a number of new concepts as well. My next comment is not meant to undermine that effort at all - maybe best read as a bit of side-chat between Suzy and I.

Suzy, I'm not sure brute-forcing edge via a meta is the complete answer. It may work, but I can't see any benefit in emulating older versions especially in new sites, and this is a registered domain name: Rather than configuring the server to send emulate ie, then ordering edge in each document, just remove the server configuration instead.

Plus there's the html invalidities, not to mention the script penders referred to that snoops for quirks, then adds extra classes for additional css that deals with the quirks issues. Better to code to avoid the issues, rather than creating them, then coding to fic them.

[penders]

...and it certainly looks as if the server has been configured to send emulate ie7.

Ah yes, I didn't see this at first since I was checking the response headers using Firefox! It seems the server only sends the "X-UA-Compatible: IE=EmulateIE7" response header when it receives an IE8 User Agent!

[SuzyUK]

alt, I agree the meta may not be a complete "fix", (in my defence, I did add troubleshooting) - it could be that if IE8 is forced it will break something else on the site - I think you were likely close with your original observation about CMS themes.

just remove the server configuration instead.

Easier said than done maybe, unless you're a theme fixer guru :) did you see the OP was using the Thesis WP theme? just try a search for Thesis, WordPress and emulate IE7.. (and be horrified at the "easy fix" being built into WP themes and lines of code given out on WP forums :o)

It's quite possible that the header is built into an ajax/admin.php (or some such template file) as a fix for the theme version. Paid themes are notoriously difficult to troubleshoot especially if there's been some tweaking going on. - and then if a theme version is only supported via upgrade then there is no need to keep the old version future compatible so no harm in the meta header, in theory

I don't think it's the actual server httpd.conf (or whatever Apache file) as I checked some other sites on the IP and they're not affected, but the actual configuration could depend on the level of edit privileges an author has so it's still a possibility - I do think it could be the WP theme, or some amendment to it?

it's very often quicker, easier to use the brute force method, kind of like CSS specificity overrides, instead of trying to find the needle in the haystack ;)

Guess work really, but interesting (and btw stop thinking like me haha!)