Weird anchor issue

when you visit this page, everything seems aligned correctly at the top of the page.

but then click on the “SUBMIT YOUR STORY BELOW” link at the end of the Step 1 text. it’s an anchor link that takes you to the bottom of the page. no problem there…

but when you scroll back up to the top of the page you’ll see that the top 2 inches got sucked up into the header section and disappeared behind it. and it stays that way if you refresh the page.

why is this happening?

I have absolutely no idea why it’s doing that. Of course this being wordpress with 5000 times more code than necessary to build a simple page does not help in the slightest. It’s hard to discover which of the 300 wrapping containers with bunches of classes are doing what.

However I was able to get rid of the problem with CSS… this is weird, I have no idea why this works. But I needed to remove the overflow: hidden from #main. This seems to have been put there so the background on #main would show through to the bottom, but this is only an issue because someone floated #container. No idea why, but if someone is full-width and has no siblings sitting next to them, then they don’t need to be floated for anything.

So removing float: left from #container means #main doesn’t need overflow anything to keep the background image showing, because now #main will naturally enclose its (non-floated) child #container.

However you’d want to make a copy and try these two changes and then check all your pages. Possibly somewhere you have a page where the float makes sense?? A page with a sidebar or something?? Otherwise, that ought to fix it.

But I’ve never seen overflow jump up like that. I tried typing in fake id’s in teh URL but I could only trigger it by typing a real one like #submit. Though I have no idea why there’s a name attribute on that anchor, those are ancient from the bad old days of HTML3.2.

Then again, I can’t complain about ancient code floating around… this is wordpress after all.

i removed the left float. it was there because on the homepage the container is floated left. but anyway, its changed to NONE on this page.

i also got rid of the x and y overflows, and it seems to be working now!!! thanks!!! though i’m not sure how they got there in the first place. wasnt part of my child theme css and i dont remember ever seen those in the twentyten parent theme but oh well.

thanks!

When you think about it, this is not so weird. Your link points to an anchor within a container. Because of the “overflow :” property, you are causing the contents of THAT container to scroll up within the container itself. Then when you use the scroller on the window to move back up to the top of the page, you move the whole page NOT the contents of the container and you see that your “guitar horror” seems to have disappeared. As a test, you could at a link before or after the submission form that points to an anchor on or above “guitar horror” … and you will see what is happening. Am not sure the float had anything to do with it, but the overflow was probably put there to self-clear the element.

As Stomme said, removing the float and overflow should fix it ( actually , even just using a different float clearing will do it).

Hopefully my expanded explanation will help if you run into similar problems. WP themes are often loaded with them.

thanks dresden. appreciate the insight!

Because of the “overflow :” property, you are causing the contents of THAT container to scroll up within the container itself. Then when you use the scroller on the window to move back up to the top of the page, you move the whole page NOT the contents of the container and you see that your “guitar horror” seems to have disappeared.

#container shifted up inside #main, who did not move. It jumped up about 140px, and I actually could not see who finally stopped it either. Header isn’t positioned so should have stopped another element from being able to slide up underneath it! Normally boxes can’t just slide around in front of or behind each other unless positioning and z-index are involved… and the float’s not somehow doing it since float: none didn’t change the behaviour.

After clicking on the #submit, if you were to scroll down further instead of back up, you’d see the #container’s bottom is also up from the bottom of #main by about 140px. So it still makes no sense to me and I still don’t see why removing overflow on #main, a static box, would fix it. I use overflow all the time to contain floats and I’ve never had boxes sliding around outside a 2-D plane. It shouldn’t be physically possible without introducing a third dimension.

But again who knows, one of those hundreds of boxes might have had position on it that I missed.

CSS3D?!
==;)

OK, kidding aside.

I got lost in the style sheet myself. I think this was a trick born of the primordial WP CSS ooze accidentally. But, you CAN achieve this effect intentionally by creating a container with fixed dimensions and overflow hidden and some clever anchor work. I also know that if you set overflow in one axis to ‘hidden’ the other becomes “scroll” ( actually it’s more complex than that….

I THOUGHT I came across a pure CSS slide show that made use this concept. I am drawing a blank for links to specific examples at the moment.

I didn’t see the original but you can trigger a similar overflow bug with the following code:


<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>Untitled Document</title>
<style type="text/css">
.test {
	width:300px;
	overflow:hidden;
}
#last { background:#fcf }
.inner {
	margin-bottom:-100px;
	padding-bottom:100px;
}
</style>
</head>

<body>
<div class="test">
		<div class="inner">
				<p><a href="#last">Go to last item</a></p>
				<p>test 2</p>
				<p>test 3</p>
				<p>test 4</p>
				<p>test 5</p>
				<p>test 6</p>
				<p>test 7</p>
				<p>test 8</p>
				<p>test 9</p>
				<p>test 10</p>
				<p>test 11</p>
				<p>test 12</p>
				<p>test 13</p>
				<p>test 14</p>
				<p id="last">test start</p>
		</div>
</div>
</body>
</html>


That bug effectively killed the “one true layout” as a valid technique.