其实原故事是说，发现很多男人周五买尿布，所以超市就把啤酒也摆在尿布旁边。所以刚刚我故意混淆了两个细节：尿布和啤酒的相关性是“单向”的；推荐方式是“隐式”的（摆在一起）而不是“显式”的（口头推荐）。更重要的是，它是针对一个特定目标用户群（已婚有小孩的妻管严男人）的行为。

令人吃惊的是，我看到大多在讲“啤酒和尿布的故事”的地方，都故意忽视了这些细节，转而大谈诸如协同过滤或数据挖掘什么的。恐怕这就是为什么现在很多网站的推荐系统都做得相当糟糕的缘故吧。推荐系统，本质上一种产品，而不是什么技术架构，回归到产品设计的根本原则，才有可能把它做得“有用”，进而“好用”。

我其实也对推荐系统的技术一知半解，不妨抛开那些技术算法，谈几点我认为很重要的设计原则：

一，着眼于“后续期望”。举个例子，假设我在浏览ipad的产品介绍，旁边的相关推荐应该是什么？设想几种答案：A：iphone,ipod；B：ipad皮套等配件；C：不同渠道商的ipad报价；D：仿ipad的其他山寨产品。如果甲同学想买一个时尚电子产品送给女友，乙同学是ipad的狂热粉丝，丙同学还在为ipad的价格犹豫，丁同学只是想要一个电子阅读器，那上面这四个答案都恰好能让他们可以继续多看一些产品。所以，推荐系统是否成功的最关键因素，并非算法实现等技术问题，而是如何洞悉用户的当前行为以及后续期望。

值得一提的是，除了揣测用户本身已有的期望外，为用户创造出一个新的期望也是推荐系统常常做的。比如卖书的网站就经常告诉我，这两本书可以配套买。但这种为用户推荐他原本并不期待的东西，成功率就会低很多，相反可能会打乱用户原本的行为路径。所以要慎重，不能自作聪明弄巧成拙。

二，牢记80-20法则。想用一套算法解决千万用户不同的需求是不可能的，这就要求我们作一些取舍。我有一个绕口的原则是：用最简单的办法顾好大多数人在大多数情况下的最常见需求。我的这个原则的灵感来自于一个叫everything的桌面搜索软件。不管是微软还是google的桌面搜索软件，一开始总是要花很长时间（几个小时）来建索引。但这个everything只用1分钟就能建好整个硬盘的文件索引，很神奇！后来才发现，它只能搜文件名，而不能搜文件内容，而后者正是其他桌面搜索长时间建索引的原因。问题就在于，其实我们绝大多数时候找文件都是在找文件名而非内容，everything正是抓住了这个问题的核心，用20%的精力解决了80%的问题，然后，将剩下20%的问题直接抛弃！

将这个80-20法则用到推荐系统里，是再合适不过的了。你只需要集中精力在最常发生的情况下，用合适的算法找出合适的推荐结果，剩下的结果只要保证“相对过得去”就好。当然，这样做的前提是，你对用户的后续期望很有把握。

三，解决信息焦虑。假设“釜山料理”餐厅介绍页上，相关餐厅列出“港丽茶餐厅”，你会觉得他们相关么？那，“韩膳宫烧烤”呢？会不会觉得后一个明显靠谱很多？其原因是后一个你可以看得出它与“釜山料理”都是韩式烧烤店。但如果你是一个要在人民广场约朋友吃饭的人，“釜山”和“港丽”都恰好在人民广场，而“韩膳宫”其实是在离人民广场很远的徐家汇，那不用说自然“港丽”应该作为你下一个要浏览的餐厅。

这里很重要的，其实是要告诉用户“为什么相关”。否则用户就会困惑，从而忽略掉你精心为他推荐的内容。一个很好的例子是网易新闻，在它的相关新闻列表上，都会将它匹配的标签显示出来。比如“与 富士康 相关的新闻”。

四，始终记得商业目标。做推荐系统的最终目的，是为了商业目标：增加后续转化率？增加总用户数？还是增加成交量？其他产品设计，或许有时候需要牺牲一下眼前的商业利益，来满足用户目标。但推荐系统的商业目标与用户目标的分歧并不大，相反往往更加统一，所以这时候就要特别提醒自己注意商业目标，所有的功夫都要朝那个方向努力。当然一些很基本的用户体验还是要保证的，像在推荐系统里塞广告这种杀鸡取卵的事情还是做不得，呵呵。

之前挺累，就懒得写。不过关键的原因是我一直在思考一个问题：互联网好玩在哪里？由来是我开始觉得这东西越来越无聊了。最近又恰好看到两篇文：《警惕信息窄化》，及《我们正进入另一个黑暗和无知的时代》。我的老天，他们的观点正好将我沉闷心底的想法打着旋的给搅出水面。

不过，得到共鸣并不意味着我就赞同他们的观点。他们讲来讲去，无非就是在说“孩儿们，你们太堕落了，要警惕啊”。首先“警惕”两个字就很好笑，下一代若真是要垮掉，警惕也没用。再说了，除非你老人家愿意对着摄像头用裸体说唱的方式把文章念一遍传到土豆再转到人人，那垮掉的一代压根就不知道你的逆耳忠言，你是要谁警惕？

第二，诚然，老先生们讲的都有道理。我也觉得在咱眼里，90后是挺无聊堕落的（数据说话-> 点这里）。但80后在70后眼里，不一样的无聊堕落嘛？这里有一个逻辑是：1. 你玩的东西我都不感兴趣，2. 我也看不出对我有什么价值，3.我自己玩的东西我能证明（对我）是有价值的，结论：你挺无聊堕落的。这样推断出的观点和结论，尤其那些再戴上“世代”帽子的，是很不靠谱的。你觉得魔兽装备很没价值，哈？人家可用这个来赚钱呢~

话说几年前，我跟一70后的姐姐说到最近一个新兴的网站叫twitter。我兴高采烈的跟她描述这个网站的特点，就是可以随时随地的发一条自己想说的话，她就一脸疑惑的说这听起来挺无聊的啊，我说那只能说明你老了跟不上时代了。好啦，现在该我得到报应了：我已经感觉不到foursquare有什么好玩的了，虽然我能理解那种升级和收集的动机（跟我在植物大战僵尸里攒花一个道理），但我打心底里说：这TMD的也太无聊了吧！anyway，喊归喊，我还是听说mayor头衔是可以换酒喝的，哎。

所以呢，胡诌一通，我想说的是：老先生你们讲的现象都是对的，但这没什么好紧张的：世界变得和你当初以为的不一样了而已。不用高呼“警惕”，放松点，管他们去死呢。

不过，规划好选择符的命名，还是有几点好处的：
1. 节约时间。不得不承认，我本人经常把10%-20%左右的时间花在斟酌选择符命名上。当然，或许这只是我个人的强迫症问题。

2. 防止冲突。虽然概率很小，但还是会遇得到这种情况：某个选择符的名字，已然被用过了，导致样式冲突。这种情况通常发生在不同尺度的样式：比如登录框和登录页，某个模块里的下拉菜单和导航栏，等等。

3. 防止冗余。其实这点就比较关键啦。如果命名冲突，换个名字就是了。但如果是前后由不同的人来写样式，很可能为了避免冲突而另起炉灶。一方面浪费人力，另一方面久而久之会产生大量被废弃或覆盖的样式：打开firebug，某个样式被不同的人在不同的样式表里覆盖了N次。这就比较糟糕了。

所以，好的命名规划，一定程度上还是比较的。一些关键的命名原则有：

1. 通用的样式，一定要规范好命名。所谓通用的样式，主要有：

    a) 页面布局：比如头部顶部啦，左侧栏右侧栏啦，负责整个页面“骨架”的一些样式。

    b) 常用布局：比如列表，田字格布局（1排5个，一共5排），标签切换（tab），翻页这种经常被网页设计所用的模块布局样式。

  上面两种，在各处的样式定义可能完全不同，但由于经常用到这些布局结构，所以可以统一命名。

    c) 通用模块：这里指的是一些“固定样式”的模块，会在全站各处出现。比如登录框、搜索框、浮动工具箱等等。

    d) 小尺度的通用样式：比如菜单激活状态，文字高亮之类的。还例如某些同学喜欢用的清除浮动的样式。
把这几种类型的样式的命名规范好，就能避免很多问题。原因是因为它们通常会在很多页面里被反复使用到，所以是最容易出现冲突和冗余的地方。

2. 页面布局、常用布局以及通用模块的样式，命名要特别。

比如对于全站导航菜单，我比较喜欢用nav（navigation，即导航）来命名，而不是menu，或是main_menu之类的。原因是，可预见的是，在某些特定的页面内，会出现“菜单”这种元素，比如分类索引页，侧栏可能会出现分类的菜单列表。那如果menu被全站导航占用，到时候就容易出问题。

同样的问题也出在“登陆框”或是“搜索框”，如果简单的用login或是search，那你到“登录页”或“搜索页”的时候，就又头疼了。我比较习惯的是用login_box和search_box。

总之呢，一些“自然而然就能想到”的名词，尽量不要用在大尺度或全站通用的样式上，一开始把它们挤占了，就会导致后来的样式命名不得不另想花样，命名的混乱就由此开始。

3. 相反，小尺度的通用样式，命名要通俗简短。

其实小尺度的通用样式命名，就纯粹是一个“惯例”了。比如激活的菜单，有的人用on，有的人用now，有的人用active。你管不着别人的，只能作为一个惯例推广给团队里其他同事。但不要认为“惯例”就没约束性，如果坚持用同一个名字，到处都用，其实其他同学会潜移默化的也跟着用的。比如土豆网的视频截图模块，几年来一直被称作pack。这就是aether同学最初的发明。

下面稍微列了一下，可能用到的通用样式，后面附的英文是我个人的习惯，可以参考，也可以忽略。

页面布局：

  -页面头部：header
    -图标：logo
    -右上快捷区域：quicklinks
  -页面中部：page
    -侧栏：side column
    -主栏：main column
    -第三栏：extra column
    -区块：section
      -区块顶部：heading
      -区块中部：container
      -区块底部：footing
  -页面底部：footer
    -版权说明：copyright

常用布局：

  -田字格布局：show case
  -列表布局：list
  -标签切换：tab
  -排行榜：billboard
  -表单：post form
  -纯文字区域：text area
  -翻页：page navigation

通用模块：

  -导航栏：navigation
  -登陆框：login box
  -搜索框：search box

通用样式：

  -高亮：highlight
  -激活：active，或者on
  -清除浮动：fix，或者clear
  -图：pic
  -文：txt

自己可以根据具体情况来编写这个命名规范表。比如有些网站可能全站底部有个通用的工具栏（比如facebook），那就可以把tool box放到“通用模块”里。又比如，对于“田字格”布局，有些同学可能习惯每一行用一个框套起来，每一项再用一个框套起来，那就会衍生出“row”和“item”这样的样式，另外的做法是每一行末尾用一个空div隔开，可能需要用的是“line”或者直接就用“clear”。whatever，自己决定。

4. 选择符命名的常用方法有：

  a) 基于结构的命名：比如头部/底部，主栏/侧栏，菜单列表/菜单项，区块，按钮

  b) 基于功能的命名：登录框、搜索框、排行榜、翻页、提示（tip)，等等

  c) 基于内容的命名：今日焦点(focus)、用户排行榜（top users)、评论（comments）、搜索结果（search results），等等

  d) 基于样式的命名：列表、田字格、tab、高亮、标红或加粗，等等

  e) 基于状态或行为的命名：激活、拖拽、展开，等等

我没那么教条，不去从什么“样式和结构分离”的形而上原则来规定该用什么。只是谈谈，如果在未来发生需求变动，怎样的命名会让你尽量少做改动。

基本上呢，前两种——结构和功能——是最安全的。因为如果结构或功能发生巨大变化，你要做的工作就多着去了，也不在乎这个命名会改动多大了。

基于内容和样式命名，就比较危险。很可能只是将“今日焦点”改名为“最新话题”，而样式完全不变。或是新增的“分类索引”模块，设计上直接照搬“搜索结果”的排列样式。遇到这种情况，你的命名就尴尬啦。基于样式命名的危险，就更不用说了。

基于状态或行为来命名，通常发生在两种情况：1. 用作JS的钩子；2. 用作某种状态变化的样式。以我的经验，它们的问题往往不是“改动”，而是“不能改动”。一旦用了，就会一直用下去，除非相应的行为方式发生变化。对此我还没深思熟虑过，但值得提醒的就是，对它们的命名要慎重，而且，最关键的是，要将它们和其他的样式剥离开来。当然，这就不是“命名”的范畴，而是“架构”的范畴，这里就不多讲，以后再说。

最后还要特别强调的是：不管采用哪种方式命名，最忌讳的是同时基于两种方式。最常见的就是“左侧栏（left column)”，它同时基于样式和结构。还比如“顶部介绍（top intro）”，同时基于样式和内容；“频道下拉框（channel dropbox），同时基于内容和功能。这些命名，在遇到样式变动，或是新增同样式的模块时候，就会陷入尴尬。

5 最后讲一个比较棘手的问题：层叠（Cascading）。写CSS，经常会遇到层叠的情况：

    搜索
      搜索关键字
      搜索提示
      搜索结果
       搜索过滤选项

这个例子，其实还好解决：就按照各元素的内容或功能直接命名即可。之所以好解决，是因为这些元素大多是本模块（搜索）所特有的，不大可能重复。但另一种情况就比较麻烦了：表单。我举个例子：

    登录
      用户名
      密码

    注册
      用户名
      密码

类似的例子还有：blog的文章（标题、内容）和留言（标题、内容）。问题的关键在于，它们是不同的模块，包含同样内容或功能的元素。更要命的是，有时候，这些元素的样式是一致的，有时候，又有点小不同，有时候，又是迥然不同。

对于层叠的情况，有三种命名方式：

  a) 模块名和元素名绑成一个名字。比如.comment_title。

  b) 只用元素名，只对元素名定义样式。比如.keywords。

  c) 也是只用元素名，但是将选择符层叠定义，比如.login .username。

至于什么情况采用什么方式，完全在于经验。但关键要考虑的因素是：一，在其他模块中是否会出现同样的元素？二，它们在样式上有一致性吗？像“搜索关键字”这种元素，如果断定在其他模块不会有同样的元素，就大胆只用元素名吧。而“登录 用户名”和“注册 用户名”，可推断的是它们的样式有一致性，或许只是一些小不同（比如输入框宽度），那就用选择符层叠定义。而“文章标题”和“留言标题”，很明显它们在样式（甚至结构）上会有很大不同，那最好各取各的名字。

我个人呢，比较倾向于用a)，即模块名和元素名绑在一起。这样可能会造成一些冗余的样式定义，但即便冗余，也有一个好处：解耦。样式各管各的，不用互相牵扯。只有对于那些特别通用的模块，我才会用c)方式，比如.list .item这样。

呼，这个无聊的主题，居然也洋洋洒洒写了这么多。其中肯定有很多漏洞，毕竟我也不能预见到所有的情况。就当是一个自我总结，供参考吧。

“总之，样式类虽然不至于罪大恶极，但还是应该，也可以尽量避免的。”

这句话我同意。但我仍然要对我已经同意——同时也被那芸芸的web标准的信众同意——的话抛出个疑问：为什么要避免样式类？

标准答案自然是“结构样式分离”。所……以，为什么要分离？

话说我们当年被“感召”时，都笃信了这条“结构与样式分离”。很诡异的是，这么多信众中我始终没发现有人能站出来讲一个真正对柴米油盐有意义的理由。我试图回溯了那些曾经“感召”我的词句：

“样式表能够再恰当的地方集中一批命令，以实现某种可视效果，而不是将它们到处分散在整个文档中。比如，假设要让文档中所有的标题都显示为紫色。……然而可能又决定（或许是老板决定）将标题变为暗绿色……那么又得回到前面，修改每一个FONT标签。……”

——Eric A. Meyer《CSS权威指南（第一版）》2000年，第一章

“以前重新设计网站需要几天或者几星期，现在只需要几小时，从而减少成本和避免工作烦恼”

“支持非传统的设备，从无线设备到孩子们想象到的、可以上网的智能手机以及盲人阅读器、屏幕阅读器等残疾人士使用的设备，都不需要再争论开发特殊版本的费用”

——Jeffrey Zeldman 《网站重构》 2004年，第1章

这几句话勾勒出几点很梦幻的好处：
一，原先每处都要一一修改，现在只用改一处就好；
二，一个版本，就可以支持所有的设备；
三，构建模块，重用代码。

OK，题外话，过去的15个月里，我把咱公司的网站的样式表翻了个底朝天：重写了所有页面的CSS。鉴于此，我想我还是有权抛出这样一个观点：这些梦幻般的“好处”，都是非常，非常，非常的微不足道。我们实际工作中面临的问题要比这些复杂得多：

一，原先每处都要一一修改，现在只用改一处就好——如果老板仅仅要求把紫色的字改成绿色的话；

实际的情况是：
1. 老板需要把顶部的登陆框改到左侧栏；
2. 老板需要把一排4个变成一排5个，同时把每个的图尺寸调小；
3. 老板需要让原先的紫色的其中一部分变成绿色，而另一部分变成红色；
4. 老板需要把原来直角的边框改成圆角的。

请问，这种情况下，你样式和结构要分离到什么程度才能保证“一处修改即可”？

二，一个版本，就可以支持所有的设备——如果我们的网站需要支持手机、盲人阅读器、低版本浏览器、未来的浏览器；

而实际情况是：
1. 97%的用户使用IE，其中70%使用IE6，就别提什么未来的浏览器了
2. 我们不在乎盲人是否能打开视频网站的页面
3. 对于手机业务，我们的问题不是要不要另做个页面，而是要不要另开一家公司。

三，构建模块，重用代码——如果我们的页面可以划分成固定不变的模块，同时需要它们的N种组合方式。

而实际的情况是：
1. 只有少数样式是被超过3个页面使用的。
2. 只有极少数样式是在被其他页面使用时，完全不需要做任何适应性改动
3. 很多时候，直接把一段CSS拷贝过去，比多链一个CSS文件要划算得多，无论从性能上还是从开发上讲。

诚然，用现在的情况，来抨击老人家在2000年时宣传CSS时说的话，是很不公平的。但时过境迁，如今CSS应用的如此广泛，我们理应呼唤一些更好的价值观和方法论，来指导我们如何克服在朝圣途中所遇到的阻难和纠结。

好吧，讲了N多废话（或许漏洞百出），是想宣布俺自己的一个计划：把过去15个月的关于CSS各方面的实践经验整理成系列的笔记。因为基本上在接下来一段时间，我不大会有机会如此密集的钻研一项技术了，所以也算是为这一阶段的工作做个交代吧。

既然说出口了，为了防止极可能出现的太监现象，我粗粗的整理了一个提纲。基本上它们不会包含什么具体的实践方法，可能只是一些纯理念。它们未必是最好的实践，也未必百分百正确，能抛砖引玉就好：

1. 选择符命名方法
我个人是觉得选择符不需要有什么“规范”，尤其是在Firebug之类的工具如此方便的当下。但命名还是需要方法的，好的方法可以达到的目的：一，不用花时间起名字（这个很重要，呵呵）；二，不用怕起名字重复；三，节约字符；四，避免英文不好而丢脸。

2. 大网站的CSS架构
好的架构可以带来的好处：一，避免冗余的定义；二，避免改动的风险；三，避免冗余的文件夹；四，便于更好的交接和协作。

3. 常用的CSS套路
这就纯粹是讲个人习惯了，不建议照搬。做了N多网页，就能总结出一些套路，可以很快的搭好架子铺好路，不用每次都要一字一句的从body {margin:0; padding:0 }开始。

4. Sprite技巧
也不知道sprite会流行多久。这个纯粹是sprite这一狭窄的技术的一些心得，如果你很有远见的认为sprite用不了多久就会被内联图片取代，那就随便看看吧。

5. CSS变更控制与管理
CSS好写，可改起来就有些头疼了。尤其是对于一些有洁癖的人来说，更是纠结啊纠结。我想试着总结一些经验，包含从最开始如何搭建样式，到预测可能的变更，以及应对的更改方式。

6. 前端与其他工种的协作与沟通
我之前说过，前端是集结设计与开发的重要环节，与其他工种的同学保持良好的默契与沟通，是优秀前端必备的技能。可能和前端有接洽的工种包括：UI设计、后端开发、产品经理、项目经理、测试、交互设计师、数据分析、SEO，等等。我未必讲得都对，不过我会尽量挑出遇到过的做得好的例子。

哈哈，摊子铺的有点大，我都开始害怕了。anyway，如果迟迟未能完成，或是写出来让大家觉得“也不过如此”，别怪我让你失望，就怪你自己之前期待太高吧（:P）

2. 对话
@zhaozexin 小马，黑丝姐姐说你不如去年那样有咬一口滋滋冒甜水的水灵feel了，注意保养啊。
@mikko 今年结婚了

3. 我、Dex、张峰，居然都中奖了！大满贯啊~中的T恤的图案，还是俺设计的呢~~

4. 推荐大家使用人间网

如果有个功能根本就无用，但又必须提高它的使用率（转化率，whatever），就把它做得更好玩吧~~反正无论如何都“不实”，至少要让它“华而不实”咯。

当然，做成键盘，或许成本高了点。那至少可以在阶梯上贴上如下的标签？哈哈

关于“前端开发工程师”这个职位
当一个词开始泛滥，就会被人忘记它的本意。我只讲我认为的解释。首先，它是“开发工程师”，也就是程序员。其工作内容的本质，就是写代码。所以，程序员应该具备的素质，比如逻辑能力，写代码的水平等等，算是它最最基础的要求。

在此之上，则是另一个要求：“界面开发”。对“看得见”的东西的感觉要敏锐。这偏偏是大多数重于理性思维的普通开发工程师，所无法具备的一项能力。坦率的说，这也是前端开发工程师与众不同，可以引以为傲的地方。前端开发职位，正是一个将看不见的逻辑转化为看得见的图形的重要角色，也可以说，一个优秀的网站产品，“最终”的成败系于前端开发这一环。

如何入行前端开发
由于现在这个劣币驱逐良币的年代，前端行业里滥竽充数太多，真正优秀的又都各占着坑不大挪窝，所以有必要仔细回答一下这个问题，以期更多有潜质的人能加入我们。我按当前状态来分类：

如果，你正在从事“网页设计”、“网页制作”方面的工作。我得先说明一下，“会做网页”不等于“前端开发”。再重复一遍：前端开发是写代码的，是用代码来构建网页界面和交互。如果还不明白，我举个例子。在宜家买个电脑桌，带回来需要自己把几块板拼成电脑桌。这个过程你会做，但绝对不会有人把你称作家具木匠。这只不过是有现成的材料，按照图纸把成品拼装起来而已。前端开发，就相当于给一块木头，要从刨木头弹墨线开始做。也不要以为今后WYSIWYG工具发达了，就没前端堆代码这碗饭。但凡纯手工打造的都是上乘精品，再过一百年，这个道理都会在的。（这样说，感觉自己好像深山里的老师傅，hoho）

如果，你正在从事“软件开发工程师”方面的工作。那你遇到的就是另一个问题了：对于界面的敏锐度。其实前端开发也不用做设计，所以不需要知道该如何“做菜”，但一定要知道好吃不好吃。能够知道什么界面的是好看，什么界面是不好，这其实并不容易。我其实也很困惑，为什么大多数人对界面好看不好看没有什么感觉。但苹果告诉我们，界面好看到极致，确实是可以比一般的产品多出一些价值的。

如果，你正在从事“前端开发”方面的工作。那就需要问问自己几个问题了：对于前端开发所必须的技术，你掌握多少？“够用就行”的知识量，是无法胜任“真正的前端开发”的。这里有一个很重要的问题：我接到的很多简历，确实可以看到对方过去一直在从事前端开发工作，但给我的案例都是非常糟糕的。如果说，过去的工作环境让你无法做出自己想做的东西，我认为这不是值得体谅的借口。我也面试过很多来自不好的公司的人，他们同样给了我他们自己平时做的实验性作品。诚然工作环境局限会让一个人很容易止步，但我真正欣赏的其实是对前端开发本身充满热情的人。之前的“堆代码”，只是我的一种戏称。如果你真的觉得前端是无聊的堆代码，那其实也无法指望在将来有不断的进步。其实，任何一份工作都是这个样子的，只有热情才能将人推向完美。

如果，你只是一个“前端开发爱好者”，比如，只是一名学生，还没有工作经验。其实我经常会遇到这个来自菜鸟的问题：怎么学CSS或JS。那，如果认真的打算作为职业来学习，有几个简单的忠告：

1. 通读权威指南。不要瞎读，外面烂书太多。倒不是说烂书学不到知识，它们之所以是烂书，是因为它们缺乏一种“正确的价值观”。什么是卓越的方法，什么是优雅的代码，这些都是有“品味”和“格调”的。由于我近期看的书不多，也不想为别人打广告，所以我只能给出一个简单但绝对不会错的答案：看《权威指南》。

2. 多做自己想做的练习。比如自己做一个简历网站或是博客，把想用的技术都用上去，做了一版再做一版。不要指望通过接外包项目之类的能给你带来技术上的提高，替他人做嫁衣其实让你很难很好的发挥的。

3. 多向他人学习。这不是说你得缠着个高手整天帮你解答问题。但凡技术高手，都是自学、google、自己琢磨+和人讨论的。计算机技术，向来不存在“教会（呃，第一个字念一声）”这一说。多和别人交流，共同提高，这才是正确的做法。

我还会其他的技能
我也时常会接到简历，声称会设计，会flash，会PHP或.NET。淘宝倒是一直要求应聘的前端开发一定要会一门非前端编程语言。我想他们的本意或许是在强调我开篇的第一点：前端开发是开发工程师。回到开初的问题，会一些周边的技能，对前端开发是否有帮助？答案当然是肯定的。但我在面试时从来对这些方面只字不问。对于一个优秀的前端开发，最重要的仍然是对前端技能本身的精通，而我相信，当你全身心投入在前端技能上时，是不大可能将其他的技能也同样做到精通的。既然不精通，我也没必要测试了。如果来者说会这些，我知道了，我也相信，就可以了。反过来，如果你真是对前端技能精通，是不可能对这些周边知识一无所知的。其实，它们都是和前端开发工作紧密结合的，很容易触类旁通。就像一个优秀的网页UI设计师，是不可能对HTML一窍不通的。

只会CSS或只会JS
一般而言，前一种情况比较多：CSS简单嘛。aoao同学说，百度是愿意要的，当前前提是“足够精通”。而淘宝的招聘广告则是狠狠的说：两者都要好。我个人是觉得，可以容许在前端开发中再细分为界面工程师和JS工程师的。但前提是，这个team已经有足够的钱来养一个大大的前端开发团队。至少对于小公司（比如偶们公司），仍然希望来者身上有足够多的剩余价值可以被榨取（hoho）。

先写这么些吧。其实，还有一些关于前端开发职业发展的想法，等我下次无事可做时再说吧。

标准的 Web 组成应该包括 3 部分：结构、行为和表现。这种思想最早在微软设计的DHTML 模型中初步提出来，但是很不规范，也不成系统。后来，W3C（World Wide Web Consortium，万维网联盟）组织规范了 Web 的构成。根据 W3C 制订的标准，Web 标准不是某一个标准，而是一系列标准的集合。完整的Web 应该由以下3 部分组成：
· 结构（Structure）。
· 表现（Presentation）。
· 行为（Behavior）。
这 3 部分对应的实现技术如下。
· 结构标准语言：主要包括 XHTML 和 XML。
· 表现标准语言：主要包括 CSS。
· 行为标准语言：主要包括W3C DOM、ECMAScript。
上面各种标准语言大部分由W3C 组织制订，但是部分标准也由其他标准组织制订，如ECMA（European Computer Manufacturers Association，欧洲计算机厂商协会）制订的ECMAScript。

“标准的 Web 组成应该包括 3 部分：结构、行为和表现。”
“ 完整的Web 应该由以下3 部分组成：结构 行为 表现”

1. 先挑最重要的说吧。Web标准的核心思想是，结构、表现和行为要“分离”。不是说包含这三个部分的就是标准，也不是说不包含这三个部分的就不标准。

2. 稍微扯玄一点。任何一个网页都会有结构、表现和行为，就哪怕不带JS、不带CSS的“纯HTML”也是这样：比如HTML标签的默认样式，就是它的“表现”；比如target=”_blank”这种属性，就是它的“行为”。Web标准号召结构、表现、行为要分离，也正是这个思想，导致XHTML 1.0 strict 废除了a标签的target属性，希望交由JS来决定链接是否新开窗口（呃，当然，现在看来这个规范很蠢）。

3. 所以，即使那么喜欢“结构、表现、行为”这种辞藻，也不一致一段话里开头讲一遍，末尾又讲一遍吧？

根据 W3C 制订的标准，Web 标准不是某一个标准，而是一系列标准的集合。

其实我一直以来没跟人较过这真：但事实上Web标准跟W3C半毛钱关系都没有。Web标准是WaSP（Web Standard Project，网页标准组织，大本营在这儿）提出的一种“前端开发规范”（呼，这个名词我真喜欢）。当然，W3C制定的一系列规范文档，是多少融合了Web标准的思想，但它只是一些语法规范，完全没有提到所谓结构、表现和行为分离的事情。我可以写一堆带了N多style和N多onclick的标签，严格符合XHTML语法规范，但很明显它并不符合Web标准的分离原则。

所以这里引出一个重要的结论：通过哪些啥W3C验证，跟网页是否符合Web标准没有任何关系。

一本书开篇第一章就这么糊里糊涂的，也能看得出治学态度的浮躁了。其他的部分，我也不是啥高手专家，不敢妄加评判。不过，反正我本人是看得云里雾里的，不知道真正的初学者看了之后，能收获些啥。当然，这种书也有个好处，就是让那些梦想成为专家的“初学者”们，一下子捕获了众多华丽辞藻，说不定能激起他们对散发出牛逼哄哄气氛的网页前端技术有了新的神往。前端技术嘛，永远是这个下场，门槛低，易炫耀，会点皮毛再堆点辞藻，就能忽悠住一大片人。

好吧，我确实是因为blog老不更新，才硬挤出这么一篇赶时髦的文章。其实，我可没那众多高手和前高手（呵呵）那么有社会责任感，初学者嘛，总是要走很多弯路，买很多烂书的。咱这些从洪荒年代走来的人，谁没买过几本“实战100例”之类的书嘞？一个人的成绩只跟自己追求真理的态度有关，跟图书市场环境没啥关系。

—————-

土豆网上海总部招聘前端开发工程师。作为前端开发团队的一员，你将会肩负如下的职责：

1. 根据产品需求与UI设计稿，负责土豆网主站页面的开发；
2. 保持优秀的界面与交互体验的同时，始终将前端性能的最优放在首位；
3. 设计整站前端架构，并为前后端整合提供完美解决方案；
4. 积极探索先进的前端开发协作模式，持续优化工作流程；
5. 营造一流的前端开发理念与文化，进一步扩大团队影响力。

我们希望你能大致符合如下描述：

1. 全面掌握HTML 4.01与CSS 2.1规范，对于网页标准有成熟而独立的看法。
2. 精通JS的语法特性和运行机制，乐于钻研JS设计模式，并积极探索高级Web应用的最佳实践；
3. 充分理解前端开发对界面设计、交互设计、网站性能的重要性；
4. 持续关注业界新话题与新技术，对前端技术的发展保持浓厚的兴趣与激情。
5. 我们不限资历，但希望你能有丰富的经验，以便游刃有余的面对各种挑战。

如果你目前还不完全具备这些要求，但很渴望并自认有潜质做到这些，我们也很愿意与你面谈并提供尝试的机会。

请在简历里附上以下的内容（如果有的话），以方便我们更全面的了解你：

1. 你最精彩的案例
2. 你阅读的书籍、关注的技术，或是沉迷的技术社区
3. 你的blog

简历请发至 join@tudou.com。

1. 在地址栏里输入“alipay.com”（记住，不是zhifubao.com，是“阿里呸”），回车。

2. 首页右下角登录。（我一直搞不清楚，好像我淘宝的用户名是不可以直接用于支付宝登录的。但是我在淘宝付款，它又能直接跳转到我对应的支付宝帐号）

3. 登录后的惯例页面。一定要仔细阅读两个按钮上的文字，然后选“跳过该页面”

4. 成功到达了支付宝神秘的注册用户首页（为什么神秘？我稍后再讲）。心中开始默念“手机充值，手机充值”。抬头看到菜单里有个“充值”。不假思索的就点了。

5. 啊呃。走错了。这是给支付宝账户充值。

6. 然后发现顶上有“生活助手”。想起之前缴电费好像也是在这里面，手机充值也应该是吧。于是，点。

7. 啊哈，到了。果然，右边有“通讯费”。点。

8. 成功到达。选“切换项目>手机费”；选上海、上海；选“中国移动通讯集团上海有限公司”（呃，坦率的说，头一次知道这个公司的正式全名。从移动哪儿都从来没听说过这么正式而完整的名称）。然后….

10.现在是什么情况？？需要填条形码？我是预付费手机啊，我是想来买充值卡号，怎么还要问我要条形码号？

11. 惊慌中，找到顶部的“使用遇到问题”。点。把我带到页面下方的帮助。连看了好几条都不之所云：

12.这不是缴水电费的说明么？抬头再一看，通讯费的页面顶部写的是“公共事业缴费”，而我刚刚点的是它旁边的“使用遇到问题”。好吧，我的错。我以为通讯费上写“使用遇到问题”指的是通讯费页面的使用问题。

13. 无奈中，只能重新再找找看把。四处没发现“首页”的菜单，于是点右上角“支付宝”LOGO，回到首页。愕然发现自己到了登录前的首页：

刚刚的“生活助手”或是“充值”的那个橘色导航条不见了，取而代之的是“立即注册”？我要怎么回到那个页面，那个“我心目中的首页”？

OMG~~~

直到现在我手机也还没充上值。好吧，因为我懒，而且我笨，所以不配使用阿里呸。