CSS中为啥div标签的位置会从右往左排列？
实际上这里的div就是相册里的照片
1 2 3 4
5 6
第一行是从左到右排列，第二行却从右到左排列（只是位置，图片顺序还是从左到右的）
CSS里有一条float:left，去掉没有影响，改成float:right就变成了
4 3 2 1
6 5
这究竟是怎么回事……我几乎不可能会用到从右到左排列的CSS啊……
与HTML代码无关的
<div>相册1</div>
<div>相册2</div>
……
<div>相册6</div>
知道才说啊……不知道就别同求了……这问题真纠结 展开
首先我们要看一下选择器的「解析」是在何时进行的。
主要参考这篇「 How browsers work」（http://taligarsiel.com/Projects/howbrowserswork1.htm）来看，浏览器渲染的过程以 WebKit 为例大致如下：
HTML 经过解析生成 DOM Tree；而在 CSS 解析完毕后，需要将解析的结果与 DOM Tree 的内容一起进行分析建立一棵 Render Tree，最终用来进行绘图。Render Tree 中的元素（WebKit 中称为「renderers」，Firefox 下为「frames」）与 DOM 元素相对应，但非一一对应：一个 DOM 元素可能会对应多个 renderer，如文本折行后，不同的「行」会成为 render tree 种不同的 renderer。也有的 DOM 元素被 Render Tree 完全无视，比如 display:none 的元素。
在建立 Render Tree 时（WebKit 中的「Attachment」过程），浏览器就要为每个 DOM Tree 中的元素根据 CSS 的解析结果（Style Rules）来确定生成怎样的 renderer。对于每个 DOM 元素，必须在所有 Style Rules 中找到符合的 selector 并将对应的规则进行合并。选择器的「解析」实际是在这里执行的，在遍历 DOM Tree 时，从 Style Rules 中去寻找对应的 selector。
因为所有样式规则可能数量很大，而且绝大多数不会匹配到当前的 DOM 元素（因为数量很大所以一般会建立规则索引树），所以有一个快速的方法来判断「这个 selector 不匹配当前元素」就是极其重要的。
如果正向解析，例如「div div p em」，首先就要检查当前元素到 html 的整条路径，找到最上层的 div，再往下找，如果遇到不匹配就必须回到最上层那个 div，往下再去匹配选择器中的第一个 div，回溯若干次才能确定匹配与否，效率很低。
逆向匹配则不同，如果当前的 DOM 元素是 div，而不是 selector 最后的 em，那只要一步就能排除。只有在匹配时，才会不断向上找父节点进行验证。
但因为匹配的情况远远低于不匹配的情况，所以逆向匹配带来的优势是巨大的。同时 也能够看出，在选择器结尾加上「*」就大大降低了这种优势，这也就是很多优化原则提到的尽量避免在选择器末尾添加通配符的原因。
HTML <div> 标签可以把文档分割为独立的、不同的部分。它可以用作严格的组织工具，并且不使用任何格式与其关联。
<div> 是一个块级元素。这意味着它的内容自动地开始一个新行。
如果需要达到不换行的效果，可以通过CSS样式通过设置div的dispaly、position、float等任意一种方式实现。
div标签的位置会从右往左排列那就是设置了div的float值为right。
CSS float 属性定义和用法
float 属性定义元素在哪个方向浮动。以往这个属性总应用于图像，使文本围绕在图像周围，不过在 CSS 中，任何元素都可以浮动。浮动元素会生成一个块级框，而不论它本身是何种元素。
如果浮动非替换元素，则要指定一个明确的宽度；否则，它们会尽可能地窄。
注释：假如在一行之上只有极少的空间可供浮动元素，那么这个元素会跳至下一行，这个过程会持续到某一行拥有足够的空间为止。
可能的值
怎麼可能……调用的同样的样式，高度会不一样？
而且CSS裏也没有定义样式，高度是由图片决定的
而图片是缩略图，尺寸完全相同
你之所以会这麼觉得，是因为第三个处於选中状态，会有一个边框而已……
没有……我看不到选中的状态……你审元素，看看是不是第三个比第四个要高。
你可以给一个比图片更高的高度试试，应该飘的问题就没有了。
或者你可以把代码发出来，我给你看看。
什麼什麼……完全不懂你指的哪个
再说一次……div调用的同样的样式，图片大小也完全相同，所以这几个div除了图片内容之外是完全相同的
