Is there a CSS expert in the house?
I've noticed that links in becontrary.com that have have a fragment (i.e. something after a #) don't always go to the exact location of the named anchor. I figured this was a Firefox bug originally, but I see the same thing in other browsers. I believe I have figured it out though. The browser changes the scroll position after the html is read, but before the stylesheets have been read. Once the browser has the CSS information the page updates, but because the CSS contains the dimensions of some elements, the named anchor changes position -- but the scroll position doesn't update accordingly. At least thats my working theory. The only solution I can think of for this is to make all my style sheets inline -- but that would mean I wouldn't have the cache-related benefits of having them external. I can't be the first developer to be irritated by this. Can anyone offer a solution?
Hi,
did you put a HTTP cache information on your CSS?
You can at least put 1 week or if not 1 month. Your CSS must certainly not evolve that much.
The browser will cache the information and your CSS should not take time to download at the second reload.
If you put your anchors in absolute positioning (I haven't looked at the details of your CSS), you might create issues indeed.
Hi,
We’re an open source gaming engine project that’s looking for python devs. If you or anyone you know is interested, please visit us at www.projectangela.org.
TIA,
M.
The CSS is definitely cached, but it still seems to happen. I'll do some experiments to try and verify it is the external stylesheets that are the root cause...
Evil-ish, but I guess this might work, if run after the page is done loading:
document.getElementById((/#([^#]+)$/.exec(document.location))[1]).scrollIntoView(true);
This isn't just a CSS problem. If the page layout changes because size-unspecified images load or the user resizes the window, the scroll anchor doesn't move either.
It's worth your while to spend some time running the results through a validator like http://validator.w3.org/check?uri=http%3A%2F%2Fwww.becontrary.com to see what kind of code you can change and whether that makes the page behave a little better. For example, you might want to add an HTML opening tag to the top of the document ;) Lots of times I've found incompliant code will work right _most_ of the time, but cause funny behaviors like this.
I've always thought it was caused by the delayed loading of images. The structure of your page loads relatively quickly, jumping to the named anchor before the images have a chance to download. As soon as an image finishes loading, it bumps everything down, causing you to move away from the anchor.
Maybe you can try explicitly setting the width and height of your images, that way the spaces are already filled in, regardless of whether they have downloaded or not. Please post a followup if you can get it to work, I've always been annoyed at this behavior and I'm curious about the solution.
Ted, I had a gazillion validation errors, and it turns out that TG was serving my templates as html even though my doctype said xhtml, plus some foolish bugs. It took a few hours to fix it, and it looks exactly the same. *sigh*
Steve, I figured it may be the images, so I made sure that my img tags had the image dimensions, but the problem still occurred. The CSS contains fixed sizes for some classes, but I don't know how to specify the dimensions in a div tag. I tried setting the style attribute in the tag, as well as overriding it in the CSS, but that didn't work either. :-(
Will, it's a browser bug; you were right. That it occurs in browsers other than Firefox doesn't change that. If the browser waiting until everything was loaded, all Javascript had run, and it had fathomed out everything's location before displaying anything to the user then it could position the scrollbar correctly.
Theoretically, there's no reason Firefox can't constantly monitor the anchor's position as it continues to build and display the page and, if the user hasn't manually altered the scroll position himself, maintain the anchor at the same point, i.e. the web page may grow off the top of the window but the only visible change would be the scrollbar.
So see if it's a Firefox bug and if any workarounds are mentioned. If it's not a bug, raise one. :-)