对于我自己来说，这本书进一步增加了我过去一些关键经验的 connect the dots 过程，同时对当今世界中心学科和它们的中心议题有了一个框架性的了解。这也正是我前面说“积累式收获”的原因，积累的前提是存在某种一致性的主线。对我来说，大主线就是对自然世界和人类社会的经验和理解程度，更聚焦的子线就是投资和计算机路线，但正如在关于我中提到的那样，对世界的理解是更宏大的问题，是基础中的基础。
Connect 了哪些 dots？
ACM 校赛、阿黄的超越数、中科大自主招生、小学竞赛
大学时期参加 ACM 校赛时，有一个问题涉及到超大数，也即超出了 32 位或者 64 位二进制能表达的数字范围。这个时候需要用到一些语言中内置的 long long 类型。当然语言中是否内置了超大数的处理方法不是关键，关键是我在此之前没有任何关于超大数的背景知识，于是就按照正常的整数和浮点数类型设计了算法，结果显然是精度不够，计算偏差很大。
后来我才知道这是「计算机和 C 语言数据表达精度有限的问题」，我知道这事的第一反应是：「这特么的大学的 C 语言课堂上根本没教过啊」，这题不是超纲了吗？
Creating the web was really an act of desperation, because the situation without it was very difficult when I was working at CERN later. Most of the technology involved in the web, like the hypertext, like the Internet, multifont text objects, had all been designed already. I just had to put them together. It was a step of generalizing, going to a higher level of abstraction, thinking about all the documentation systems out there as being possibly part of a larger imaginary documentation system. But then the engineering was fairly straightforward. It was designed in order to make it possible to get at documentation and in order to be able to get people — students working with me, contributing to the project, for example — to be able to come in and link in their ideas, so that we wouldn’t lose it all if we didn’t debrief them before they left. Really, it was designed to be a collaborative workspace for people to design on a system together. That was the exciting thing about it.
创建 Web 确实是一种绝望之举，因为我后来在 CERN 工作时，没有 Web 时候的情况非常糟糕（注：指的是多种文档系统工作，协同起来非常痛苦的情况）。 其实在哪个时候，与 Web 相关的大多数技术，如超文本、互联网(指底层的 internet，注意它和 World Wide Web 的区别)、多字体文本对象，都已经在实际应用的设计。我只需要把它们放在一起，对(所有的这些东西)进行一些概括抽象，进入更高的抽象层次，将所有文档系统视为可能是更大的一个想象文档系统的一部分。 但整体的工程设计相当简单。它的设计目的是获取文档，并让其他人——例如与我一起工作、为项目做出贡献的学生——能参与进来并链接他们的想法，这样即使这些人离职了，我们也不会失去这些想法。 实际上，Web 被设计为一个供人们一起在系统上进行设计的协作工作空间。 —— 这就是最让人兴奋的事情。
—— Academy Achives 2007 年对 Tim Berners-Lee 的采访: Visionary of the Internet [3]
HTML: HyperText Markup Language. 超文本标记语言 The markup (formatting) language for the web.
URI: Uniform Resource Identifier. 统一资源定位符 A kind of “address” that is unique and used to identify to each resource on the web. It is also commonly called a URL.
HTTP: Hypertext Transfer Protocol.超文本传输协议 Allows for the retrieval of linked resources from across the web.
还是回到现在的眼光来看：
这三种元素设计高度抽象， 用户只需要遵循几个简单的规范就可以搞一套自己完全控制的文档系统(而不是在别人控制的软件结构中写自己的文档)，或是改造已有的文档系统让它可以连接到其他系统，这构成了现代 Web 的基础框架。
CSS 最早目标多是针对文档排版（就像 Word 那样），用于二维网页布局的时候就很吃力，需要通过对一维流式布局的 hack 来实现很多在平面设计领域中很寻常的能力。
JavaScript 的早期目标是用来处理一些网页中的小任务， 它并不是一个深思熟虑的语言。但好在实现通用图灵机的机制要求是简洁的， JavaScript 也同样是图灵完备的（拥有完整的顺序执行、条件分支执行、循环执行能力），只要 API 足够，它理论上仍然能实现任意其他语言能实现的能力。
由于 Web 的开放性，当这个系统越来越大之后，网页开发者和浏览器的开发者就需要互相兼容互相迁就，任何一个网页开发者都希望自己的网页能被浏览器正常解析，任何一个浏览器也都希望能解析任何一个网页。这共同形成了很强的已实现技术路径依赖，引入新技术必须要考虑对已有技术的兼容。这保证了开放性和可用性的同时，也为 Web 积累了很大的历史负债。
但立下这个 flag 之后，我只在独立博客上写了一年的文字，在续费域名的时候觉得维护独立域名比较麻烦，于是就放弃了独立博客。 后续辗转使用了知乎、公众号、小报童这些平台作为自己公开输出文字的地方，本来以为可能会像上面的三个阶段那样，把文字托管到这些地方可以更加专注在写作的本质上，但实际的效果可以说是正好相反。
We challenged ourselves to create a visual language for our users that synthesizes the classic principles of good design with the innovation and possibility of technology and science. This is material design. Develop a single underlying system that allows for a unified experience across platforms and device sizes. Mobile precepts are fundamental, but touch, voice, mouse, and keyboard are all first-class input methods
我们用了洪荒之力，为用户设计了一种视觉语言，它综合了传统设计原则中好的部分，以及科学技术带来的创新和可能性等。这就是 material design。 （material design 可用来）开发一套基准系统，在这个系统的基础之上，构建跨平台和超越设备尺寸的统一体验。它遵循基本的移动设计定则，同时支持触摸、语音、鼠标、键盘等输入方式
设计原则
material（材料）其实是一个隐喻： 这个隐喻是理解 material design 其他内容的基础。在考虑 material 设计空间以及一系列元素动作行为设计的时候，都不要忘记背后的隐喻。
… 这些最初用于传统纸质媒介的设计准则，被搬到新的电子媒介上来并且取得了很好的效果——要知道网页刚开始除了页面上有一些超链接外，其他展现方式跟纸质媒介中的丰富性相差甚远，传统平面设计中的理念能对 web 设计产生非常有用的指导，比如网格系统：
随着 web 的发展，电子媒介就有了自己独特的地方，不再像纸质媒介那样是纯静态的了——它有了真正的「交互」。新的 web 特性也需要寻求其他的理论支撑，如果不能再从传统的平面设计中借鉴，如何开创一套适用于 web 这些新特性的设计准则？这就来到了 material design 文档中所说的「科学技术带来的创新和可能性」。
虽然这些概括的命题争议很大，在这些学科中至少可以说「部分如此」。在设计上往更深层次寻找，基本上到「心理，生物」这一范围。找到更深层次的理论，就为「创造性」设计提供了基础，使得设计空间的表达可以发生转变，也不必再囿于传统平面设计在新 web 媒介下的套用，完全可以根据这些深层理论进行自由发挥，创造出适合 web 的设计形式。
material design 所隐喻的是一种设计材料（material），姑且称之为「material 卡片」是从现实中抽象出来的，去掉现实中的杂质和随机性，保留空间关系、变化与过渡，光影效果。这种材料具有厚度，材料之间有空间关系。这其实暗示着一个更大的隐喻 —— 整个 material design 其实隐喻着一个特殊的设计空间，这个空间具有三维结构，而 material 卡片则是组成这个空间的基本材料。
一路类比下来，在设计领域也是有部分内容是可以找到更为普适的心理学依据的，比如很多设计原则中提出的：对齐，靠近，对比等等。这就为设计提供了一种「普适的说明性基础」，让设计不再看起来只是设计师的个人喜好传达，当遇到一些设计上的不同意见时，可以找到（比 AB 测等数据验证）一种更为轻松的解决方式——咱们往下还原一步看看怎么说。
带着忐忑的心开始求职，去了一个学长创办的创业公司，不清楚是自己无知，还是公司对自己过于信任，第一次出来面试，就直接入职了。后来因为这和家人朋友还发生了一些争执，果真是年少轻狂啊。此外还有些在现在看来有些装 B 的疑惑：都说找工作难，但这是什么情况？不过也没多想，紧迫的毕业，入职，开始了职场菜鸟的生活，计划中的毕业旅行也取消了。
目前不同的 JavaScript 引擎实现有好几种，但是当前最流行的实现版本是 Google Chrome 的 V8 引擎（这个引擎不受限于浏览器端，在服务器端的 Nodejs 使用的也是它）。说了这么多，那 JavaScript 引擎到底是干啥的？其实很简单——它的工作就是遍历 Web 应用中的每一行 JavaScript 代码，并且逐个执行（process one at a time）。你没有看错——就是逐个执行，这意味着 JavaScript 是单线程的。这一特点的主要影响是，如果你执行一行需要非常非常长的时间才能返回结果的代码，这之后的代码都会被阻塞掉。我们当然不想写出这么阻塞的代码——特别是在浏览器中。想象一下你正在查看一个 Web 网页并且垫底了某个按钮…它就这么耗在了那里。你试着点击其他的按钮，然而并没有什么卵用，啥作用都没起。这种蛋疼的局面只能归罪于点击按钮的时候触发了某些代码的执行（假设没有 bug 的话），但是这些代码阻塞在了那里。
最近又看到一个经典的前端面试题：「你是如何理解 web 标准以及 W3C 的」，其实这个问题的思路跟上面基本是一致的：工业标准化能带来什么，Web 标准化就能带来什么。
关于 web 标准的细节，这里不做讨论。Web 标准当然很好，它为内容，表现，行为提供了良好的可实践标准，并且可以据此建立起高可用，易理解，适应性强的 web 系统结构。
W3C
标准的意义是在标准被普及，被遵守后体现出来的。遵守的人越多，产生的好处越大，最终建立一个运行在互联网上的一个个标准的 Web 系统。由于每一个 Web 系统都是标准的，那它们不仅对于人类是友好的，对于各种处理这些 Web 系统的更高层的系统（比如说搜索引擎）也将是友好的。
关于互联网有一个经验公式，互联网的价值和组成它的节点数量的平方成正比。对于 Web 标准化也是类似的。根据 Web 标准本身可以建立起一个个结构清晰的 web 系统，而这些标准的 web 系统又联合起来组成一个更大的标准系统，这就使得各类工作更容易进行，以及在此基础上做更多的事情，产生更大的价值。这个时候就类似于之前说的板砖，或者更早博客中提到的集装箱了。
Web 标准的自身的意义并不是最重要的，很可能存在比当前 web 标准更好的标准。一个易于普及的良好定义的标准，比一个更优秀的但是难以普及的标准，可以产生更大的价值。类似的例子再历史上比比皆是。
至于 W3C（万维网协会），则是 Web 标准化进程的领头羊，负责制定，推广 Web 标准，不仅要保证当前标准自身是好的，还要协调不同的厂商，让标准是更容易接受，普及的，可谓任重道远。
In user interface design, a modal window is a graphical control element subordinate to an application’s main window which creates a mode where the main window can’t be used. The modal window is a child window that requires users to interact with it before it can return to operating the parent application, thus preventing the workflow on the application main window. Modal windows are often called heavy windows or modal dialogs because the window is often used to display a dialog box.
Modal windows are commonly used in GUI systems to command user awareness and to display emergency states, although they have been argued to be ineffective for that use. Modal windows are prone to produce mode errors.
设计原理本质上是一种信念、一种想法、一个概念，是你行动的支柱。不管你是制定规范，还是制造一种有形的物品，或者编写软件，甚至发明编程语言。你都能找到背后的一个或者多个设计原理，多人协作的任何成果都是例证。不仅仅 Web 开发领域是这样。纵观人类历史，像国家和社会这样大规模的构建活动背后，同样也有设计原理。
在座各位对蒂姆·伯纳斯 - 李的贡献都是非常熟悉的，因为大家每天都在用。他发明了 Web，与罗伯特·卡里奥（Robert Cailliau）共同发明了 Web，而且在发明 Web 的同时，也发明了我们每天都在 Web 上使用的语言。当然，这门语言就是 HTML：超文本标记语言。
HTML
HTML 最早是从 2.0 版开始的。从来就没有 1.0 版。如果有人告诉你说，他最早是从 HTML 1.0 开始使用 HTML 的，那他绝对是在忽悠你。从前确实有一个名叫 HTML Tags 的文档，其中的部分标签一直用到现在，但那个文档并非官方的规范。
使用标签、尖括号、p 或 h1，等等，并不是蒂姆·伯纳斯 - 李首创的想法。当时的 SGML 里就有了这些概念，而且当时的 CERN（Conseil Europeen pour la Recherche Nucleaire，欧洲核子研究委员会）也在使用 SGML 的一个特定的版本。也就是说，即便在那个时代，他也没有白手起家；这一点在 HTML 后来的发展过程中也体现了出来：继往开来、承前启后，而不是另立门户、从头开始。
换句话说，这篇名为 HTML Tags 的文档可以算作 HTML 的第一个版本，但它却不是一个正式的版本。第一个正式版本，HTML 2.0，也不是出自 W3C 之手。HTML 2.0 是由 IETF，因特网工程任务组（Internet Engineering Task Force）制定的。在 W3C 成立之前，IETF 已经发布了不少标准。但从第三个版本开始往后，W3C，万维网联盟（World Wide Web Consortium）开始接手，并负责后续版本的制定工作。
20 世纪九十年代 HTML 有过几次快速的发展。众所周知，在那个时代要想构建网站，可是一项十分复杂的工程。浏览器大战曾令人头疼不已。市场竞争的结果就是各家浏览器里都塞满了各种专有的特性，都试图在专有特性上胜人一筹。当时的混乱程度不堪回首，HTML 到底还重不重要，或者它作为 Web 格式的前景如何，谁都说不清楚。
这就是个大问题。XHTML 1.0 之后是 XHTML 1.1，只是小数点后面的数字加了一个 1，而且从词汇表的角度看，规范本身没有什么新东西，元素也都相同，属性也都相同。但对 XHTML 1.1 来说，唯一的变化是你必须把自己的文档标记为 XML 文档。在使用 XHTML 1.0 的时候，还可以把文档标记为 HTML，而我们也正是这样做的，否则把文档标记为 XML 没准真会把人逼疯的。
为什么这么说呢？首先，把文档标记为 XML 后，Internet Explorer 不能处理。当然，IE9 是可以处理了。恐怕有人会讲“真是太可爱了”，他们到现在居然都没有忘了这件事。这艘船终于靠岸了！不过那时候，作为全球领先的浏览器，IE 无法处理接收到的 XML 文档类型的文档，而规范又要求你以 XML 文档类型来发送文档，这不把人逼疯才怪呢。
所以说 XHTML 1.1 有点脱离现实，而你不想把文档以 XML 格式发送给那些能够理解 XML 的浏览器，则是因为 XML 的错误处理模型。XML 的语法，无论是属性小写，元素小写，还是始终要给属性值加引号，这些都没有问题，都很好，事实上我也喜欢这样做，但 XML 的错误处理模型却是这样的：解析器如果遇到错误，停止解析。规范里就是这么写的。如果你把 XHTML 1.1 标记为 XML 文档类型，假设你用 Firefox 打开这个文档，而文档中有一个和号（&）没有正确编码，就算整个页面中就这一处错误，你看到的也将是黄屏，浏览器死掉了。Firefox 会说：“没戏了，页面中有一个错误，你看不到这个网页了。”根据 XML 规范，这样处理是正确的，对 Firefox 而言，遇到错误就停止解析，并且不呈现其他任何内容是严格按照 XML 规范做的。因为它不是 HTML，HTML 根本就没有错误处理模型，但根据 XML 规范，这样做没错。
这就是为什么你不会把文档标记为 XML 的另一个原因。接下来，新的版本是 XHTML 2，大家注意后面没有日期，因为这个规范并没有完成。
首先，XHTML 2 仍然使用 XML 错误处理模型，你必须保证以 XML 文档类型发送文档；这一点不言自明：没人愿意这样做。其次，XHTML 2 有意不再向后兼容已有的 HTML 的各个版本。他们甚至曾经讨论过废除 img 元素，这对每天都在做 Web 开发的人来说确实有点疯了的味道。但我们知道，他们之所以这样做，理论上确实有充足的理由——使用 object 元素可能会更好。
为什么 XHTML 1.1 没有像 XML 那样得到真正广泛地应用，为什么 XHTML 2 从未落到实处？因为它违反了一条设计原理，这条设计原理就是著名的伯斯塔尔法则（Postel’s Law）。大家都知道：
发送时要保守；接收时要开放。
没错，接收的时候要开放，而这也正是 Web 得以构建的基础。开发浏览器的人必须敞开胸怀，接收所有发送给浏览器的东西，因为它们过去一直都在接收那些不够标准的东西，对不对？Web 上的很多文档都不规范，但那正是 Web 发展的动力。从某种角度讲，Web 走的正是一条混沌发展之路，虽然混沌，但却非常美丽诱人。在 Web 上，格式不规范的文档随处可见，但那又怎样呢？如果所有人都能够写出精准的 XML，所有文档的格式都十分正确，那当然好了。可是，那不现实。现实是伯斯塔尔法则。
有人可能会说 XML 有错误处理模型，XHTML 1.1 和 XHTML 2 都使用该模型，但那个错误处理模型太苛刻了。它绝对不符合接收时开放这个法则，遇到一个错误就停止解析怎么能叫开放呢？我们只能说它与健壮性法则（也就是伯斯塔尔法则）是对立的。
HTML5
之后，就到了 HTML5，但 HTML5 并不是由 W3C 直接制定的。故事的经过是这样的，到 20 世纪末的时候，还没有 HTML 工作组，W3C 内部的一些人就开始琢磨了，“HTML 也许还可以更长寿一点，只要我们对它稍加扩展就行了。只要把我们放在 XHTML 上的时间和精力拿出一部分来，就可以提升一下 HTML 中的表单，可以让 HTML 更接近编程语言，就可以让它更上一层楼。”
于是，在 2004 年 W3C 成员内部的一次研讨会上，当时 Opera 公司的代表伊恩·希克森（Ian Hickson）提出了一个扩展和改进 HTML 的建议。他建议新任务组可以跟 XHTML 2 并行，但是在已有 HTML 的基础上开展工作，目标是对 HTML 进行扩展。W3C 投票表决的结果是——“反对”，因为 HTML 已经死了，XHTML 2 才是未来的方向。然后，Opera、Apple 等浏览器厂商，以及其他一些成员说：“那好吧，不指望他们了，我们自已一样可以做这件事，我们脱离 W3C。”他们成立了 Web Hypertext Applications Technology Working Group（Web 超文本应用技术工作组，WHATWG）——可巧的是，他们自称工作组，而不是特别小组（task force），这就为 HTML5 将来的命运埋下了伏笔。
WHATWG 决定完全脱离 W3C，在 HTML 的基础上开展工作，向其中添加一些新东西。这个工作组的成员里有浏览器厂商，因此他们不仅可以说加就加，而且还能够一一实现。结果，大家不断提出一些好点子，并且逐一做到了浏览器中。
而 WHATWG 呢，他们还在不断地迭代。即使目前我们说的 HTML5，也不能完全涵盖 WHATWG 正在从事的工作。最准确的理解是他们正在开发一项简单的 HTML 或 Web 技术，因为这才是他们工作的核心目标。然而，同时存在两个这样的工作组，这两个工作组同时开发一个基本相同的规范，这无论如何也容易让人产生误解。误解就可能造成麻烦。
是不是，基本上相同。它要告诉浏览器的是：这个文档是 XHTML 1.0 的文档。那么在 HTML 5 中，省掉不必要的复杂性，doctype 就简化成了：
1
<!DOCTYPE html>
仅此而已。好了，就连我也能过目不忘了。我用不着把这几个字符记在记事本里了。我得说，在我第一次看到这个 doctype 的时候——我当然以为这是一个 HTML 文档的 doctype——被它吓了一跳：“是不是还少一个数字 5 啊？”我心里想：“这个 doctype 想告诉浏览器什么呢？就说这个文档是 HTML 吗？难道这是有史以来唯一一个 HTML 版本吗，这件事我得首先搞清楚，HTML 今后永远不会再有新版本了吗？”好一副唯我独尊的架式！我错了，因为这个 doctype 并没有这个意思。为此，必须先搞清楚为什么文档一开头就要写 doctype。它不是写给浏览器看的。Doctype 是写给验证器看的。也就是说，我之所以要在文档一开头写那行 XHTML 1.0 的 doctype，是为了告诉验证器，让验证器按照该 doctype 来验证我的文档。
浏览器反倒无所谓了。假设我写的是 HTML 3.2 文档，文档开头写的是 HTML 3.2 的 doctype。而在文档中某个地方，我使用了 HTML 4.01 中才出现的一个元素。浏览器会怎么处理这种情况？它会因为这个元素出现在比 doctype 声明的 HTML 版本更晚的规范中，就不解释呈现该元素吗？不会，当然不会！它照样会解释呈现该元素，别忘了伯斯塔尔法则，别忘了健壮性。浏览器在接收的时候必须要开放。因此，它不会检查任何格式类型，而验证器会，验证器才关心格式类型。这才是存在 doctype 的真正原因。
而按照 HTML5 的另一个设计原理，它必须向前向后兼容，兼容未来的 HTML 版本——不管是 HTML6、HTML7，还是其他什么——都要与当前的 HTML 版本，HTML5，兼容。因此，把一个版本号放在 doctype 里面没有多大的意义，即使对验器证也一样。
同样，我也不会把这行代码背下来。我还想省下自己的脑细胞去记点别的更有价值的东西呢。不过，如果我想指定文档使用 UTF-8 编码，只能添加这行代码。这是在 HTML 4.01 中需要这样做。要是你在 XHTML 1.0 指定同样的编码，就得多敲一下键盘，因为你还得声明 meta 元素位于一个开始的 XML 标签中。
同样，这样写也是有效的。它不仅适用于最新版本的浏览器，只要是今天还有人在用的浏览器都同样有效。为什么？因为在我们把这些 meta 元素输入浏览器时，浏览器会这样解释它：“元数据（meta）点点点点点，字符集（charset）utf-8。”这就是浏览器在解释那行字符串时真正看到的内容。它必须看到这些内容，根据就是伯斯塔尔法则，对不对？
我多次提到健壮性原理，但总有人不理解。我们换一种说法，浏览器会想“好，我觉得作者是想要指定一个字符集……看，没错，utf-8。”这些都是规范里明文规定的。如今，不仅那个斜杠可以省了，而且总共只要写 meta charset=”utf-8″就行了。
关于省略不必要的复杂性，或者说避免不必要的复杂性的例子还有不少。但关键是既能避免不必要的复杂性，还不会妨碍在现有浏览器中使用。比如说，在 HTML5 中，如果我使用 link 元素链接到一个样式表，我说了 rel=”stylesheet”，然后再说 type=”text/css”，那就是重复自己了。对浏览器而言，我就是在重复自己。浏览器用不着同时看到这两个属性。浏览器只要看到 rel=”stylesheet”就够了，因为它可以猜出来你要链接的是一个 CSS 样式表。所以就不用再指定 type 属性了。你不是已经说了这是一个样式表了嘛；不用再说第二次了。当然，愿意的话，你可以再说；如果你想包含 type 属性，请便。
同样地，如果你使用了 script 元素，你说 type=”text/javascript”，浏览器差不多就知道是怎么回事了。对 Web 开发而言，你还使用其他的脚本语言吗？如果你真想用其他脚本语言，没人会阻拦你。但我要奉劝你一句，任何浏览器都不会支持你。 愿意的话，你可以添加一个 type 属性。不过，也可以什么都不写，浏览器自然会假设你在使用 JavaScript。避免 - 不必要的 - 复杂性。
支持已有的内容
支持已有的内容。这一点非常重要，因为很多人都认为 HTML5 很新，很闪亮；它应该代表着未来发展的方向，应该把 Web 推向一个新的发展阶段。这就是 HTML5，对吗？显然，我们都会考虑让 Web 的未来发展得更好，但他们则必须考虑过去。别忘了 W3C 这个工作组中有很多人代表的是浏览器厂商，他们肯定是要考虑支持已有内容的。只要你想构建一款浏览器，就必须记住这个原则：必须支持已有的内容。
下面我们就来看一个 HTML5 支持已有内容的例子。
这个例子展示了编写同样内容的四种不同方式。上面是一个 img 元素，下面是带一个属性的段落元素。四种写法唯一的不同点就是语法。把其中任何一段代码交给浏览器，浏览器都会生成相同的 DOM 树，没有任何问题。从浏览器的角度看，这四种写法没有区别。因而在 HTML5 中，你可以随意使用下列任何语法。
在所有设计原理中，这一条恐怕是最响亮的了——求真务实。不知道大家有没有在公司里开会时听到过这种口号：“开拓进取，求真务实。”实际上，除了作为企业的口号，它还是一条非常重要的设计原理，因为求真务实对于 HTML 的含义是：在解决那些令人头痛的问题之前，先看看人们为应对这些问题都想出了哪些办法。集中精力去理解这些“民间的”解决方案才是当务之急。
这里有一个 div 使用了 id=”header”，另一个 div 使用了 id=”navigation”，……。怎么样，都轻车熟路了吧？在 HTML5 中，这些元素都可以换掉。说起新增的语义元素，它们价值的一方面可以这样来体现：“嘿，看啊，这样多好，用 HTML5 新增的元素可以把这些 div 都替换掉。”
这四个新元素：section、article、aside 和 nav，之所以说它们强大，原因在于它们代表了一种新的内容模型，一种 HTML 中前所未有的内容模型——给内容分区。迄今为止，我们一直都在用 div 来组织页面中的内容，但与其他类似的元素一样，div 本身并没有语义。但 section、article、aside 和 nav 实际上是在明确地告诉你——这一块就像文档中的另一个文档一样。位于这些元素中的任何内容，都可以拥有自己的概要、标题，自己的脚部。
这里，请注意，最重要的还不是我用几个新元素替换了原来的 div 加类，而是我把原来的 H2 换成了 H1——震撼吧，我看到有人发抖了。我碰到过不少职业的 Web 开发人员，多年来他们一直认为规范里说一个文档中只能有一个 H1。还有一些自诩为万能的 SEO 秘诀同样说要这样。很多 SEO 的技巧其实是很教条的。所谓教条，意思就是不相信数据。过去，这种教条表现为“不行，页面中包含两个以上的 H1，你就会死掉的。”在 HTML5 中，只要你建立一个新的内容块，不管用 section、article、aside、nav，还是别的元素，都可以在其中使用 H1，而不必担心这个块里的标题在整个页面中应该排在什么级别；H2、H3，都没有问题。
最近在使用 bootstrap 的时候，遇到一个下拉菜单（dropdown menu）的设计问题。bootstrap 默认的下拉菜单组件是使用 list 作为 html 基础完成的，而不是<select></select>。我想这背后一定有设计者的意图，但是对于刚入门前端的我来说很难考究。不过问了一些人之后，发现似乎并没有关注这些实现背后的设计意图问题。
All the world’s a stage, And all the men and women merely players; They have their exits and their entrances. and one man in his time plays many parts… —William Shakespeare
在 vim 中，$符有丰富的含义，这里指的是行尾前一个字符 ## 前端 主要记录一下前端学习中遇到的容易混淆的地方，个人感觉在 html，css 和 javascript 中。当属 css 最令人难以捉摸，由于浏览器默认样式或是限制，css 继承，层叠规则等的存在，综合作用之下，很多时候都觉得 css 效果与预期不一致。因此 css 的内容或许会更多一些。 仅仅是零散的记录，暂时没有整理成单独文章的精力。以后或许会把一些可以扩展的地方扩展成文章式的内容。 ### CSS 伪类和伪元素区别 伪类：Pseudo-elements 伪元素：Pseudo-classes #### 概念辨析 stackoverflows 上的回答 [What is the difference between a pseudo-class and a pseudo-element in CSS?](https://stackoverflow.com/questions/8069973/what-is-the-difference-between-a-pseudo-class-and-a-pseudo-element-in-css)
关于这些缺陷，可以简单参考阮一峰的文章：javascript 的十个设计缺陷，以及书籍：《javascript: the good parts》
use strict 其实是 ECMAscript 5 中加入的指令，非常接近于语句，但又有所区分：不包含关键字，只是个字符串字面量，而且只能出现在特定的位置。
use strict 的目的是使其后的代码使用 js 的「严格模式」执行，它是 js 的一个子集，修正了一些语言的重要缺陷，并提供健壮的查错功能和增强的安全机制。严格模式与非严格模式有一些重要的区别。
严格模式中不能使用 with 语句
严格模式中变量都要先 var 声明（非严格模式不声明使用会给全局对象添加一个新属性）
严格模式中，函数调用时 this 值为 undefined，而不是全局对象。
模糊点
包装对象
原始类型不是对象，但你可能会见过 APrimitiveType.method 的调用形式，这是因为数字，字符串，布尔值存在「包装对象」这个概念。也就是说，档使用上面的。运算时，javascript 会自动调用 new String(s) | new Number(s) | new Boolean(s) 的方式将这三种基本类型临时转换为对象，并继承相应类型的方法。
1 2 3 4
//一个经典的例子 var s = "test"; s.len = 4; //因为点运算，这里会临时建立一个 string 对象，但是随即又销毁了 var t = s.len; //这里也会创建一个 string 对象，但是已经不是上面那个了，故 undefined
functionfinallyTest(){ var x = 'catch', y = 'except', z = 'finally'; try { k = x + y; a = b; console.log("here is try------------"); } catch(e) { console.log("here is catch----------"); return x; } finally{ console.log("here is finally---------"); return z; } } //执行 finallyTest() //返回值 here is catch---------- here is finally--------- 'finally'
函数名
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
// 直接声明函数是具有函数名的 functionfoo(){} foo.name// 函数名为 foo var bar = foo bar.name// 将函数赋值给一个变量，只是让变量指向了函数结构，并不会改变函数结构本身 // 函数表达式生成的是匿名函数 var foo = function(){} foo.name// "" (空字符串) // 函数名称只存在于函数自身结构内，被传递时不会改变这个结构 functionfoo(){} var o ={ a: 'a', bar: foo }; o.bar.name// foo
this 引用丢失
1 2 3 4 5 6 7 8 9 10 11 12 13 14
// 函数被多次传递时可能发生 functionfoo(){ console.log(this.a); } var obj = { a: 2, foo: foo }; var bar = obj.foo; var a="oops, global"; bar(); //"oops, global" // 回调函数中可能发生（异步） // 代码同上 setTimeout(obj.foo, 100); // "oops, global"
