{"id":1925,"date":"2013-11-14T19:41:28","date_gmt":"2013-11-14T19:41:28","guid":{"rendered":"http:\/\/www.sitekickr.com\/blog\/?p=1925"},"modified":"2013-11-14T19:41:28","modified_gmt":"2013-11-14T19:41:28","slug":"technique-avoid-jumpy-links","status":"publish","type":"post","link":"https:\/\/www.sitekickr.com\/blog\/technique-avoid-jumpy-links\/","title":{"rendered":"Dynamic Fragment Identifiers – A New Technique to avoid “jumpy links”"},"content":{"rendered":"

I found myself working on a user profile management tool this week. This tool had dozens of internal links to other areas of the user profile.<\/p>\n

During testing, I became quickly annoyed by the fact that each time I clicked a link to another part of the profile, the page scroll position was "reset" to the top.<\/p>\n

Within this tool, I'd ideally like it to maintain the scroll position between page loads.<\/p>\n

For the purposes of this article, I'll call this technique persistent scroll location<\/strong>.<\/p>\n

 <\/p>\n

Why not fragment identifiers?<\/h3>\n

\"fragment-identifier\"<\/a>The traditional way to approach this is to provide an id<\/em> attribute to the element you wish to scroll to, then append a fragment identifier<\/a> to the end of the link.<\/p>\n

For "one-off" links, this technique is perfect and is exactly what fragment identifiers were meant to do.<\/p>\n

There are two problems with fragment identifiers though:<\/strong><\/p>\n

    \n
  1. They may require additional markup.<\/strong> The id<\/em> attribute may need to be added to an element that didn't otherwise require it.<\/li>\n
  2. Difficult to maintain.<\/strong> If you have 100 links containing the same fragment identifier, they would all need to be changed if the id<\/em> of the referenced element is changed.<\/li>\n<\/ol>\n

     <\/p>\n

    Session Storage might work<\/h3>\n

    \"session-storage\"<\/a>HTML 5 Storage may be the next logical choice. If we create click event handlers on links that require persistent scroll location<\/strong>, we can store the current scroll position in session storage, then retrieve it on the next page load.<\/p>\n

    Issues with Session Storage:<\/strong><\/p>\n

      \n
    1. It's not available on legacy browsers.<\/li>\n
    2. It doesn't allow us to share a link that includes the scroll location (as fragment identifiers do).<\/li>\n<\/ol>\n

       <\/p>\n

      Passing in the Query String<\/h3>\n

      \"query-string\"<\/a>My next thought was to hijack the link click event as in the Session Storage technique above, but instead, append a query string parameter to the link which indicated the scroll position.<\/p>\n

      For example:<\/p>\n

      http:\/\/www.sitekickr.com\/?scroll=190<\/kbd><\/p>\n

      Issues with appending a query string parameter:<\/strong><\/p>\n

        \n
      1. This might create duplicate content issues from an SEO perspective if too many variations are spread around the web. Fragment identifiers appear to be "SEO-safe". All of my research indicates that Google ignores the fragment identifier.<\/li>\n
      2. A scroll query string parameter would conflict with a document fragment identifier if there was one.<\/li>\n<\/ol>\n

         <\/p>\n

        Dynamic Fragment Identifiers<\/h3>\n

        \"dynamic-fragment-id\"<\/a>There is a simple solution to eliminate all six issues discussed above. We can maintain the positive aspects of fragment identifiers (SEO & link sharing), while removing the negatives (additional markup and maintainability).<\/p>\n

        I'll call this technique Dynamic Fragment Identifiers<\/em><\/strong>. The premise is simple:<\/p>\n