Forum Moderators: open

Message Too Old, No Replies

Page Shifts in IE 6.0

Happens on all but one page

         

kmansworld

4:13 am on Mar 16, 2005 (gmt 0)

10+ Year Member



I came across this page when looking for help with my problem. So, hopefully someone here can help me out.

I'm in the process of redesigning the layout of my personal website (so, for those that visit, I apologize for the mess on some pages). The link is:

<Sorry, no personal URLs.
See Terms of Service [webmasterworld.com]>

The problem in a nutshell:

The main page does not shift. The three other pages that I have so far redesigned all shift
noticably to the left upon loading.

The first has a lot of integrated tables that I thought might have been giving trouble, but all table codes look okay to me. And the last two don't use as many tables and still shift. When you refresh those pages, they are centered and have shifted "back" to where they should have been all along.

However, if you click on another page and later return, they shift again. In trying to double check the code, I deleted whole sections of each page to see if I could narrow down where the problem was. But the shift still happened everytime. The most surprising thing about this to me is that it only happens in IE, not Netscape (which I gave up on a long time ago). That just adds to the frustration.

Just as a caution, I really only use basic HTML. So, if any fixes involve other languages, some help with implementation would also be much appreciated.

Thanks to all who attempt to solve this for me; I appreciate any and all feedback.

[edited by: tedster at 5:07 am (utc) on Mar. 16, 2005]

tedster

5:14 am on Mar 16, 2005 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



Hello kmansworld - welcome to the forums.

all table codes look okay to me

A first suggestion here - know for sure if there is a code problem by using the W3C free validation service:

W3C Validator - HTML [validator.w3.org]
W3C Validator - CSS [jigsaw.w3.org]

Second, what method are you using to center the layout?

And finally, is there always a scrollbar visible? Or do the layout shifts you see correspond to a vanishing scrollbar?

kmansworld

5:43 am on Mar 16, 2005 (gmt 0)

10+ Year Member



Hey tedster, thanks for the reply.

Sorry about posting my personal URL, didn't know about the rule.

I ran the W3C validation tool on one of the pages giving me trouble and got this message:
----------------------
No Character Encoding Found! Falling back to UTF-8.I was not able to extract a character encoding labeling from any of the valid sources for such information. Without encoding information it is impossible to reliably validate the document. I'm falling back to the "UTF-8" encoding and will attempt to perform the validation, but this is likely to fail for all non-trivial documents.

So what should I do? Tell me more...

Sorry, I am unable to validate this document because on lines 28, 217 it contained one or more bytes that I cannot interpret as utf-8 (in other words, the bytes found are not valid values in the specified Character Encoding). Please check both the content of the file and the character encoding indication.
-----------------------
I checked both of those lines and do not see any problem. So, not sure what the error is for.

Secondly, I use the table align=center tag to center my page (as I use a lot of tables in the layout).

And lastly, no, this problem is not due to a vanishing scroll bar. In IE 6.0, the scroll bar is simply grayed out if the page doesn't extend far enough. So, it is always there. And like I said, the main page does not shift with the scroll bar there. The other three pages do. Puzzling.

Thanks for the response, again, and let me know what you think I might have to do about the W3C error.

tedster

8:12 am on Mar 16, 2005 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



Assuming you are using a regular Western European character set, I would say use the following meta tag in your head section:

<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">

kmansworld

12:30 pm on Mar 16, 2005 (gmt 0)

10+ Year Member



Ok, I fixed that and added a DOCTYPE and here are the following results (any insight on some of these problems and whether they might cause the shift would be helpful, though I know it's a lot of information):

Below are the results of attempting to parse this document with an SGML parser.
Line 23, column 6: end tag for element "HEAD" which is not open
</head>
The Validator found an end tag for the above element, but that element is not currently open. This is often caused by a leftover end tag from an element that was removed during editing, or by an implicitly closed element (if you have an error related to an element being used where it is not allowed, this is almost certainly the case). In the latter case this error will disappear as soon as you fix the original problem.
If this error occured in a script section of your document, you should probably read this FAQ entry.
Line 25, column 30: there is no attribute "LEFTMARGIN"
<body text=#000000 leftmargin=0 topmargin=0 marginwidth=0
marginheight=0 bgcolor
You have used the attribute named above in your document, but the document type you are using does not support that attribute for this element. This error is often caused by incorrect use of the "Strict" document type with a document that uses frames (e.g. you must use the "Transitional" document type to get the "target" attribute), or by using vendor proprietary extensions such as "marginheight" (this is usually fixed by using CSS to achieve the desired effect instead).
This error may also result if the element itself is not supported in the document type you are using, as an undefined element will have no supported attributes; in this case, see the element-undefined error message for further information.
How to fix: check the spelling and case of the element and attribute, (Remember XHTML is all lower-case) and/or check that they are both allowed in the chosen document type, and/or use CSS instead of this attribute.
Line 25, column 42: there is no attribute "TOPMARGIN"
... text=#000000 leftmargin=0 topmargin=0 marginwidth=0
marginheight=0 bgcolor=#
Line 25, column 56: there is no attribute "MARGINWIDTH"
<body text=#000000 leftmargin=0 topmargin=0
marginwidth=0
marginheight=0 bgcolor=#C0C0C0>
Line 25, column 71: there is no attribute "MARGINHEIGHT"
...rgin=0 topmargin=0 marginwidth=0 marginheight=0
bgcolor=#C0C0C0>
Line 25, column 88: document type does not allow element "BODY" here
...idth=0 marginheight=0 bgcolor=#C0C0C0>
The element named above was found in a context where it is not allowed. This could mean that you have incorrectly nested elements -- such as a "style" element in the "body" section instead of inside "head" -- or two elements that overlap (which is not allowed).
One common cause for this error is the use of XHTML syntax in HTML documents. Due to HTML's rules of implicitly closed elements, this error can create cascading effects. For instance, using XHTML's "self-closing" tags for "meta" and "link" in the "head" section of a HTML document may cause the parser to infer the end of the "head" section and the beginning of the "body" section (where "link" and "meta" are not allowed; hence the reported error).
Line 33, column 46: there is no attribute "TYPE"
<tr><td height=1 bgcolor=#2F4C7B><spacer
type=block
height=1></td></tr>
Line 33, column 59: there is no attribute "HEIGHT"
<tr><td height=1 bgcolor=#2F4C7B><spacer
type=block height=1></td></tr>
Line 33, column 60: element "SPACER" undefined
<tr><td height=1 bgcolor=#2F4C7B><spacer
type=block height=1></td></tr>
You have used the element named above in your document, but the document type you are using does not define an element of that name. This error is often caused by incorrect use of the "Strict" document type with a document that uses frames (e.g. you must use the "Frameset" document type to get the "<frameset>" element), or by using vendor proprietary extensions such as "<spacer>" or "<marquee>" (this is usually fixed by using CSS to achieve the desired effect instead).
Line 34, column 11: there is no attribute "HEIGHT"
<tr height=14><td
bgcolor=#F5F5F5><font size=1 face=verdana
color=#2F4C7B><b><fo
Line 34, column 97: non SGML character number 155
...color=#2F4C7B><b><font
color=#FFD200>¼/strong>?&#155;</font> 2 6
5&nbsp;&nbsp; W E B S I
Line 34, column 98: non SGML character number 155
...olor=#2F4C7B><b><font
color=#FFD200>¼strong title="Position where error was
detected.">?&#155;</font> 2 6 5&nbsp;&nbsp; W E B S I
T
Line 35, column 60: element "SPACER" undefined
<tr><td height=1 bgcolor=#2F4C7B><spacer
type=block height=1></td></tr>
Line 36, column 44: element "SPACER" undefined
<tr><td height=3><spacer type=block
height=3></td></tr>
Line 310, column 126: document type does not allow element "NOSCRIPT" here; missing one of "APPLET", "OBJECT", "MAP", "IFRAME", "BUTTON" start-tag
...ounter/counter.js"></script><noscript><a
href="http://www.statcounter.com/" t
The mentioned element is not allowed to appear in the context in which you've placed it; the other mentioned elements are the only ones that are both allowed there and can contain the element mentioned. This might mean that you need a containing element, or possibly that you've forgotten to close a previous element.
One possible cause for this message is that you have attempted to put a block-level element (such as "<p>" or "<table>") inside an inline element (such as "<a>", "<span>", or "<font>").

kmansworld

12:31 pm on Mar 16, 2005 (gmt 0)

10+ Year Member



Oh, and one comment - the head tag is open, so I'm not sure why the program thinks it isn't. Any ideas?

tedster

6:42 am on Mar 17, 2005 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



When you are working with validator output, sometimes the reported error is just a bit later than the "real" error. So for instance, if you actually have only one <head> and one </head> in the code, the validator may be seeing something earlier on in the head section that seems to close the head - because that kind of element doesn't belong in the head section, for instance.

So, having assumed that the </head> tag has occured, the validator's error report now "cascades" to a spot later in the code.

In fact, you should usually work through an entire error list from top to bottom. When you fix one error, many times later errors just vanish because of this cascading effect.