How does a URL fragment affect CSS layout?

Compare these 3 URLs (look in the top navigation bar in each case):

Note that the only difference is the URL fragment at the end.

The first two pages are displayed absolutely normal (at least in Firefox). This is the third where the problem is. Fragment # node -2655 pops the top navigation bar at the top of the screen. When you then scroll back to the top of the page, the navigation bar has been cut in half. This happens when using any portion of the URL that causes the navigation bar to exit the original view when the page first loads.

So how to use a URL fragment affecting css layout like this ?!

SOLUTION: as suggested below, overflow removal: hidden on the container element that the navigator held, fixed the problem. I would like to understand why!

+4
source share
8 answers

Remove overflow:hidden on #main in css_75afd7072eaf4096aaebf60674218e31.css

+8
source

I would say that this is a rendering error in FireFox, as well as in Opera. There should not be, in any case, the anchor will change the CSS as you say (unless you use jQuery or something else).

+2
source

I also have this problem, and I think I see what is happening.

A column block with massive (5678 pixels) margin and indentation makes this block very tall. On browsers other than Firefox, positive and negative values ​​cancel each other out, but FF does make it so high.

FF also knows that the two cancel each other out, but they seem to look at the 5678px add-on and decide that the column block is digging the bottom of the #wrapper block. This is an overflow - and with the overflow set to auto on #wrapper, you see the true size of the #wrapper with the scroll bar to the side.

With overflow set to hidden, FF selects the scroll bar, but still seems to scroll the #wrapper content so that the element the fragment points to is at the top of the page. This is normal behavior for fragmented links in scrollable blocks, but since there is no scrollbar, you cannot scroll the contents again, hence it looks like the fragment was executed by the fragment.

In short, I suspect that in this example, FF works with an invisible scrollbar. This may be considered a mistake, but it is probably the correct behavior. The ability to scroll content up and down inside a fixed-size block without overflow using URL fragments is a method that can be effectively used to implement image sliders that work even in the absence of JavaScript.

Hope this helps. This puzzled me for years, and this explanation suddenly hit me because of the blue. My current workaround for this is to use the jQuery “scroll to” plugin to scroll the entire page to a fragment, as this seems to prevent #wrapper content from scrolling inside.

You can also remove the "display: hidden" C # wrapper, but your page then ends half a mile away.

+2
source

I just point out that there might be some weird inheritance of the 30+ styles associated with the head. It may not be there, and this is probably a rendering error (possibly related to the :target style) proposed by Dan. I just felt it was worth noting that if you have more than thirty style sheets, you will probably start to see some kind of weirdness, no matter what happens.

+1
source

The reason is that a column with a large addition expanded its container, but the extension is then hidden, but the overflow is: hidden; but using the fragment, it scrolls to the position of the fragment, effectively chopping off anything above it. You can use javascript and set scrollTop to 0 and put it back to its normal position.

Basically, a weird edge that browsers don't seem to handle very well.

+1
source

Sorry, this is not an “answer”, this is an answer to other comments here. This problem is simply overwhelming. This is very easy to isolate (that is, it has nothing to do with the number of style sheets) and does not have a proper “solution”, since there is no way to achieve the desired rendering.

 <!DOCTYPE html> <html> <head> <style> #container { margin: 1em auto; width: 40em; } #wrapper { overflow: hidden; position: relative; } #c1 {background-color: #aaf;} #c2 {background-color: #ccf;} .column { float: left; margin-bottom: -5678px; padding-bottom: 5678px; width: 50%; } #footer { background-color: #eee; padding: 1px; text-align: center; } p {margin: 1em;} </style> </head> <body> <div id="container"> <div id="wrapper"> <div id="c1" class="column"> <p>This is some content in a short column. We would need some Javascript to change its height if we wanted a different background color for each column to stretch the full height of the respective columns...or we can use large padding together with an equal negative margin.</p> <ul> <li><a href="#p1">Jump to P1</a></li> <li><a href="#p2">Jump to P2</a></li> <li><a href="#p3">Jump to P3</a></li> </ul> </div> <div id="c2" class="column"> <p id="p1">The desired effect is to have the height of the two columns appear the same. We use 'overflow:hidden' on the containing div (#wrapper) to wrap it around the floated columns.</p> <p id="p2">These paragraphs have fragment identifiers. Problem comes in when clicking one of the links on the left. Instead of scrolling just the page, the browser scrolls the div with 'overflow:hidden' so the target is at the top. It does this even if the target is already visible.</p> <p id="p3">Opera does not exhibit this behavior. This occurs in Chrome/Safari, Firefox, and IE. (Interestingly, IE also works as expected if we completely remove the DOCTYPE declaration.)</p> </div> </div> <div id="footer"> <p>Footer stuff.</p> <p>To see why 'overflow: hidden' (or any other piece of the CSS) is needed, just try disabling it.</p> </div> </div> </body> </html> 
0
source

As a note, the technique described above is usually used to create a flexible width malit column. This is becoming less important these days, since fixed-width layouts are getting a lot more comments - browsers can enlarge a webpage to see small text, and fixed-width makes it easier to control the typography of a page, for example, set the width (in ems) to display the perfect nine words per line no matter what font size and increase the user selects.

Sorry if this does not seem to be the answer, but basically offers to abandon this old model and consider moving to fixed-width columns (which is a completely new subject).

0
source

I was able to solve this problem with some JavaScript to scroll the body to the position that the hidden overflow element was scrolled to.

 setTimeout(() => { let intendedScroll = document.getElementById("fragmentfix").scrollTop; document.getElementById("fragmentfix").scrollTop = 0; window.scrollTo(0, intendedScroll); }, 0) 
0
source

All Articles