回顾历史，CSS1于1996.12.17发正式版，它是为辅助HTML的展现效果而生的。
1998.5.12，CSS2发正式版。随后发修订版CSS2.1，纠正了CSS2中的一些错误。注意从CSS2起，CSS的作用就不是辅助展现了，变为全全负责展现。
（注：当年CSS2的勘误表有兴趣可以看看）

CSS2.1明确了2个模型，一个是众所周知的盒模型(Box model)，CSS1没有盒模型的概念，盒模型的前身在CSS1里叫做面向盒的格式化模型。元素抽象为盒，以盒为对象设计思路清晰多了。CSS3的盒模型丰富了更多属性。盒的产生，以及盒的定位就是CSS2.1定义的第二个模型－可视格式化模型(Visual Formatting Model)。CSS3相关的布局标准实际上也在这个大的框架之下。

CSS布局有明确标准始于CSS2。CSS1里压根没提布局，虽然CSS1里有Float元素的定义，但它的设计不是为页面布局，只是为了实现图文绕排。早期用table布局便顺理成章。CSS2是98年变为推荐标准的，按理此时应该普及新的CSS布局标准，但table布局的使用习惯一直保持到2004年才被Jeffrey Zeldman那本书点醒。05年它的中文版《网站重构》出版，国内掀起重构浪潮。早期网页开发者是受软件教育的(Frontpage, Dreamweaver之类)，完全没有标准的概念。

所以要从标准出发学习CSS，而不是仅仅掌握一些工具(包括一些库)。这是有前车之鉴的。

回到布局的话题上。CSS2.1的布局分为3种：
1. 常规流(Normal Flow)
2. 浮动(Float)
3. 绝对定位(Absolute Position)

这3种不能混用。如果代码里看到position:absolute;display:block;这种明显是概念混乱。很多人也错把position:relative跟position:absolute归为一类。position:relative是常规流中的一种，例外是它可以和Float一起使用。关于CSS2.1布局的阐述请看这里：http://kejun.github.io/bootcamp_htmlcss/?5。

IE6时代被忽视的常规流布局：
1. Inline-Block。兼容性：http://caniuse.com/#feat=inline-block，触发IE的hasLayout可以实现相似的效果，以至于可以兼容IE6/7，逐渐被广泛应用。
2. CSS Table。兼容性：http://caniuse.com/#feat=css-table，仅仅不兼容IE6/7，在IE6时代被埋没。随着IE6/7的淡出终有出头之日了。

“对float的滥用就像当年对table的滥用“。很多人设计布局时不假思索的用Float，明显欠缺对布局技术有更多了解。尤其在低端浏览器日渐淡出，新的布局技术触手可及的当下，是时候学习实践这些新技术了。之前做过一个demo，用6种思路实现同一种两列布局：http://dabblet.com/gist/4094139。看完本文后，可以有更多实现思路。

今天脱囗而出的CSS3只是一种笼统的叫法。有CSS Level 1，CSS Level 2，时至今日还没有CSS Level 3。CSS2.1之上的新标准大部分仍在WD状态，只有CSS Color Level 3和Selectors Level 3进入REC状态。

（注：PD – Public Draft, 公共草案，初步想法。不乏PD之后就废弃的。WD – Working Draft, 工作草案。开始有人修订它了。LC – Last Call, 对外宣布了。CR – Candidate Recommendation, 候选推荐。REC – Recommendation，正式推荐。也就是正式版标准。这些状态只能说明标准的稳定状态。浏览器厂商从自身利益出发，选择性的支持了一些仍处于WD状态的标准。于是出现各种厂商前缀。标准制订跟不上发展，浏览器厂商在竞争中冒进，苦逼的是开发者。）

新的布局标准可以更简单更灵活的实现布局。CSS3目前有5种布局方案：
1. 多栏布局(Multi-Column Layout )
2. 灵活盒布局(Flexible Box Layout)
3. 栅格布局(Grid Layout)
4. CSS3的浮动盒(CSS3 Floating Boxes)
5. Regions

Multi-Column Layout
当前状态：CR
历史：1999.6.23发PD，2009.12.17进入CR状态
兼容性：http://caniuse.com/#feat=multicolumn
Demo: http://dabblet.com/gist/5507829，
问题：
1. 目前只能平均分栏，还不支持分别指定栏宽（未来会有）。
2. 浏览器支持的新旧标准不一。
比如，上例中div.intro的内容想保持在一栏中，chrome支持column-break-inside: avoid;这是2005.12.15更新的WD中的标准。由此推测chrome遵循的是05年的WD标准。目前CR标准已改成break-inside。Firefox20仍实现的是2001年的WD标准。
3. 多栏布局更适合用于内容流布局，不适合页面布局。

Flexible Box Layout
当前状态: CR
历史：2009.7.23发PD, 2011.3.22进入WD状态，2012.9.18进入CR状态
兼容性：http://caniuse.com/#feat=flexbox
Demo: http://dabblet.com/gist/5508104
理解它分为两部分：Flex容器(Flex Container)和Flex项(Flex Item)。
1. 定义Flex容器(display:flex)后, 它的一级子元素(inline box/block box/anonymous box)，可沿水平或垂直方向排列(flex-direction, 默认row)，可指定靠某一边对齐(flex-wrap)，可指定对齐方式(justify-content)。每个Flex项默认是等高的(align-items, 默认stretch)。
2. Flex项不指flex属性时，宽度由实际内容的宽度决定。
3. Flex项可以指定以什么比例填充空白。如：
.list li { flex:1; } 则均匀填充。
.list li:nth-child(1) { flex: 4; background: #f80; }  本例中Flex Item 1的宽为4/8。
4. flex属性是可以动画的。
5. Flex项可以控制顺序(order, 默认0，值高在后面)。
参考：http://d.hatena.ne.jp/teramako/20121021/p1

曾在weibo上出过一道题：“实现一个不定宽高的层，在窗口中水平垂直居中”，用Flex Box可以轻松实现:
html,body { height:100%; }
body { display:flex;justify-content:center;align-items:center; }

(Grid) Template Layout (曾经称为Advanced Layout)
当前状态：WD
历史：2005.12.15发PD, 2007.8.9进入WD状态。最终合并进Grid Layout

Grid Position
历史: 2007.9.5发PD，随后被废弃

Grid Layout
当前状态：WD
历史：2011.4.7发PD，2012.3.22进入WD状态，最新一版是2013.4.2
兼容性：http://caniuse.com/#feat=css-grid ，
以这种兼容性还不值得学它。1996年有个基于帧布局的草案。当时没往这条路上走，最终绝对定位进入CSS2。Grid Layout正是建在它的基础之上。

CSS3的浮动盒(CSS3 Floating Boxes)
当前状态: WD
历史：2002.10.24就出现在CSS basic box model的草案中。
CSS3的浮动盒太未来了，还没有浏览器支持。比如：
float: right contour; contour关键字，文字可以沿图片不规则的轮廓绕排。
min-height: contain-floats; 新的清浮动方式
float-displace: block; 新的float-displace属性

Regions和Shapes
当前状态：WD
历史: 2011.6.9发表PD, 2011.11.29进入WD状态，最新一版WD是2012.8.23
兼容性：http://caniuse.com/#feat=css-regions
Demo: http://dabblet.com/gist/5509294 Chrome 19+, IE10+
它适用于内容流布局。兼容性有限，可以先简单看看。

Have Fun!

进入触屏时代意味一切要对触屏友好。首先要搞清touch事件。今天仅仅测试了ios6，其它版本包括android还不清楚差别有多大。看了PPK的touch兼容表（http://www.quirksmode.org/mobile/tableTouch.html），深感刚准备告别ie6，又迎来了一个新的混乱时代，苦逼的前端工程师们永远摆脱不了兼容的魔咒。

做这个测试的目的是为了写这个库： https://github.com/kejun/SwipeEvent

—————————————————————————

测试地址：http://jsbin.com/isuqaf/2/

在iOS上的测试结果：

一：发生在非可点击元素上：
1. 手指点击(tap)，坐标不变：
touchstart
touchend
mouseover
mousemove

2. 手指在屏幕上滑动，坐标改变小：
touchstart
touchmove (多次)
touchend
mouseout (若前一次触发过mouseover)
mouseover (有时没有, 坐标改变很小时没有)
mousemove (有时没有)

3. 手指在屏幕上滑动，停留时间长一些：
touchstart
touchmove (多次)
touchend

二：发生在可点击元素上：
1. 链接若绑定touch事件，touch事件里操作dom（内容发生改变），不会触发click事件，链接也不会跳转
2. 包括父级的touch事件若改变页面内容，同样不会触发click事件
3. 不触发click的情况，解发顺序：
touchstart
touchend
mouseover
mousemove

三：window和模块都绑定事件：
1. window绑定scroll事件和touch事件，顺序:
page touchstart
page touchmove (多次)
page touchend
page scroll (手指水平移动，不触发scroll)

2. 滑过模块不会触发模块的touch事件

3. 在模块上滑动页面
touchstart
page touchstart
touchmove, page touchmove (交替触发)
touchend
page touchend
scroll (页面停止滚动时，触发一次，若手指水平移动，不触发scroll)

4. 页面滚动过程中，手指在模块区域内移动
touchstart
page touchstart
touchmove, page touchmove (交替触发)
touchend
page touchend
scroll (触发两次)

5. 页面在开始位置，向下拉并保持，再松开
同3，touchmove, page touchmove交替触发多次

四：阻止模块touchstart事件的默认行为(preventDefault)，在模块内移动手指：
1. 页面滚动失效，事件顺序：
touchstart
page touchstart
touchmove, page touchmove (交替触发)
touchend
page touchend
只是没触发scroll

五：callout时会触发touchcancel，如长按链接之类

已知的BUG:

http://code.google.com/p/chromium/issues/detail?id=142187

PPK的touch兼容表：http://www.quirksmode.org/mobile/tableTouch.html
苹果官方文档：https://developer.apple.com/library/safari/#documentation/AppleApplications/Reference/SafariWebContent/HandlingEvents/HandlingEvents.html

响应性开发的概念不做细述，一年前曾做过一次分享”聊聊响应性设计和开发“。
仅仅利用media query适配样式是远远不够的，并没有考虑触屏下的行为和特有的内容组织方式的不同。简单在桌面版基础上叠加mobile版的代码，会带来请求增多、流量、性能、代码冗余等诸多方面问题。有统计说86%的手机站看起来small其实体积比桌面版还大。

我们这次充分发挥“响应”的灵活性，实现one web。

响应式开发就为了实现one web:

1. 响应性的模块
原本网站的模块化程度越高越便于做响应性开发。一个page例如是这样组织的:
<%include file=”path/mod1.html” args=”data=data” />
<%include file=”path/mod2.html” args=”data=data” />
如果在手机下访问，模板系统在生成这个页面时，会在path/下找mobile.mod1.html，有则加之，否则加mod1.html。也就是说在同一目录下，会存在多个版本的模块，当前只有2种：mod1.html（桌面版），mobile.mod1.html（mobile版）

响应部分的代码，跟主站代码是放在一起的，这样更便于维护。一个页面模板的结构是这样的：

page1.html:

<%inherit file=”/base.html” />

<%def name=”main”>

桌面版主要内容

<%include file=”path/mod1.html” args=”data=data” />

</%def>

<%def name=”sidebar”>

桌面版边栏内容

</%def>

<%def name=”mobile_main”>

<%block filter=”collect_css”>

mobile版css

</%block>

mobile版主要内容。如果可以复用，直接调${self.main()}

很多情况下内容是不同的，比如去掉不必要的模块。

</%def>

<%def name=”mobile_sidebar”>

mobile版底部内容

</%def>

这意味可以同时开发/维护两个版本。（同样，设计师在设计一个页面，也需要秉承mobile first的原则）
在同一目录、同一文件维护比分布在不同的仓库中要方便的多。

2. 响应性的css/js
mobile版的变化很大，在样式上并不是桌面版css+mobile版css的关系。这得益于我们之前对静态文件管理系统的改造。传统的css的组织方式是集中式的，集中在几个通用文件中，形如base.css + product.css。而我们现在的方式是base.css + mod_1.css(inline) + mod_2.css(inline) + mod_3.css(inline) … 是按需组合的形式。

这样，加上设备判断后就可以轻易变成：
mobile.base.css + mobile.mod_1.css(inline) + mobile.mod_2.css(inline) + mobile.mod_3.css(inline) …

css/js文件跟模板一样，在同一目录下分别有桌面版和mobile版。根据访问端的情况，自动适配、按需组合。这样可以得到一个更优化的mobile站。

3. 增强触屏行为和兼容桌面事件
前者是指附加触屏上特有的事件：touchstart/touchmove/touchend以及手势swip/pinch/rotate/shake。这个不是难点。

mobile浏览器和桌面浏览器的事件模型有明显差异，为了完全复用桌面版的各种js组件，首要问题是设法兼容桌面事件（click和mouse事件）。

mobile上的click和mouse事件有几个需要注意的地方：
a. click和mouse事件不会发生在不可点击的元素上，意味绑在document上的事件代理完全失效
b. mouse事件是发生在手指离开屏幕后，且顺序是mouseover > mousemove > mousedown > mouseup
c. click事件最后触发。从手指离开屏幕起，有约300多毫秒延迟，而且有可能不会被触发

见下图：

“If the user taps a clickable element, events arrive in this order: mouseover, mousemove, mousedown, mouseup, and click. The mouseout event occurs only if the user taps on another clickable item. Also, if the contents of the page changes on the mousemove event, no subsequent events in the sequence are sent.”(出处)

android/ios不支持beforeunload事件，对unload事件的支持有些怪异，需要用pageshow/pagehide事件替代。

以上事件的差异都是要尽力消除的。解决思路是利用jQuery的special event机制覆盖掉原本的事件绑定。即：node.click(fn)，mobile上转向node.touchend(fn) 。实现的代码：https://gist.github.com/3358036

4. 优化和用户体验

a.去掉了apple-mobile-web-app-capable声明。单页应用要加上，用响应式开发的加上这句体验反而不好，跳转的链接会弹出窗口打开。

<meta name="viewport" content="width=device-width,initial-scale=1,maximum-scale=1,user-scalable=no">
<meta name="format-detection" content="telephone=no"/>
## <meta name="apple-mobile-web-app-capable" content="yes">


b. “If the user taps a nonclickable element, no events are generated.”(引自Apple Dev Center)，所以：

body {
cursor:pointer;
}


c. 设定内容中图片的最大宽：

.topic-content img {
max-width:100%;
}


d. 加载提示，感觉像异步加载。

e. application cache本身是为web app设计的，在响应式开发中的应用是不同的。
把大文件在手机端cache起来:

CACHE MANIFEST
# version 0.0.1
CACHE:
${static('/js/jquery.min.js')}
${static('/js/do.js')}
${static('/css/mobile/base.css')}
${image_url('/pics/icon/dou.png')}
${static('/css/ui/dialog.css')}
${static('/js/ui/dialog.js')}
${static('/js/mobile/jquery.mobile.events.js')}

这个文件是动态生成的，好处是当文件更新后，文件名中的签名会跟着变，也就会触发手机端app cache的更新。

判断cache更新：

if (window.applicationCache) {
window.applicationCache.addEventListener('updateready',function(){
window.applicationCache.swapCache();
}, false);
}

为了避免动态页面被cache，在一个隐藏的iframe里指定它。(更改，还需要进一步测试)

f. mobile上的UI库，比桌面版更有必要。

5. 调试和监测

用了两个工具adobe shadow和自带的tcpdump，对android/ios均适用。

a. adobe shadow 出了一段时间了。原来的问题是它要走adobe的weinre server，慢！终于最新版4已经可以指定本地的weinre server了。怎么启用本地weinre server是另外话题自己去搜吧，我是用jar启动的，作者网站提供各种版本：http://people.apache.org/~pmuellr/weinre/builds/1.x/
>java -jar ~/weinre-jar/weinre.jar –boundHost 10.0.2.48  (ifconfig查具体ip是什么)
weinre server启动参数：

安装shadow，同时手机上安装shadow client。

指定本地server:
 手机打开shadow client直接找ip。shadow其实就是对weinre包装了一层，它的inspector其实就是weinre调web inspector调试。

b. 用tcpdump监测http请求（参考这里）。步骤：

step 1: 建一个wifi热点
step 2: 用tcpdump命令捕获tcp的traffic，命令：
sudo tcpdump -i en1 -n -s 0 -w group.pcap tcp or port 53
(参考tcpdump用法http://www.tcpdump.org/tcpdump_man.html)
step 3: 手机联上热点，打开网站（先清cache）
step 4: Ctrl+c停掉tcpdump，log保存到指定的group.pcap文件中。pcap(packet capture)
step 5: pcap转成har文件浏览，http://pcapperf.appspot.com 或导入到charles里查看也很方便，分别看下图：

c. 在线工具：mobitest.akamai.com (说是开源了)

响应式开发最大的优点是投入产出比高。可以高效的把产品向各种终端设备上部署，而且使用体验也可以做到不错。这只是探索的开始。
用手机访问：http://group.douban.com

1. head里的顺序如下，考虑会对请求有何影响：

a. 外部js在css前面

<script src="1.js"></script>
<link rel="stylesheet" type="text/css" href="1.css?sleep=5s">
<link rel="stylesheet" type="text/css" href="2.css?sleep=5s">

b. 外部js在css后面

<link rel="stylesheet" type="text/css" href="1.css?sleep=5s">
<link rel="stylesheet" type="text/css" href="2.css?sleep=5s">
<script src="1.js"></script>

c. 内部js在css前面

<script>
// do something
</script>
<link rel="stylesheet" type="text/css" href="1.css?sleep=5s">
<link rel="stylesheet" type="text/css" href="2.css?sleep=5s">

d. 内部js在css后面

<link rel="stylesheet" type="text/css" href="1.css?sleep=5s">
<link rel="stylesheet" type="text/css" href="2.css?sleep=5s">
<script>
// do something
</script>

e. 内联css在外联css前面

<style>
body { background:red; }
</style>
<link rel="stylesheet" type="text/css" href="1.css?sleep=5s">

f. 内联css在外联css后面

<link rel="stylesheet" type="text/css" href="1.css?sleep=5s">
<style>
body { background:red; }
</style>

结果：
a,b – head里出现外联js，无论如何放，css文件都不能和body里的请求并行。补充：body里dom渲染取决于head里的js执行完。 （图1）
c – head里的内联js只要在所有外联css前面，css文件可以和body里的请求并行（图2）
d – head里的内联js只要在任一外联css后面，css文件就不能和body里的请求并行。补充：原因也是要等js执行完（图1）
e – firefox/ie下，要等1.css加载完生效。safari/chrome下，则先生效，再加载1.css
f – 等1.css加载完生效

2. 内联js要等它前面的所有外联css文件加载完后执行。之前写过一篇子资源原理的笔记。

<link rel="stylesheet" type="text/css" href="1.css?sleep=5s">
<script>
s_time = +new Date;  // 5s后才执行，所以在这里记录开始时间是不准确的。
</script>

3. 外联js放在页面最后，高级浏览器会自动做优化。如：

<head>
<link rel="stylesheet" type="text/css" href="1.css?sleep=5s">
<link rel="stylesheet" type="text/css" href="2.css?sleep=5s">
</head>
<body>
<img src="1.png">
<img src="2.png">
<img src="3.png">
<script src="1.js"></script>
</body>

firefox/chrome/safari加载的优化处理相似。见图3。

4. 内联长执行时间js，无论放在页面任何位置，都会影响整个页面的渲染。测试文件，如：

<body>
<img src="1.png">
<img src="2.png">
<img src="3.png">
 
<button id="bn">button</button>
<script type="text/javascript">
  document.getElementById('bn').onclick = function() {
    alert(1);
  }
  // 正常渲染时间
  document.body.appendChild(document.createTextNode(+new Date - s_time + 'ms'));
</script>
 
<script>
// 执行5s。重新打开页面（不是刷新），整个页面空白5s。
// 前面的dom结构正常渲染，但不显示，等5s后全部显示出来。
</script>
</body>

在页面初始执行阶段如果有长执行时间的内联js，对性能的影响是非常非常严重的！但是，如果把那段执行5s的js放到外部就不会有上述影响，或者移到domreay/onload后执行也可以。

依据上述结论组织页面中的css和js才会更合理。

感谢玉伯的这篇很好做了解释也指出一些问题： http://lifesinger.wordpress.com/2012/02/03/performance-impact-of-js-css-loading-order/

非常有幸受Franky之邀参加北京腾讯CDC“火山囗”活动。第一次同时面对100多设计师谈一些或许设计师会认为跟自己无关的技术话题，虽然我认为这个话题至少50％是设计相关的，感谢他们耐心的听完了。

响应性设计（Responsive UI），这是一个关于新时期设计策略的话题。幻灯里解释了它，我不想再赘述。

这是一个有意义的话题，主要解决跨设备跨平台布署产品的问题。从PC到各种移动设备，各个终端上的产品形态是在一个统一规划的设计策略下管理的。真正的大手笔啊，想想就令人兴奋。

简要列下我认为响应性设计和开发中的要素（具体要到幻灯里看）：
1. 兼顾移动设计
2. 模块化设计和开发
3. 浏览器分级支持
4. 自适应布局
5. 资源响应性优化
6. 性能敏感

应用响应性设计不仅仅是变变布局，而是应该把各种设备的不同特点发挥在产品设计中，这里面包含了各种响应性问题。要做到兼顾各种设备是对设计师极大的挑战。而对于工程师来说，要考虑各种技术方案、fallback支持或是降级处理的综合性方案，最终形成一个响应性UI框架把开发的成本降下来，同样是极大的挑战。

这东西现在看起来是一个大公司不想玩、小公司玩不起的事。要实现这个大“阴谋”，需要设计和技术的通力配合。但一般大公司角色分工过于明确，都是各想各的事，不愿意尝试不确定的事，因此通常用人海战术分别解决问题而不是统一解决问题。于是，会有ipad.xx.xx, touch.xx.xx, wap.xx.xx… 这看起来很蠢。当后期维护成本大到无法承受，或看到别人做到时，我想最终会回到这个路子上。