title: Mobile Safari fails to scroll to named anchor
body: <p>I have a big SVG document <a href="http://b2tf.com/mm.svg" rel="nofollow">here</a>, containing a map of all the quests in a certain online game.  Each quest node is inside a SVG <code>&lt;a&gt;</code> element, linking to a distinct named anchor in a big HTML document that loads in another tab, containing further details about that particular quest.  This works exactly as desired in desktop Safari, and I'd expect it to work just as well in any browser that supports SVG at all since I'm using only the most basic form of linking, but it fails badly on Mobile Safari (iOS 6) - which is my single most important browser target, considering that the game in question is for the iPad.  It only scrolls to the correct anchor on the initial load of the HTML page; clicking a different quest in the SVG tab will cause a switch to the HTML tab, and the hash (fragment ID) in the address bar changes, but the page doesn't auto-scroll.</p>
  
  <p>This appears to be a known limitation in Mobile Safari - hash-only changes in the URL apparently used to force a page reload, and that got over-fixed such that nothing gets triggered at all now.  The fixes I've found online all seem to be applicable only in cases where the URL change is being generated programatically, from within the same document, rather than static links from a different document.</p>
  
  <p>Further details:</p>
  
  <ul>
  <li>I've tried doing the named anchors in both the old <code>&lt;a name="..."&gt;</code> form, and the newer <code>&lt;h1 id="..."&gt;</code> form.  No difference.</li>
  <li>I've tried adding an <code>onhashchange</code> handler, to force the scrolling to take place, but the handler isn't being called at all (verified by putting an alert() in it).</li>
  <li>I could presumably fix the problem by having each quest's details in a separate HTML file, but that would severely affect usability - with all the details in a single file, you can use your browser's Find feature to search through them all at once.  (Also, deploying 1006 files to my web hosting after each update would be a bit of a pain...)</li>
  </ul>
  
  <p>Anybody have an idea for a work-around?</p>