最终图片查看页面支持几个快捷键，相关说明就在“上一张”、“下一张”的按钮旁边，鼠标晃晃就能发现。其他的么，慢慢看吧，刚上线图片还不多，欢迎评论，有评论的图片标题下面会有一个小小的指示标签，目的是在一张挨着一张快速浏览的时候，也能很方便地无需滚动屏幕就知道此图是否有评论值得一看。

　　这些小功能做的不是很起眼，希望是经常来看的人能偶然发现，之后给他们带来些方便。不过不能确定是否“过于”不起眼，以至于我不说的话大家来逛几百次也难以注意到？小调查一下，你看到页面上有奇怪的圈圈、箭头，会用鼠标指上去看看么？

　　几句制作说明：画廊和相册列表页面基于WP的 Gallery Shortcode，略作增强；图片页面写了image.php覆盖了WP的默认模板，其他就是JS的活儿了。Loading背景图片来自 Ajaxload。

　　基于WP的 MediaLibrary 制作的好处是不需要额外插件，我喜欢干净的程序，虽然我是插件狂……但坏处是，WP的MediaLibrary虽然很好用，但仍有少许需要增强的地方，现在的主要问题是图片整理起来不大灵活，没法方便地把一个图片从一篇帖子(相册)转移到另一篇帖子(相册)里去。不过瑕不掩瑜，目前这些功能还算比较满意。

　　大家有什么其他关于画廊，关于看图感受的建议，欢迎都提出来，谢谢。画廊今日开张，欢迎光临！

　　Update[2010.03.01]：
　　已知问题：IE6下一团糟，完全不可看。考虑是修正呢，还是给IE6显示升级提示……我现在没有IE6，微软自家几代浏览器都不能和平共处，真是太废柴了。IE7好像也不妙。

　　Update[2010.03.01]：
　　重整了一下画廊Header部分代码(Thanks to Amai)。现在画廊部分的模板基本跟博客独立开了，额外的好处是IE6下面布局有了很大改观，基本上只剩下PNG透明问题了。

　　Update[2010.03.06]：
　　终于对完成了对IE6的兼容。真是屎一般的工作感受。

　　Update[2010.03.11]
　　添加了<meta http-equiv="X-UA-Compatible" content="IE=edge" />，强制IE8使用标准模式渲染页面。

　　不过进展还是比计划的慢，相册部分现在划归二期工程，少量考虑成熟的细节仍会继续改进，但是……再不上线我觉得真没法交代这些日子花费的心思，尤其是那些下了一百遍“坚决在某日之前完成”的决心。

　　风格的基调取自dA上一张壁纸：Lorem ipsum(by manicho)，那大概是很早很早以前了，当时第一眼就大爱——这个可以做成个Blog风格，就要这个感觉！

　　之后构思了很久，到动手开工的时候，博客程序都从EE换成了WP；又折腾了很久，现在终于可以拿出来示人了。

　　更新(2010.2.22)：
　　1、如果URL中包含评论锚点(#comment-xxxx)，则文章页面打开之后会高亮此评论。
　　2、文章页面增加了上一上和下一篇的链接，鼠标指向文章标题即可显示。

　　更新(2010.2.23)：
　　1、修正了页脚返回顶部箭头在FF下无效的Bug(thanks to Amai)。
　　2、在About页面底部增加了停止音乐的按钮(thanks to reizhi)。

　　更新(2010.03.01)
　　1、MioPress：画廊上线

　　更新(2010.03.06)：
　　1、终于对完成了对IE6的兼容。真是屎一般的工作感受。

　　更新(2010.03.11)
　　1、添加了<meta http-equiv="X-UA-Compatible" content="IE=edge" />，强制IE8使用标准模式渲染页面。

　　写程序经常会有一些代码要注释掉，而不删掉它是因为某个时候可能还需要重新激活，这个很常见，大家通常这样注释掉代码：

/*
$this = 'code is deactivated';
$and = 'so is this';
*/

　　这个注释方法有一点不便就是，每次重新激活代码都需要删除开始和结束符“/**/”，Daisy Olsen 用了一个小技巧：

/*
$this = 'code is deactivated';
$and = 'so is this';
/**/

　　这下方便了，只要移除第一个“/*”就可以启用代码。不过还有点小小瑕疵，就是把代码块注释的开头清除掉之后，回头再要注释这段代码就得重新考虑从哪儿开始，Mark Jaquith 给出一个改进版：

//*
$this = 'code is reactivated';
$and = 'so is this';
/**/

　　Excellent！现在这段代码是激活的，想要注释掉它，就删除第一个“/”，注释还是激活，只要修改第一个“/”。OK了，但是还不够完美，你知道，超级程序员们都是建筑师，既要代码靠谱好用，又要格式整洁漂亮，来看 Aleem Bawany 的版本：

//*
$this = 'code is reactivated';
$and = 'so is this';
//*/

　　功能和前一个相同，格式更整齐，终于，Perfect了。
　　爱死了程序员的小聪明。

　　问题如下图，两层Div结构，Outer Div属性为“margin:0 auto”，本该紧贴外框顶部的，如果没有Inner Div，或者没有Inner Div的“margin-top”属性，一切如预期。但是当Inner Div设置了“margin-top:10px”之后，它的父元素Outer Div也被撑出来一个本不该有的“margin-top:10px”效果。

　　这个“问题”……它是CSS2.1的盒模型中规定的内容——Collapsing margins：

In this specification, the expression collapsing margins means that adjoining margins (no non-empty content, padding or border areas or clearance separate them) of two or more boxes (which may be next to one another or nested) combine to form a single margin.

所有毗邻的两个或更多盒元素的margin将会合并为一个margin共享之。毗邻的定义为：同级或者嵌套的盒元素，并且它们之间没有非空内容、Padding或Border分隔。

　　这就是原因了。“嵌套”的盒元素也算“毗邻”，也会 Collapsing Margins。这个合并Margin其实很常见，就是文章段落元素<p/>，并列很多个的时候，每一个都有上下1em的margin，但相邻的<p/>之间只会显示1em的间隔而不是相加的2em。这个很好理解，我就是奇怪为什么W3C要让嵌套的元素也共享Margin，想不出来在什么情况下需要这样的表现。

　　这个问题的避免方法很多，只要破坏它出现的条件就行。给 Outer Div 加上 padding/border，或者给 Outer Div / Inner Div 设置为 float/position:absolute(CSS2.1规定浮动元素和绝对定位元素不参与Margin折叠)。

　　更多信息，关于不同值的margin折叠后表现的计算方法等等，可自行查阅W3C的CSS2.1规范：Collapsing margins。

　　最近在忙的一大堆事情中的正事儿部分是关于博客的，虽然表面看起来没什么动静，但是内部已经全副武装起来，大大小小装了20多个插件。以前每天没事儿就看NGACN，现在经常是到了晚上吃过饭，懒洋洋地闲暇了才想起来去瞄一下。现在天天看的是 WordPress Plugins，查阅各种插件，反复测试比较，我似乎又回到了当年疯狂翻找Firefox插件库，或者前一阵子每天关注Chrome插件更新的日子了。

　　说起来，当年第一次用FF的时候无甚好感，很快就放弃了，后来第二次再用才发现小样好赞；第一次用Chrome时觉得很精巧但是并未动摇FF在我心中的正房地位，而现在我对这小家伙的热情已经熊熊燃烧，虽然我仍然爱着笨拙的Firefox，但是它开始被压在箱底只有万不得已才出场压阵。初识 ExpressionEngine 的时候我也是感觉平平，到第二次用的时候才发现它模板系统的灵活强大，文档齐备格式整洁，现在这依然是我觉得最优秀的CMS模板系统——功能强大同时保持了简洁优雅。

　　至于WordPress，当初觉得速度特慢，看到EE的迅捷之后立马倾倒过去，最近因为EE的变动被迫换到了WP，现在，我已经完全被新欢折服了，就算是EE放出免费版，我想我也不会再回头了。

　　上面这些说明了什么？这说明想要征服我需要有足够的耐心，哪怕是被一脚踢开也要冲上来紧紧抱住我的腿，如此反复我就乖乖变心了，说明我是一个反应迟钝后知后觉的人。

~~~~~ (⊙v⊙) ~~~~~

　　恩……废话真多。其实我只有两三句话要说，标题算一句，剩下的一两句是：我多方查找WP的各种Gallery插件并且本地测试了NextGEN Gallery和PhotoQ，都不错，但我最终发现其实WP的默认媒体库加上模板系统就可以实现我想要的效果。爱WP果然是没错的。

　　下面我对这一两句话做个简单的阐述。

~~~~~ (⊙v⊙) ~~~~~

　　NextGEN Gallery 用户群庞大，基本上不用担心这个项目将来某一天荒废掉，它会一直跟着WP的最新版保持更新的。NextGEN的好处是结构上独立于WordPress，包括文件目录和数据库，不想用的话，可以卸载得很彻底(它还提供有清理数据库的卸载脚本)；并且可以方便导入以前已经存在的相册图片。

　　PhotoQ Photoblog Plugin 完全忠实于它的名字，就是把你的WordPress变成一个PhotoPress。在PhotoQ的面板里发布的每一张图片，它都会帮你自动发布为一篇博文，仅有一张图片的博文。这种形式比较适合纯Photoblog，这样你可以把前台风格优化成一个相册的模样，链接也写成上一张(图片)下一张(图片)，而非上一篇(博文)下一篇(博文)。

　　虽然理论上你也可以用WP的默认功能发布纯文字内容，但是想象一下用户在一个相册样的界面中点击下一页下一张，结果翻出来的不是照片，而是一篇文字，岂不是很囧？但如果风格是给文字博客设计的，那又委屈图片们了。对于想要文字和图片并发的博客而言，PhotoQ这类非常不合用。

　　WordPress上的各种相册插件，都可以划分为这两类，给WP添加相册功能——Gallery，或者将WordPress转换成PhotoPress——Photoblog。这方面更多插件推介，可以看看这篇Codex：Photoblogs and Galleries。

~~~~~ (⊙v⊙) ~~~~~

　　我想要的Gallery功能，就是像Amai:Pix这样的(刚看了下，Amai换了个相册皮肤，风格相近，翻页功能用了更加流行的样式，也很不错，不过我还是偏爱之前的多一点:P)：

　　O. 简单纯粹、开门见山，而不是首先要选择相册类别；

　　O. 文字很少，额外信息很少，图片就在页面中占据主导性的地位，哪怕是列表页面——这一点我觉得Amai选的新风格不如之前的效果，新风格的列表页面(见下图)左栏列出了日期存档，文字很多，而之前的风格只有相册分类，并且条目更简洁——没有横线和图片数目(我的体验是没有更好，作为用户而言更能突出未知和探索的意味，虽然图片数量统计也是有效信息，但这部分信息对于访客的看图体验而言并无太大意义，或者说，不如留出来更纯粹的图片空间效果更赞)，颜色也更淡更低调，我喜欢这种样子，也很推崇这个效果，我理想中的Gallery就是，一切都用图片来说；

　　O. 图片载入之前显示Loading图标，载入完成之后图片FadeIn(翻译过来叫“淡入”，更难理解╮(╯_╰)╭)。这两个效果只算是小Trick，但是这组合起来效果很不错，让看图的过程无比流畅，没有载入的停滞感，我也要这么做。还有一点我觉得可以改进，就是如果返回上一张，缓存里已经有了图片，这时候是不需要显示Loading图标的，如果这个FadeIn过程能把Loading图标去掉，那就更好。不过目前还没想出来比较高效率的实现代码，只算Wish List。

　　O. 最后一点是额外补充的，就是……大爷的，上一条写得太长，思路断了……喵的……(抓耳挠腮五分钟之后终于想起来了)啊——快捷键。初步构思了一下，用四个方向键：“左”和“右”是上一张下一张；“向上”=随机图片；“向下”=展开/折叠评论。这个键位有点弊端是“向上”的功能不那么直观，而且也容易跟“向下”混同为“展开/折叠评论”功能，所以待定。欢迎大家踊跃建议。取消显示随机图片功能也行，弹出一个贪吃蛇游戏也行，随便什么快捷键方面的建议，只要能最优化用户的看图体验，请讲出你的想法和感觉。

~~~~~ (⊙v⊙) ~~~~~

　　上面是我想要什么样的Gallery，我会尽力实现这些现在预期的目标。接下来是为什么我不用 NextGEN Gallery。

　　这相册插件足够优秀而且我也十分喜欢，技术上它也应该能完成我想要的功能效果，然而就在我查找实现方法的时候，我发现WordPress的媒体库(Media Library)也能。

　　如果，如果是WordPress也有一个像ExpressionEngine那样简陋的——姑且称之为“上传”功能吧，实在是太简陋了……我就很乐意装个NextGEN Gallery，但是WP有媒体库。它精美细致，功能贴心，用起来的快乐简直如沐春风，有这样得意的小刀，我一定首选对它略作增强实现我的功能，这是毫无疑问的。

　　虽然我是插件爱好者，但是一点都不喜欢我的超级武器上有任何多余的功能，冗余就是累赘。所以我从一开始就在找 Media Library 的相关插件，看哪一个可以实现我想要的Gallery效果，最接近的是 Media Tag，但是只能作为辅助。真正起决定性作用的，是WordPress的“Gallery Shortcode”，发现它之后，我终于安心了。

~~~~~ 此文也终于写完了 ~~~~~

　　最后是参考资料链接，我这阵子忙活的内容，精华全都在这几个链接上，等将来有了结果，就是发自这些链接，发自最近一直到处查资料翻文档，比较来比较去，找来的这些插件和链接。

　　BTW：WP的Codex因为是Wiki，太自由，链接来链接去，内容是丰富，但是规范性不是很好，文档结构层次比较乱，你想找的东西肯定有，但是想找到它可不容易。这点不如EE官方维护一个结构明晰内容完整的文档更便于查找。

WordPress Codex：Using Themes
WordPress Codex：WordPress Gallery Code
WordPress Codex：Using Image and File Attachments
Michael Fields：Adding text links to WordPress Gallery
WordPress Codex：wp_get_attachment_image_src();

　　在WP的插件库里找了很长时间，有个1 Year Ago，能在侧栏显示一年前的帖子，但是它的时间基准是当前时间；还有个“Around this date in the past…”算是“1 Year Ago”的增强版，可以显示任意时间段的帖子，但问题同上，仍然不能基于某篇帖子显示那个日期不同年份的发布内容。最后只好考虑自己做个了。

　　好在查了文档之后发现还不是太难，代码量很小，不过WP上面写个内容真是不容易，编辑器里满是php标签和html标签混插，可读性极差。这点比EE差远了。

　　OK，来看代码，加在单篇文章的末尾即可：

<!-- amio: today in history [tih] -->
<?php
$tih_date = split('-',the_date('n-j','','',false));
$tih_args = array(
  'monthnum' => $tih_date[0],
  'day' => $tih_date[1],
  'order' => 'DEC',
  'orderby' => 'date',
  'exclude' => $post->ID
  ); 
$postslist = get_posts($tih_args);
if($postslist):
?>
<div id="tih">
<span class="tih-header">历史上的今天 | Today In History</span>
<?php foreach ($postslist as $post) : ?>
<div class="tih-item">
  <span class="tih-pdate"><?php the_time('M j, Y'); ?>&nbsp;-&nbsp;</span>
  <a class="tih-plink" href="<?php the_permalink(); ?>" id="post-<?php the_ID(); ?>"><?php the_title(); ?></a>
</div>
<?php endforeach; ?>
</div>
<?php endif; wp_reset_query(); ?>
<!-- amio: today in history [tih] : over -->

　　剩下的就简单了，样式搞下即可。这是我的，请随意修改怎么好看怎么来：

#tih .tih-header { font-size: 12px; font-weight: bold; color: #000; display: block; padding: 4px 0; width: 300px }
#tih .tih-item { padding: 2px 50px }
#tih .tih-pdate { color: #999 }
#tih a.tih-plink { text-decoration: none; color: #222 }
#tih a.tih-plink:hover { color: #000 }

　　Live Demo：见本文末的“历史上的今天 | Today In History”。

　　BTW：
　　WP的自动HTML格式化也不好用啊原来(⊙v⊙)…编辑器样子不错就是。也不能自定义，最大的问题是解析不能自动略过<code>中的内容，除非你手动把代码里的“<”全都修改为字符实体。幸好WP插件多，找了个 Preserve Code Formatting Settings，这下才舒服了。

　　Update 1 (2010-01-10)：
　　发现点Bug，对于某些帖子会导致当页的评论显示为另一篇帖子的评论，最近事儿多，稍后会查这个bug，暂时请勿使用本贴代码。

　　Update 2 (2010-01-18)：
　　问题解决，代码已更新。
　　Thanks to Miu for a relaxing talk.

　　从EE迁移到WP，采用Movable Type Import Format格式作为中介，这个格式简单明了，包含了文章内容、评论以及Trackback，所以也很通用。

　　第一步，先从EE中导出文章备份。

　　1、新建一个模板组，名为“export”；在其下新建一个模板，名为“comments”，开启它的PHP解析，设置为“Parse PHP on Input”。
　　2、修改“comments”模板内容如下：

<?php global $IN; $IN->QSTR = '{embed:the_entry_id}' ?>
{exp:comment:entries weblog="default_site" sort="asc"}COMMENT: 
AUTHOR: {name} 
URL: {url} 
DATE: {comment_date format="%m/%d/%Y %h:%i:%s %A"} 
{comment} 
----- 
{/exp:comment:entries}

　　3、修改“export”模板组的“index”模板内容如下：

{exp:weblog:entries weblog="default_site" limit="999" rdf="off"} 
AUTHOR: {author} 
TITLE: {title} 
STATUS: Publish 
ALLOW COMMENTS: 2 
CONVERT BREAKS: br 
{categories}CATEGORY: {category_name} 
{/categories} 
DATE: {entry_date format='%m/%d/%Y %h:%i:%s %A'} 
----- 
BODY: 
{body} 
----- 
EXTENDED BODY: 
{extended} 
----- 
{embed="export/comments" the_entry_id="{entry_id}"} 
-------- 
{/exp:weblog:entries}

　　4、OK。现在点击“index”模板后面的“view”按钮，即可得到导出的文章内容。查看源代码->复制->粘贴到一个文本文件“Backup.txt”中。

　　第二步，将备份文件导入至WP中。

　　这个就更简单了，打开后台管理界面，工具->导入，选择“Movable Type and TypePad”，然后上传刚才得到的“Backup.txt”就完成鸟。

　　Tips：
　　1、如果不放心想要实践之前测试下，第一步导出之后，第二步可以去WordPress.com注册个博客，那里也支持导入。
　　2、迁移之后肯定需要把以前的EE链接重定向到WP格式，可以用这个插件 Redirection，非常赞，我研究了.htaccess好多天，最后还是用这个插件解决问题了。

参考资料：
http://www.sixapart.com/movabletype/docs/mtimport
http://expressionengine.com/wiki/Export_Entries
http://codex.wordpress.org/Importing_from_Movable_Type_to_WordPress

　　不过，不过……Gmail Air Skin 该怎么办呢？一开始想是不是要废掉了……不过再想想，GAS最初的要义就是以Gmail默认风格为基础，在不改动原始配色和设计的基础上改进用户体验细节，不算是 Gmail风格，而更像是Gmail风格的增强或补充。So，GAS还是要继续的 ^^

　　以前Gmail只有一个默认配色，所以GAS可以只按照这一个配色制作，现在Gmail有了30种颜色，而且还能根据地区显示日照或夜空——如果还要保持和默认风格相匹配的话，就只能用JS获取颜色然后插入CSS了。

　　这样，结果就是没法再发布纯CSS(Stylish)版本，只能用Greasemonkey做了。

　　很惋惜，我是比较崇尚Stylish的简洁的，userscript对于风格切换来说有点牛刀杀鸡，不过既然Gmail变得日益复杂，连风格都没法纯粹用Stylish完成了，只能转投Greasemonkey了。

　　希望GAS的未来版本能继续得到大家的热情支持 :-)

　　新风格名为Nidoo，没什么特别重大的含义，就是把相关的一些意义拼成个比较好听的发音，就是这样：nidoo。

　　这一次新风格的宗旨就是跟上一次尽量反差大些，原来用亮色，这次用暗色；原来用冷色调，这次用暖色调；原来为了效率把图片尽量减到最少，这次是美观第一效率第二(再也不吝啬对图片的使用了)；上次是苗条的导航栏，这次是又粗又宽的效果。

～～ 分隔线 ～～

　　以下是一些设计方面的想法，对网页设计无甚兴趣的可以直接跳转到最后发表评论或者扫一眼新版About页面。

　　1、根据 Google Analytics 的统计数据，在Blog上使用800×600分辨率的用户比例已经下降到3%左右，其他全都是1024及以上的，所以 nidoo 也不再局限于780px的宽度，设计宽度1024及以上，实际内容宽度800px。此外，为了进一步适应大屏幕，默认字体也加大了1个像素，包括评论部分。

　　2、页面使用了Table布局——从布局角度来说纯粹是多余的，Table作为布局有一点好处就是在IE下加载的时候可以一部分一部分地显示，而不用等整个页面都载入完毕才显示。用Table，只是为了增强一点IE的用户体验。

　　3、以前的设计思路是，页面附属元素(包括导航、页脚等)文字使用PX设置大小，正文内容使用PT设置大小，这样是为了正文能够满足缩放，同时尽可能小地影响页面布局。不过现在各家浏览器的缩放功能基本上已经都已经进化到了全页面缩放的水平，用像素控制也不影响缩放。从精确的角度上来讲，我更偏爱px而非pt——毕竟网页的最主要用途还是在计算机屏幕上显示。

　　4、都说IE8多么标准，但我觉得它没多少改进。改的只是增加功能，增加对CSS的支持，而对于以前IE就特立独行的盒模型、伪类等问题，基本还保持了IE的一贯作风，还是得要用Hack来给IE全系列浏览器开小灶。此外，在IE8 Beta1下面布局正常的页面，到了IE6下面也都OK，可见IE8仍然是非常固执的坚持自己的路线，只不过在此基础上增加了更多对标准的支持而已——从好的方面么，可以这么说：针对IE8设计的网页向下兼容。

　　5、其实按我的计划，风格还不算100%完成，存档部分的“Timeline”页面还没有做，搜索也尚未开放。还有个早先就规划好的栏目，也要等下一步添加。所以说，新风格Nidoo——好戏还没完～

　　我想正是这个价值观，造成了EE与众不同的特色，包括好的和不好的(最显而易见的例子就是很漂亮的后台界面和很垃圾的默认前台界面)。也是因为EllisLab非常坚持自己的价值观，因此在面对社区的功能需求方面甚至会显得有些固执——只要有自己的观点，EllisLab就会坚持自己的路线方针不动摇。

　　最初我觉得EllisLab面对社区不够友好，但后来慢慢多了些理解，那并非无视用户需求，而是对于技术和理想主义的崇拜所导致的偏执，狂热的技术分子多少都会有些这类毛病的。至于需要增加的功能，干脆自己来改好了。

　　进入正题。

　　EE输出的评论内容全都是经过格式化的，即带有HTML标记，截断的话就可能会出现HTML标签被断开，导致页面解析错误。如果是自己写的文章，可以修改下内容避开发生截断问题的位置，但是用户评论就不能这么信手调整了。所以，需求就是：让EE能够输出不经格式化的评论原文内容，这样就可以在首页上放心显示限定字数的“最近评论”了。

　　修改方法：

　　打开EE的 system/modules/comment/mod.comment.php 文件，查找如下内容(大约在第1164行前后)：

if ($EXT->active_hook('comment_entries_comment_format') === TRUE)
{
  $comment = $EXT->call_extension('comment_entries_comment_format', $row);
  if ($EXT->end_script === TRUE) return;
}
else
{
  $comment = $TYPE->parse_type( $row['comment'] ......

　　增加如下粗体四行，修改为：

if ($EXT->active_hook('comment_entries_comment_format') === TRUE)
{
  $comment = $EXT->call_extension('comment_entries_comment_format', $row);
  if ($EXT->end_script === TRUE) return;
}
<strong>elseif ( $TMPL->fetch_param('no_formatting') == "true" )
{
  $comment = $row['comment'];
}</strong>
else
{
  $comment = $TYPE->parse_type( $row['comment'] ......

　　OK，Hack部分修改完成。使用方法也很简单，在输出评论的 {exp:comment:entries} 标签中加入一个参数：no_formatting=“true”，就像下面这样：

{exp:comment:entries no_formatting=“true”}

　　That’s All.