在上一次弄出个基本满意的界面后，又改了改字体和行内代码的背景色颜色（都在Tinny\source\css\_base\variable.styl内），以及一些小细节。但是调着调着就发现主题内的样式还是有一些比较难处理的显示问题的，除了上文提到的两个遗憾，还有几个坑也浮现了出来。尤其在移动端下问题会被放大得更明显，而一个立志高远的响应式主题怎么可以容忍移动端的糟糕体验？所以特别针对移动端的体验做了点优化，但是能力有限，还是有些坑填不上额。

解决使用webkit内核浏览器查看时行内代码不会自动换行问题

在火狐和chrome下对markdown的行内代码展现效果有很大不同；在行内代码处在一行最右且跨行时，火狐里会直接让行内代码整个到行而chrome会把上一行行内代码左边一个字扯下来一起到下一行，看图：

经过和其他博客的对比，发现这是pacman主题的通病，在该主题说明文档里也有这种情况出现。关键在于Tinny\source\css\_partial\article.styl文件里一个white-space属性，w3c解释该属性：

用于规定如何处理元素中的空白

但是这里什么空白都没有啊亲！好吧，我只能理解为行内代码会在其中带来一个神奇的空白咯。而将原有的值white-space nowrap改为且只能改为white-space pre后在chrome里就实现行内代码的顺利换行了，如图：

可是

normal 默认。空白会被浏览器忽略。
pre 空白会被浏览器保留。其行为方式类似 HTML 中的 <pre> 标签。
nowrap 文本不会换行，文本会在在同一行上继续，直到遇到 <br> 标签为止。
pre-wrap 保留空白符序列，但是正常地进行换行。
pre-line 合并空白符序列，但是保留换行符。

nowrap是明明是文本不会换行没有说会把上一行的文字带下来啊亲！chrome你肿么了。。。而此时再用火狐打开，发现在火狐底下pre的表现和nowrap一模一样，而其他三个属性值却与chrome里的pre一样，我凌乱了。。。

嗯，我已经被这个不知道在哪里的“空白”打败了，不想再深究下去。而既然是针对移动端的体验，考虑到webkit内核在移动端的绝对优势，还是以改成white-space pre作为最终解决方案吧，而且毕竟在火狐下这样也还是不错的。

2016.5.28更新
其实上面吐槽了这么多，现在突然发现问题还是没有解决啊喂。。。深入学习前端后再来看之前写的吐槽文字真觉得好笑，当时就是所谓的少见多怪吧。

以前不能理解的white-space属性现在理解了，不就是处理空白和换行方式嘛；但仅靠配置该属性是不行的，因为这个换行是以单词为单位的，也就是说遇到超长单词或超长行内元素时还是不会自动换行。而要实现如原来贴的第三张图那些的彻底自动换行，就得加上word-break: break-all属性才行（更详细的讨论参见元素auto宽高的影响因素）。所以，当时会出现这个结果要么是chrome出了bug、要么是胡乱试出来的吧。。。

解决toc-article在只有一级标题情况下一闪而过的问题

toc的坑还蛮大的啊，在上次toc-aside搞得焦头烂额时就已经注意到这个问题了，而且这个问题在网速慢的情况下，比如手机2g网，更为明显———导航不仅仅一闪而过，会停留更久时间后消失，十分诡异。这次我不想删掉它了，于是开始寻找解决方案，又发现这是pacman主题的通病，参考别的博客无望，就只能自己对照自己的，因为在有二级标题时toc-article还是会正常显示导航的。

对比结果：还是display在作祟，在只有一级标题情况下会出现个

element.style {
                display：none
              }

而且这回可就和浏览器没关系了，百度了一下，element.style是浏览器自己加上去的，优先级还挺大，解决方案是自己在Tinny\source\css\_partial\helper.styl里对.toc-article手动添加display block !important，其中!important用于提高优先级。

此时问题只解决了一半，因为这种简单粗暴的办法让toc-article失去判断能力，在所有文章里都会出现。对于没有内部标题的文章，那一坨堵在开头简直让人不爽。既然简单粗暴了，那我就简单粗暴到底，把toc-article里多余文字删掉，并让它内外边距皆为0；这样文章没标题时就不会有再出现toc-article了。

手机端导航栏收回时时间过长

pacman通病，收回导航栏的等待时间实在太长，但目前仍无解，已向作者反映。期待他的更新吧。

移动端优化至此告一段落。