Full site moves 10px up when clicking on a page jump link

HTML & CSS
1

HI all,
It’s been a while since I stumbled upon a problem which made me go to a forum for help.
I’ve had great help by Paul’OB in the past, so I’ll try here.

I even find it hard to describe the problem in a search query, or figure it out, so search results don’t get me further.

I’ll try to explain the situation as good as I can.

<html style="position: relative; height: 100%">
  <body style="position: relative; height: 100%">
    <div class="l-full-canvas" style="position: absolute; height: 100%; width: 100%; top: 0; left: 0; overflow: hidden">
      <div class="l-main-canvas" style="position: absolute; height: 100%; width: 100%; top: 0; left: 0; overflow: hidden">
        <div class="l-main-canvas-inner" style="position: absolute; height: 100%; width: 100%; top: 0; left: 0; overflow: hidden">
          <div class="l-cont-fw-top" style="position: absolute; width: 100%; left: 0; top: 0;">elements inside make it 60px high</div>
          <div class="l-cont-fw-main" style="position: absolute; width: 100%; left: 0; top: 60px; bottom: 30px; overflow-x: hidden; overflow-y: scroll"> this div contains sections with id's that act as page jump targets</div>
          <div class="l-cont-fw-foot" style="position: absolute; height:30px; width: 100%; left: 0; bottom: 0; "></div>
        </div>
      </div>
    </div>
  </body>
</html>

When you open the page … everything renders correct. (just started making it responsive, so kinda buggy on smaller screens).
http://www.contend.be/~contend/experience-matters/nl/products-amp-services.htm

But when you click on one of the tab nav items, that act as page jumps to section id’s. the .l-cont-fw-top, .l-cont-fw-main & .l-cont-fw-foot all go 10px to the top.
The .l-main-canvas-inner element still renders with the full height, with no 10px jump to the top.
Only all the elements inside jump like this.

This is also when you open the page with the id in the url. (well it is in firefox)

same link with

#portfolio-mio-technology-device-coverage

behind (sorry I can only post 2 links)

If I make everything position relative … the problem dissapears.
But I realy want these elements to be position absolute.

Here is a screenshot (with firebug selecting the l-cont-fw-main element (light blue) to illustrate the problem.

1198×692 90.3 KB

I’m really curious what causes this problem, so if anybody has an idea … please shoot.

2

Nobody ? :frowning:

3

Hi E_M,

I have looked through it a couple of times and I see the 10px exactly as you described it. While trying to find any reason for the jump I felt like I was having to deal with too many layers (nested divs) to find a clue.

I would suggest you make a bare bones minimal test case that shows the problem. See if you can take the code snippet you posted above and insert a jump link in it, turn it into a working test page. Enough to reproduce the problem with bare minimal code.

I saw some erratic behavior in Chrome that was not there in FF. Have a look at this screenshot, notice the position of the scroll bar and how the Explain… & Choose… links jump around. They were literally jumping up and down while my mouse was on them.

800×430 48.5 KB

1 Like
4

Hi Ray, I’ll make a codepen example.

I was first hoping that somebody came up such a problem before, and might now the answer asap.
But it really seems some kind of cross browser bug.
Why I think it’s some kind of bug ? Click on a page jump link … and it moves 10px … but then rescale the browser window and its back where it should be.
If you try it on mobile scale … the move is much more then 10px, more like 40-50px.

There are indeed a lot of layers, which I tend to use for more special interactions on mobile & tablet version.
It’s our own CMS, that renders the HTML & CSS (with a Sass like language but with some nice breakpoint additons, and it renders 15-30x as fast). ,
Currently all options of nested divs are enabled (which I’ll disable if I don’t use them.

5

Right, the browser is redrawing the page.

I was having to use my browser back button to get out of the anchored link and then do a hard reload (shift key + reload) to get out of the 10px jump.

6

Here is a simplified example .

http://www.contend.be/~contend/experience-matters/bugs/page-jump-test.html

vs

http://www.contend.be/~contend/experience-matters/bugs/page-jump-test.html#portfolio-sip-well-rent-amp-buy

I put a red square in the header, 10px below the top of the page, for easy check (also you can see it on the red footer).

I tried it in Codepen with the same code, but couldn’t produce the problem.
Copy pasted it in its own html document on the server … and the problem is there.

7

That’s what we needed :slight_smile:

I am seeing about a 32px jump with this test page.

Saved the page to my local machine so I could cut out css rules on the fly.
When I cut out height & line-height out of the footer the jumping went away.
That can indicate that there is a problem with the math elsewhere in the page.

      .l-cont-fw-foot {
          bottom: 0;
          /*height: 48px;*/
          left: 0;
          margin: 0;
          padding: 0;
          position: absolute;
          z-index: 2;
          /*line-height: 48px;*/
          background: #ff0000;
          width: 100%;
      }
1 Like
8

If you leave the footer but give the paragraph in the footer a margin of 0 the problem is gone as well.

      .l-cont-fw-foot {
          bottom: 0;
          height: 48px;
          left: 0;
          margin: 0;
          padding: 0;
          position: absolute;
          z-index: 2;
          line-height: 48px;
          background: #ff0000;
          width: 100%;
      }

      .foot-copyright {
        margin: 0;
        padding: 0;
      }
9

Always easier to debug with a minimal test case.

I had made an edit to my last post, was just saying that the footer height was not necessarily the problem but rather the math wasn’t adding up somewhere.

1 Like
10

But on the first example (not the simplified version).

The footer copyright has margin 0 & padding 0 as well, but the problem still exists.
remove the hight of the footer … and its fixed …
Now this is a absolute positioned footer, with a fixed height & no element inside it is bigger then that height.

I don’t have a clue why this is happening.
Knowing the fix is ok … but I would really like to understand what’s going on here.

edit nevermind, there is an element in the footer which is 40px.
So that is the problem.

Any idea why the browser does it this way ?
The containing element has overflow hidden, so I don’t really understand why it takes into account absolute positioned elements that get out of its box.
If you give the footer an overflow hidden … the problem is gone as well.

Massive thnx, I would never have looked at the footer myself.

11

PS, I’ll keep the original simplified version intact so others can see the original problem (I’ll keep it online for a few months).

here is the fixed version.
http://www.contend.be/~contend/experience-matters/bugs/page-jump-test-fixed.html

Just an overflow hidden on the footer element itself

      .l-cont-fw-foot {
          bottom: 0;
          height: 48px;
          left: 0;
          margin: 0;
          padding: 0;
          position: absolute;
          z-index: 2;
          line-height: 48px;
          background: #ff0000;
          width: 100%;

         /* fix */
          overflow: hidden;
      }
12

Cutting away at rulesets is a crude way to debug but it works when you don’t have a clue.

Glad you got it sorted out :slight_smile:

13

I think the actual problem was the top margin collapse on the p element in the footer which collapses onto the footer itself. The p elements have a default top and bottom margin and this collapses onto the footer as there is no content, padding or borders in the way.

Overflow:hidden creates a block formatting context and in this context margin doesn’t collapse through the element.

5 Likes
14

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.