SCROLL TO IT JOSH.
Well, that's sort of a fun thing: I am. At least, I do the best job that I can, given the random content I'm displaying.
There are two display mechanisms on idkfa:
For classic mode, browser scrolling isn't an issue: you're only every displaying 1 thing, and that thing is at the top.
For full mode, this becomes a problem, as the contents of a post can change the geometry of the thread after a page has loaded. For instance: a thread full of dozens of hilarious, hand-picked GIFs that load slowly even over a broadband connection. Even though I can tell the browser "Go to this inline bookmark called thread_NNNN," the browser can only do so accurately at the time that I ask it (meaning, I can tell it to focus anywhere on the page, but that point can change according to user action, dynamic changes to page elements, or late-loading page elements changing the geometry of the page). So, I do scroll for you, but it only works well when there are relatively few page geometry changes after the initial page load.
If you look at the thread display page's HTML source, you'll see the following code (with actual commentary):
// Little hackish... but so is everything else.
Event.observe(
document,
'dom:loaded',
function() {
if( window.location.href.indexOf( '#thd_' ) == -1 ) {
window.location = window.location + '#thd_5043';
}
}
);
This script binds an event handler that triggers when the programmatic underpinnings of the rendered page are available for manipulation (the "dom:loaded" event). It says, "When the browser is ready to accept commands, scroll the user to the anchor element labeled "thd_5043". The problem with this is as I said above: slow loading content that is still loading long after the "dom:loaded" event. I could wait until after all elements are loaded on the page, but depending on your connection, or the size of my choice GIF meats, that might not be for 10+ seconds. By then, the user is already bored, navigated away, or has taken it upon themselves to scroll to the content they desired. I could potentially trigger this event both on the programmatic "ready" event and the "all done" event, but then the user would be subject to random scrolling at random times (particularly bad if you're trying to write a post).
My solution works well for what idkfa was designed for: textual content, loaded with minimal asynchronous elements, and relatively few images. That that thread consists entirely of slow-loading GIFs is a corner case that is difficult to account for without punishing the user.