首先说明引起我注意的问题，因为Twitter的字数限制，我没法把问题讲的特别清楚，这里可以补上：

1. 有问题的页面：南方周末网站几乎所有文章页面，例如这个；
2. 我的主要工作环境：Mac OS X 10.6，Safari 4.0.5浏览器（加最新的WebKit内核）；
3. 我的测试环境：Mac下加测Chromium最新开发版本，Firefox 3.6.3；另在Windows XP和Windows 7下测试最新版本的IE 8、IE 9、Firefox和Chromium。

首先看看我的主工作环境下的情况，我录了一段视频，以便手边没有Mac电脑的朋友参考，点击下图在线观看：

或者直接下载全屏大小的视频文件（1440*900，约5MB）。

p.s. 从视频中可以看到南周在我的Top Sites中占了很前面的位置，是我经常去瞄一眼的网站，所以不是我有意挑刺儿 XD

这个页面的问题是：

1. 选中文字，Copy的缺省快捷键（Cmd+C）被禁用，按该快捷键无任何效果。
2. 选中文字并在选中块上点右键，缺省右键菜单的行为被覆写，改为显示自定义的菜单。
3. 使用该自定义菜单中的“复制”功能，无法正常复制选中的文字，只能得到一个空行和“【南方周末】本文网址：[网页URL]”。

然后我用同样基于WebKit的Chromium测试（我猜开发者应该是基于Windows下的Chrome或者Chromium开发这一功能的），这次结果较好：

1. Copy的快捷键仍然禁用，右键菜单仍然被覆写，但是。。。
2. 使用自定义菜单中的“复制”功能，可以复制选中的文字，后面加换行和“【南方周末】本文网址：[网页URL]”字样。

我猜这个效果应该是开发者的本意。

再测试Mac下的Firefox，发现这个浏览器下所有功能都是缺省的，没有被改写或者禁用。

因为南周网站页面上的所有脚本都经过压缩混淆，所以无法轻易的分析其实现方式。

Windows下各浏览器的表现与Mac下类似：Firefox仍然是干净的；Chrome/Chromium与Mac版本表现相同；IE下无论Ctrl-C快捷键还是缺省菜单都工作，但是Copy到剪贴板的内容都会在选中文字之后加上“【南方周末】本文网址：[网页URL]”字样。

说实话，我可以理解保持自己内容的版权信息的愿望和努力，所以对于设计者的初衷我们就不评论了，这里我只想由此出发，从纯技术视角来说说我对于“设计良好的网站”的看法——仅是一家之言，南周网站的设计和开发者大可大度一点（说实话，南周的页面布局和内容都是相当好的，没啥可说的）。

我心目中（技术上）专业的、设计良好的网站应该具备的最重要特征就是，以用户为中心，高度关注用户体验的设计，包括这样一些特征：

高度结构化

内容、功能区域划分合理，易于重排、组合和个性化。这不仅可以方便用户优化自身的使用体验，还可以帮助开发者更快的进行布局优化、开发跨不同设备的专用显示版本。

跨浏览器兼容

现在主流的浏览器主要是包括：IE系（IE 7/8/9/）、Gecko系（Mozilla、Firefox以及其它变种）、WebKit系（Safari、Chrome/Chromium）、Opera。由于相关规范和Web开发框架的不断发展，目前要实现相当好的跨浏览器兼容性并不是太难，就看是不是看重这个事情。这说白了是对待细分客户群的态度问题，没有对错，只看投资者的观念和态度。

尊重缺省行为

浏览器的缺省行为（快捷键、鼠标操作和手势、Back/Forward历史管理等）代表了用户在90%以上时间里习惯的事情，网站改变这些缺省行为不仅不尊重用户而且会带来用户体验上的下降，降低用户持续访问网站的欲望。目前互联网信息高度饱和，各种信息获取渠道高度发达，除了内容，用户体验是吸引用户的最重要手段，不可轻视。

顺便说一句，个人认为“在当前窗口打开链接”也是一种缺省行为，现代浏览器都提供了标准的“在新Tab打开链接”、“在新窗口打开链接”的快捷方式，并不需要网站自作主张。

兼顾多种浏览设备

最近三网融合炒的挺热，我个人不太看好智能家电在近期的发展，但是移动互联网已经是最近几年最热门、发展最快的领域，我很高兴的看到广州的一批媒体都走的很前：南周是最早拥抱iPhone等新一代智能手持设备的主流媒体之一，而网易也是最早针对不同手持设备提供多种定制浏览界面的主流门户（这方面新浪落后多了）。

如果在页面的组织上实现了良好的结构化，要实现针对特定设备优化的浏览体验并不难，只要抽掉功能区域，针对特定显示设备重新设计就好。而一旦做到了，会大大增加网站的可浏览时间（毕竟大部分人坐在电脑前的时间有限，而揣着手机出门坐车这类无聊时间不少）。

面向信息重组

这里说的重组包括分享（Share）、聚合（Aggregate）和混搭（Mashup）。现代互联网的信息发布，正在逐步走向细分，信息的原始创造、信息的重组（以便面向个性化的信息消费人群）、信息的评论（通过用户实现信息的自我再创造）等环节会变的越来越专门化，每个媒体都要想清楚自己的核心价值和定位，选择最有价值的方式来强化之。无论怎样，设计良好的网站应该支持自己的信息消费上下游更容易利用自己提供的信息产品，所以应该有API或者RSS一类的内容摘要索引，来方便这种上下游的协同，从而更好的延展自己的市场价值。

说回南周页面的这个小毛病，我觉得有几个值得考虑的问题：

1. 我相信这不是为了防盗版防拷贝，因为根本起不到这个作用，真要盗版盗链岂会被一个快捷键或者右键菜单阻止。
2. 最要命的一点是：针对所有WebKit内核的浏览器禁用了拷贝的缺省快捷键，这无论是个by-design的“特性”还是个bug，都希望能尽快修复。
3. 在拷贝的内容后加上版权和链接信息，这个属于“有时有用”的设计，比如选一段文字拷贝，然后发去微博，这个设计好像还不错；但我仍然不认为用这个取代浏览器的缺省行为是个好主意，这个功能属于页面，不属于作为页面容器的浏览器，跨界的操作总是会带来很多问题的。试试在页面上增加一个分享工具栏？应该会更友好（这个其实也很常见了，EverNote、Twitter等都有这类实现）。

HTML 5 标准的执行编辑是来自 Google 的 Ian Hickson 和来自 Apple 的 David Hyatt。这恰恰是推行这个标准最出力气的两个业界巨头。

目前，WHATWG 和 W3C 网站上的最新版本是2010年2月4日的 draft；Ian Hickson 希望标准文本可以在2012年成为 W3C 建议草案，2022年成为 W3C 正式建议标准。

WHATWG 提出 HTML 5 的基本出发点是构建一个完全开放和自由、更加开发者友好的 Web 应用生态环境，其主要目标是消灭网页上的各种私有专利插件，尤其是和网页富应用（RIA）有关的那些，其中最有来头的是 Adobe 的 Flash，Microsoft 的 Silverlight 和 Sun 的 JavaFX。为此，作为主要策划者的 Google 也毫不犹豫的放弃了自己的插件，例如 Google Gear，而全力在 HTML 5 草案框架内来实现相关的功能。我们后面会看到，正因为这个初衷就包含了对很多其它业界巨头的侵略性，所以它注定不会一帆风顺。

这篇文章试图利用现有的资料粗浅分析以下的几个问题（除注明出处的以外均属个人臆断，请勿轻信）：

1. HTML 5 值得期待吗？或者说，对于开发者和用户有什么价值？
2. HTML 5 有多大的成功机会？进一步的，还要多久？
3. HTML 5 会让以 Flash 为代表的私有专利技术边缘化吗？

Part I HTML 5 的特性和价值

HTML 5 主要引入的变化包括两大方面：HTML 标记语言，和面向脚本的 API。

在标记语言方面：

1. HTML 语法和对应的解析规则发生改变，HTML 不再基于 SGML，浏览器开发者可以开发更适合于 HTML 的解析器，来提供更好的效率、兼容性和错误处理。当然，浏览器应该提供向下兼容的能力。
2. 直接在 text/html 上下文显示 SVG 和 MathML 的能力。
3. 强化的表单元素，包括增加了一些输入类型的支持（例如日期、时间等），和一些更像应用程序的属性（例如输入框的 tab order 全局属性）。
4. 废弃了那些已在 CSS 中完全实现的功能对应的标签，例如 <font> 和 <center>；还有，彻底和 <frameset> 说再见吧。
5. 表单支持 PUT 和 DELETE 行为，以实现对 REST 的全面支持。
6. 通过一组新的标签和属性来支持新的功能，以取代以前必须使用一些私有专利的插件才能做到的事情，这里面最引入注目的包括用于多媒体播放的 <audio> <video> 和用于绘图的 <canvas>。
7. 一组使 HTML 更富语义性的标签：<article> <section> <footer> 等。

在脚本 API 方面：

1. 配合 <canvas> 标签的实时二维绘图，这将使得纯页面脚本的高动态游戏和互动成为可能。
2. 时间精确的媒体播放。
3. 离线数据存储，支持键/值对，也支持嵌入式的SQL数据库。
4. 基于 contenteditable 属性的内容编辑操作。
5. 基于 draggable 属性的拖放操作。
6. 跨文档消息机制提供了一种方式使文档可以互相通信而不用考虑它们的来源域，在某种程度上，这样的设计是为了防止跨站点的脚本攻击。
7. 服务器发送的事件，与新的 event-source 元素配合可以建立页面元素与远程数据源之间的持久性连接，来实现消息 push——而不必轮询。
8. 浏览器历史记录管理以支持 AJAX 麻烦的页面前进/后退问题。
9. MIME 类型及协议处理器的注册（这也是 REST 风格需要的核心能力）。
10. 内置的缓存机制来支持脱机应用。
11. 新的网络 API 支持 Web 应用在本地网络上互相通信，并在它们的源服务器上维持双向通信。

比较明显的是，HTML 5 是一个主要面向开发者的标准，当前 Web 开发者头痛的很多问题可望成为浏览器的标准功能，直接利用简单的标签、样式和脚本即可实现——当然前提是各个浏览器都跟进标准。而不少在开发者中广受欢迎的插件和脚本框架提供的功能都被收编了。这种趋势显然受到这些技术概念的影响：语义网，RESTful，Web 2.0。我个人期待着这些努力能够使 Web 应用开发更加自然、一致和协调。

对于用户来说，又会有什么更好的体验呢？客观的说，不会很明显。对于设计良好的站点来说，用户的体验只会有较小的变化，很多将是不易察觉的小优化；对于设计比较糟糕的站点——我不指望它们能够很快的开始接触 HTML 5 的先进特性。不过一个可以期待的变化，是大屏幕的智能手机上，基于本地存储、内置的媒体播放等能力，可望出现更多基于 Web 技术的强大应用，而不必因为现在先天不足的移动版本 Flash 之类的问题而捉襟见肘。

另外我们也可以看出，对于浏览器的功能的极大加强，而摆脱其它五花八门的插件和非标准化的工具包的依赖，和 Google 关于“一切计算在云端”的模型是高度一致的，Google 在 HTML 5、Chrome 浏览器和轻量级操作系统上的投入是一个完整的战略链条。

Part II HTML 5 的可行性

和 SOA 这样虚无缥缈的概念不同，HTML 5 并不是远在天边的，它的很多技术基础已经存在甚至成熟，所需要的是 Web 应用的服务端和客户端（也就是浏览器）逐步的整合，拿出完整的实现——而其中最重要的，无疑是浏览器。

有了 Google 和 Apple 的大力推动，WebKit 为核心的浏览器势必成为这个进程中的先锋，可以预见的将来，WebKit 将是 HTML 5 事实上的“参考实现”；Microsoft 由于尚未完全评估清楚对其自身战略的影响，所以至今也没有表态，但是“有选择的接纳”将是一个多赢的选择；Mozilla 社区目前表现出了对 HTML 5 的热情，但是由于总体架构设计上的一些问题，它们全面转向新标准将没有 WebKit 那么轻松——当然，一旦社区下定决心，这应该不是问题。

理想状态下似乎一切都很美好，但设想一下，如果 IE 继续无视标准，Mozilla 也三心二意，结果可能是很糟糕的，开发者不得不在两个都很难过的选项中抉择：或者固守老的标准看着 HTML 5 美丽的愿景掉泪，或者花出成倍的代价来做多浏览器兼容性实现。

HTML 5 的工作组从过往历史中已经预计到这个可能的问题，在跨标准、跨浏览器兼容上做了很多的工作，几乎每一个新的功能都包含了自动或者半自动的降级解决方案，从而保证严格遵循规范的网页能够在不支持 HTML 5 的浏览器上得到可接受的结果。这方面的思路无疑是对头的，但是任务也是艰巨的，需要持续的努力才能达到目标。

所以我认为，HTML 5 的技术基础，以它颇有雄心的目标来说，算是非常脚踏实地了，这是一群真正的 Web 开发者弄出来的标准，不会像 SOA 那样，把 WS-* 协议族搞得复杂繁琐几乎没人乐于使用。

至于是不是能够成功，取决于整个业界，尤其是大的 Web 应用提供者的态度，目前暧昧不明的浏览器状况，其实是因为 HTML 5 的杀手级应用还在酝酿（或者说还在暗战），一旦在某几个关键的应用上 HTML 5 带来了至关重要的生产力或者用户体验的提升，那么浏览器的战局就会发生显著改变。在这个领域，Apple 和 Google 无疑能够提供足够的重量级应用——但不是全部——诸如 Facebook、Amazon 之类的重量级第三方的态度将是关键的影响因素。考虑到这些应用提供者先天的开放技术倾向，对于未来我准备抱有稍微偏乐观的态度。

可以预计，今年和明年在几个特定领域（我们下面就要提到的视频播放就是其中之一）会开始第一回合的较量，新生的标准将经受考验——它面临一系列实验室里碰不到的险恶问题；而广大 Web 开发框架已经开始考虑对 HTML 5 的支持（参见这篇文章）。和 HTML 5 正式提交给 W3C 成为草案的时间相当，如果顺利的话，2012年前后将是主流应用和浏览器开始全面转向新标准的关键时间。

Part III HTML 5 的第一批对手

最近 Adobe 已经开始在多个场合进行防御性的宣传，Kevin Lynch (CTO) 强调目前网络视频播放上 Flash 仍然是最好的选择，声称 HTML 5 的媒体播放能力将使 Web 世界 “back to the dark ages of video”，并攻击 HTML 5 的实现将是有问题的，跨浏览器兼容性无法保证。

Kevin Lynch 先生激动的原因很简单，目前 Flash 在 Web 领域应用最广的是前三位是：视频播放、广告、游戏。一旦 HTML 5 的 <video> 标签被普及，前两个应用就和 Flash 没啥关系了，任何网站都一定更喜欢像拿 <img> 标签处理图片一样，拿 <video> 标签来处理视频，Twitter 上的 overboming 朋友用一段生动的描写说明了这种境况：

想象没有 <img> 的世界，如果要看图片，你得用个第三方插件，这东西很慢而且没有标准的方法嵌入页面，你不能随意地复制图片内容，而搜索引擎也没法知道这是个图片或者游戏还是广告，这就是支持用标签取代 Flash “视频”功能的原因。

目前世界上最大的两个视频分享网站 YouTube 和 Vimeo 都推出了自己的 HTML 5 测试，它们实现转换的时间都不长，说明在服务器端进行转换的代价不高——但是它们目前都只支持基于 WebKit 的浏览器，即 Safari 和 Google Chrome，而目前占据最大用户比例的 IE 和 Firefox 都不支持，这是什么原因呢？别忘了，Firefox 是世界上最早宣称支持 HTML 5 的 <video> 标签的浏览器（3.1版本）。

这个问题出在视频编解码器即 codec 的授权上。

目前网络视频分享和播放的事实标准是 H.264，这个标准具有从低到高各种分辨率下良好的表现，对于大容量视频的流播放支持尤其优异，YouTube、Vimeo 还有 iTunes 的缺省格式都是这个，但是很不幸，H.264 标准既不开放也不承诺免费——是的，它目前是免费的，但是专利的所有方有权随时修改授权协议，这种事情历史上发生过多次，如果你不了解，不妨看看当年 GIF 图片格式和 MP3 音频格式上发生过什么故事。

另外一个被 HTML 5 工作组考虑的视频编码格式是完全开源和自由的 Ogg Theora 格式，这个倒是符合 HTML 5 “完全开放和自由的 Web” 的理想，但问题是，这个格式还很不成熟，问题很多，对于大容量视频尤其表现糟糕，所以短期内没有哪个真正营运的视频网站会采用。

所以目前的情况是，因为 H.264 的授权，Opera 和 Mozilla 都不愿意实现它（前者是成本问题，后者则是源码分发协议问题，Firefox 已经支持了 Ogg Theora 格式），事实上 Chrome 的 开源版本 Chromium 的缺省分发也不具备 H.264 实现（以二进制方式分发的 Chrome 则包含，因为 Google 得到了授权），Safari 和 WebKit 的 Mac 版本则没有问题，因为 Mac OS X 的 QuickTime 内置了已获得授权的 H.264 实现。

来自 Google 的 HTML 5 工作组执行编辑 Ian Hickson 认为有两个可能性来最终解决这个问题：要么 Ogg Theora 编码器不断优化开始实现商用，要么 H.264 逐步开放（有个潜在竞争者毕竟是好事啊）。他采取的策略是从 HTML 5 草案中移除关于视频播放的 codec 部分，而把这个问题交给市场去做出选择，他认为最终胜出的一方将是（参见这里）：

• 无需费用就可以实现，而且可由任何人分发
• 拥有可用的硬件解码器
• 使用广泛以弥补额外的专利费用
• 拥有足够高的“每比特质量”（quality-per-bit）以处理大容量视频应用

这个看似麻烦的问题，最终的解决方案倒不少，最坏情况下就是 Google 或者 Apple 拿出一个格式，开源它就行了，别忘了 YouTube 和 iTunes 都是这个领域的重量级玩家。

综合收益和可行性之后，我认为最终 HTML 5 相关标准会将 Flash 逐出视频播放这个领域，而这并不意味着 Flash 就完蛋了，它应该更加专注于互动性、数据性更强的应用领域，比如游戏和教学，还有仪表盘一类的企业级应用，其优势在于工具和已有的开发者群体，Adobe 为了 Flash 而攻击 HTML 5 是不明智的，他们应该好好改进和强化自己的 Web 创作/开发工具——就像当年 Macromedia 做的。

所以与其说使 Flash 边缘化，还不如说：Flash，你该干正事了，作为一个全功能的开发平台，就守着个视频播放应用难道不害臊么。。。（大雾

这个事情的背景是，我最近在和一个年轻有冲劲、但是比较内向（也就是说，和外界的交流不多）的团队一起工作，课题是一个服务型的网站，除了完成软件产品之外，我还希望能够在开发方法和流程、甚至氛围上能够有个提升。

在工作开始之后不久发生了一个问题，这个团队中的某个小组，只有一个网页设计师，但是有好几个熟悉J2EE后台的程序员，结果他们都在等网页设计师一个个的出HTML原型页面，于是有了类似这样的对话：

问：为什么不自己出HTML？难道你们不会？
答：我们会，但是我们出不了美工（注：这是他们对网页设计师的称呼）那种页面，我们的HTML最后还会被美工改的面目全非，出现一大堆问题，我们还要重新写业务逻辑的部分。。。
问：为什么不约定一个HTML线框（wireframe），然后各自去做内容和样式的部分？
答：那是什么？

经过了解，网页设计师很久很久以前就曾经提出用 div 来定位的建议，但是由于不够系统也没有坚持，所以没有成果，结果这个团队2-3年以来一直是用老式的 table + gif 来做页面框架，作为面向服务的EIP门户网站，其元素和结构都相当复杂。

那时候我只是大致的知道，HTML的进化方向在于语义的强化以及内容和展现的分离，这在企业架构上会带来更好的模块化，对内容的重用和聚合都有利，而具体到 <div> vs. <table> 的问题，要说服一个工作了多年的团队放弃看上去没有什么问题的模式并不简单，况且对于目前大部分需求来说，<table> 确实看不出有啥不妥——而 <div> 定位更像一种“结构化写作”，就好像和 Word 比的 TeX 一样，是有一定的学习曲线的，他们的组长就问过我：我用 DreamWeaver 几分钟就可以完成一个复杂页面的 <table> 布局，用 <div> 好像找不到什么可视化工具。。。

我花了一些时间做了准备，然后要求小组的成员仔细研究这份文献（这是Scott Design的Bill Merikallio和Adobe的Adam Pratt两位专家在2003 Seybold大会上的主题演讲，拥有有趣的插图、精辟的文字和详实的实例）：

Why tables for layout is stupid: problems defined, solutions offered （中文翻译）

这篇文章中提出使用 div 的优势包括：更小的页面size（载入变快、节约流量），更容易修改（页面布局和样式），更加“搜索引擎友好”，更容易制作移动设备版本的页面——我想补充一点：更容易模块化以及随之而来的协作流程上的灵活性。

然后我们进行了多次的讨论，并在一个小的模块中进行了尝试，具体做法是：

1. 做出只包含页面内容模块的线框HTML，产品设计师、页面设计师和程序员一起做，很快的确定下模块所需要的所有页面框架，里面是一组 div 标签，按照业务的重要性和嵌套结构排列。
2. 页面设计师根据这个线框HTML制作对应的样式表，包括用于定位的样式表、用于外观描述的全局样式表和页面样式表等。
3. 程序员完成后台代码编写，目标是生成各个 div 里的内容。
4. 页面设计师输出定位样式表、全局样式表等阶段性里程碑时就给程序员去验证，最后再合并成果做模块级的验证。中间有过一些问题，两边的版本出现了差异不过很快就修复了。

上周五进行了一次总结性讨论，下面这些体会来自小组成员：

• 网页设计师：页面更小和更干净，原先的主页仅HTML就有近150K，改造之后只有80K左右。
• 程序员：进行布局的调整更快一些，更专注于内容本身的构成；被强迫进行“这些内容可能会以完全不同的方式被展现”，开始不太习惯，但是一段时间之后发现很酷！
• 产品设计师：可以更早的预览内容和业务流程。
• 需要一套标准化的规范，定义线框HTML的标准元素；需要一个页面元素库来缩短构造常用模块的时间。
• 沿着这条路线继续下去，网页设计师和程序员的沟通会更有效，因为把各自最专业的部分一定程度上屏蔽掉了，线框HTML是双方易于理解的概念交集。

老实说，有些发言甚至超出我的预期。

下面是我自己的感想：

当一个团队决定从一个技术/机制/方法转向另一个的时候，大凡有两种可能：

1. 被迫的、快速的切换：比如，某产品被证明无法提供所需要的功能或者性能或者可定制性，经过验证的另一产品是可行的替代品，那么无论多大的代价，都会立刻进行切换。这种事情没人喜欢，但是也没啥更好的办法——谁能保证自己的技术决策永远正确？
2. 主动的、渐进的切换：一个比另一个具有一连串微小但实在的优势，但另一个也能完成几乎所有工作，这时候启动切换是非常难的，因为没有足够的动机和动力。对这种情况来说，合适的时机（例如：某个激起大家思考的问题，规模恰当的项目，找到称职的实验小组等）和强有力的evangelist是必要的基础。

（写到这里感觉有点像国际象棋里所谓的战术派和局面派，前者是一锤定音的战术组合打击，后者靠的是逐步积累微小但是实在的局面优势——中心兵型更优、双象、开放线控制等等，哈哈！）

其实我同意，<table> 并不是不可用，但是当出现机会的时候，要毫不犹豫的推动这类渐进式的技术变革，而不必太在意当前的投入产出比，只要预算许可，越早越好，收益越多，尤其还有些习惯性的问题是需要时间去逐渐解决的。

托推友 @wangpei 的福看了月光博客上的“互联网岁末大恐慌”这篇文章，引用一段话来说明状态：

2009年的最后一个月，广电部和工信部联合在中国互联网领域引发了前所未有的恐慌情绪，先是大量关闭BT下载网站和视频网站；接着整顿CN域名，禁止国内个人域名注册；接着未备案域名停止解析；论坛被要求重新备案；接着是关于“境外注册的域名将不得用于开展中国业务”和“境外域名将实施白名单制度”等传闻，让这种恐慌也在数亿互联网用户中蔓延开来。

想起昨天早上我看到关于所谓“境外域名白名单”的传闻时候，即使自认为是行业老油条的我，也不得不承认我恐慌了、愤怒了、甚至有点狂躁了。不过等我冷静下来想了想，就发现其实事情并没有那么可怕，Internet 作为人类进化的车轮之一，没那么容易倒塌，即使在相当神奇的国度里。

简单地说，我基本同意月光博客那篇文章的主要结论，但是有些细节我想做些说明。

首先，目前的整顿行动，直接受到影响的主要是所谓的“地下互联网经济”，所有正常的创业团队是不会不去注册一个法人的（是，没有美国那么方便，但是也不算很麻烦），更不会顶风作案不备案而上线——即使在美国，不注册而进行经营活动也是不被法律支持的。

当然，这并不是说没有影响，但不是“互联网创业者大量失业”，而是下面这类更加深远的影响：

• 一些长久以来就存在的政策黑洞会显露出来，例如基于 Internet 的经济规模和税收问题，稍微处理不好就会把国家叫了多年的现代服务业转型、两化融合等政策扼杀掉。
• 信息管制的加强会动摇一部分精英在国内创业的信念和决心，要知道，本来国内的创业环境就不好（相对发达国家尤其是美国而言），现在在国内创业的互联网精英都不是出不去，而是看重国内的市场的某些特点，或者有自己的环境、资源原因而没有出去闯荡；信息管制和对互联网基础环境的随意践踏（例如动不动关闭机房几天）会打击他们的信心，把他们赶去竞争对手那边并可能最终毁掉他们的人生机会。

其次，我要谈谈对于那个关于境外域名管理的传闻的看法。

1. “境外注册的域名将不得用于开展中国业务”或者“境外域名实施白名单制度”，这些话本身是一些管理性的要求，技术上怎么实现？凡是国内根DNS上没有记录不进行解析？这个只要使用国外的DNS就可以绕过，而且所有跨国公司都必须在国内注册自己的域名，产生的费用谁来承担？这算不算贸易保护？

2. 关于境外域名的备案，如果开展这种备案业务，是不是 cnn.com、bbc.com.cn 这些域名通过备案了就保证可以访问？不能简单的认为政府可以耍赖或者强行说备案不通过，事情没有那么简单。是，你可以就是那么操纵了这个结果，但这意味着在国际环境中做了一个强硬举措，迟早要在别的地方作出让步——除非说无所谓，回到闭关锁国、“自给自足”的时代（还别说，可能真有人觉得这样更好）。

3. 就算以上这些真的很强大的就那么做了，也就是说，只有政府选择的境外域名可以解析，别的都不能解析了，境外的DNS也封光了——这还是得不偿失的，因为真正要反党反政府的人大都在国外有资源，而且会指导他们的信徒采用IP一级的代理（VPN、SOCKS等等），只要境外有一个可连接IP提供代理服务就行了。嗯，你会说，一般老百姓哪会用代理啊，还不是就被封住了？没错，但是真要反党反政府的人都不是老百姓，而且他们会在网络以外的渠道去煽动老百姓（多了很多煽动的理由啊）。

4. 最狠的，就是大中华局域网的降临，所有境外IP都被封锁（这在技术上非常简单），最多只有白名单上的可以访问，这个绝对有效，但是代价就是本文开头说的，中国将被人类进化的步伐甩开，所有不愿停止进化的人，会使人肉翻墙成为潮流，直到。。。

所以说，所以说。。。这次我选择了乐观，所谓内联网（我喜欢称之为大中华LAN）大概类似于今年早先时候某个绿*的闹剧那样，还没开始就会结束吧。。。

最后，牺牲掉的是无执照的在线资源分享网站和海量的个人网站，他们的存在极大的活跃了中文互联网世界和创造了大量的信息价值（以及垃圾），绝对配得上我们的敬意和怀念——但我总觉得，一般性的个人网站还会回来的，至不济还可以去新浪开博、百度开吧嘛。

p.s. 当我最早开始写博客时就下定决心无论如何不谈政治相关的话题，这次破戒了，不过破就破了吧，任何事情总有第一次。

YouOS comes from the MIT Labs and contains an email client, Chat Function, RSS Reader, and Text Editor. YouOS is a web operating system that lets you run diverse applications within a web browser. Small applications like sticky notes or clocks. Large applications like word processing, mp3 players, and instant messaging. Even better, it’s very easy to tweak an existing application or write your own.

The Future of Computing

– from Slashdot

Dune and StarWars Compared Very interesting…

– from del.icio.us/popular

– from Slashdot

What I’m calling Search 2.0 are actually third generation search technologies. To explain the generations:

• First-generation search ranked sites based on page content – examples are early yahoo.com and Alta Vista.
• Second-generation relies on link analysis for ranking – so they take the structure of the Web into account. Examples are Google and Overture.
• Third-generation search technologies are designed to combine the scalability of existing internet search engines with new and improved relevancy models; they bring into the equation user preferences, collaboration, collective intelligence, a rich user experience, and many other specialized capabilities that make information more productive.

I extremely like this design… does any geek want to migrate it to MT 2.6… MOST WANTED!!!

Here are some interesting related info:

Slashdot | Slashdot CSS Redesign Winner Announced

There’s more discussion of the pros/cons of the new design in the “100 Best Tech Products” thread at Slashdot.

Sure we have not-so-good point of view.

转眼间，World-Wide Web诞生已经超过了十年，回头看去，似乎那个时候拿着Mosaic浏览器看到的东西，和现在Google Calendar这样的东西是那么的不同，这种变迁就像Web的诞生本身一样，带来了理念、架构、基础技术的潜在的巨大变化可能，面对各种纷繁的概念和炒作，我们有必要自己好好用用自己的脑子，来看看究竟什么是Web的未来。

Part I Web的过去和现在

Web的核心是什么？一般认为是HTML和HTTP，也就是超文本置标语言HyperText Markup Language和专门设计来接受和传输它的超文本传输协议HyperText Transfer Protocol。Web诞生伊始就已经具备的、目前也仍然是核心的特性就是：超文本(HyperText)，这是从SGML等更早期的学术成果发展而来的一种文本格式，其最核心的特性是： 1、统一资源定位：使用标准化的体系来命名和寻址特定的资源，这种资源可以通过任何支持HTTP协议的机制访问。 2、超链接：允许使用标签把不同地方的HTML文件链接起来，通过点击来快速的跳转。 3、多媒体：允许使用标签嵌入图片(后来通过扩展机制又引入了音频视频等资源)。 另外，Web最初主要用于学术交流，所以HTML也提供了一定的排版功能。

如果要从上面的特性中找出一个最核心的，毫无疑问的应该是超链接。正是超链接改变了人们使用信息的方式，是的全球范围的信息互联、共享和快速传播成为可能。最早的Web也就是这样了，没有什么更多的东西可以挖掘。

很快的，使用Web的人们开始探索一种可以一边看超文本一边进行交互的方式，BBS等网络社区开始建立，这个时候的关键技术是HTML Form和后台的CGI，也就是在后台书写的一段程序，能够接受HTML上一些用户填写的数据，经过处理再动态的生成新的HTML页面反馈给用户。不要小看了那时候简陋的CGI BBS们，它们一下子把Web从一个网络超文本库往应用程序这边拉近了好多，后面就开始路路续续的产生了ASP啊JSP啊PHP这样一些简化CGI编程的技术，再加上InterDev、Dreamweaver这些IDE工具的大行其道，顿时，所有的程序员几乎在学会应用程序开发之前就已经可以写出交互式的Web页面了，Web变成了新的应用平台。这是上个世纪最后几年时候的事情。

作为新兴的编程平台，基于Web的开发有了非常迅速的发展，但是很多程序开发上的问题在这个时候也开始暴露，这里说几个最突出的。 1、缺乏标准。不仅编程接口没有标准，随着厂商加入大量自定义的标签，搞得连HTML本身的解释也没了标准，开发者要为不同的浏览器开发不同版本的页面。 2、代码结构混乱。往往是表达内容的文本，和表达交互的脚本，还有表达样式的标签混杂在一个文件中，比面条还面条。 3、交互方式受限。HTTP最早设计目标仅仅是针对超文本的传输，根本没有考虑应用的问题，所以它只支持无连接、无状态的模式，这使得复杂的交互要在页面上实现不得不自己另外想办法来保存和维护中间状态，这使得在线交互的设计变得非常困难。 4、展现方式静态和单一。HTML所有的显示样式是高度分散在页面的各个部分中，所以修改起来非产困难。而且HTML本身只支持简单的输入UI控制，像产用的树型结构、Tab结构等都需要另外实现。 5、程序调试困难。分布式的代码使得一体化的调试很难实现，而分布式的调试又具有很高的技术要求。

所有这些，最后导致的结果就是：开发效率低下，应用功能受限，响应效率难以令人满意。直到几年前为止，几乎没有基于Web的killer级的应用出现，网上最成功的应用是搜索引擎以及类似的以信息检索为核心的应用，罕见复杂的交易和生动的用户界面，更不用说大型企业级应用了。在这个过程中，业界提出了不少的解决方案，影响比较大的包括： 1、使用样式表来分离样式和内容。 2、使用MVC模式来分离展现和控制逻辑。 3、使用嵌入式程序插件来提供有状态连接模式(包括微软体系的ActiveX和Java体系的Applet)。

说起来，我们也是最早的吃螃蟹者之一。我们在1998年开始开发在线交易系统的时候，几乎碰到了上面的所有问题，我们当时的解决方案：前端采用Java Applet，按照传统应用程序的方法来设计交互流程，实际上只把浏览器当作一个容器而已。这个也带来很多问题，例如Java Applet的分发(记得那些个Applet大约几百K)。当然，后来我们也改变这种方式，转向MVC模式的页面开发。

2004年前后，一些新的技术和思想开始崛起，给Web带来了全新的希望，现在就让我们进入这些激动人心的新领域，看看Web的未来会是什么样子。

Part II Web的未来

最近的一些新的技术发展给Web的应用前景带来了新的希望。我们从几条线来描述这些新的发展(基本按照发展时间而不是其他顺序排列)。

一、样式表：真正的出版级输出控制

层级式样式表(CSS)诞生比HTML还早，但是真正被业界接受成为标准的进程到现在也还没有完全完成，这里面有些技术问题，但是更多的是商业利益——也就是著名的浏览器战争(War of Browsers)。但是随着W3C CSS标准^[1]越来越完备，以及Mozilla Firefox这样的100%标准化浏览器的普及，即便是MS这样的巨人，也不得不慢慢的靠向标准，虽然还是坚持自己的一些东西，但是MS毕竟已经同意并且实际上实现了绝大部分的CSS特性，现在不兼容网页(指在不同浏览器下现实效果有明显差异的网页)越来越少就是一个明显的迹象。

CSS目前能够提供与内容和交互脚本完全独立的样式控制，使用独立的CSS文件，可以给同一个HTML页面进行不同风格的装饰(decorate)，快速的切换显示的效果。伴随着blog的风行，这种“模板”技术已经广为大家所熟悉。CSS还提供可以集中管理的版式管理，包括对绝对定位、比例定位和相对定位的良好支持^[2]。现在的HTML编写者可以很方便的切分页面区域，然后通过一个集中的CSS文件来管理这些区域的位置、大小、样式、显示/隐藏等。CSS还可以实现非常结构化的交互构件，例如下拉列表、树型列表等。

CSS成熟的巨大意义在于：Web上的内容和样式可以非常结构化的分离，这就允许编程者可以针对内容和样式分开设计不同的处理模块，极大的提高架构的灵活性。

二、基于RSS/XML的内容聚合：新的超链接系统

关于这个主题，我在2004年写了一篇专门的文章进行了探讨，可以在我的blog上找到这篇文章^[3]。

简单的说，RSS/XML的聚合提供了一种最简单因而也是最灵活的方式，使的跨应用的内容/数据交换成为非常容易的事情。

三、面向服务架构(SOA)：应用体系架构和产业链的革命

这是另外一个巨大的话题。我会在以后更深入和大家交流。这里只提出一些关键的要点： 1、SOA不是架构也不是产品，而是一种方法论。 2、SOA不仅仅是Web Service技术(虽然Web Servce确实是它的核心)，它要求对业务模型和产业链进行调整，以适应不同层次的服务要求。例如一层是提供基础设施服务(主机、网络、安全等)，一层是提供技术平台(数据库、应用中间件等)，一层提供基础公共构件，一层提供业务公共构件，一层提供流程组装和个性化，等等。每一层有自己的开发、服务和运维体系。 3、SOA的核心包括服务的注册、组装、寻址、请求，而服务接口的中立、灵活、互操作性是其主要的难点。 4、SOA尚未标准化。涉及到诸多环节还没有达到令人满意的互操作性，这使得SOA的蓝图仍然飘在空中，远未落到地面。

SOA的价值勿庸置疑，它相当于上面第二点的超集，能够把所有软件应用服务像内容一样通过服务接口进行随意的分发，实现最大限度的重用和整合。那时候使用应用服务就像点击新闻链接一样的无缝，无疑这是应用集成的最高境界。

顺便说一句，关于SOA，上面只是讨论它的技术实质。而SOA很可能会带来产业链的革命——如果它真的能够实现的话，关于这个还有很多有趣而令人兴奋的话题，我们就留到下次再说吧。

四、富客户端(RIA)技术：扩展Web应用范围

前面说到的Web页面限制了应用的范围，难以建立大规模的、包含丰富复杂交互操作的系统。RIA技术应运而生。目前主要产生了两个大的分支：基于脚本和基于交互式插件。前者的代表是AJAX的各种实现，后者的代表是各种Flash RIA解决方案。

AJAX的意思是：Asynchronous JavaScript + XML。这个名字来源于AdaptivePath公司创始人Jesse James Garrett在2005年初发表的一篇文章^[4]，这篇文章系统的阐述了为什么以及如何使用XMLHTTPRequest对象来实现Web页面的异步请求和处理(这里“异步”的意思是不需要同步刷新整个页面)。AJAX技术的核心是使用页面内置的javascript，利用浏览器提供的XMLHTTPRequest对象来接受远程的XML数据，然后使用javascript来修改页面上的显示和行为。这种方法的优势在于轻量级和安全性，完全使用浏览器内置技术带来最低的客户端代价。但是其问题也很明显：首先javascript的编码效率很低，复杂的逻辑需要非常多的代码来实现；其次javascript本身不是结构化的，维护、调试都很不方便，开发成本比较高；再就是著名的浏览器兼容性问题，一般来说需要针对不同的浏览器编写不同的AJAX库，否则很难保证兼容性。AJAX拥有非常多的开源工具包，例如比较出名的Bindows；厂商也有一些比较完整的开源实现，例如Adobe的Spry Framework for Ajax。

另外一个技术分支，也就是以前端Flash展现为主的RIA，代表者是Adobe/Macromedia的Flex技术和类似思路的开源实现如Laszlo。它们的实现方式都类似，就是通过编写一种特定的描述语言，然后在服务器端处理这种描述语言生成动态的Flash componennt，然后在页面上用这种componennt处理用户交互，需要与后台交互的时候，这些componennt也是用远程XML数据或者服务接口来访问后台。这种实现最大的好处是浏览器无关，只要安装了Flash Player，任何浏览器上的表现一定一致。问题嘛，当然就是这个Flash Player，而且要注意，这是一个厂商专有技术，跟完全开放的javascript性质是完全不同的。由于后面的这个差异，现在越来越明显的，Flash-based RIA很可能将被更多的用在企业内部应用中。有兴趣的可以自己动手试一试。我们也对Flex有过初步的研究和尝试，有兴趣的也可以自己试一试^[5]。

针对这些技术本身的问题，可以看到厂商和开源社区都在努力提升自己的产品，包括开发生产力、规范化等努力都不断在持续着。值得一提的是最近一个比较重要的方案，来自AJAX最实干的实践者——Google。Google的Gmail、Google Suggest、Google Maps、Google Calendar、Google Spreadsheet、Google Notebook都是AJAX技术和RIA体验的典范。最近Google开源了他们的AJAX工具包^[6]，其采取的是一种全新的设计，允许开发者使用完全的java环境进行开发调试，最后工具包自动把java代码编译为AJAX的Web页面和javascript脚本。这是一个非常sharp的想法，具有非常好的潜力。

RIA是是非常新的技术体系，是Web页面和传统应用开发进行融合的产物。其深层包含了SOA的思想和服务/内容、展现、行为进一步拆解的编程模式。应用RIA技术，绝对不是学会javascript和一两个AJAX包，或者学会Flex语言就可以的，而是需要对整个开发生命周期作出规划调整，这里有一个很好的例子来自Macromedia的Flex社区，可以参考^[7]。

RIA技术的价值主要在于控制和展现层的丰富化，其使命就是突破传统浏览器静态、无状态的交互限制。最终实现把桌面应用分布化扫清架构障碍。

Web世界的诺查丹玛斯大预言

综合以上的4大领域，我们可以估计得到，未来的Web会具备的特性。

1、可以和桌面应用相媲美的交互性。支撑技术是：RIA。 2、内容、样式和交互分离的设计成为主流。支撑技术是：CSS、RSS、Web Service。 3、高度的可整合，每个网站都可以很容易的变成后台服务的提供者，向其他网站提供内容和服务。支撑技术是：RSS、Web Service。

这些只是技术问题。大家可能都看了Google Calendar和Google Spreadsheet，难道Google只是希望证明他们的AJAX能力很强，能够把在桌面上为人们所熟知的应用搬上Web页面么？才不是呢，仔细研究其中蕴涵着的在线协作(collaboration)和社会化软件(social software)能力——要注意，目前Google对这些特性还是有所保留的——就可以知道，这是真正的应用模式的革命。所以未来的Web所有的技术革新其实都是为商业模式(biz model)服务的。这里有两篇非常精彩的文章可以帮助大家理解新Web环境下技术和商业模式的关系^[8][9]，至于这个具体的讨论，我想也放到以后来谈吧。这篇东西已经太长了，就此收尾大概还算来得及吧。

如果对于本文提到的技术和问题有兴趣的，可以选择相关的一些资源作进一步的研究。

[1] Cascading Style Sheets(W3C) [2] Learn CSS Positioning in Ten Steps [3] Internet时代的出版：从猫扑和Slashdot到内容集成 [4] Ajax: A New Approach To Web Applications [5] Ragnarok Studio: Macromedia Flex Starter’s Kit [6] Google Web Toolkit [7] Case Study: The Development Life Cycle of a Flex Application [8] Web 2.0 Startup – The Business Model [9] Web 2.0 编程思想：16条法则

[sms] Web 2.0 Battleship Game

GoogleMail Remote Command

– from del.icio.us/popular

Nintendo Learns from Mistakes with GameCube

Display System That Knows Who You Are

– from Slashdot

– from Slashdot

How to create an internet radio station | Poromenos’ Stuff

Intelligent Life 2006 | From A to Zzzzz

– from del.icio.us/popular