在YUI2中，我们没有官方的时间模拟机制，但是YUI3带给了我们这个便利，使我们可以通过模拟来对代码进行最直接的重用：

一个简单的例子：

YUI().use('node-event-simulate', function(Y) { 

     Y.one("body").simulate("click");}

);

这样就模拟点击了body的click事件。

当然你还可以附加其它按键，例如模拟shift键同时按下点击效果。

Y.one("body").simulate("click", { shiftKey: true });

同理alt键也是如此

node.simulate("click", { altKey: true} );

更方便的是你可以指定源

node.simulate("mouseout", { relatedTarget: document.body });

还有坐标

node.simulate("mousedown", { clientX: 100, clientY: 100 });

对于ui层面的改变它也同样敏感

YUI().use('node-event-simulate', function(Y) {
  var node = Y.one("#myInput");
  // 模拟节点选择改变
  node.simulate("change");
  // 模拟节点被选中
  node.simulate("select");
}
);

更轻量

－ 出色的颗粒化模块，子模块划分；

－ 延迟加载；

－ 强调代码重用（公共基类、插件、扩展）；

更易用

－ 统一的API；

－ 便利（each, bind, queue, 支持链式）；

更快捷

－ 重构node, event, selector等，解决很多核心痛点；

－ 依赖性处理；

Hello YUI

初识YUI3.x，最先发现的一个变化就是，原先YAHOO的命名空间被改为YUI，这样命名的修改，就不用在为了使用这个开源的框架而非要搞得代码里到处都是YAHOO公司的名字，但更好的一点是，可以借助不同的变量名让YUI3和旧版的YUI共存而不至于冲突。

沙箱(Sandboxing)

这是YUI3.x的一个显著特点，它可以在页面中创建一个多重开发环境。每一个YUI实例会自包含的，保护和限制。

YUI().use('node', 'event', function(Y) {
      // ready
});

在这里，YUI()执行并返回一个use方法执行后的库的实例。use方法至少有两个参数是必须，库组件名称和加载完毕后执行的回调函数。 上面的例子中，会加载名字为’node’和’event’的库组件，最后一个参数是回调函数，YUI()执行后的包含所加载的库组件的实例会以参数Y传给这个回调函数。

相对于YUI2.x的只有YAHOO一个全局变量，沙箱的这种多重开发环境的好处还是很明显的。

YAHOO.widget.HelloWorld = doSomething; // 开发者A的代码
...
YAHOO.widget.HelloWorld = doOtherthing; // 开发者B的代码

如上，在YUI2.x中，YAHOO作为全局变量，多人开发的时候，将会出现B的代码覆盖A代码的情况，而且这种情况不是使用闭包所能解决的。而YUI3.x的沙箱，提供每个实例可独立开发：

YUI().use('node', function(Y) {
      Y.HelloWorld = doSomething; // 开发者A的代码
});
YUI().use('anim', function(Y) {
      Y.HelloWorld = doOtherthing; // 开发者B的代码
});

沙箱使得代码更安全，而且，每一个实例的YUI3.x版本不同也没有关系。

YUI().use()的另外一个特点是每个实例的依赖，可以按需加载。这样不但可以节省带宽，而且也使得更加力度的颗粒化模块变得更有意义。而且，加载的所依赖的js文件是延迟加载的，加快了页面渲染的速度。

测试显示，延迟加载使得页面在更短的时间内渲染完成。

但同时，因为依赖进来的包，都是独立的文件，每引入一个文件，就创建一个<script>标签去请求js文件，这样大大的增加了HTTP请求的数量。

颗粒化模块

YUI2.x每个模块庞大的体积让不少人望而兴叹。比如有时候要使用日历里面的基础功能，你不得不把整个日历组件导人，整整75K的代码，你实际用到的仅仅是基础功能，这也是很多公司没有使用YUI的原因之一。YUI3.x做了大调整，对每个模块都进行了更细颗粒度的划分。比如，DOM模块，划分为了base, screen, style, selector-css2, selector-css3, selector-native等几个小模块，这样，我们可以根据需要选择所需的模块，对于我们控制页面的载入的数据量有很大帮助。

但更细的划分模块，带来的弊端就是，代码文件增多，维护成本变大。

选择器(Selector)

YUI2.9就已经引入了选择器引擎，但由于它在整个YUI2.x中出现得比较晚，所以，在很多基于旧版本的YUI项目中，还是用传统的元素匹配技术。

而在YUI3.x中，选择器已经成为了一种标准支持。

Y.one('#demo');
Y.all('.demo');
Y.all('.demo').filter([filter]);
Y.all('#demo li');

如果需要用到css选择器，需要把selector-css2.js和selector-css3.js引入。但从性能的角度上讲，我还是觉得没有必要去用那么复杂的选择器。

链式调用

跟jQuery一样，YUI3.x也开始支持链式调用，对于一些没有逻辑返回值的方法，YUI3.x都支持链式调用。

Y.one('#demo').set('innerHTML', 'Hello World!').addClass('hight-light');

链式调用并非YUI3.x的主打亮点，但的确带来了书写的便利性，但同时，对于向来严谨的YUI，链式一定程度上会带坏现有代码风格。使用YUI开发的人，至少要在链式调用使用程度上达到一定的共识。

Nodes

由于各个浏览器对DOM标准的支持不同，YUI Node对底层的DOM节点进行封装，并强化其功能，为创建、操作和获取DOM节点对象（集合）提供了丰富的方法。封装后的YUI Node和浏览器HTMLElement对象对比：

封装后，获取到的不在是一个浏览器DOM对象，所以对YUI Node对象的熟悉的访问和修改，必须通过getter和setter来操作。

var el = Y.one('#demo');
alert(el.id); // undefined
alert(el.get('id')); // 'demo'

小结

正如我们所看到的，YUI3.x相对于早前版本，完全是一个新的产物。通过新的语法，我们使用到的是，更轻量，更易用，更快捷的库。YUI2.x是一种工具集，而YUI3.x更像是一种架构，框架或者说解决方案。

本周的豆知识分享就来深入研究一下window.event对象。请先看看下边的代码片断。

<button id=”btn”>Click!</button>
<script type=”text/javascript”>
// <![CDATA[
    document.getElementById('btn').onclick = function (e) {
        if (typeof e == 'undefined') e = window.event;
        var target = (typeof e.target == 'undefined' ? e.srcElement : e.target);
        alert(target);
    }
// ]]>
</script>

<button id=”btn”>Click!</button>
<script type=”text/javascript”>
// <![CDATA[
document.getElementById('btn').onclick = function (e) {
if (typeof e == 'undefined') e = window.event;
setTimeout(function () {
var target = (typeof e.target == 'undefined' ? e.srcElement : e.target);
alert(target);
}, 1000);
}
// ]]>
</script>

<button id=”btn”>Click!</button>
<script type=”text/javascript”>
// <![CDATA[
document.getElementById('btn').onclick = function () {
setTimeout(function () {
alert(window.event.srcElement);
}, 1000);
}
// ]]>
</script>

<button id=”btn”>Click!</button>
<script type=”text/javascript”>
// <![CDATA[
var lastEventObj = null;
document.getElementById('btn').onclick = function () {
if (lastEventObj == null)
lastEventObj = window.event.srcElement;
else
alert(lastEventObj === window.event.srcElement);
}
// ]]>
</script>

<button id=”btn”>Click!</button>
<script type=”text/javascript”>
// <![CDATA[
document.getElementById('btn').onclick = function () {
alert(typeof window.event.toString);
}
// ]]>
</script>

<button id=”btn1″>Click1!</button>
<button id=”btn2″>Click2!</button>
<script type=”text/javascript”>
// <![CDATA[
var btn1EventObj = null;
document.getElementById('btn1').onclick = function () {
btn1EventObj = window.event;
alert(btn1EventObj.srcElement.id);
}
document.getElementById('btn2').onclick = function () {
alert(btn1EventObj === window.event);
alert(btn1EventObj.srcElement === window.event.srcElement);
alert(btn1EventObj.srcElement.id);
}
// ]]>
</script>

<button id=”btn”>Click!</button>
<script type=”text/javascript”>
// <![CDATA[
var eventObj = null;
document.getElementById('btn').onclick = function () {
eventObj = window.event;
setTimeout(function () {
alert(typeof eventObj.srcElement);
}, 1000);
}
// ]]>
</script>

<button id=”btn”>Click!</button>
<script type=”text/javascript”>
// <![CDATA[
var target = null;
document.getElementById('btn').onclick = function () {
target = window.event.srcElement;
setTimeout(function () {
alert(target.id);
}, 1000);
}
// ]]>
</script>

一个注释以<!开头，以>结尾。注释中可以包含零个或多个注释块，每个注释块以–开头，并以–结尾。并且，注释块之间可以包含空格。

因此，以下注释都是正确的：

<!--Hello--> <!--Hello-- --World--> <!----> <!>

用正则表达式来表示的话，/<!(–[^-]*–)?(\s*–[^-]*–)*>/能够匹配的注释都是正确的。因此，下边这种诡异的注释虽然是一个正确的SGML注释，但是按照W3C的定义来说就不正确了。

<!--Hello---->World-->

反过来，下边两种注释是正确的W3C注释，但是却不是正确的SGML注释，因为包裹注释块的–没有配对。

<!---- >--> <!------>

然后问题就来了。Firefox按照SGML的标准来解释注释的。而IE、Chrome、Opera按照W3C的标准来解释注释。所以<!–Hello—->World–>这种注释在Firefox下正常，但是在其它浏览器下会把World–>显示在页面里。反过来，<!——>在其它浏览器里正常，但是Firefox下会把<!——>显示在页面里，因为Firefox认为这不是一个注释。另外，对于<!—- >–>来说，Firefox会认为<!—- >才是注释，把后边的–>显示出来，IE和Chrome下这个是一个正确的注释，而Opera会“智能”地认为<!—- >–>中间的空格是不小心多出来的，所以“好心”地把空格去掉后，把不适注释部分的–>给显示出来。

由于注释中间的中划线在各种浏览器中的表现如此不一致，因此为了避免种种意想不到的惊喜，最直接的做法就是避免在注释中包含中划线。

有的同学或许要问，这个或许是一个不错的知识，可是和我们的日常开发有什么关系呢？那么请看下边这段html：
<!--<a href="http://www.alibaba.com/products/used_cars/--1217----------------6-5574,.html">Sedan <span>(79727)</span></a>-->
在我们的网站里这种链接很常见，而且href的value是模板变量生成的。因此，如果我们在模板里这么写：

<!--<a href="${Url}">${Name}<span>(${num})</span></a>-->

可能觉得不会有问题，但是最后生成的页面在Firefox下就会把注释部分显示成下边这样：

Sedan (79727)-->

这个例子作为理由来讲的确很不充分，毕竟没有谁会用HTML注释来删掉页面里不需要的内容，但是说不定以后的什么时候这些关于注释的知识会在各位的工作中派上用场，这就是豆知识。

PS：如果有同学对HTML注释特别感兴趣，可以继续阅读本文的参考文献：

http://www.howtocreate.co.uk/SGMLComments.html

http://htmlhelp.com/reference/wilbur/misc/comment.html

注：此文版权属于 邓楠乔

本地数据持久化（或者也叫做浏览器本地存储）是一种在浏览器中长久保存数据的方法，在刷新页面，同域名内页面跳转之后仍然可以将数据保留，例如用户的偏好设置、记录已填表单项等，可以减少服务器存储压力，节省网络传输带宽，加快响应速度。目前通用、可靠的跨平台和跨浏览器的数据持久化方案只有cookie，但不幸的是，使用cookie来存储持久化的数据会遇到下列这几个问题：

大小：cookie的大小被限制在大约4K左右，IE6下每个域名下cookie中名值对上限是20个，超出则随机丢弃；其他浏览器一般限制在50个。
占用带宽：cookie信息会被附加在每一个http请求上被来回传送
复杂度：对cookie的操作（解析或增删改）需要成本。
针对这些问题，现代浏览器已经实现了一种不需要依赖cookie的本地数据持久化的方法 ，这些方法相比起cookie都很简单易用，能过存储足够多的数据，并且可以不被附加在http请求上消耗网络带宽。但不幸的是，每一个浏览器的实现方案都不相同并且互不兼容，目前就有下面这四种迥异的本地数据数据持久化方案：

globalstorage：FireFox 2.0+, IE 8 + (https://developer.mozilla.org/en/Storage)
localstoarage: HTML5标准 (http://dev.w3.org/html5/webstorage/)
openDatabase: Safari 3.1+ (http://webkit.org/misc/DatabaseExample.html)
userdata behavior: IE 5.5+ (http://msdn.microsoft.com/en-us/library/ms531424(v=vs.85).aspx)
另外，使用下面这些浏览器插件同样可以实现本地数据持久化：

Adobe Flash
Google Gear
依赖插件实现本地数据持久化会带来一个很明显的问题，就是那些没有安装这些插件的用户将被抛弃，并且你的应用将会被捆绑在一个特定的软件提供商身上（例如Adobe）。Google Gear这个技术在还没有被广泛部署就被Google抛弃了。Flash的装机率虽高，但也有自己的问题，例如：

许多用户阻止了浏览器中的flash或者需要一个单击操作才能够激活flash，这就使得flash很不适合用来作为一个透明的本地数据持久化解决方案
Flash在较新的64位机器上是出了名的不稳定
一些公司处于安全原因阻止了一切flash内容
不管怎么说，如果我们再算上Flash和Gear，这就意味着已经有至少6种互不兼容的方案可以实现本地数据持久化。

不同的存储方法有各自不同的大小限制，你可以不必关心用户使用的是哪种存储方法，但你需要了解一下他们所支持的存储容量的最小值，然后根据你所需要存储的数据大小作出决策。除了cookie，其他几种类型都可以支持我们在本地存储足够多的数据。

Cookie：4k
gears：未知
flash：至少100k，超出一个阈值(?)时需要用户的“允许”。
globalstorage：5M
userdata(IE) ：64k
localstorage：理论上为5M（http://dev.w3.org/html5/webstorage/#disk-space）
openDatabase：默认200k[来源请求]
最后需要注意的是，本地数据持久化均有域的限制，也就是不能超出当前的域进行数据的读写操作。

TODO：

本地数据持久化是否可以控制过期时间(expired date)？
持久化到了本地的数据存在了硬盘的什么地方？
参考文献：

persist-js ReadMe (http://pablotron.org/software/persist-js/ )
Last Modified on Wednesday May 25th 2011 04:31:23 PM, Post Revisions:
This post has not been revised since publication.

注：此文版权属于 刘爽

Yahoo的: Best Practices for Speeding Up Your Web Site

Google的: Web Performance Best Practices

上面的最佳实践条例其实也就是我们常在YSlow和PageSpeed这两个Firefox的add-ons中看到的网站检测结果的参考标准.

而整个WPO其实是对浏览器(browser)的加载(load)和解析(parse)过程中的一些消耗行为进行优化, 而load和parse在整个浏览器工作过程中又互相纠结互相作用.

在这篇文字中讨论的更多是FE们能够伸手处理或者通过达成共识的方法来进行快速推动Tech们协助的一些事情.

OK, 我们慢慢把浏览器的工作过程掰细了看吧.

首先, 我们先整一个浏览器如何找到一个网站的简易工作原理 – DNS查询:

首先当用户在浏览器的地址栏中敲入了网站的网址 ( 比如: alibaba.com ) ,这时浏览器会首先通过访问的域名来定位到IP (DNS) 从而找到去哪里获取资源, 这时, 浏览器会依次进行如下查找:

1. 浏览器缓存 :

浏览器首先会在自己的缓存中查找有没有对应的域名 – IP匹配, 如果好运的话, 这里就可以直接尝试去访问资源了, 如果运气平平则往下走吧.

2. 系统缓存 :

浏览器缓存中没有命中, 浏览器会告诉操作系统:”嘿, 我在我自己口袋里没找到, 可能丢了, 我得去你那看看”, 然后, 一个系统进程(?)调取系统中的DNS缓存进行查询, 重复上一条的运气判断…

3. 路由器缓存 :

走到这, 运气还真不太好啊, 操作系统也没辙了, 那怎么办呢, 向路由去要要看吧… 重复运气判断…

4. ISP DNS缓存 :

好吧, 真不知道说运气好还是运气不好了, 不废话, 去ISP (网络提供商) 的DNS缓存服务器中寻找了, 一般情况下, 在ISP端的缓存中都能找到相应的缓存记录了, 不该这么背了, 或者… 您的ISP有够菜…

5. 递归搜索…

最无奈的情况发生了, 在前面都没有办法命中的DNS缓存的情况下, ISP的DNS服务器开始从root域名服务器开始进行递归, 顺序是从.com顶级域名服务器到alibaba的域名服务器, 再没找到…好吧, 您认为您要去的网站真的公开存在么…?

要强调的是, 不只是对网站第一次的域名访问需要做这样一次查询工作, 在对页面中的资源引用的域名解析时一样会有这样的一系列工作. 最明显的就是启用全新域名来做静态资源存储服务时, 基本上上述的1 – 5个步骤都得走上几遍. 才能让新域名在各DNS缓存服务器上留下记录.

在这个话题上, 关于DNS的类似系统级的解决方案不是FE能够控制得了的, 我们q可以在涉及到DNS时有些小Tips来从中做些事情.

好吧, 第一项.DNS相关的优化:

常规实践 : DNS解析的复杂性决定了不当的使用多域名获取资源会造成不必要的性能开销. 在WPO中, 很多优化工作是很艺术的, 在DNS和HTTP这两方面优化是就可以看到这个神奇的艺术性:

DNS的优化, 当然是尽可能少的造成DNS查询开销, 而在HTTP优化的策略中有一项优化措施是避免单域名下连接数的缺陷来进行资源多通道下载, 实施的细节会在 <HTTP优化的原理和方法> 中详细介绍, 在这里只是简单的提一下, 静态资源多域名服务可以绕过浏览器单域名载入资源时并行连接数的限制, DNS优化需要我们尽可能少的域名解析, HTTP优化时需要我们适当的使用多域名服务, 那怎么样让两个优化实践都能够比较好的实施呢? [todo]

优雅降级 : 在某些现代浏览器 ( Google Chrome, Firefox 3.5+ ) 中, 已经能够支持DNS的预取了, 怎么个预取呢? 就是在浏览器加载网页时, 对网页中的<link>或者<a>的href属性中的域名进行后台的预解析(上文中的 1- 5步), 并且将解析结果缓存在浏览器端, 当用户在真正点击链接时, 省去在当下的DNS解析消耗, 把这个消耗过程转嫁到用户无法感知的浏览过程中去.

第一, 现代浏览器已经支持且默认打开了DNS Prefetch的功能. 当然也可以通过浏览器的配置来管理该功能:

用Firefox3.5+可以这样: 浏览器默认就打开了HTTP协议下的DNS预取功能, 默认关闭HTTPS协议下的DNS预取功能, 可通过 about:config 的 network.dns.disablePrefetch 和 network.dns.disablePrefetchFromHTTPS 两个选项来控制两种协议下的预取功能.

Chrome管理DNS Prefetch方法暂时缺少.

第二, 可以通过用meta信息来告知浏览器, 我这页面要做DNS预取:

<meta http-equiv="x-dns-prefetch-control" content="on" />

第三,可以使用link标签来强制对DNS做预取:

<link rel="dns-prefetch" href="http://www.alibaba.com/" />

[todo DEMO]

扩展阅读:

Controlling DNS prefetching in Firefox

DNS Prefetching for Firefox (blog post)

DNS Prefetching in Chrome

link prefetching in HTML5

另, 小康(lazyKang)同学发现一个神奇的现象:

在一次无缓存访问中,  在一个并行下载通道内, 就算是同域名的情况, 也会造成DNS并行解析的消耗…

DNS预解析一次, 应该就能避免这样的问题, 空了做个DEMO试试看.

注：此文版权属于 赵振宇

“对于自己输出要严格; 对于他人的输入要灵活.  –鲁棒性原则”

一切从鲁棒性原则说起, 把鲁棒性原则放在第一位, 是为了:

1. 让大家带着鲁棒性原则的思考来听这次分享.

2. 鲁棒性原则是促成HTML5的设计原则主线.

3. 鲁棒性的引申义可以上升到为人处世中去.

一. XHTML2 & HTML5之间不得不说的故事

HTML Tag的文档作为HTML诞生的见证, 但是HTML Tag这份文档并不是官方的规范.

真正的官方HTML规范是从HTML2开始的, HTML2继承了HTML Tag的成果, 继往开来, 承前启后, 而非另立门户, 从头开始.

但是小悲剧的是, HTML2的标准出台的时候恰好是浏览器大战的年代,  浏览器厂商各行其道, 无视标准的存在, 而W3C也在这个时期也不停的将一些浏览器私有特性转换成标准的一部分. (Cowpaths)

97年 – 99年, 浏览器大战如火如荼, HTML标准也经历了从3.2 – 4.0 – 4.01的版本变迁, 非常的迅猛, 但是到了HTML4.01是, W3C的头也许是被敲坏了, 认为:”好了, HTML就这样了, HTML4.01是HTML的最后一个版本了, 我们也用不着HTML工作组了.”

而事实上W3C并没有停止开发这门语言, 只不过他们对HTML失去了兴趣, 在HTML4.01后, 他们提出了xHTML1.0,虽然听起来完全不同，但是xHTML1.0与HTML4.01其实都是一样的，唯一不同的，就是xHTML1.0要求使用XML语法。也就是说我们现在习以为常的：所有标签必须小写，所有属性必须小写，所有属性值都必须加引号，所有标签必须闭合…

从规范本身的内容看,实际是相同的, 不同之处就是编码风格, 因为对浏览器来说, 读取符合HTML4.01,HTML3.2或者xHTML1.0规范的网页都没有问题, 对于浏览器来说,都会生成相同的DOM树,只不过xHTML1.0严格的编码风格让人们比较偏好.

到了2000年,Web标准项目的活动如火如荼, 开发人员对那些个私有特性都忍无可忍, 大家都在骂浏览器厂商:”他妈的支持个标准真有这么难吗?!”. 正巧那个时候CSS有了长足的发展,而且与xHTML1.0的结合也很紧密, CSS + xHTML1.0基本上就成了”最佳实践”.而xHTML的那种优雅的书写风格在专业人士的带领下, 成为了业界最被认可接受的风格了.

在xHTML1.0之后紧跟着出来的是xHTML1.1,我印象很深刻的是:当时还在用Editplus, 去官网找了个xHTML1.1的template, 结果…

xHTML1.1和xHTML1.0不仅仅是版本号加了0.1这样的差异, 1.1居然是要求必须把文档标记成XML? 而当时最先进的IE无法处理接收到XML文档类型的文档, 这这太崩溃了.而真正使人不想把文档标注成XML的原因是, 如果你在文档中哪怕是只写错了一点点, 比如&没有编码成&amp;那整个页面的渲染结果就是黄屏了,没戏了,这个页面中有一个错误,你丫别想看这个网页了. “如果解析器渠道错误,那就停止解析”是的.这就是XML文档的错误处理机制.

依稀记得xHTML2的坟还没长草, 而促使他死亡的原因就是鲁棒性原则.
1.程序员们不会去支持他,因为XML的错误处理机制和xHTML2故意而为的不向后兼容.
2.浏览器厂商不回去支持他,因为浏览器必须要保证向后兼容.

当然并不是说这样的规范不好, 恰恰相反, 从理论角度他是个非常好的规范, 是个非常好的格式, 但仅限于理论角度, 问题就是他并不实际.

可以说鲁棒性原则是杀死xHTML2.0的战略性理论武器. 而且让他死的非常瞑目.

好吧, 回到当初和xHTML2.0并驾齐驱的HTML5.

HTML5并不是直接由W3C制定的,就在大伙认为HTML应该在HTML4.01时结束生命时, 有那么一伙人认为”也许HTML应该更加长寿一些,只要我们对他稍加扩展,只要我们把放在xHTML的时间和精力拿出一部分，就可以提升下HTML中的表单，让HTML更加接近编程语言，就可以让他更上一层楼”

于是，在2004年Opera的伊恩.希克森提出了一个扩展和改进HTML的建议,他建议新任务和xHTML2并行,但在已有的HTML基础上开展工作,目标是对HTML进行扩展.W3C的投票结果是NO,因为HTML已死,xHTML2才是未来.

于是,Opera,Apple等浏览器厂商以及一些成员说, 那好吧不指望他们了,我们自己也能做好这件事,我们脱离W3C.他们成立了WHATWG.而在接下去的一段时间内,WHATWG的工作效率非常高， 并且在短时间得出了一些成果， 因为他们的工作组成员理由浏览器厂商，因为他们不仅可以说加就加，而可以实现，大家不断地提出一些好点子并且逐一做到了浏览器中。 反观W3C的xHTML2没有什么实质性的进展，特别是从实现的角度来看，用原地踏步形容都不足为过。

戏剧性的事情又发生了， 2006年蒂姆.伯纳斯-李写了一篇博客,说:你们知道吗?我们错了,我们错在企图一夜之间就让web跨入XML时代,我们的想法太不切实际了,是的,也许我们应该重建HTML工作组了.

So,2007年故事就真的这样发展了,W3C组建了HTML5工作组, 这个工作组面临的第一个问题是:我们重头开始做呢,还是在04年成立的那个啥WHATWG工作组的既有成果上开始工作? 答案显而易见,他们又一次投票同意了在WHATWG基础上继续工作.ok, W3C和WHATWG有并肩作战了.

那第二个问题就成了这两个工作组之间的关系,W3C这个工作组的主编是由谁来干呢?是不是让WHATWG的伊恩希克森(google)来?又一次投票,同意了这个提案.

这就变成了2个工作组都有一份自己的规范,而且看起来基本上一样,那到底那份是真正的规范呢?实际上这两个标准还是会分道扬镳,W3C最重要制定一个具体的规范,这个规范最终会成为一个working draft,然后就定格了,而WHATWG呢?他们在不断的迭代,即便是现在HTMl5都不能涵盖他们的目标,他们是正在开发一项简单的HTML或者web技术.

这两个工作组的流程截然相反,因为他们的理念完全不同.

WHATWG可以说是一种独裁的工作机制。我刚才说了，伊恩·希克森是编辑。他会听取各方意见，在所有成员各抒己见，充分陈述自己的观点之后，他批准自己认为正确的意见。

W3C是一种民主的工作机制。所有成员都可以发表意见，而且每个人都有投票表决的权利。这个流程的关键在于投票表决

WHATWG的工作机制让人很不舒服,而W3C的工作机制让人听起来很舒服,但实际情况是WHATWG工作的非常顺畅,主要归功于伊恩·希克森。他的的确确是一个非常称职的编辑。他在听取各方意见时，始终可以做到丝毫不带个人感情色彩。W3C的工作机制很公平，而实际上却非常容易在某些流程或环节上卡壳，造成工作停滞不前，一件事情要达成决议往往需要花费很长时间。

两个截然不同的工作组之所以能够同心同德，主要原因是HTML5的设计思想。因为他们从一开始就确定了设计HTML5所要坚持的原则。结果，我们不仅看到了一份规范，也就是W3C站点上公布的那份文档，即HTML5语言规范，还在W3C站点上看到了另一份文档，也就是HTML设计原理。

二.HTML5设计原则

设计原则, 是一种信念, 一种原则, 一种概念, 是设计原则涉及的人群行动的动力.

不管是W3C在制定规范, 还是通用在制造汽车, 还是我们在编写软件, 甚至是大牛们在创造编程语言, 设计原则也许就是贯穿整件事情的一条主脉, 任何矛盾与挫折都可以用他去衡量.

例如离我们最近的Alibaba公司的设计原则就可以认为是: 让天下没有难做的生意.

再例如Jquery的设计原则是: write less, do more.

说到这里, 我就想起来我们应该问问自己:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
<link rel="stylesheet" type="text/css" href=""/>
<script type="text/javascript"></script>

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
<link rel="stylesheet" type="text/css" href=""/>
<script type="text/javascript"></script>

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" dir="ltr">
<meta http-equiv="content-type" content="text/html; charset=utf-8" />
<link rel="stylesheet" type="text/css" href=""/>
<script type="text/javascript"></script>

<!DOCTYPE html>
<html>
<meta charset="utf-8" />
<link rel="stylesheet" href="" />
<script src=""></script>

<img src="foo" alt="bar" /><p class="foo">Hello World</p>

<img src="foo" alt="bar"><p class="foo">Hello World

<IMG SRC="foo" ALT="bar"><P CLASS="foo">Hello World</P>

<img src=foo alt=bar><p class=foo>Hello World</p>

<h2>Heading text</h2>
<p>Paragraph text.</p>

<a href="somewhere">
	<h2>Heading text</h2>
	<p>Paragraph text.</p>
</a>

<body>
	<div id="header"></div>
	<div id="navigation"></div>
	<div id="main"></div>
	<div id="sidebar"></div>
	<div id="footer"></div>
</body>

变!

<body>
	<header></header>
	<nav></nav>
	<div id="main"></div>
	<aside></aside>
	<footer></footer>
</body>

怎么样? 像模像样了吧?

再看:

<div class="item">
	<h2></h2>
	<div  class="meta"></div>
	<div  class="content"></div>
	<div  class="link"></div>
</div>

再变!

<section class="item">
	<header><h2></h2></header>
	<footer class="meta"></ footer >
	<div class="content"></div>
	<nav class="link"></nav>
</section>

虽然在这个文档中，我们用这些新元素来替换的是id，但在我个人看来，将它们作为类的替代品更有价值。为什么这么说呢？因为这些元素在一个页面中不止可以使用一次，而是可以使用多次。没错，你可以为文档添加一个头部（header），再添加一个脚部（footer）；但文档中的每个分区（section）照样也都可以有一个头部和一个脚部。而每个分区里还可以嵌套另一个分区，被嵌套的分区仍然可以有自己的头部和脚部，是这样吧？

这四个新元素：section、article、aside和nav，之所以说它们强大，原因在于它们代表了一种新的内容模型，一种HTML中前所未有的内容模型——给内容分区。迄今为止，我们一直都在用div来组织页面中的内容，但与其他类似的元素一样，div本身并没有语义。但section、article、aside和nav实际上是在明确地告诉你——这一块就像文档中的另一个文档一样。位于这些元素中的任何内容，都可以拥有自己的概要、标题，自己的脚部。

其中最为通用的section，可以说是与内容最相关的一个。而article则是一种特殊的section。aside呢，是一种特殊的section。最后，nav也是一种特殊的section。

最重要的是它们的语义；跟位置没有关系。

这里，请注意，最重要的还不是我用几个新元素替换了原来的div加类，而是我把原来的H2换成了H1——震撼吧，我看到有人发抖了。我碰到过不少职业的Web开发人员，多年来他们一直认为规范里说一个文档中只能有一个H1。还有一些自诩为万能的SEO秘诀同样说要这样。很多SEO的技巧其实是很教条的。所谓教条，意思就是不相信数据。过去，这种教条表现为“不行，页面中包含两个以上的H1，你就会死掉的。”在HTML5中，只要你建立一个新的内容块，不管用section、article、aside、nav，还是别的元素，都可以在其中使用H1，而不必担心这个块里的标题在整个页面中应该排在什么级别；H2、H3，都没有问题。

这个变化太厉害了。想一想吧，这个变化对内容管理是革命性的。因为现在，你可以把每个内容分区想象一个独立的、能够从页面中拿出来的部分。此时，根据上下文不同，这个独立部分中的H1，在整个页面中没准会扮演H2或H3的角色——取决于它在文档中出现的位置。面对这个突如其来的变化，也许有人的脑子会暂时转不过弯来。不要紧，但我可以告诉你，我认为这才是HTML5中这些新语义标记的真正价值所在。换句话说，我们现在有了独立的元素了，这些元素中的标题级别可以重新定义。

e. degrade gracefully

优雅降级

HTML5中设计了这么些新玩意：

input type="number"
input type="search“
input type="range"
input type="email"
input type="date"
input type="url"

很有趣, 但是浏览器不认识, 怎么办呢?

最关键的问题在于浏览器在看到这些新type值时会如何处理。现有的浏览器，不是将来的浏览器，现有的浏览器是无法理解这些新type值的。但在它们看到自己不理解的type值时，会将type的值解释为text。

无论你写的是input type=”foo”还是input type=”bar”，现有的任何浏览器都会说：“嗯，也许作者的意思是text。”因而，你从现在开始就可以使用这些新值，而且你也可以放心，那些不理解它们的浏览器会把新值看成type=”text”，而这真是一个浏览器实践平稳退化原理的好例子。

比如说，你现在输入了type=”number”。假设你需要一个输入数值的文本框。那么你可以把这个input的type属性设置为number，然后理解它的浏览器就会呈现一个可爱的小控件，像带小箭头图标的微调控件之类的。对吧？而在不理解它的浏览器中，你会看到一个文本框，一个你再熟悉不过的文本框。既然如此，为什么不能说输入type=”number”就会得到一个带小箭头图标的微调控件呢？

当然，你还可以设置最小和最大值属性，它们同样可以平稳退化。这是问题的关键。

HTML5还为输入元素增加了新的属性，比如placeholder（占位符）。有人不知道这个属性的用处吗，没有吧？没错，就是用于在文本框中预先放一些文本。不对，不是标签（label）——占位符和标签完全不是一回事。占位符就是文本框可以接受的示例内容，一般颜色是灰色的。只要你一点击文本框，它就消失了。如果你把已经输入的内容全部删除，然后单击了文本框外部，它又会出现。

使用JavaScript编写一些代码当然也可以实现这个功能，但HTML5只用一个placeholder属性就帮我们解决了问题。

当然，对于不支持这个属性的浏览器，你还是可以使用JavaScript来实现占位符功能。通过JavaScript来测试浏览器支不支持该属性也非常简单。如果支持，后退一步，把路让开，乐享其成即可。如果不支持，可以再让你的JavaScript来模拟这个功能。

再来看一个比较极端的优雅降级方案:

<video>
 	<source src="movie.mp4">
 	 <source src="movie.ogv">
 	 <source src="movie.webm">
 	 <object data="movie.swf">
 	 	 <a href="movie.mp4">download</a>
 	 </object>
</video>

很NB吧…

f. Priority of  constituencies

最终用户优先

事先声明, 这是条很哲学的设计原则, 没有代码可以看.

它的意义就是: 一旦遇到冲突，最终用户优先，其次是作者，其次是实现者，其次标准制定者，最后才是理论上的完满。

在有人建议了某个特性，而HTML5工作组为此争论不下时，如果有浏览器厂商说“我们不会支持这个特性，不会在我们的浏览器中实现这个特性”，那么这个特性就不会写进规范。因为即使是把特性写进规范，如果没有厂商实现，规范不过是一纸空文，对不对？实现者可以拒绝实现规范。

嗯, 要学会辩证的去看这些问题, 别钻牛角尖就好.

最后附上PPT, 花了老子半天时间整的20页啊!!!

HTML5 设计原则

还有这次分享的出处, Jeremy老板在W3C Tech上的分享的PPT(PDF)

Jeremy-DesignOfHTML5

还有感谢新总分享的翻译版Design of HTML5, 这篇文章在我编PPT时很给力:
JEREMY KEITH在 FRONTEERS 2010 上的主题演讲

以及他的原文出处,感谢为之漫笔(李松峰):
JEREMY KEITH在 FRONTEERS 2010 上的主题演讲

注：此文版权属于 赵振宇

——————————————低调的分割线————————————————————

Tom：请问你是什么部门的？

Heidi：我是国际站用户体验设计部的，就是UED，听说过吗？

Tom：哦，了解，是不是我们网站布局都是你们来改的？

Heidi：应该是的。

Tom：我是负责客户培训的，我想问一个问题，你们为什么要经常改我们的网站啊？我给客户培训，经常打开网站，就发现布局换了，我的讲义也需要经常更新。

Heidi：这……改动总是有改动的理由的嘛（笑）。也许是要提高转化率，也许是为了新的产品上线做拓展，也许是用户的需求更明确了……其实首页来讲的话，平均2年也需要大翻新一下的，老是同一张面孔，多枯燥啊。不过我们每次大的改动，都会通知到可能会受影响到部门的，比如销售、客服等，都有相关的邮件抄送给接口人。我回去确认一下你们部门是不是也在抄送名单里。

Tom：恩，谢谢了。对了，做你们的工作的，专业背景都是什么啊？都是学计算机的吗？

Heidi：不是。其实我们部门分四种角色，每种角色的专业背景是不一样的。

Tom：都是什么？

Heidi：比如，用户研究员，专业背景可能是心理学，人类学，社科等学科——但是也有其他专业背景。交互设计师专业背景可能是工业设计，也可能是其他设计专业，比如平面设计——但是也有完全和设计不沾边的专业，比如心理学也有。前端工程师的专业背景可能是计算机，也可能是其他专业，比如我们团队曾经有从演艺圈出来的杰出前端。还有一个角色是视觉设计师，专业背景有可能是平面设计，也有可能是动画设计。啥专业都有可能，不能笼统去讲……

Tom：你刚才说，有可能是学工业设计的，我觉得很奇怪啊，工业设计我想的不是都一些现实的产品吗，比如汽车，洗衣机等……

Heidi：毕竟国内专门的交互设计专业很少，专业的也不多，还是会借鉴很多来自成熟的工业设计领域的一些理论。工业设计可能本身发展比较成熟，而且研究的方向也是人机交互类的，也需要研究用户的特点，行为和习惯，进而设计或者改进产品设计，让它简单易用。所以，和交互设计是有很多相同的部分。我个人感觉交互设计是从工业设计领域衍生出来的，而且并不局限于网站和软件界面……可能在不同的领域有不同的叫法吧。

Tom：那其实，网站、软件和洗衣机设计是同一个道理，只不过是虚拟的和实体的……

Heidi：也许可以这么理解。

Tom：做一个网站很难吗？你们为何需要这么多人？不是就给程序员一个图，写些代码就可以了？

Heidi：……恩，单纯做网站是挺简单的。做好，不容易。做个房地产宣传的网站，挺容易的，做个小企业的形象网站，也挺容易的。做好支付宝网站，不容易，做好阿里巴巴网站和淘宝网站，不容易。网站这个概念也不能笼统去讲。越是要用户去使用的网站，设计难度就越高。而且，也并非一个ued的团队在“做”网站，我们几百个人的工作都聚焦在这个网站上。有做产品规划的，有做运营的，有做客户支持的，也有做海外推广的，有做数据分析的——只是大部分的人的工作，需要最终流转到我们手里得以分析、实施。（Heidi注：做网站看起来简单是因为对于其他人来讲，只能看到20％的工作，但是这个20％是靠那些看不到80％决定的，参见图1。）

图1.网站用户体验层次：用户看到的是简单的20％

关于此图的更多说明：此图参考的原图，请点击查看。我原本是想把这张图做得更加形象一些，想到了冰山模型。后来发现用植物更加能够说明问题，战略即是那棵种子，如果种子不好，再多的肥料都无济于事。而土壤和水代表了做出成功的产品必需的资源（团队、时间、资金），植物的根部是一套协作系统，代表了不同的部门做的不同的事情，比如产品团队、用户体验设计团队、开发和测试团队等。而土壤里也会有害虫来危害产品，这正意味着产品开发中也会遇到种种的风险。于是……就产生了上面的图。

Tom：那你们UED平时都是怎么工作的？

Heidi：做新的产品和优化老的产品的流程不太一样。如果是新的产品规划，很早之前就开展了工作了，交互设计师，用户研究员配合产品经理(此阶段，大部分是以产品经理为主导)做一些目标人群的调研，分析，看我们的产品针对的目标人群都是谁，他们都有什么需求，都有什么特点。这样才能够帮我们找到产品的真正定位，确定核心的功能以及功能的优先级等。

Tom：有点像目标市场划分？

Heidi：确实是有营销的分支在其中。其实卖产品要想事半功倍，一定要先有需求才有产品。而不是先生产出产品，再去市场上找能够卖给谁。

Tom：那你们什么时候开始设计呢？

Heidi：刚才说我们前期要投入一些人力去做分析和调研，接下来，在产品经理去细化需要什么功能时，我们就可以开始设计工作了。（交互设计师有可能和产品经理同步开展工作，共同得到产品功能需求文档，也有可能由产品经理先进行需求文档工作后再开始交互设计）但是不像你刚才说的，直接去出一张图。而是先由我们这个角色，也就是交互设计师去做一些线框图。

Tom：线框图，就是草图对吗？

Heidi: 你可以理解成草图。就好像大楼要施工之前，也需要有一个蓝图一样。先得把蓝图确认了才能开工。

Tom: 这个我理解。做草图是和别人去讨论是吧？视觉设计师设计不也是要出很多稿草图吗？

Heidi：我们设计的草图和视觉设计师做的不一样。我们是在他开工之前更早的一环。但是你说得没错，我们确实可以不出这个草图，而直接让视觉设计师去做。但是这个视觉设计师会非常非常痛苦。因为他需要花很多精力在草图上，然后他接受很多意见和建议，而且他去优化的方向无从把握，很多，结果导致迟迟确认不了。

Tom：为什么会这样？

Heidi：视觉嘛，每个人都有自己的感受，视觉的评价标准是大部分建立在主观评价上的。你觉得紫色好看，老板觉得红色大方，视觉设计师需要找到一个契合点去让所有决策方达成共识。

Tom：这本来就应该这样，即使有你们，他们的痛苦也不会减少多少吧？

Heidi：的确。但是我们的存在会帮助视觉设计师减少大部分痛苦（当然我们存在的价值不限于此）。因为我们会缩小他们确认的内容范围。如果没有交互设计的存在，就会把所有的可能性都抛给视觉设计师。在视觉确认时，会发现布局a和布局b，布局c存在各种偏好，而颜色a，颜色b, 颜色c 也存在不同的偏好，版块a的位置，存在不同的偏好……结果布局、颜色、结构的排列组合会非常非常多……（ Heidi注：如图2所示，视觉设计师的大部分痛苦来源于对各种意见无法控制，从而有效达成决策）

Tom：恩，我理解了，会不会有人说：我觉得这个版本的结构很清晰，但是颜色很不好看，你看看能不能把另一个版本的颜色换过来看看？

Heidi：经常！但是这样来回排列组合，会诞生出更多的排列组合……

Tom：恩，想法有时在设计的时候也会收不住，也会诞生出一些自己的新的想法。

Heidi：是的。所以我们通常会在交互设计阶段先从理性上确认一些问题，比如布局，信息结构，内容的逻辑性等。这些内容可以不那么感性去评价，更多是靠一些说服性的东西去说服大家接受。

Tom：那你们怎么说服别人接受？

Heidi：如果有数据，就用数据；如果有用户的生意就用用户的声音。如果有已经了解到用户的特点、行为，都可以拿来应用到设计方案的说服框架里。另外，大家都会尊重专业的观点。另外，知识就是力量，专业让人信任，把自己武装得更加专业一些，会有比较大的帮助。

Tom：就是一样要说服别人？

Heidi：其实有时也不能叫说服，我们最起码自己得相信那就是最好的解决方案，如果自己不确信，就让更多的人去帮你看看是不是有更好的解决方案，如果时间和资源允许，就引入真正的用户去帮我们看看。之后别人都会相信这是目前阶段最好的解决方案。但是，即使交互不像视觉那么感性主观，但是依然每个人都有自己的想法，我们就需要说服他们相信这是最好的解决方案。

Tom：所以还是要找一些支持。

Heidi：数据，用户声音，都很有帮助。实在没有资源，就需要我们去描述使用场景，让其他人觉得自己就是现实的用户，进入到我们描述的使用场景里去，我们把这个说服的方式叫做讲故事（ Heidi注：图3，讲故事已经成为一种业界的术语，storytelling）。

图3：讲故事是将用户使用场景具体化形象化的方式，成为交互设计师说服框架里重要的一种技能。

Tom：”讲故事”很有意思！那是不是你们就提供一张页面的草图给视觉设计师就可以了？

Heidi：不但是单个页面的草图结构和布局。我们最主要的是设计任务流。

Tom：任务流？

Heidi：比如用户的目标是上传产品，为了达到这个目标，他需要经过几个步骤，完成哪些任务等。我们要做到尽可能让用户在最短的时间内通过最少的步骤达到目标。哦，其实，我们的目标不只是这个，更高级的是，用户在这个过程中感觉到简单，容易，放松。最有效率有时需要和“用户的感受”平衡，也需要和我们投入的成本和用户投入的成本相平衡。

Tom：看起来又比较复杂。

Heidi：其实很简单，打个比方，你在一栋停了电的大楼里，有15层楼高，你需要下楼。最快的方式就是吊个绳滑下来，最舒适的方式是叫个直升机来接你。但是前者虽然效率高但是不安全，你会担心不敢尝试。后者虽然舒适但是成本太高……

Tom: 所以，从楼梯上慢慢走下来，也许才是最好的。

Heidi: 恩，从楼梯上慢慢走下来，对比其他两者，才是最合适的解决方案。我们平时选取设计方案也会有多个维度的（图4）。

图4：好的设计方案应该能够满足多个维度的评审标准

Tom：我了解了。但是你刚才说收集用户需求，你们都是通过什么渠道？其实我们是负责客户培训的，才是每天面对客户的人。

Heidi：客户和用户还不是一个概念。你们培训接触的客户是其中一类用户，也就是国内的供应商，对于他们的需求收集，我们有时也会“上山下乡”，直接派一些设计师去他们的工作地点去观察他们如何用我们网站。当然，我们也通过内部渠道，比如来自销售、客服部门反馈过来。另外，我们也可以很方便邀请他们过来我们公司，中国站有专门的实验室，可以让他们在实验室里做一些可用性测试。但是另外一部分用户是海外的买家和供应商。他们离我们很远，他们不容易过来，我们也不能过去。这些用户是我们网站的买家，服务好买家，才能够让卖家受益，所以他们的需求非常重要。

Tom：那你们怎么办呢？

Heidi：只能尽可能挖掘渠道。每年的广交会，国外的买家会来不少，我们也会去广交会参加用户调研。平时有专门的团队，BI部门（网站参谋部）会定期做一些海外买家的问卷调研，并逐渐沉淀出一些买家分层研究，我们可以通过他们知道很多买家的需求和问题。另外，我们自己也会偶尔做一些远程的在线的用户调研和测试。

Tom：但是我们网站不会经常推出新的产品，你们平时闲着吗？

Heidi：(汗)………我们也想啊……但是事实上是我们每天都很忙，而且还在不断招新的人。大的战略级的产品非常不会经常推出，但是小的产品会经常出现。但是一些老产品的优化是不断在进行的——打个比方，刚发布时，注册表单的转化率是50％，之后的优化目标就是将这个转化率提升到70％，目标在不断提高，就需要有后续的行动。

Tom：不能一开始就做的很好，以后就不会经常需要优化了吗？

Heidi：也许快速迭代就是互联网产品的明显特征吧。刚开始大家就是想把产品做到线上去，这时也许本来就解决最核心的功能，和主要的流程没有问题。我们也无法一开始就做到尽善尽美，一个原因就是资源不允许。另外有可能是，我们确实不清楚到底完美的方案是什么，那些耗费大量资源的功能到底有多少用户需要，所以我们有时就会先发布一个简单版本，之后随着用户使用的数据和访谈的声音，去迭代优化。另外，我们对于在线的页面、功能都有数据监测，会分析流程中的流失率，我们去判断可以优化的点是什么，然后去改，再监测。

Tom：但是依然没有百分之百满意的时候。

Heidi：每次优化要保证数据是正向的。不是正向的就返回老的版本，继续思考。但是确实不可能说什么是永远不用再优化的。网站的体验就是一点点被优化升级的啊。

Tom：我明白了，谢谢。我之前理解做网站太简单了，想不到这么复杂。

Heidi: 哈哈，我们也常说，我们不纠结，用户就纠结。简单是复杂的结果，复杂是简单的必备过程。

［总结］：在用户的视角来看，我们也希望他看到的都是最简单最愉悦的一面。作为客户培训师，你不需要知道产品数据在我们后台是存储在什么服务器的。用户搜索产品时，也更加不需要了解一个检索词是经过了多少词解析判断计算，跑了几台服务器，最终把结果呈现给他的。但是作为工作人员，我们得了解需要怎么做，才能够把最简单最愉悦的结果呈现出来。（Heidi注：如图5所示）

图5：简明网站产品建设流程图

这个图呈现的流程，依赖于多个部门的通力合作。从战略层高瞻远瞩的判断、从产品经理对于市场的分析以及功能、内容的规划、描述，到用户体验团队，开发和测试团队的全力配合，而网站产生后，还要依赖于SEO、市场营销、销售和客服的工作。

成功的网站，一定是多个部门一起围绕相同目标运作的结果，但是其中一个环节失败，则可能会造成全盘皆输。

本文虽然篇幅已经很长，但是涉及到具体的流程、方法，都只能简单带过，希望大家要记住这是对话的场景，不要以偏概全哦。
你对他提出的问题，想如何回答呢？如果你有问题，质疑，鼓励……欢迎交流。

有没有在网上开店的经历？

有人赞美过你是个有品位的人么？

有没有深度怀疑过苹果系的产品？

有没有环游世界的冲动？

只要以上有任何一条你的回答是yes,可能就意味着我们是同一类人了.

点击进入招聘网站