参考：
http://filamentgroup.com/examples/responsive-images/
http://coding.smashingmagazine.com/2011/01/12/guidelines-for-responsive-web-design/
原则
responsive Web design is not only about adjustable screen resolutions and automatically resizable images, but rather about a whole new way of thinking about design. 响应设计不仅仅是适应分辨率或者缩放图片，也是一种整体设计形式。
initial-scale=1
这个是约束浏览器的缩放行为，而maximum-scale=1.0是约束用户的缩放行为。因为默认的viewport是980，然后要现实在320的尺寸里，所以最开始initial-scale的值是320/980，我们设置为1的意思就是不让浏览器缩放以自适应。
maximum-scale=1.0
如果没有这个属性，用户是可以用手指缩放页面的，那么设置为1的意思就是，你放大也只能放大为以前的1倍，本质意思就是放大不了。如果设置为2，我们可以测试下，确实再怎么努力，只能放大为2倍。
例：
<meta name="viewport" content="">
p{ width:50%; }
什么都不设置的时候，竖屏转横屏的时候，p会放大。因为竖屏幕的时候viewport是980，所以initial-scale是320/980，而横屏幕的时候initial-scale是480/980，所以当p的width为50%的时候，虽然横屏竖屏都是490px，但是实际大小不一样，因为initial-scale是不一样的，横屏幕的实际尺寸要大一些。所以这样的“放大行为“，不要以为和maximum-scale有关，它是控制用户缩小放大的，而非浏览器。
还如：
<meta name="viewport" content="width=device-width">
p{ width:50%; }
竖屏时，viewport 320px没问题，所以p是160px。
横屏时，320px是小于屏寸的，但没设置initial-scale，所以浏览器会自动赋予initial-scale的值，这个值是480/320。所以最后的viewport还是320px，p也是160px，但是横屏幕下的160px实际尺寸大于竖屏幕下的160px，因为前者initial-scale的值为480/320，而后者是1（不需要放大），前者比后者大。
minimum-scale=1.0
貌似多余。。。。
user-scalable=no
设置后，用户就不能进行缩放操作。感觉这个跟maximum-scale有点重复，既然你都不能缩放，
那我设置缩放的值意义在哪里？难道是为了以后修改代码的方便？先把属性打上去，万一要缩放了，把这个属性去掉，然后maximum-scale的value改一改？
content="width=320"
如果竖屏的话，默认的viewport是980,所以我们设置320是要只显示320的内容。如果设置的width小于320，则其实跟width设置为320的效果一样。如果设置超过320，而initial-scale又设置1，则如果元素设置的width超出50%，则会出现滚动条。
viewport
既显式设置viewport width，又设置initial-scale的时候，
<meta name="viewport" content="width=400,initial-scale=1">
p { width:50% }
横屏幕时，p的width值为240，竖屏幕时，p的width值为200。
初步结论为，如果设置的viewport width通过initial-scale还不能达到屏幕尺寸，则viewport width取屏幕尺寸的值。
上面因为横屏幕的时候400还是小于480的，而缩放设置为1，不能拉伸了，所以最后取了480，为验证，我们再，
<meta name="viewport" content="width=500,initial-scale=1">
p { width:50% }
横屏幕时，p的width值为250，竖屏幕时，p的width值也250。这说明横竖的时候设置的viewport值都超过屏寸，所以最后取设置的值为实际的viewport。
例：
<meta name="viewport" content="initial-scale=2,width=260">
p { width:50% }
最后竖屏幕是130，横屏幕也是130,因为260x2＝520,远远满足无论竖屏还是横屏的任何一种需要，所以viewport就是260。
如果viewport width的值要取屏寸的值，那么最后还要除initial-scale，才得到真正viewport值，当initial-scale的值为1的时候，除1好像没变化，于是我们就容易忽视这个动作：
例：
<meta name="viewport" content="initial-scale=2,width=160">
p{ width:50% }
横屏幕的时候，p的width160，因为160*2＝320，还是小于480，所以viewport widh只能取屏寸，但屏寸是480，而且这里已经有initial-scale放大2倍，所以只需240的viewport width就可以达到充满屏幕的要求了，因此最后的viewport值为240，最后p的值为120。
例：
<meta name="viewport" content="initial-scale=2,width=300">
p{ width:50% }
这里viewport的值为300，最后是不需要除2的，因为它不符合“viewport width的值要取屏寸的值”的要求。
显式设置viewport width，但不设置initial-scale值的时候，
这个属性非常有用，当我们设置的viewport值小于屏寸的时候，它可以拉伸来解决问题，所以又不一定要取屏寸来作为viewport，如：
<meta name="viewport" content="width=200">
p { width:50% }
横屏幕时，p的width值为100，竖屏幕时，p的width值也100。这说明width为200的时候，虽然竖屏屏寸为320，但通过initial-scale放大充满了屏寸也可以满足viewport的需要，横屏也是一样。
200/320
不显式设置viewport width，也不设置initial-scale的时候，
如果不显示设置，貌似默认的viewport无论是横屏幕，还是竖屏，这个值都是980px，如
<meta name="viewport" content="">
p { width:50% }
横屏幕时，p的width值为490，竖屏幕时，p的width值也490。初步说明以上结论正确。
这个是怎么得出来得呢？我只是猜想得过程是这样得，
因为没有显式的设置viewport widh，所以这个width值是要默认取屏寸的，但是根据第一条的原则，如果要取屏寸作为viewport width，则还需要除initial-scale的值。而这里initial-scale的值是320/980，所以竖屏的时候320/(320/980)，最后结果是980,于是得到了我们所谓默认的viewport 980px。。
横屏幕的时候也一样，横的时候initial-scale的值是480/(480/980)，所以也是980。
仅设置initial-scale的时候，
<meta name="viewport" content="initial-scale=0.5">
p { width:50% }
横屏幕时，p的width值为480，竖屏幕时，p的width值也320。额，这个值一出现的时候，吓到我了，因为这么说竖屏幕时viewport的值至少是640。。。再推断只能是屏寸去除0.5才会达到这个值，这个结论不敢下，于是再，
<meta name="viewport" content="initial-scale=2">
p { width:50% }
如果竖屏幕时，p的width值为320/2/2＝80，则说明结论基本正确。。结果实验后，确实如此，竖时为80，横时为480/2/2=120。所以，
如果不显式设置viewport，仅设置initial-scale，那么viewport的值并非是传说中的默认值980，而是等于屏寸，但是还是那个原则，如果你要取屏寸作为自己的viewport width，那么还是要取除以initial-scale才能得到真正的viewport值，跟第一条遥相呼应。
注：
initial-scale的值最多只能设到5，因为设置6，8，10乃至30的p width都和设置5的时候一样。
总结论是：
大了我不管，小了用initial-scale能搞定，我也不管，但若要取屏寸，则需除initial-scale。
width=device-width
我们经常设置的<meta name="viewport" content="width=device-width,initial-scale=1">，可以用以上结论来解释，
横屏幕的时候，320不满足屏寸，又不能放大缩小，所以用屏寸作为viewport width，然后要除initial-scale，所以最后值是480，所以p的width为240。竖屏的时候，320完全够，所以p的width是160。
<meta name="viewport" content="width=320,initial-scale=1">，其实效果也一样，
因为竖屏幕320当然满足尺寸，所以竖的时候为160这没问题。但横屏幕的时候，320是小于device width 480的，但initial-scale的值又为1，又不能进行拉伸，所以只能用屏寸的值来当作viewport值，所以最后还是480（480要除initial-scale的值1，值还是480），最后横屏幕的时候p的width为240。
看起来，设置width=device-width似乎没必要，但其实它是为了兼容不同的设备，如ipad什么的，这样device-width的值会跟着设备变化，所以还是用它比较好。
注意设置width=device-width的时候，这个值在iphone上就是320，无论横屏还是竖屏。当为横屏时，这个320就不够，而且此时若设置了initial-scale则无法拉伸，则viewport值还是取屏寸480的。而如果没有设置initial-scale，则这个值也是ok的，因为浏览器会自动设置initial-scale，让其拉伸适应480的屏，所以viewport值为320没问题，最后p的width应该是160，实验和结论一致。
显示的实际尺寸
<meta name="viewport" content="initial-scale=1,width=400">
p { width:50% }
最后显示的实际尺寸应该是viewport width*initial-scale，所以这里是400，因此已经超出屏寸，所以肯定会有滚动条（手指滑动时出现）。
什么都不设置的时候，实际尺寸其实也是320，因为initial-scale的值是320/980，然后viewport width是980，所以实际尺寸还是320，因此初始状态没有滚动条。
<meta name="viewport" content="initial-scale=2,width=160">
p { width:50% }
viewport width为160，然后160*2=320刚好符合屏寸要求，所以没有滚动条。
apple-mobile-web-app-status-bar-style
用于改变顶端bar条的样式（本地测试米反应）
<meta name="apple-mobile-web-app-status-bar-style" content="default">
content可以设置black，black-translucent，
参考：
http://developer.apple.com/library/safari/#documentation/appleapplications/reference/SafariHTMLRef/Articles/MetaTags.html#//apple_ref/doc/uid/TP40008193-SW1
apple-mobile-web-app-capable
If content is
set to yes, the web application runs in full-screen mode; otherwise, it does not. The default
behavior is to use Safari to display web content.
全屏幕模式还是safari栏也要出现。
<link rel="apple-touch-icon" href="logo.gif"/>和<link rel="apple-touch-icon-precomposed" href="logo.gif" />
两者都是添加到主屏幕，前者图表会高光显示，后者不会。
devicePixelRatio
js通过window.devicePixelRatio 来判断
是否为Retina
css的话，利用media query来做：
@media all and (-webkit-min-device-pixel-ratio: 2) {
#home-news a {background-image:url(images/icon-news@2x.png);
}
准备两个背景图，一个是2倍分辨率，一个1倍。然后设置background-size:57px 57px;不用说大图的实际尺寸是114x114的，所以设置这个是为了缩放至57x57（注意和background-position的意义不同），然后由于retina的关系在57x57的区域里，又实现了114x114，所以会比较清晰。