《CSS揭秘》笔记（一）
前言
我们在现代 CSS 中所面临的挑战已经不在于如何绕过这些转瞬即逝的浏览器 bug。如今的挑战是，在保证 DRY ① 、可维护、灵活性、轻量级并且尽可能符合标准的前提下，把我们手中的这些CSS特性转化为网页中的各种创意。这正是这本书将要呈现的内容。——引用自前言
①DRY 是 Don’t Repeat Yourself 的首字母缩写，意思是不应该重复你已经做过的事。它是一种广为流传的编程理念，旨在提升代码某方面的可维护性：在改变某个参数时，做到只改尽量少的地方，最好是一处。强调 CSS 代码的 DRY 原则是一个贯穿本书的主题。DRY 的反面是 WET，它的意思是 We Enjoy Typing（我们喜欢敲键盘）或 Write Everything Twice（同样的代码写两次）。
全书都是以前言这段话为基础，根据不同场景下的各种问题给出更有创意的实现方案，一共包含了47篇攻略，按主题分为 7 章，每篇攻略至少会附上一个在线示例，在线示例一定不能错过，对案例的理解有很大帮助。
虽然建议是作为进阶阅读，但是每篇攻略都贴心的提供了背景知识提示，不管能否完全看懂，仍然可以开阔思路。
ps：有兴趣想看这本书的可以联系我分享pdf电子版（仅供学习使用，还是呼吁大家支持正版书籍），笔记基本就是摘要==巩固知识，阅读完整书籍才能达到更好的学习效果。
第一章 引言
Web 标准：是敌还是友
标准的制定过程
- 编辑草案（ED）
- 首个公开工作草案（FPWD）
- 工作草案（WD）
- 候选推荐规范（CR
- 提名推荐规范（PR）
- 正式推荐规范（REC）
浏览器兼容性
推荐以下网站查证浏览器对CSS属性的支持情况：
浏览器前缀
通过在名称前面加上浏览器特有的前缀，就可以自由地尝试使用不同浏览器实现的一些实验性的（甚至是私有的、非标准的）特性，工作组会将收到的反馈吸收到规范之中，并且逐渐完善该项特性的设计。然而这种方式产生了很多弊端，例如随着规范的修改要来回打补丁修改，代码冗余不利于维护等。
最近，浏览器厂商已经很少以前缀的方式来实验性地实现新特性了。取而代之的是，这些实验性特性需要通过配置开关来启用，这可以有效防止开发者在生产环境中使用它们，因为你不能要求用户为了正确地浏览你的网站而去修改浏览器设置。当然，这会导致一个后果：尝试这些实验性特性的开发者会减少；但我们仍然会得到足够多的反馈，甚至是更高质量的反馈（你可能会质疑），同时还避免了浏览器前缀的所有缺点。不过我们还需要很长的时间，才能从浏览器前缀所引发的涟漪效应中解脱出来。
CSS 编码技巧
尽量减少代码重复
代码可维护性的最大要素是尽量减少改动时要编辑的地方，当某些值相互依赖时，应该把它们的相互关系用代码表达出来。例：line-height: 1.5;。
代码易维护 vs. 代码量少。
currentColor：它是从SVG 那里借鉴来的一个特殊的颜色关键字。它没有绑定到一个固定的颜色值，而是一直被解析为 color，这个特性让它成为了 CSS 中有史以来的第一个变量。
inherit （继承）：很容易被遗忘，可以用在任何 CSS 属性中，而且它总是绑定到父元素的计算值（对伪元素来说，则会取生成该伪元素的宿主元素）。
tips：推荐使用 HSLA 而不是 RGBA 产生半透明的白色，因为它的字符长度更短，敲起来也更快，这归功于它的重复度更低。
相信你的眼睛，而不是数字
人的眼睛并不是一台完美的输入设备，有时候精准的尺度看起来并不精准，而我们的设计需要顺应这种偏差。
在视觉设计领域广为人知的例子：我们的眼睛在看到一个完美垂直居中的物体时，会感觉它并不居中，实际上，我们应该把这个物体从几何学的中心点再稍微向上挪一点，才能取得理想的视觉效果。
关于响应式网页设计
每个媒体查询都会增加成本，用对了它就是利器。
我们的思路是尽最大努力实现弹性可伸缩的布局，并在媒体查询的各个断点区间内指定相应的尺寸。当网页本身的设计足够灵活时，让它变成响应式应该只需要用到一些简短的媒体查询代码。
如果你发现自己需要一大堆媒体查询才能让设计适应大大小小的屏幕，那么不妨后退一步，重新审视你的代码结构。因为在所有的情况下，响应式都不是唯一需要考虑的问题。
以下建议可能会帮你避免不必要的媒体查询：
- 使用百分比长度来取代固定长度。如果实在做不到这一点，也应该尝试使用与视口相关的单位（ vw 、 vh 、 vmin 和 vmax ），它们的值解析为视口宽度或高度的百分比。
-
em：相对于当前对象内文本的字体大小。
-
rem：r是"root"的缩写，意思是 1rem 等于根元素的字体大小；大部分情况下，根元素就是
<html>元素。rem 也可以用基于 html 根元素字体大小的 rem 作为整个网格布局或者UI库的大小单位.container { width: 70rem; // 70 * 14px = 980px}。 -
vw：1vw 等于 1/100 的视口宽度。
-
vh：1vh 等于 1/100 的视口高度。
-
vmin 和 vmax：是 vw 和 vh（视口高度和宽度）两者的最小或者最大值。
-
ch：单位通常被定义为数字 0 的宽度。
-
ex：定义为当前字体的小写x字母的高度或者 1/2 的 1em。 很多时候，它是字体的中间标志。
-
pc：1pc 等于 12 点。
-
pt：1pt 等于 1/72 英寸。
-
当你需要在较大分辨率下得到固定宽度时，使用 max-width 而不是 width，因为它可以适应较小的分辨率，而无需使用媒体查询。
-
不要忘记为替换元素（比如 img 、 object 、 video 、 iframe 等）设置一个 max-width，值为 100%。
-
假如背景图片需要完整地铺满一个容器，不管容器的尺寸如何变化，background-size: cover 这个属性都可以做到。但是，我们也要时刻牢记——带宽并不是无限的，因此在移动网页中通过 CSS 把一张大图缩小显示往往是不太明智的。
-
当图片（或其他元素）以行列式进行布局时，让视口的宽度来决定列的数量。弹性盒布局（即 Flexbox）或者 display: inline-block 加上常规的文本折行行为，都可以实现这一点。
-
在使用多列文本时，指定 column-width （列宽）而不是指定 column-count（列数），这样它就可以在较小的屏幕上自动显示为单列布局。
合理使用简写
合理使用简写是一种良好的防卫性编码方式，可以抵御未来的风险。
当我们要明确地去覆盖某个具体的展开式属性并保留其他相关样式，那就需要用展开式属性。
展开式属性与简写属性的配合使用，可以让代码更加 DRY。
我应该使用预处理器吗
预处理器为 CSS 的编写提供了一些便利，比如变量、mixin、函数、规则嵌套、颜色处理等。如果使用得当，它们在大型项目中可以让代码更加灵活，而 CSS 自身在这方面确实有很大局限。只要我们在代码健壮性、灵活性和 DRY 方面有追求，就会感受到 CSS 在这方面的局限。不过，预处理器也不是完美无缺：
-
CSS 的文件体积和复杂度可能会失控。即使是简洁明了的源代码，编译后也可能会变成一头巨兽。
-
调试难度会增加，因为你在开发工具中看到的 CSS 代码并不是你写的源代码。不过这个问题已经大大好转了，因为已经有越来越多的调试工具开始支持 SourceMap。
-
预处理器在开发过程中引入了一定程度的延时。尽管它们通常很快，但仍然需要差不多一秒钟的时间来把你的源代码编译成 CSS，而你不得不等待这段时间才能预览到代码的效果。
-
每次抽象都必然会带来更高的学习成本，每当有新人加入到我们的代码库中，这个问题都会重演。
-
抽象泄漏法则：“所有重大的抽象机制在某种程度上都存在泄漏的情况。”预处理器是由人类写出来的，就像所有由人类写出来的大型程序一样，它们有它们自己的 bug。这些 bug 可能会潜伏很久，因为我们很少会怀疑预处理器的某个 bug 才是我们 CSS 出错的幕后元凶。
-
还可能导致不自觉地“依赖”和“滥用”。在某些时候，预处理器并不必要，比如在小型项目中；或者在未来，说不定预处理器最受欢迎的那些特性都被加入了原生 CSS 中。为了避免可能发生的“依赖”或“滥用”，在引入预处理器的问题上需要冷静决策，不应该在每个项目一开始时就不动脑筋顺着惯性来。
已经有很多受预处理器启发的特性都已经以各种方式融入到原生 CSS 中了，原生特性通常比预处理器提供的版本要强大得多，例如：calc() 函数和 color() 函数。
掘金：《CSS揭秘》笔记（一）
博客园：《CSS揭秘》笔记（一）
