—— 本文刊登在《程序员》2009年6月期

最近网上再度兴起了CSS布局和Table 布局的争论。我最初颇有些不以为然：我原以为CSS 布局的意义早已深入人心，却没想到还有这么多设计师及开发人员持有异议。

静下心来看罢大家的讨论，一番细想，觉得原因可能有两个方面：

一方面，IE6阴魂不散，让Web开发成本居高不下。网上曾经有一个统计，数据显示Web开发人员针对IE6的投入/产出比是最低的。相信大多数前端工程师都有被IE6折磨得咬牙切齿的经历。与其那般痛苦的用CSS布局，还不如用table 来的爽快方便。

另一方面，我发现前端工程师们越来越务实和注重效率。CSS2以及CSS3的诸多新特性迟迟未能广泛普及，而Web标准布道者们所津津乐道的CSS的优点，在照进现实时又经常会遭遇妥协。尽管我一直以Web标准布道为己任，但也不得不同意：table的浏览器兼容性是最好的；table 布局对于设计师来说更容易上手。 就国内环境而言， table切图依旧是制作门户网站专题或者电子商务网站促销页面的最常用方式，存在即有它的合理性。

所以，我们在推崇CSS布局的同时，无需为了证明它的优越性而把table本身贬得一文不值。日常开发中，也无需激进得完全抛弃table。table本身有语义，该显示数据表格的时候就应该使用<table>；在开发过程中，一些需要权衡成本的场合用table+css的布局也未尝不可。在这方面，很欣赏google 和 facebook 前端工程师们的务实做法。大家可以去关注下facebook 上常见的带半透明阴影的弹出对话框，就是使用<table>来制作的，同样非常的精妙。

这一番的争论，结合近年来Web标准的发展，让我开始思考Web开发中改良和改革的区别。

XHTML 2试图直接进化到XML，宣布与HTML的决裂。这曾经让我这个传统的HTML开发者感到恐慌。而当我看到WHATWG组织提出HTML5(最终被W3C认可)的时候，它的温良的改进让我感觉亲切得多，事实也证明，HTML5正越来越向我们走进。而Douglas Crockford甚至觉得HTML5都太猛烈了，提出了HTML 4.2的改良方案。

再看JavaScript， ECMAScript 4 将JavaScript 改得天翻地覆，所幸技术委员会在最终阶段回归理智，重新提出的向下兼容的ESMAScript 3.1 显然得到更多真正战斗在一线的开发人员的认可。

改良，而非血淋淋的改革，也许才是推动技术发展的更实际、更合情合理的方式。Web标准的演进是如此，产品或项目的升级是如此，甚至社会制度的建设亦如此。

首先明确几点在文中所需要用到的概念：

注：这些概念为作者自定义，仅用于本文。

引用:

关于同辈元素是个非常关键的词，这里还需要详细解释一下。

在这个例子中，div#a与div#b并不是“同辈元素”，只有像div#b和div#c这样拥有同样父体div#f的的元素才能叫“同辈元素”。

引用结束

接下来看看这五条法则：

法则一：同辈元素定位方式相同，且无z-index设置时，html靠后者居上。

法则二：同辈元素同为动态定位时，且有z-index设置时，z-index值大者居上。

 猛点这里测试

法则三：同辈元素定位方式不同时，动态定位居上。

猛点这里测试

法则四：非同辈元素，任意一者及其祖元素不具备动态布局时，html靠后者居上。

猛点这里测试

法则五：【重要】非同辈元素，任意一者或其祖元素拥有动态定位时，同时各自向上寻找动态定位的祖元素，并分别从中拿出具备最高级别的祖元素（或其本身）进行比较。 

情况1：子元素的z-index无论多大，父元素大者居上。

情况2：父元素居下，子元素也可以居上。

情况1、情况2结合扩展比较。

猛点这里测试

其实前四点都是基础，只有第五点比较难于理解，这里详细解释一下：

在这个例子中，我们来比较div#a_inner5和div#b_inner4的层叠关系。
到它们所共同拥有的祖元素div#ab的下一级为止，div#a_inner5的祖元素包括：div#a,div#a_inner1,div#a_inner2,div#a_inner3,div#a_inner4；div#b_inner4的祖元素包括：div#b,div#b_inner1,div#b_inner2,div#b_inner3。
然后分析它们的祖元素中具有动态定位的：div#a_inner5的祖元素中含有动态定位的元素有：div#a,div#a_inner3；div#b_inner4的祖元素中含有动态定位的元素有：div#b_inner3。
然后再拿出最高级进行比较：div#a > #div#b_inner3。

父元素居下，子元素也可以居上的情况，则是利用非同辈元素在祖元素具备动态布局时，其比较已经与position:static无关，而其祖元素却可以通过html的位置来进行比较。

引用结束

当然，有时候还存在特例，比如flash、比如ie6中的select无法遮住，这些都属于异常情况，大家可以自己搜索一下相关文章。

整合了 ucenter就等于整合了整个php界的所有php程序。

一、功用：
不对，何止整合了整个php界的所有php程序，而是整合了 ucenter就等于整合了所有的asp/asp.net/php/jsp等其它语言的所有web应用程序。（因为ucenter client的api开发包，dz会推出其它语言版）

而且所有整合的程序同步登录，同步退出，同步修改密码。最终用户可以通过它轻松通行在各个应用之中，无需重复登录、注册、退出

一个id可以出入一个站内的所有程序，如cms和bbs,也可以一个id出入www.a.com和www.b.com及www.c.com

a.com的用户可以和b.com的用户互发短消息pm，a.com的用户可以和b.com的用户加好友。

而且可以实现站内信(pm)和其它任意站的任意程序的站内信(pm)互通。

可以实现www.a.com与[url]www.b.com及[url=http://www.c.com]www.c.com[/url][/url]共享一个用户库，www.a.com的用户可以给[url=http://www.b.com]www.b.com[/url]的用户pm短信.

用户组与discuz不对应的问题也得到解决。因为一般应用程序的用户组是单独的一个应用，和discuz再没有关系，而是和ucenter有关系，而ucenter没有用户组的概念。

二、整合方法：
如果单说整合用户的话，整合时应用程序的改动也非常小，原数据库不用动，原写cookies的代码不用动，原写数据库session的代码不用动，原来的程序不用怎么动，只需改动以下4个文件：

longin.php  register.php  logout.php  修改密码文件.php  （忘记密码.php不用动，用原来的就可以）

4个文件中加上和ucenter api通信的语句和逻辑结构。

另需要针对ucenter新增加一个文件uc.php，这个文件就是应用程序接收ucenter传来的指令并执行的文件。而且他利用p3p技术实现反向登录a.com或是同时反向登录a.com/b.com/c.com的dedecms或是phpcms或是任意所有程序。

共计改4个文件，增一个文件。

如果要是整合站内信pm,好友，头像等功能，思路与方法和整合用户类同。

另外有一点，在不同的系统之间注册的用户，在第一次登录这个从来没有登录过的系统时，会让激活。借用这个激活，可以让用户完善在本应用程序中的资料，如企业注册资料。资料不完善，不可以激活。

如在bbs注册一个用户test,第一次来到b2b的程序中，这时，并不会自动登录，而是要求用户激活，而test在bbs注册时填的字段与b2b中要求的不同。这时让用户完善资料。第二次来就会自动登录。

三、 uc原理：

以用户登录为例介绍，其它注销，改密码，消息，头像，好友均类同。

1.
从用户xxx在某一应用程序的login.php，输入用户名，密码讲起。
先用uc_user_login函数到uc server验证此用户和密码，如正确，则写入session,写入cookies，并更新应用程序会员表中的登录ip，登录时间。用户感觉不到这个过程。
2.
然后通过uc_user_synlogin通知uc server 用户xxx登录成功,这个过程可能使用ajax，用户感觉不到通知过程。
3.
uc server收到这个消息后，马上命令手下，把xxx登录的消息，像令牌环一样，发给所有愿意接收（后台中那个是否开启同步登录）这个消息的其它应用程序。其实就是带参数访问一下各应用程序的uc.php,用户感觉不到这个过程。
4.
各应用程序靠api下的uc.php来接收uc server发来的消息，并对uc server言听计从，让干什么就干什么。现在，收到让xxx用户在你的程序中登录的命令，马上执行。
并写本应用程序的session，并且使用p3p, 写入相同域或不同域的cookies.  用户感觉不到这个过程。

5.最后所有和uc整合的程序，xxx均登录成功。用户从www.test.com/bbs登录后， 跳到www.test.com/news同样显示登录。因为bbs 和news系统在后台均已登录。

6.应用程序与uc server的会话结束。

得益于uc设计的精巧过程，整个过程，用户完全感觉不到ucenter的存在.这是整合程序历史上的创新。完

图形化按钮，就类似这个样子的：

当然，它其实就是一张图片而已。这样做纯粹是为了好看。这里探讨的不是怎么设计这种按钮，而是怎么在网页里把它做出来。这里要提几个要求：
A. 语义化。如果这个按钮叫“完成注册”，就要在HTML中写出这四个字，以保证只读HTML的情况下也知道这个按钮是什么文字。
B. display:inline。用display:block可以很容易的调整大小。但是如果一横排并列两个按钮，就比较难解决。用float?不好。万一我需要两个按钮并排，且居中，用float会增加更多额外的代码。
C.理所当然，跨平台兼容性。所以inline-block的想法，在IE6上就行不通。

有几种方法可以做这种按钮：
1. 用image类型的input标签，或是button标签。这样做最大的问题是，必须在HTML里引用图片地址。我个人是倾向于不要将修饰图片地址放在HTML代码里。结构和表现要分离嘛。此外，用button环绕img，你会惹一堆布局上的麻烦。

2. 用a标签，CSS加背景。这种方法挺容易。但是有几个问题：
a) 对inline的a标签设置高宽，你会遇到一堆麻烦事儿。
b) 此外，为了达到要求A，需要在a里面写入文字，并且将文字隐藏掉。这里如果用text-indent的话，就不能用inline了。另外一个方法是vertical-align，但是，这个属性基本上被我废止。原因是vista里，用微软雅黑及vertical-align，你会遇到很可怕的事情。记住要求C：跨平台兼容性。
c) 用a标签，你还得写JS来提交表单，麻烦。

3. a标签环绕图片。这个同样不是太好，理由在1和2里都有讲。（但它倒是可以满足要求B：display:inline）

4. 用buton类型的input，加CSS背景。这种方法看上去是可以满足要求A和B。关键的问题是：在保证跨平台兼容性的同时，如何隐藏掉button的文字。

我这里给出一个比较好的方法：

解释一下：在FF3和Chrome中，将按钮的text-indent设为-3000px，就可以将文字隐藏。但同样的设置在IE下，会导致按钮本身也跟着跑到-3000px的位置去，除非按钮被声明为display:block（但这就不满足要求B了）。

对此有一个巧妙的解决办法：首先用hack在IE里将text-indent恢复。然后再将左padding设置成120px，和width一样。这个方法之所以很妙，是因为按钮是唯一一个不遵守盒模型的元素，无论在哪个浏览器下。所以将左padding设为和width一样宽，会将真正的文字空间压缩到0！。

但是这个解决办法在FF中却会有问题。原因是，即使文字空间压缩到0，FF仍然会将文字显示出来，而不受overflow的影响（事实上这样处理是符合标准的，理由自己思考一下）。所以仍然要写text-indent。

还有一个问题是，在Opera里，左padding要设为差不多180才能将文字隐藏。原因不详。至少我用的9.2版本是如此。所以上面的代码在Opera中并不兼容，需要再单独为Opera做hack。

还有一层更深入的思考：那为啥不就将padding: 0 0 0 180px以正常的形式写到CSS中呢？这个就作为思考题啦，提示一下，180px会对FF造成不利影响。

综上呢，我给的代码是多一不可，缺一不可的（当然，我没写对Opera的变态hack，因为这家伙已经开始背叛标准了，而且不同版本之间兼容性很差，所以放弃掉它）。

此外还可以补充一下，cursor:pointer是为了增强可用性。这是个很奇怪UX问题，如果是正常的button，鼠标不改变，也不会觉得奇怪。但是如果按钮没有突起感，鼠标移上之后不变形，就会感觉是不可点。

描边文字

#navMain li a{float:left;display:block;height:39px;line-height:39px;padding:0 13px;color:#285080;font-size:12px;filter:Dropshadow(offx=1,offy=0,color=#ffffff) Dropshadow(offx=0,offy=1,color=#ffffff) Dropshadow(offx=-1,offy=0,color=#ffffff) Dropshadow(offx=0,offy=-1,color=#ffffff);/*only for IE*/}

　　插件简介：
　　在使用WordPress过程中，当我们设置“自定义永久链接结构”包含postname的时候，我们发布的中文标题的文章就会出现很长的包含一大串%XX的字符串，很不美观，我做的这个插件，可以在发布文章的时候自动将postname的内容转化为中文汉语拼音，在自定义URL中以拼音的方式发布，看起来也美观一些。
　　这个插件启用后，发布文章的“文章缩略名（Post Slug）”会自动变成文章标题的汉语拼音，例如，如果你发布一篇文章，标题是“中文拼音”，通常情况下WordPress会自动产生一个缩略名%e4%b8%ad%e6%96%87%e6%8b%bc%e9%9f%b3，如果你启用了“中文标题转换拼音插件”，则文章缩略名会变成zhongwenpinyin。这个缩写是在保存文章的时候产生的，因此你在发布文章前还可以对其进行修改，或者直接发布。这个插件对于以前已经存在的文章标题缩写是无效的，只对新文章有效，你可以通过删除旧文章后发布一篇新文章来自动产生这个拼音缩写。
　　插件安装：
　　这个插件的安装很简单，先下载插件文件，然后解压缩到wp-content/plugins目录下，然后在WordPress插件管理菜单启用PinYin Slug插件即可，不需要修改任何文件。
　　插件的中文介绍地址是：请点这里。
　　这个插件的英文版介绍页面是：WordPress Plugin: Chinese PinYin Slug
　　版权协议：
　　此插件基于GPL的许可协议的自由软件。插件的使用者可以：

• 以任何目的运行此程序的自由；
• 以学习程序工作机理为目的，对程序进行修改的自由；
• 再发行复制件的自由；
• 改进此程序，并公开发布改进的自由。

把JS文件中的document.body换成document.documentElement就可以了