代码压缩UglifyJS ——解决了display:inline
话说自从在某些地方用了display:inline-block取代float之后，问题出来了一次又一次，归根结底还是那个“传说”中的空白符问题，追究其原因，度娘竟然告诉我说它是历史遗留问题，就是西文的排版问题。好吧，既然度娘就这么说了，那该怎么解决呢？我总不能向科幻电影中那样坐着时光机或者通过虫洞穿越到那个西文刚出来的年代，然后义愤填膺的告诉他们，你们的西文不能这个排版，不然，千年之后会对你们的子孙后代造成很大的麻烦的！不过。牢骚归牢骚，问题还是得解决的，不然，boss就会指着你的脑袋告诉你，这点问题都不能解决，我要你何用，卷铺盖滚蛋吧！然后你就抱着铺盖，喝着西北风，大骂创造西文的那些人，恨不得将他们掘墓鞭尸（尸体估计都归于尘土了）！好吧我承认，这些都是我臆想出来的。第一次在这里写东西记录自己所学，就不说废话了。
度娘告诉俺造成间隙你的原因有两种：一是空白字符；二是font-size。那空白字符到底是什么呢？原来代码中的一些tab、回车、空格、换行这些都是，这些在浏览器渲染页面的时候都会被转换成“\n”。至于font-size为什么会导致间隙，原因很简单，既然是字符，当然不会摆脱font的控制。换行符导致的问题可以将代码写成一行就可以解决了，如果写成一行代码的可读性就会明显降低，就要着手从font-size上做文章。方案一：给父元素设置font-size:0，此方案存在问题，font-size还要被重写一次，较老版本的浏览器兼容性不好，向IE7以下依然会留下1px的间隙，较老版本的webkit对于小于12px的font-size设置不友好，chrome还可以设置-webkit-text-size-adjust:none用以支持较小的字体，Safari即使设置了也不能搞定，但是，ie8及以上浏览器，FireFox，Opea，Safari6，Chrome18均可使用；方案二：font-size + 负margin，但是，至于这个负margin的值到底是多少像素，不同的浏览器不一样，不同的字体也不一样，所以不建议此方案。方案三：font-size + word-spacing:normal，font-family指定字体不同，间隙也会随之而变；同时为了避免受到上下文font设置影响，在局部我们将之设置为12px的arial，为什么选择arial？主要是为了兼容尽可能多的平台，通常windows和Mac OS都会有arial字体，选择Arial字体后间隙将变成3px，对于子元素你仍然可以重置为想要的字体；这样无论外部环境如何变化，这个间隙将始终是3px。使用属性级hack设置字体大小12px [;font-size:12px;] ,因为IE7及以下浏览器也能识别该hack，所以用*font-size:0重置一次；因为word-spacing对chrome和Safari的间隙调整均无效果，可以使用letter-spacing:normal替代，现在所有的主流浏览器应该都可以使用了。但是，如果觉得这样的样式设置还是比较麻烦的话，就要去寻找更好的解决方案了。
在解决这个问题的道路上，我无意间查看了页面的源代码，发现一个问题，我觉得这个问题就是我解决留白问题的关键所在。那这个问题是什么呢？直接看图吧。
好吧，图太大了，就这样吧，就不处理了，重点不是图的大小，而是图展示的内容。同样是两个网站的源代码，第一个网站的源代码是一行显示，第二个网站的源代码就分行显示的。对于刚刚发现这个问题的我并不知道一行显示的是被压缩了，当时我知道压缩代码这个事情，但是愚蠢的我并没有往那个方面想。当时我觉得是浏览器渲染代码的问题，就拼命的去找寻答案，去了解浏览器渲染代码的机制。既然我就那么费尽心思的去了解渲染的机制了，那就说说吧，也不枉我一番心血。
经大师指点 + 各种网站，终于有了自己的思路： 盗用一下别人的图
主线是四个步骤，就是上图四个黄色的色块。第一步，浏览器解析三个东西，一是：HTML/XHTML/SVG，这三个文件分别对应Webkit内核中C++的三个类，会将它们解析成一个DOM Tree（Webkit的命名）/Content Tree（Gecko的吗，命名）；二是CSS，浏览器会将它解析成CSS Rule Tree（CSS规则树）；三是Javascript脚本，主要是通过DOM Tree开放的DOM API 和CSS Rule Tree 开放的CSSOM API 来操作DOM Tree 和CSS Rule Tree 。第二步，解析完成后，浏览器引擎会通过DOM Tree 和CSS Rule Tree生成Rendering Tree（渲染树Webkit的命名）/Frame Tree (Gecko的命名)，当然，这个Render Tree和DOM Tree 是不一样的，至于哪里不一样，为什么不一样会在下面写到，这里先不多说了。CSS Rule Tree 主要是为了完成匹配把CSS Rule 附加到Rendering Tree 的每一个Element 上，也就是DOM 节点 或者Frame 。第三步，计算每个Element（frame/dom 节点）的位置，这个过程叫layout 或者reflow 。第四步，就是调用操作系统的Native GUI 的API进行绘制，页面也就出来了。
刚刚我们说过，Rendering Tree 和DOM Tree是不一样的，现在我们来说说它们之间的区别：1、Rendering Tree 使用来显示的，就相当于“MVC模式”中的'V",既然是用来显示的，那么一些不会被现实在页面上的东西当然就不会出现在Rendering Tree中，比如head ，display：none等等，这就造成了有些DOM没有Rendering来对应，有些又有多个Rendering对应，比如select ，一种rendering不能够准确的描述它等等。2、Rendering和DOM的位置可能不一样，比如那些添加了float 或者position：absolute的元素，在Rendering中显示的就是经过计算定位后的实际位置。3、DOM 的根节点是document ，而Rendering的根节点是RenderView（Webkit命名）或者viewPortframe（Gecko命名）
到这里，浏览器的渲染机制基本上算是介绍清楚了，接下来我们言归正传，继续介绍我的寻找答案之旅。说到这里，我基本上钻进了牛角尖里，一头猛的扎进浏览器的渲染机制里，甚至还打算继续寻找，为什么浏览器没有过滤掉结束标签后的那个换行\n 我百思不得其解，当然，这种情况下，度娘也没有什么能够告诉我的了。就像朱棣在要进军应天一直以为都要打开山东的大门，但是在当时朱棣的军力根本不足以攻打山东，并且当时山东还有铁铉和盛庸在镇守，在这关键时刻，搅乱时局的道衍的一句话点醒了朱棣“去应天不一定要过山东”。虽然我不能跟朱棣相提并论，但是也有这么一个人的一句话将我从死胡同里拽了出来，当然，他也不是当时搅动风云的道衍，他的那句“不是浏览器渲染机制的问题”你仅仅是彻底否定了我之前的思路，还将我又打回了原形，一切好像又要从头开始了。我又年开始迷茫了，这是什么问题呢，我又仔细的研究了一下，回想这个过程，查看之前看过的资料，终于我发现了一个我以为的关键，当然，事实证明那就是关键。就是node_before 和node_after 函数，
/*** 此为会跳过空白符节点及注释节点的 |previousSibling| 函数
* （ |previousSibling| 是 DOM 节点的特性值，为该节点的前一个节点。）
** @参数 sib 节点。
* @传回值 有两种可能：
* 1) |sib| 的前一个“非空白、非注释”节点（由 |is_ignorable| 测知。）
* 2) 若该节点前无任何此类节点，则传回 null。
*/
function node_before( sib )
{while ((sib = sib.previousSibling)) {
if (!is_ignorable(sib)) return sib;
}
return null;
}
/**
* 此为会跳过空白符节点及注释节点的 |nextSibling| 函数
* @参数 sib 节点。
* @传回值 有两种可能：
* 1) |sib| 的下一个“非空白、非注释”节点。
* 2) 若该节点后无任何此类节点，则传回 null。
*/
function node_after( sib )
{
while ((sib = sib.nextSibling)) {
if (!is_ignorable(sib)) return sib;
}
return null;
}
由这两个函数，在我代码中我找到了UglifyJS，度娘告诉我他是压缩的工具，我当时才恍然大悟，原来我费了那么大力气，就两个字就解决了，那就是压缩，当然，UglifyJS 的出现当然不是为了解决display：inline-block的留白问题，只是在压缩这种情况下，留白不会存在而已，这种解决办法的原理还是第一种，将代码压缩在一行。其实我现在是又气愤又高兴，气愤的是自己明明知道代码压缩了会变成一行，但当时为什么就没有想起来呢。高兴的是，幸亏自己没有想起来，才会大费周章的去了解浏览器的渲染机制，也算是大有收获吧。
至于UglifyJS，现在我就不多说了，因为我也没有搞清楚，等我搞清楚了再记录一下吧、！！
