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?

This blog post was posted to It's All Geek to Me on Sunday October 28th, 2007 at 12:13PM
 

8 Responses to "Is there a CSS expert in the house?"

  • karl
    October 28th, 2007, 3:49 p.m.

    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.

  • October 28th, 2007, 5 p.m.

    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.

  • October 28th, 2007, 5:52 p.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...

  • October 28th, 2007, 10:53 p.m.

    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.

  • October 29th, 2007, 2:29 a.m.

    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.

  • Steve
    October 30th, 2007, 4:33 a.m.

    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.

  • October 30th, 2007, 10:25 a.m.

    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. :-(

  • Ralph Corderoy
    October 30th, 2007, 12:37 p.m.

    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. :-)

Leave a Comment

You can use bbcode in the comment: e.g. [b]This is bold[/b], [url]http://www.willmcgugan.com[/url], [code python]import this[/code]
Preview Posting...
Previewing comment, please wait a moment...
Will McGugan

My name is Will McGugan. I am an unabashed geek, an author, a hacker and a Python expert – amongst other things!

You are reading my tech blog. See the homepage for my other blogs.

Search for Posts
Possibly related posts
Tags
Popular Tags
 
Archives
2013
 
Recent Comments
Trying to implement this code. What are the requirements? Does it need a certain version of PHP, etc? Do I ...
No an ad.cssSlider is a free slide show creator with the Kenburns effect (and very few others), it is a ...
No an ad.cssSlider is a free slide show creator with the Kenburns effect (and very few others), it is a ...
Hi Will Can't seem to run any pyopengl applications on my Win7 64bit setup. Using python 3.3 but keep getting ...
Great work, is it possible to jump to a specified picture?
 
© 2008 Will McGugan.

A technoblog blog, design by Will McGugan