今天肯定有人还记得IE 4刚刚推出来的时候有一个有趣的功能，那就是新闻频道。这个新闻频道的功能与Netscape推出的新闻频道是很相似的(当时Netscape还是市场上领先的浏览器)。为此Netscape 定义了一套描述新闻频道的语言，这就是RSS，只不过Netscape自当时起每况愈下，所以最终也没有发布一个正式的RSS规范(只发布了一个0.9版本)。而微软也在当时推出了支持自己IE的CDF(Channel Definition Format)数据规格，与RSS非常接近。微软试图用新闻频道的功能把“推”(Push)技术变成一个应用主流，并与Netscape抗衡。不过出乎预测的是，“推”技术自始至终没有找到合适的商业模型，而且伴随着其他各类网络特性的出现，也日益无法显现自身的优势。新闻频道在浏览器中的地位最终日暮西山，最后也在IE的后续版本中消失了。
新闻频道的确进入了低谷，但是RSS并没有被业界人士所抛弃。过去两年，Blog从一个专业群体开始，逐步成为了网络上最热门的新话题。而RSS成为了描述Blog主题和更新信息的最基本方法。于是RSS这项技术被著名Blogger/Geek戴夫·温那(Dave Winner)的公司UserLand所接手，继续开发新的版本，以适应新的网络应用需要。新的网络应用就是Blog，因为戴夫·温那的努力，RSS升级到了0.91版，然后达到了0.92版，随后在各种Blog工具中得到了应用，并被众多的专业新闻站点所支持。在广泛的应用过程中，众多的专业人士认识到需要组织起来，把RSS发展成为一个通用的规范，并进一步标准化。一个联合小组根据W3C新一代的语义网技术RDF对RSS进行了重新定义，发布了RSS 1.0，并把RSS定义为“RDF Site Summary”。这项工作并没有与戴夫·温那进行有效的沟通，而戴夫则坚持在自己设想的方向上进一步开发RSS的后续版本，也并不承认RSS 1.0的有效性。RSS由此开始分化形成了RSS 0.9x/2.0和RSS 1.0两个阵营，也由此引起了在专业人群中的广泛争论。
因为争论的存在，一直到今天，RSS 1.0还没有成为标准化组织的真正标准。而戴夫·温那却在2002年9月独自把RSS升级到了2.0版本，其中的定义完全是全新的模式，并没有任何RSS 1.0的影子。这引发了网络上进一步争议，究竟让一个越来越普及的数据格式成为一个开放的标准，还是被一家公司所定义和控制，成为了争议的焦点。戴夫·温那并没有为自己辩解，他的观点是RSS还需要进一步发展，需要专业人士更明确的定义，不过恐怕这种轻描淡写不能消除人们对RSS“被一家商业公司独占”的担心。
前面的铺垫对用户来说也许没有什么太大的意义，可能更多人关心如何在自己的Blog增加RSS输出，这样可以让很多新闻聚合工具(例如CNBlog刚刚推荐的NewzCrawler)很容易找到你并自动获得你在Blog中的更新内容。
它是什么：站点用来和其他站点之间共享内容的简易方式(也叫聚合内容)。 RSS使肵ML作为彼此共享内容的标准方式。
它代表什么：Really Simple Syndication (或RDF Site Summary，RDF站点摘要)
例如：一些免费的软件能够让你阅读那些RSS使能的站点，比如 NewsIsFree 和 Amphetadesk。
它有什么用处：让别人容易的发现你已经更新了你的站点，让人们很容易的追踪他们阅读的所有weblogs
层叠样式表，简写为CSS，是英语Cascading Style Sheets的缩写。它是W3C定义和维护的标准，一种用来为结构化文档（如HTML文档或XML应用）添加样式（字体、间距和颜色等）的计算机语言。
第2章里面我们了解了document的结构和CSS选择器是如何查找定位对应的元素的。每一个合理的document都会生成一个结构树，基于此，选择器基于元素的祖先，属性，兄弟节点和更多的因素来定位元素。而且这一dom结构树也是CSS种实现继承的基础。
继承是(Inheritance)CSS属性如何从一个元素传递到它的所有子元素的过程。浏览器在决定给一个元素配置什么样式的时候，除了要考虑继承关系，同时也要考虑元素的特异性(Specificity，这个翻译需要斟酌下，但是意思很明显，存在于多个冲突样式中的优先级机制)。而考虑的这一过程就称为级联（cascade）。接下来我们就来探讨一下这三种机制-特异性，继承和级联。后两者的区别其实可以简单归纳为：h1{color:redcolor: blue}的结果就是级联，而在h1中创建一个span就是继承。
综上，别管这几个有多抽象，继续学习，会看到回报的。
从第二章我们看到选组元素的方式太多了，所有很有可能同一个元素被很多规则选中，来看看下面的例子：
上面的3对样式中每对都是作用在同一个元素上，那么到底浏览器该在元素上应用哪一个样式呢？结果就在每个选择规则的特异性中。浏览器逐条评估每条选择器规则的特异性，然后将样式声明应用到元素上。当同一个元素中包含多个存在冲突的属性声明时，有最高特异性的属性就会胜出，把其他冲突规则替换掉。
一个选择器的特异性有选择器的组成决定，而一个特异性的值可以分成4部分，就像这样：0,0,0,0。而真实的特异性是由下面这些决定的：
还是举例来说明吧，分别来看看不同的选择规则对应的特异性值：
既然刚学了如果计算特异性值，赶紧用在之前的例子上吧：
虽然我们一般在写CSS的时候会把多个属性都写在一起，例如：
然而实际上浏览器为了更好的计算特异性值实际会把聚合的属性进行单独的拆分：
咱们再来考虑一个稍微复杂的例子：
基于这个结构最终显示的效果是这样的：
从这个例子中，我们可以很好的看到浏览器按照之前说的特异性的规则展示对应不同值得样式结果。可以看到，浏览器要对每个元素进行拆分，然后计算特异性值后再确定对这个元素渲染那些样式，想想整个流程就很繁杂，幸好浏览器都自动帮我们做好了，而且这是我们后面讲到的级联的很重要的一环。同样，详细了解浏览器的渲染流程也对我们优美的书写CSS样式有很大助益。
通用选对特异性值是没有贡献的，但它是有值的，虽然值是0,0,0,0,但这和没有特异性值是有区别的，后面会在继承章节中详细讨论。所以下面的结果是显而易见的：
除了div的后代p显示为黑色外，其他都显示为灰色。而通用选择器是不贡献特异性值得，因此下面两个表达式的值也是一样的：
之前有提过直接的ID选择器和通过属性选择器设置ID值，他们最终计算的特异性值是不同的。我们先回到之前的一个例子：
因为直接用ID选择器贡献的特异性值为0,1,0,0，而属性贡献的值为0,0,1,0, 所以下面的结果也是显而易见的：
到现在肯定很多读者会想，之前计算的特异性值的4位里面第一位是什么时候设置的？答案就是为内联样式设计的，比其他的所有声明优先级都高。来看看下面的例子：
结果很明显h1就是绿的，因为内联样式的值更高，或者说优先级更高。
有时候特异性值更高的样式还并不是你想要的，这时候可使用!important来表示那些特别重要的样式，不过格式有严格的规定，就是必须在分号前面加，例如：
!important表达式必须正确，不然的话会报错。那如果存在对同一个样式有多个important声明会怎样呢？那么这些样式都不会被应用，所以需要保证important的唯一性。
其实浏览器是这么处理important样式和非important样式的：将它们单独分成两拨，important的一拨优先级更高，并且在这个组内处理自身的冲突啥的；同样的逻辑对应于非important组，组内采用特异性值来解决冲突。来看个例子：
继承，顾名思义就是属性在祖先-后代节点间的传递机制。比如说一个在h1标签中设定的颜色，那么h1中的所有后代文本都会继承。
上例中em就是继承了h1中的gray颜色。来看个ul标签的例子：
可以看到ul的所有li元素也都继承了这一特性。继承看似简单不过也需要注意几点：
有没有很意外em中的元素为啥还是灰的，照理说应该都是黑色才对，就是因为继承来的黑色属性没有特异性值，而被全局的样式给替换了。
有时候没有特异性值也会带来麻烦，比如看：
如果id=toolbar的元素下面有链接，那么就很有可能因为没有定义而采用浏览器的默认样式，一般来说是这样：
解决方案归根结底还是要有特异性值，可以有多种方法都是可以的：
再来考虑下个问题，如果两个具有完全相同特异性值的元素作用在同一个节点上，那该怎么办？比如说像这样：
还记得css为啥叫css么？Cascading Style Sheet,级联样式表，通过定义相关的规则来结合继承和特异性值。来看看都有哪些吧。
为了更好理解，我们对后四个规则进行详细说明：
虽然p本身有内联的样式，但因为标记了!important,所以还是显示为灰色。另外即使给内联样式加上了important也没啥用：
在上面权重相同的情况下对比源头，作者的优先级高于读者的。但如果在important情况下，读者的优先级要高于作者的，总结一下顺序就是：
如果上面的类型相同，则会进入到这一步，判断特异性值。
如果特异性值也一致，最后判断下出现的顺序，后出来的覆盖先前的。
结果就是blue颜色。而这一顺序对import进来的样式也是一样的。
而就是因为这个原因才会有链接推荐样式的顺序方案，一般称为LVFHA，就像下面这样：
这个顺序还可以有另一种玩法，实现的效果是只有未访问的链接才会有hover样式，而且所有链接都会有active样式，就像下面这样：
不过最好的办法就是使用串联的伪类来彻底消除这种情况，为不同的状态设定不同的样式：
不过如果引入了active类的话还是会触发冲突：
如果我们把最后两个active状态移到hover前面，那么它们就会被忽略，当然也是有办法解决的，就是引入更多的伪类：
可能对CSS来说最基本的就是本章所讲的级联机制本身，如何解决冲突，如何实现继承，如何实现排序，都有一套底层的规则在作用。
1、Search Space的引入盲检就意味着费时费力，还增加UE的复杂度，CORESET中的CCE结构虽然有助于降低盲检尝试的次数，但是这并不够，因此，需要某种机制来限制终端假设监听的CCE集合的次数。从调度的角度来说，限制被许可的聚合并不是所希望的，因为会影响调度的灵活性；从UE的复杂度考虑，对于大带宽和大PDCCH集来说，终端监听所有可能的CCE是没有吸引力的。为了尽可能减少限制调度器，并同时希望限制终端盲检的尝试最大次数，就定义了所谓的Search Space：一组候选的控制信道（candidate control channels）集合CCE，它们以一定的等级聚合，终端试图对它们进行解码。
由于聚合等级可以有多种（1/2/4/8/16），所以一个UE可以有多个Search Space。由此可知：一个CORESET可以对应多个Search Space（Search Space Set），而一个Search Space只能对应一个CORESET。
UE监控的PDCCH支持5种不同的聚合等级，所以在每个PDCCH符号中，UE将尝试对每个Search Space中有CCE构成的所有可能的PDCCH进行解码。如果CRC校验成功，则认为该终端解码到了PDCCH，UE将根据PDCCH的内容处理相关信息（调度分配，调度请求）。如果控制信息只在终端Search Space Set中某一个Search Space的CCE构成的PDCCH上进行传输的话，那么网络可以只寻址一个终端。例如，如图1所示，终端A不能在始于CCE序号20的PDCCH上进行寻址，而终端B可以；此外，如果终端A正在使用CCE 16~23调度，那么终端B就不能以聚合等级4进行寻址，这是因为在A的聚合等级4的搜索空间中的所有CCE对其他用户都是禁止使用的。以此可以直观的理解为，当系统中存在足够CCE时，各个终端的搜索空间将不同，因此系统中的每个终端在每个聚合等级上都有一个终端特定的搜索空间。
图1：两个终端的PDCCH搜索空间原理说明
上面说到，系统中的每个终端在每个聚合等级上都有一个特定的Search Space且特定的Search Space是不能重叠的，那么对于一个给定的CORESET而言，USS的数量肯定小于系统中可在相应聚合等级上的PDCCH数目（UE数目）；简单而言，就是在一种聚合等级下，通常没有办法在一个CORESET里面给所有的UE都分配特定的搜索空间（USS）。所以必须存在一种机制，它能够确定每个聚合等级在终端特定搜索空间内的CCE集合。在LTE和NR中，终端特定搜索空间的定义是通过一个终端标识和子帧号的函数来实现的。基于子帧号有助于解决终端之间相互阻塞的问题。在某些情况下，需要寻址系统中一组或者全部终端，比如：系统信息的动态调度，寻呼消息传输等，这就是所有UE都可以用的公共搜索空间。据此，将搜索空间分为两大类： CSS（Common Search Space）和USS（UE specific Search Space）。如表1所示，内容总结来源于TS38.213-10.1。
