Maybe I should have titled this "Small ASP.NET Irritations Dept, possibly first entry of many". 

There's something that has been bothering me for a while regarding linking to an anchor in pages in ASP.NET.  It is a small problem, and very diffuse. Here it is:

When I use newpage#literal_anchor links in a page to go to a specific position in another page on the same site, sometimes they aren't preserved.  

The same thing occurs when I use anchor values in web.sitemap files — whether I'm using the standard System.Web.UI.WebControls adapter delivered by Visual Studio menu controls or the CSSFriendly.MenuAdapter instead. 

I much prefer the CSS Friendly version of the menu controls, btw, and hope you give it a try, but for this issue CSS Friendly is no help. With either version of the nav controls, it seems to happen more consistently if I am already on the same page where the anchor goes. IOW, when the menu option is moving me to a different position on the same page, that anchor value isn't coming through.

Maybe something "optimizes away" the navigation when the page values are the same, without checking for an anchor. (ugh, when did java and .NET both pick up that clumsy expression? I must have been asleep for a while; I woke up and noticed it all over the place.)

The issue may be provoked by something in the way I use master pages, or by something about the way I use navigation controls and sitemap configuration files. But it is unlike to be due to a particular framework or style of coding, because I've seen it in really disparate web apps. 

Somewhere deep in the bowels of the enormous, only-semi-transparent and mostly-benign forces that support ASP.NET, it looks as though the last part of the URL is not being passed along properly… sometimes.  

I don't care enough to find the root cause.  Until recently I was content to follow the advice in old joke "Doctor, doctor it hurts when I raise my arm like this." "Well, don't raise your arm like that": don't do something that doesn't work or causes some sort of difficulty.

However, when I realized how little time I was going to have to handle some of the conceptual topics in TMM and that some of them would have to be short "framing" remarks pointing into other articles, the issue became significant.  I want to be able to send you directly to Appendix C of C's DataViz whitepaper, and I expect it to work without your having to start at the top of the article and find the appendix for yourself.

It would probably help if I explain something: many parts of the DataViz whitepaper were originally written as prep for what we thought was going to be our work on the help file — that's water under the bridge, the origin story for TMM — so there is really no excuse for having to write the stuff all over again.  What's in that article is the right stuff for TMM.

So — with the kick in the pants of a similar problem to solve at work — I wrote the following little javascript hack and made it accessible to our Spacefold articles master page.  The idea is to add a querystring with ?anchor=<the literal anchor value> and use that if there is no "real" anchor value.

I thought you might like to have it. I used a nice little querystring-handling function that I found on-line (see attribution in the code), which you may find handy for other purposes. I had to adapt it slightly, but not in a way that should cause pain for other uses.  In fact I think my version is a slight bug-fix, but I'm not entirely sure <g>.

Here's the code

function navCheck() {
   var val = window.location.querystring["anchor"];
   if(val && val.length > 0 && window.location.href.indexOf("#"< 0)
  {
     var item = document.getElementById(val);
     if (item) location = location.href + "#" + val ;
  }
}

Here's the generic function it calls to handle the querystring, with my slight fix:

//from http://seattlesoftware.wordpress.com/2008/01/16/simple-javascript-keyvalue-query-string-collection/
//adapted by LSN to handle no "&" in the querystring

location.querystring = (function() {

// The return is a collection of key/value
var result = {};

// Gets the query string with a preceeding '?'
var querystring = location.search;

// document.location.search is empty if a query string is absent
if (!querystring) return result; 

// LSN added to handle no "&" in the query string:
var pairs;
if (querystring.indexOf("&") < 0) {
   pairs = querystring.substring(1).split("?");
}
else // substring(1) to remove the '?'
{ // end LSN added
   // substring(1) to remove the '?' 
   var pairs = querystring.substring(1).split("&");
}

var splitPair;
// Load the key/values of the return collection
for (var i = 0; i < pairs.length; i++)
{
   splitPair = pairs[i].split("=");
   result[splitPair[0]] = splitPair[1];
}
return result;
})();

This approach seems to work for those cases (whatever the cause) where "regular" or "real" anchors do not.  It takes a moment to register, so you'll see a slight pause and a "jump" in a long article like DataViz, but it works.  

Is there an important point here? 

I don't care enough to find the root cause. 

That's a sad feeling, and one I never used to have; it's caused by having too much to do, too much to learn, and not enough time to do and learn everything deeply.

I miss the old days when I did care, and  when I would have burrowed as deeply as necessary to find that root cause, no matter what.  Now I'll just work around it, and move on.

I wonder whether the change is in me, or if other people have experienced this also, as the rate of change in the evolution of standards and techniques continues to accelerate? 

If it's not just me, this change may be a lot more important, in the long run, than anchors in a web page.