当我们在最开始接触ASP.NET时，除了被.NET的整个框架和code-behind的代码方式吸引之外，同时对一些M$提供的cookies也非常的欣赏。其中SmartNavigation特性就是大家印象比较深的，不过这个cookie的使用和它受到的期望却相去甚远，这是为什么呢？微软在Framework 2.0里又是怎对待它的呢？

    关于Page类的SmartNavigation属性的原理、问题以及改进，我曾写了一个系列文章在份，同时有幸受约发表于《开发高手》期刊。现在来看Fx1.0/1.1中实现的SmartNavigation特性，用一句话：中看不中用。来评价，是不算太过分的。虽然这个功能的创意和实现是挺不错的，不过它实际使用的问题实在是太多了，可以看看文章了解一二。那么我们在Framework 2.0 beta2中，还要继续使用这个特性吗？     现在我们在Framework 2.0 beta2中再使用SmartNavigation特性，将会得到一个编译时warning。因为Page.SmartNavigation这个属性已被标注为Obsolete了。同时，Framework 2.0建议我们使用一个叫做MaintainScrollPositionOnPostBack的Page属性来代替SmartNavigation。名字真是无比的啰嗦，它是干什么的呢？就做和我后来弄个那个一样的事情，在页面提交后，保持Scroll Bar的位置在新的Response页面中。     MaintainScrollPositionOnPostBack的实现原理和ClientNavigation基本相同，区别是前者是通过处理Page，即整个页面的返回内容的更改来实现的，而ClientNavigation以一个控件方式提供。这都无所谓了，具体看了一下前者的实现，还是有一个地方是值得学习的，就是获取ScrollBar的位置的代码，代码片断如下：

    如此简单的代码，有什么问题呢？只细看else分支，为什么不直接返回document.body.scrollLeft，要啰哩啰唆搞得这么复杂？因为这里有一个IE的bug(我曾在开发TreeView控件，然后把TreeView放在Frame中时遇到过)，在某些情况下，我们滚动了滚动条通过document.body.scrollLeft取不到ScrollBar的位置值，这个属性总是为"0"。那么我们就都用document.documentElement.scrollLeft来取不就行吗了？这里这样做微软是为了考虑向下兼容性，因为document.documentElement属性是IE5.0以后才提供的。另外就是，回传的ScrollBar位置，通过两个预置的hide field搞定：

    MaintainScrollPositionOnPostBack和ClientNavigation都是一种非常轻便的解决方法，使用这种新的方法，基本避免了原来SmartNavigation中的所有问题，同时MaintainScrollPositionOnPostBack还支持cross-browser。新实现方式，唯一的一个小问题是如果页面篇幅太长或载入速度太慢，会有一个页面跳跃的扰动，当然这点小缺陷和正确、稳定、轻便比起来就不是什么大问题了。