<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 三人行慕课)