布罗格的烘培机

　　本来在我的电脑上已经有一个Debian的VMware虚拟映象，可惜Root的密码给忘了，不得已只好重新装。以前的那个Debian是载的Hiweed Desktop 0.5版，现在又重新载了0.6 final。用Hiweed-Debian的一个好处就是安装方便，体积小巧，最重要的是我在VMware下装Debian可以配置好网卡，不象我曾装过的Mandrake和FC2，动则数G，可是装了好几次就是搞不好网络，没办法，谁让咱是Linux盲呢？

　　硬件配置:AMD Athlon 2.0G(200*10),DDR512MB,120G+40G
　　软件配置:Windows Server 2000 SP4,VMware Workstation 4.5.2 build-8848

　　安装Debian不到20min就进入了Desktop，界面又变成了新样子，XFce小老鼠变越来越小，FireFox也更新成了1.0中文正式版。这次安装Debian发现了一个很严重的问题：启动Linux时居然系统检测不到键盘，重启一次还是这样，来回好几次键盘才正常，也不知是Debian的问题还是VMware的问题。

　　以下是几张Debian下的截图，Z-Blog整体上表现了非常好，这也要归功于网页的标准化和FireFox的支持。另外，还进行了管理操作和评论回复，都一切正常，唯一让我不爽的是在FireFox下Flash不是透明的，看上去有点破。因Hiweed-Debian只附带了FireFox，所以没有在其它的浏览器下测试Z-Blog。






　　明天将会上几张我用PearPC虚拟MAC OS 10的截图，当然主角还是Z-Blog啦，苹果的靓丽只有装过才会真正的了解，Apple+Z-BLog简真是绝配。

　　对GoogleLogoShow，Winamp SkinTown的网站程序不满由来已久，这回借着新域名、空间开通的机会，终于将其迁至基于Z-Blog 1.2版的新平台。
　　在2004年11月份，那时Z-Blog基本上还没影，想做Z-Blog不知何处下手，于是便拿这两个网站练习一下，先后在上面完成了评论，引用等等功能，算是对Blog结构大体上有个认识，后来在11月中旬就正而八经的做起了Z-Blog，再到后来，觉得原来的程序功能实在太不足了，后台基本上是没做，看着繁浩的工作量就吓人，便想到用Z-Blog代替原来的程序。

　　改造GoogleLogoShow应该说是比较简单的，将两个网站的数据库打开，比较一下，有哪些字段不同，将Z-Blog中没有的字段补上，然后完成数据库的转换。
　　因为Google的每个Logo的文件名都不一样，如果生成的静态文件也能用Logo文件名（即手动输入文件名）就好了，这样可以更有利于SEO，大郎曾经这样建议过，当时怕加大Z-Blog程序制作难度也就没做，这次何不给自己增加点便利了，另外，生成的文件也不要在POST目录下，改在了LOGO目录下，这也是当时做Z-Blog未想到的。
　　打开c_stystem_lib.asp文件，主要修改TArticle类，增加了原来没有的Picture和Tags属性，关于Tags功能目前Z-Blog也未实现，但GoogleLogoShow原来的程序却已做了（当时叫做Key，现在都流行Tags嘛），日后再补上啦。将类的方法做些调整，再修改edit.asp文件增加新的输入框后修改c_system_event.asp以接收新的字录入字段，再选择一个漂亮的样式，基本上就大功告成了。
　　另外，又将原GoogleLogoShow收集的SEO文章单独建成了一个BLOG，叫做“SEO探索”，也算是我自己夹带私货吧。


　　改造Winamp SkinTown要麻烦的多，因为它是一个下载系统，要记录每个面板的点击次数和下载次数，另外不光要生成指定文件名的文件，而且生成文件所在目录也不同(随分类名变化，如class、modern)。
　　在数据库方面，SkinTown要复杂多了，在blog_Article表中要比Z-Blog多7个字段，只是修改TArticle类就要好半天，另外，生成的静态页面还要计数，牵扯的地方会更多。
　　目前也只完成了部份工作，点击、下载排序都未做，多关键字分类也没做上去，草草的移植完先前的样式就挂上了新网站中。


　　因为Google Group太不好用了，每日在Blog上的留言也太多，实在难以承受，便有了建一个官方论坛的想法。打造Z-Blog官方论坛要比较简单，只是增加了用户注册的功能，然后再做了一个BanIP类，防止恶意注册、灌水等。
　　Z-Blog和一个真正的论坛相差太多，我只是做了些简单的改动，主要调整了用户权限表，让中级用户直接发贴，新建register.asp文件为注册界面，让用户直接注册为“中级用户”，同时增设了两个act：register、UserReg，并修改了相应的层里做了修改。
　　目前的论坛还处在试运行阶段，看运行情况再做调整。


　　鉴知堂是我做的最先的一个网站之一，已经改版多次了，最近一次则是将其标准化，现在同样是新空间新域名，也曾想到投入到Z-Blog平台，但是回头一想，还是应该保留一个苗苗，说不定比Z-Blog做的更好呢。
　　原来的样式过于深了，有点不利于阅读，且排版和Z-Blog有非常大的差异，这次在改版中，向Z-Blog靠拢，充分运用了CSS技术，更灵活的切换页面及字体配色，致力于打造一个应用标准化的网站。


　　进入了2005年的4月份，RainbowSoft.Org上的网站，搬走的搬走，合并的合并，已经只剩下了一个Z-Blog了，同时又开通了Z-Blog的论坛，基本上将RainbowSoft.Org定位于Z-Blog为主题的网站，不再是一个大杂烩网站了。
　　同时重建了RainbowSoft.Org首页，让首页看起来更简洁。


GoogleLogoShow:http://www.googlelogoshow.com/
Winamp SkinTown:http://www.skintown.net/
Z-Blog官方论坛:http://www.rainbowsoft.org/bbs/
鉴知堂:http://www.jzt.net.cn/
SEO探索:http://www.googlelogoshow.com/seo/

　　今天用Google搜索，发现Google目录已经再次更新，在两个月前Dmoz.org收录了我的Z-Blog官方网站|布罗格的烘培机，现在Google目录终于可以搜索到了。

　　众所周知，Google网页目录使用的是DMOZ数据 Google不是对DMOZ数据实时更新．以前一般一年更新34 次，这两年越来越少。(Google目录关于DMOZ数据的更新)

　　做了一张截图，看看Z-Blog在目录中的位置。


　　另外，从Google网页目录的刻度条中也发现一些很有趣的东东，居然能看出真实网站的PR值，可见人们对于Google的不遗余力的深究。(Google PR刻度：Google工具条刻度与Google目录中PR刻度)

　　想知道一个网页的PR（pagerank）值，我们可以从两个途径获得，我们可以下载Google工具条，或者从Google目录中获得。

GOOGLE工具条上共有十个刻度
GOOGLE目录中共有八个刻度

　　目录上的刻度有些不容易理解， 数字 5-11-16-22-27-33-38 分别是绿色部分的像素。灰色部分与绿色部分的总长度总是保持40象素。

　　如果你的站点在Google目录中的绿色部分的长度是22像素，那么你的站点在Google目录中的PR值是22/40=0.55

　　这里有几个例外，例如Google.com它的绿色条的长度是42像素，是有些奇怪，Google自己的PR长度比Google目录中的PR的长度长！

　　很久以来，Google目录更新不如GOOGLE索引更新的及时，常常Google目录中所显示的PR也是落后于Google工具条的显示，无独有偶，在最近的一次却是Google目录中先更新了PR,而Google工具条中却迟迟没有更新。

　　Google网页目录是一个包括了世界多种语言网页的目录集。在网页目录里面的网页内容一般不会被翻译为其他语言，而总是包括其语言在万维网中的内容的。

　　网页目录功能与网页搜索是集成的，当搜索网页时，相关网页在目录中的内容会以链接的形式在搜索结果中显现。点击链接就可以找到在同一个目录下相似网页或其它类似分类,这当你不确定到底要找什么时是非常有用的。当搜索范围涵括太广，使用网页目录可缩小搜索于指定范围。例如察看“中文／新闻／杂志”分类子目录，则可知道有哪些中文杂志有网页。网页目录可略去类似但无关的网页。如检索“大学”，将搜索范围设定“教学机构”分类，即可略去像“大学书城”、古书里“大学”、论语的内容.网页目录只包括经编辑群审核过网站。因为网页目录是在开放式目录（OpenDirectory）工程下运作的。网页重要性排列是网页级别技术及人工的结合。Google还可辨出常用重要网站，排放在目录前面（用粗体字标出）提升网页搜索效率并借由绿线长短表明网页评级。（参见 PageRank™）

相关链接:Google - Wikipedia
相关链接:Google PageRank scales: Google Directory and Google Toolbar

　　一切从一个糟糕的浏览器开始，它完全不支持 XHTML。

什么是 MIME Type？

　　为什么这么说呢？首先，我们要了解浏览器是如何处理内容的。在浏览器中显示的内容有 HTML、有 XML、有 GIF、还有 Flash……那么，浏览器是如何区分它们，绝对什么内容用什么形式来显示呢？答案是 MIME Type，也就是该资源的媒体类型。

　　媒体类型通常是通过 HTTP 协议，由 Web 服务器告知浏览器的，更准确地说，是通过 Content-Type 来表示的，例如:

Content-Type: text/html

　　表示内容是 text/html 类型，也就是超文本文件。为什么是“text/html”而不是“html/text”或者别的什么？MIME Type 不是个人指定的，是经过 ietf 组织协商，以 RFC 的形式作为建议的标准发布在网上的，大多数的 Web 服务器和用户代理都会支持这个规范 (顺便说一句，Email 附件的类型也是通过 MIME Type 指定的)。

　　通常只有一些在互联网上获得广泛应用的格式才会获得一个 MIME Type，如果是某个客户端自己定义的格式，一般只能以 application/x- 开头。

　　XHTML 正是一个获得广泛应用的格式，因此，在 RFC 3236 中，说明了 XHTML 格式文件的 MIME Type 应该是 application/xhtml+xml。

　　当然，处理本地的文件，在没有人告诉浏览器某个文件的 MIME Type 的情况下，浏览器也会做一些默认的处理，这可能和你在操作系统中给文件配置的 MIME Type 有关。比如在 Windows 下，打开注册表的“HKEY_LOCAL_MACHINE\SOFTWARE\Classes\MIME\Database\Content Type”主键，你可以看到所有 MIME Type 的配置信息。

浏览器处理 XHTML 和 HTML 有什么区别？

　　HTML 的语法过于随意了，有许多简写，标记不匹配的复杂情况，同时长期 Web 发展下来积累下来了许多错误的用法——比如一个文档里完全没有 <html></html> 标记——但浏览器还是得支持它，可想而知，为了支持这些“Tag Soup”——也就是我们所说的那些，乱成一锅粥的标签——浏览器要很费力地去猜测一段标记的意思，努力以用户期望的形式表达出来。一句话说，虽然 HTML 4.01 允许你用语义化、结构化的、内容与表现分离的方法来书写标记，但由于它沿袭了 HTML 这种格式，使得浏览器对于凡是 MIME Type 为“text/html”的文件，都得采用一种非常费劲的方法去处理，这对于 Web 的发展是很不利的。

　　再说除了浏览器，还有许多其他的用户代理要阅读 HTML：纯文本的浏览工具、读屏器等等。

　　创造 XHTML，很大一部分原因正是要通过 XML 重新严格地规范一遍标记，让这些用户代理可以以一种更简便的方式来解析这些标记。因此，XHTML 这种新的格式，天生就要求内容的发布者必须以严格的方式来标记自己的文档。

　　当然，XHTML 对于内容提供者也有好处，此处先不展开，详见下文。

MIME Type 与之又有什么关系？

　　把前两节的内容合起来，你显然可以发现：一个正常支持 XHTML 的浏览器会根据服务器提供的 MIME Type 是 text/html 还是 application/xhtml+xml 来区分获取到的内容是 HTML 还是 XHTML，对这两种格式，分别以两种不同的方式来解析文档，后者解析起来要严格得多，但对于用户代理开发者和内容提供者都有很大的好处。

　　那么，那些浏览器正常的支持了 XHTML 呢？答案是 Mozilla、基于 Mozilla 的浏览器如 Netscape 7 和 Firefox、较新版本的 Opera 和 Safari 等等。但不包括 Microsoft Internet Explorer。问题是，这一“不包括”，就除掉了大约 90% 的浏览器市场啊，在我们抓狂以前，先来看看 IE 是什么处理 application/xhtml+xml 的：IE 不认得这种 MIME Type，它要么提示你是否下载那个文件，要么就把文件内容当作纯文本显示出来，反正是不可能正常显示标记。

　　这正是造成我们不得不给 XHTML 文档标以 text/html 的原因 1，实际上，目前 Web 上 95% 的 XHTML，都是扮成 HTML 的 XHTML (包括 w3.org)，浏览器 (包括我们引以为傲的 Mozilla) 压根没有用 XML 解析器去解析那些 XHTML，而是沿用处理标签汤的老办法。

　　这个时候你会问了，在我看起来，老办法显示得很好啊，干吗为此感到头疼呢？问题正是出在“看起来”这个词上，实际上，一些细微但是不可忽略的差别仍然存在。

用 application/xhtml+xml 方式解析 XHTML 与用 text/html 方式解析的差别

　　下面所说的“HTML”，就是指 text/html 的解析方式；相应地“XHTML”就是指“application/xhtml+xml”的解析方式。

1. 这是最重要的，严格的 XML 解析至少要求文档是 well-formed 的，也就是标签要正确开闭，& 等 XML 实体要正确使用。
2. 在 HTML 中 <body></body> 是用户所能看到的全部视域，给 body 设置背景色就是给整个文档设置了背景色，但在 XHTML 中并非如此，给 <html></html> 设定背景色的效果和给 <body></body> 设定的不同。
3. 在 HTML 中 CSS 规则中对元素的匹配是大小写不敏感的，BODY 和 body 匹配的是同一个元素，但在 XHTML 中却是大小写敏感的。
4. 在注释中隐藏的 JavaScript 脚本会被 XHTML 忽略。
5. document.write() 不能在 XHTML 中使用。
6. HTML DOM 和 XHTML DOM 的元素和属性返回值是不同的，HTML 中是大写，XHTML 中是小写。
7. 还有不少其他的 DOM 问题。

　　总结起来就是，我们正在广泛使用的其实是一种看起来已经 XHTML 化的 HTML，想象一下吧，如果要求所有这些网站立即把 MIME Type 换成 application/xhtml+xml，即便用可以正常解析 XHTML 的浏览器来浏览，它们多数会死在前面列举的某一条原因下，无法正常显示。然而这不好说是 XHTML 的错，正常的处理理应如此，只不过我们一直被纵容了。

　　可是 W3C 还是不断要求我们以正确的 MIME Type 来提供 XHTML，为什么呢？因为我们要用到 XHTML 提供的好处啊，只有被认为是 XHTML 或者 XML 文档的东西，浏览器才会启用这些“好处”，比如你可以试着在 IE 中打开 XHTML 中嵌入的 MathML 看看，没有效果，它被当作 HTML 一样显示。

　　现在的问题是，既然把文档设定为真正的 XHTML 是如此的麻烦，会带来如此多的问题，干吗不舒舒服服地呆在 HTML 上呢？为什么要往 XHTML 过渡？XHTML 提供的“好处”值得我们为此付出如此多的代价吗？

XHTML 的优势

　　最重要的两点是：

1. 除了前面讨论的用户代理易于处理以外，实际上，大量的基于 XML 的工具，许多对 XML 有很好支持的编程语言，都能够方便地解析你的文档，从中提取出需要的信息。当然，也包括搜索引擎。
2. 你可以利用 XHTML 继承自 XML 的良好的扩展性，比如在 XHTML 中嵌入 RDF 数据，描述文档的语义信息；加入 MathML 标记，描述数学公式；加入 SVG 标记，使用可伸缩矢量图型。

　　显然，如果文档连 well-formed 都做不到，优点 1 对你是无效的，就算有效吧，就个人来说，其实也没有多少人对 XHTML 进行 XML 解析，因为能做到的，大概也就是从 h1、h2 这些标记中读出文档结构一类的功能，实在没什么大用处。

　　而第二点对大多数内容提供者来说，太远了，RDF 是什么东东？加入 RDF 信息有什么好处？没多少人知道或者有兴趣知道；MathML？这是可扩展性目前用得最多的地方，因为很多 MathML 阅读和编辑工具已经普及了，但如果你不是个成天在公式中打转的科学工作者，多半对此也没有兴趣；SVG 呢？倒是挺有意思，但目前显然没有获得广泛的应用，事实上，日后能否获得广泛的应用，还要看它能不能在与 Flash 的竞争中活下来：成为标准的东西被人抛弃也是常有的事。

　　总结起来，所有这些优点几乎都是一些空头支票，一些未来才能实现甚至未来都不知道能不能实现的东西，比如说你现在在开发一个 CMS 系统，如果现在都已经不能保证里面的内容 well-formed，有什么理由说以后，数据越来越多以后，反而会回头去把错误的标记一一改正？

　　事实上，用不到这些空头支票，我们的生活几乎没有受到任何影响。

　　那么，是否这就是说，XHTML 几乎就是一个鸡肋了 2？

XHTML 啊 XHTML

　　行文至此，已经陷入了僵局，其实我本无意把 XHTML 说得那么差的，但问题是我每句说的都是实话呀，也没有忽略什么有必要提到的因素，但反复查考，总结起来还是那一句话：XHTML 其实是一个带一点理想主义的，对普通用户来说，相比 HTML 4.01 并没有显见优势的格式。3

　　于是我们就陷入了两难困境：刨掉那些花言巧语，没有任何显见的优点吸引我们我们转向 XHTML，但如果我们永远躺在 HTML 4.01 舒服的被窝里，Web 岂不是永不前进了？

　　答案还是个问号。

小结

　　本来，仅仅为了未来的锦绣图景，大家多数还是愿意转向 XHTML 的，这大概是个博弈论中微妙的平衡，用户、浏览器厂家、标准制定者三家玩的一个游戏，但 IE 打破了这个平衡：它不支持 application/xhtml+xml，于是用户只好都以 text/html 来发布 XHTML 页面。

　　如果把他们人格化：我觉得“用户”大概是个剃头挑子一头热的家伙，他们为自己的 XHTML 页面在一切浏览器上都如此美好而感到满意，却浑不知道背后其实还是 HTML，自己没沾着一点“X”的好处。

　　这时标准制定者——他一定是个理想主义者——也不满意，因为用户其实还是在以 HTML 的方式来写 XHTML 的，根本没准备好向 XHTML 进行转变的决心，标准制定者一心领着大家往 Web 美好的未来远航，却发现无论是用户还是浏览器厂商都在尽给他添乱。

　　浏览器厂商们——他们拥有最大的筹码，却始终冷眼旁观——此时却在开心地内斗，对此情况耸耸肩表示无能为力。

　　你可能会对此感到沮丧，但这的确是目前 Web 中的事实，承认也好不承认也好，确定一个目标，然后艰难而执著地前行，大概是我们这些标准推广者唯一能做的。

注释

1. 也并非完全没有办法，对于用 PHP 或者 ASP 这样创建的动态内容而言，通过检测 HTTP 头来进行内容协商是最好的办法：给 `Accept: ` 中包含了 `application/xhtml+xml` 的请求提供 `Content-type: application/xhtml+xml` 的数据，而给其他的请求提供 `text/html` 的数据。(在 456 Berea Street 的一篇文章详细解释了这种方法，实际上，打开 Mozilla/Firefox 的 `about:config` 页面，你可以找到相关的配置 `network.http.accept.default` 来验证一下 Mozilla 是否发送了正确的 HTTP 头。)，这几乎是一种完美的方法了 (实际上静态内容大概可以通过 Web 服务器的内容协商功能实现这种提供方式)，但考虑到本文主要的目的是探讨是否应该用 XHTML，所以不在正文中详细讨论。
2. 仍旧是指对普通用户而言，事实上必须承认，XHTML 的出现对于整个 Web 本身的长远发展绝对有好处。
3. 其实话不该说得那么绝，应该说 XHTML 的出现是绝对有必要的，但其带来的好处绝大部分是对 Web 本身的，长远的，现在难以看出的好处，对用户或者开发者的好处微乎其微。

参考文献

1. Ian Hickson, Sending XHTML as text/html Considered Harmful
2. Gez Lemon, It’s all in the MIME
3. Gez Lemon, Specifying a MIME Type
4. Roger Johansson, Developing With Web Standards, Recommendations and best practices, Part 5: XHTML
5. Network Working Group, The ‘application/xhtml+xml’ Media Type
6. Tommy Olsson, Content Negotiation
7. W3C, XHTML Media Types

引自:Web4C » MIME Type 引出的两难困境
参看:G-P-L » 使用XHTML
参看:传承标准 » 正确使用XHTML的冒险

evolt.org作者之一Trenton写的Ten CSS tricks you may not know，还是非常有用处的，无论CSS新手还是老枪，有些技巧的确鲜为人知。你可以去看英文原版，词汇并不复杂。其实这篇文章有翻译的价值的，不过我最近比较懒，就简单用中文简述一下，其间会插入一些自己的经历和看法：

1. font的简写
   CSS很多元素都有简写，font要特别和严格一些，font-size和font-family是必须的，而且要按照这个顺序。因为font用到的地方比较多，所以他可能特别提到。简写能有效减小你的CSS文件的体积。
2. class属性叠加
   其实在class中可以同时加入多个属性，属性用空格隔开。例如：<p class="text side">...</p>这样<p>就继承了.text和.side的有效属性（冲突的地方会自动被排斥）。随便提一下kubrick主题中也有一个地方使用了这个方法。该文章回复的用户提到IE在处理多属性时可能存在问题。
3. border的缺省值
   当你使用border简写时没有指定border-width和border-color时，border是有缺省值的，宽度为medium（大概3到4个象素），颜色为框内文本的颜色。
4. !important不理会IE
   在CSS规则中，!important会使该规则额外优先，而IE却听不懂这条规则，那么在某些时候这个技巧会非常有用。
5. 图片移魂大法
   你先看看原文的叙述，我谈谈我的经历。哈哈，我最早在zeldman的Blog上发现了这个技巧，注意他的导航条，鼠标悬停时空心字图片会变为实心，而实际上这是一张图片。呵呵，你再去分析一下他的CSS就知道了。
6. 盒模式的另类hack法
   IE6以前的版本都有对盒模式的错误理解。以前都是看用CSS的声音属性来处理IE6以下版本的效果，这次你可以看看另外一种方法，看上去更简单方便。
7. 块元素居中
   我们一般都使用指定块宽度再把左右margin设置为auto来居中。殊不知有时会在IE6之前的版本出现问题。去看看解决技巧，有CSS示例。
8. 垂直居中
   CSS对垂直居中比较弱，没有表格那么灵活。而且vertical-align这个属性你就是用了也是不起作用的。方法就在于用行高来解决，把行高设置为整个box的高度。
9. 子容器的定位
   CSS的奇妙除了可以让对象随处定位外，还可以让子容器也做得到。这个用处也很多。比如Binary Bonsai的导航条。
10. 控制屏幕底部的背景色
    这个请看原文的详细讲解了。

原文:Ten CSS tricks you may not know:evolt.org, Code
引自:雨吁 » 你未必知道的10个CSS技巧