纯收藏 。过段时间页面改版的时候，应该会用到这个功能。。

有些东西找起来很麻烦，好用的又不太容易找到，之前看到很多用JS写的，固定漂浮这种效果拖动时难免会产生抖动
自己对CSS还是蛮有好感的，找来找去找到了天涯，仔细一看是纯CSS的，没有使用JS效果
我觉得它比之前看到的要精简些不用嵌套多余的DIV

简单的看一下CSS样式部分：

body {
background-image:url(text.txt); /* for IE6 */
background-attachment:fixed;
}
#bottomNav {
background-color:#096;
z-index:999;
position:fixed;
bottom:0;
left:0;
width:100%;
_position:absolute; /* for IE6 */
_top: expression(documentElement.scrollTop + documentElement.clientHeight-this.offsetHeight); /* for IE6 */
overflow:visible;
}

HTML部分加上这个id为 #bottomNav 的DIV即可：

<div id=”bottomNav”>固定漂浮物在此处O(∩_∩)O~</div>

再看看这些需要注意的地方：

_top: expression(documentElement.scrollTop + documentElement.clientHeight-this.offsetHeight);

看到 _top 大家都知道是为IE6独家准备的，但是当我只加了上面这句时，IE6下拉动滚动条看到的这个漂浮物是抖动的-_-|||
解决方法我们为IE6添加这样一条语句：

background-image:url(text.txt);

注意这里的 text.txt 其实不需要有这个txt文档，txt的文件名叫什么看自己喜好喽，如此一来我们就解决了IE6下的缓动问题。

PS:你可能会对 text.txt 和 expression 感到郁闷，也有人使用多嵌套一层 DIV 做了个假滚动条实现了这个方法，当然这种方法在也会相应的改动下默认属性，可这种写法和之前网站融合起来很郁闷，要添加一个DIV（因为我之前没有在最外 层写DIV.wrap）。
相比之下我更喜欢天涯这样的纯CSS写法，这里是DEMO

固定漂浮选择这样写的理由：

纯CSS的写法，避免了多嵌套一层外部DIV制作假滚动条造成的网站重构麻烦的尴尬场面。
同时不会有JS漂浮所产生的抖动效果。

可能更好的我没有发现，如果你有更多更好的方法别忘了告诉我哈~

本文链接：http://www.uecss.com/index.php/fixed-floating-imitation-navigation/

本文来自博客园，原理，我感觉和我以前写的很象。。。我写的如何用DIV挡住SWF？差不多也是这个意思吧？

问题描述：公司合作的一个酒店预订网站需要在页面上投广告，但对方给了一个flash文件，要求链接到其首页。直接在html的flash object前面加上<a href=...>，发现链接是点不动的。

解决过程：
开发人员没有意识到这个问题，写出的问题代码如下：

鼠标放上去是没有任何效果的，原因是默认情况下flash会被放到最高层，可能有朋友也碰到过下拉菜单被flash挡住的情况，也属于这个情况。

网上找到的解决方案是用一个透明的大button包在flash的最外层，或是用一个层盖住flash,然后定义button的onclick事件,但这种方式在firefox下工作不正常。
同时用户最关心的seo作用消失了，因为这不是一个正常的链接，是用javascript实现跳转的。

要想具有<a href...>的所有原生特性，最完美的方法应该就是用一个透明的<a href=...>链接盖住flash,最终我们采用了以下的代码，用一张大透明图链接盖住flash。
将flash放到了一个zindex为-1的层中，同时设置了wmode属性（代码中的 wmode="transparent" 和<param name="wmode" value="transparent">分别在firefox和ie下起作用）。
masker层是用来挡住flash所在层的，margin-top用到定位。blank.gif是一个透明的图片。效果如下所示，

title，鼠标手形均正常

做网站开发离不开缓存，缓存分好多种：服务器缓存，第三方缓存，浏览器缓存等。其中浏览器缓存是代价最小的，因为浏览器缓存依赖的是客户端，而几乎不耗费服务器端的资源。

让浏览器做缓存需要给浏览器发送指定的Http头，告诉浏览器缓存多长时间，或者坚决不要缓存。作为.net的程序员，其实我们一直都在用这种方 法，在OutputCache指令中指定缓存的Location为Client时，其实就是给浏览器发送了一个Http头，告诉浏览器这个Url要缓存多 长时间，最后修改的时间。

微软在OutputCacheModule中对这些缓存用到的Http头给我们进行了很好的封装，但是了解这些Http头可以更灵活的使用它们。

和客户端缓存相关的Http头有以下几个，分别是：
1. Expires:+过期时间
表示在指定时间后浏览器缓存失效，需要注意的是这儿的过期时间必须是HTTP格式的日期时间，其他的都会被解析成当前时间“之前”，缓存会马上过期，HTTP的日期时间必须是格林威治时间（GMT），而不是本地时间。举例：
Expires: Fri, 30 Oct 2009 14:19:41

使用Expires过期必须要求服务器的时间是正确的，否则发送的http头就会出问题，在windows服务下可以设置时间服务器来同步时间
2. Cache-control:
Cache-control直译成中文就是缓存控制，它的作用就是缓存控制，这个http头的值有几种。
1) max-age=[秒] — 执行缓存被认为是最新的最长时间。类似于过期时间，这个参数是基于请求时间的相对时间间隔，而不是绝对过期时间，[秒]是一个数字，单位是秒：从请求时间开始到过期时间之间的秒数。
2) s-maxage=[秒] — 类似于max-age属性，除了他应用于共享（如：代理服务器）缓存
3) public — 标记认证内容也可以被缓存，一般来说： 经过HTTP认证才能访问的内容，输出是自动不可以缓存的；
4) no-cache — 强制每次请求直接发送给源服务器，而不经过本地缓存版本的校验。这对于需要确认认证应用很有用（可以和public结合使用），或者严格要求使用最新数据的应用（不惜牺牲使用缓存的所有好处）；
5) no-store — 强制缓存在任何情况下都不要保留任何副本
6) must-revalidate — 告诉缓存必须遵循所有你给予副本的新鲜度的，HTTP允许缓存在某些特定情况下返回过期数据，指定了这个属性，你高速缓存，你希望严格的遵循你的规则。
7) proxy-revalidate — 和 must-revalidate类似，除了他只对缓存代理服务器起作用
举例:
Cache-Control: max-age=3600, must-revalidate

很显然Cache-control可以提供比Expires更灵活的缓存控制，而且它不需要依赖于服务器时间。
在Asp.Net中微软把对Cache-control属性的设置封装到了HttpCachePolicy类中，我们可以通过Response.Cache来调用以下方法来做到对Cache-Control Http头值的控制：
Response.CacheControl;
Response.Cache.SetNoStore
Response.Cache.SetMaxAge
Response.Cache.SetProxyMaxAge
Response.Cache.SetRevalidation
           
3. Last-Modified/If-Modified-Since
这 两个Http头是一对，前者表示某个地址的最近更新时间，是服务器端响应给客户端的；而后者是客户端浏览器发送给服务器的，告诉web服务器客户端有一个 最后更改时间为什么时间的缓存，服务器端接收到If-Modified-Since头后则判断客户端缓存的这份url地址的缓存是否是最新的，如果是最新 的则服务器端直接给客户端返回HttpStatus 304，意思是说这个内容在你上次请求之后没有变化过，你直接用缓存就可以了；如果服务器发现url的最后更新时间比If-Modified-Since 的值要新，则会输出新的内容。

同样微软也为我们做了服务器端设置的封装，我们可以这样调用
Response.Cache.SetLastModified(DateTime)
Response.Cache.SetLastModifiedFromFileDependencies()

如果有更复杂的需求就需要自己处理了。

4. ETag/If-None-Match
ETag和Last-Modified类似，不过他发送的是一个字符串来标示url的版本，如果url变了则此标示也跟着变化，在浏览器发送If-None-Match时告诉浏览器内容已经变了，或者没变可以使用缓存。

Iis会自动给静态文件加上Etag，在文件发生改变时重新生成一个Etag，这样对于一个网站中的n多个静态文件如：样式表，小图片等，客户端只下载一次就够了，可以减轻负载。

在Asp.Net中我们可以用以下两个方法来设置
Response.Cache.SetETag(string)
Response.Cache.SetETagFromFileDependencies()

尽管微软为我们做了很多封装，但是我们还是需要详细的了解之后才可以用好这几个Http头。

新闻来自于Cnbeta.com，我这里是纯记录
感慨一下科技的发展，就象新闻里说的，我也很向往少数派报告中在虚空中操作电脑。

原文如下：http://www.cnbeta.com/articles/88286.htm

如果不是学计算机科学的话，你可能不知道什么叫计算机视觉，也可能不知 道什么叫模式识别。但是看过电影《少数派报告》的人或许都希望自己能和汤姆·克鲁斯一样，在空中用手比划一下就能完成未来电脑的操作；甚至想过如果有像哈 利·波特那样的魔棒，挥一挥就无所不能。微软亚洲研究院语音组最近发明的空中手书项目就部分地实现了这些科幻迷、童话迷的梦想。

就如上图所展示的那样，用户手中抓一支笔、一个苹果或者其他容易辨认的 物体，在空中写下文字、做出手势，通过摄像头的“眼睛”观察，计算机就能知道用户写的是哪个汉字，想表达的是哪种手势，从而完成计算机和人的自然交流。这 也正是我们项目命名为“空中手书”的由来。之所以说是部分实现了用户的梦想，那是因为我们只是成功实现了空中手书，而真正科幻式的未来生活需要各个行业、 各个学科的共同发展进步。

孝心引发的创新

空中手书项目诞生的直接导火索是迎接2009年的微软技术节 (TechFest)，为此语音组在内部广征TechFest的参展议案，结论莫衷一是。当时，我还在家休假。我的经理霍强说，“等马磊回来再讨论吧，这 家伙鬼点子多。”回公司上班那周，正好和霍强1:1交流，当谈到组里还为TechFest参展项目悬而未定时，我就提出了要做“空中手书”的建议。其实， 这个念头由来已久，但是那次回老家度假更坚定了我的这个想法。2009年初在家过年的时候，就经常听到父母抱怨不会用键盘输入，手写板也不好用(需要不断 的抬头看屏幕和低头看板子)，我当时便吹牛说，明年回来给家里的电脑装个摄像头，然后你们对着摄像头就可以写字了。其实有这个想法也是因为之前全院的某次 Offsite，在一段非常酷的视频短片里，四位院长用手指在空中轻而易举地写下了MSRA (微软亚洲研究院的英文缩写) 四个字母，这当然是电影特效，但是却让我浮想联翩。

虽然“空中手书”的想法听上去很炫，但是霍强还是对需要投入的时间和人 力成本有所顾虑。为此，我主动请缨用两周时间先做个原型出来，然后再评定能不能继续做下去。实际上最后做出这个原型只用了2天时间，也还是一个比较简陋的 演示：首先把手的运动轨迹跟踪下来，接着保存成数据文件，然后再调用我们的识别引擎，得到识别结果文件，最后经过读取把它显示在屏幕上。

令人惊讶的是，这个原型的效果已经令人相当满意了。因此，便有了更多的人加入到这个项目的开发完善的过程中，比如我的实习生朱晓恩、霍强的实习生孙雷，以及现在继续把这个演示中加入手势识别的禹果。

技术里面隐藏的奥妙

那是不是因为这个问题太简单了，所以用两天就能做出这个演示？当然不是了。我们设计的空中书写系统里面有两个主要的组成部分，一个是运动轨迹的追踪算法，一个是手写体汉字的识别算法。而这两个领域本身都有了几十年的发展，至今还是有很多的未解问题。

比如说这个跟踪算法，跟踪什么东西、提取什么样的特征来跟踪、跟踪的效率，是不是白天晚上各种不同的光照条件下都能跟踪等等，每一个问题都可以展开来细细的做研究。而这些问题如果不解决或一定程度上解决，就不会是一个用户体验良好且稳定的方案。

再比如说这个手写体汉字识别也同样是有很多值得研究的问题。写字的风格 (楷书、行书、隶书、草书) 不同会影响识别率，不同人的写法更是差异很大。另外，汉字的笔顺也是个大问题。除去这些问题不谈，在空中写字的方式和纸面上写出来的字样式上也差别很大， 至少现在空中的汉字是要一笔写成的。这都要求我们的汉字识别器可以稳定地处理和识别出来。

两天做出来的原型只是描述了一个概念，后面还有大量的工作等着我们去做。

我们连同实习生一起做了认真的特征研究，去考虑哪些特征在光线不足的情 况下稳定，哪些在亮光甚至点光源(一般会场和室内的条件)下能够稳定等等问题。另外，现在的摄像头有自动聚焦、白平衡和自动滤波的功能，而这些功能是不是 对我们的应用有帮助？其实，有些功能不但没有帮助反而有害。我们就需要把这些问题一个个研究清楚。除了特征外，什么样的追踪算法稳定高效，适合我们的应用 场景？为此，霍强和我查阅了大量研究资料，咨询了我们微软内部的许多在这方面资深专家寻求更好的方案。

在手写识别方面，我们研究院语音组有很多年研究的积累，平面上的手写体 识别算法的性能和识别率上是全世界领先的。相关算法已经transfer (转化)到了产品部门。但是这个空中字体的轨迹有自身的特点，如一笔连画，三维空间的轨迹映射到二维上，比划之间的转折相对圆滑等。我们的算法在特征上的 处理可以对付这些问题，信号的预处理部分也可以过滤掉由于光线条件不是很好情况下跟踪算法带来的信号抖动。

除了这些在核心技术上的研究之外，在用户界面上我们也考虑了很多。这部 分我的实习生朱晓恩动了很多脑子，比如如何设计更美观的界面，捕捉到的轨迹如何呈现会更舒适。另一个重要的改进就是把识别结果中最可靠的结果放置在候选区 域的中心，把不太确定的候选结果放置在边缘。这也是为了能让用户平均选取正确汉字的手移动距离最短。

最终，完成了我们现在看到的这个对公众演示的算法设计和实现。

空中书写的应用前景

如我所言，空中手书这个项目一开始就是从用户的需求中来（有相当一批人不会用键盘输入或者不知道怎么用包括拼音输入法在内的方式）。我们的项目就给了这些人一个与机器设备交互的可能性。

我们这个空中手书关注的应用场景可以分为以下几类:

1.  交互式游戏场景。比如在Xbox中，在很多时候需要玩家的输入才能导致游戏的继续进行。这时候我们的空中手书就提供给用户一种截然不同的使用体验，用于输入名字，谜题答案；用于交互式控制完成游戏的部分场景等等。

2.  搜索是海量信息时代重要的信息组织方式。 输入搜索的查询关键词有时候并非是一件非常容易的事情。比如在IPTV上，用户的计算机连接到互联网上，用户有需要从互联网上找到有趣的视频或者电影电视 然后从自己家的电视屏幕上进行播放。这时候，我们的空中手书就提供给用户一个输入方式选择。尤其是那些不会用T9输入法的中年以上用户。毕竟，手写输入还 是自然的输入方法之一。

3.  我们的空中手书还允许用户输入手势。通过一组直观易用的手势，用户可以方便地和各种智能设备交互。控制音视频的播放，提升用户体验，快速访问某些设定功能，等等。

总之，空中手书给了用户新的选择。它的应用场景就仅仅受限于我们和用户的想象力。

空中手书的演示成功恰恰是一个研究问题的开始，恰恰说明用户对更自然的 人机交互方式提出了诉求。就在写本文的时候，我们还在研究是否有更自然的方式可以捕捉人的运动，从而和计算机交互；是否能让我们的跟踪算法和人眼的跟踪一 样稳定。同时，我们还在研究使用手势识别来理解用户意图，让每个人都可以体验到空中舞动之美，体验到人机交互带来的便利。