<div id="div1">
<div id="div2">
</div>
</div>
这里div1就是父层，div2就是子层。
<html><head>
<title>...</title>
</head>
<body>
<ul>
<li>332</li>
<li>233234</li>
</ul>
<p>...</p>
</body>
</html>
例如上面的html结构:
<html>元素就是<body>和<head>的父元素（上下级，包含关系）
而<body>又是<ul>和<p>的父元素
<ul>又是两个<li>的父元素。
两个<li>就是兄弟元素（平级）
<body>和<head>也是兄弟元素，依此类推。
相应的， ul 和p是body的子元素， 而 li 呢， 是body的后代元素（后代选择符）。
你在dreamweaver里，套用源格式后，代码自动缩进，你很容易就能看出来的。
这个问题的答案和“为何CSS相邻兄弟选择器只支持后面的元素，而不支持前面的兄弟元素？”是一样的。浏览器解析HTML文档，是从前往后，由外及里的。所以，我们时常会看到页面先出现头部然后主体内容再出现的加载情况。
但是，如果CSS支持了父选择器，那就必须要页面所有子元素加载完毕才能渲染HTML文档，因为所谓“父选择器”，就是后代元素影响祖先元素，如果后代元素还没加载处理，如何影响祖先元素的样式？于是，网页渲染呈现速度就会大大减慢，浏览器会出现长时间的白板。加载多少HTML就可以渲染多少HTML，在网速不是很快的时候，就显得尤为的必要。比方说你现在看的这篇文章，只要文章内容加载出来就可以了，就算后面的广告脚本阻塞了后续HTML文档的加载，我们也是可以阅读和体验。但是，如果支持父选择器，则整个文档不能有阻塞，页面的可访问性则要大大降低。
有人可能会说，要不采取加载到哪里就渲染到哪里的策略？这样子问题更大，因为会出现加载到子元素的时候，父元素本来渲染的样式突然变成了另外一个样式的情况，体验非常不好。
“相邻选择器只能选择后面的元素”也是一样的道理，不可能说后面的HTML加载好了，还会影响前面HTML的样式。
所以，从这一点来讲，CSS支持“父选择器”或者“前兄弟选择器”的可能性要比其他炫酷的CSS特性要低，倒不是技术层面，而是CSS和HTML本身的渲染机制决定的。当然，以后的事情谁都说不准，说不定以后网速都是每秒几个G的，网页加载速度完全就忽略不计，说不定就会支持了。(BY 三人行慕课)
