引言

兼容工具

  1. 后备机制，例如在使用linear-gradient的声明之前使用实色声明一个中间色
  2. Modernizr - 给根元素添加一些辅助类
  3. @support - 但是注意，@support本身的兼容性并不算太好

  4. 使用js自己进行辅助类的添加： ```javascript // 检验某类属性值存不存在 function testProperty (property) { var root = document.documentElement;

    if (property in root.style) { root.classList.add(property.toLowerCase()); return true; } else { root.classList.add(‘no-‘ + property.toLowerCase()); return false; } }

// 检验某个特殊的取值存不存在（给某个元素赋值，检查浏览器是不是还保存着这个值） function testValue (id, value, property) { var dummy = document.createElement(‘p’); dummy.style[property] = value;

  1.     if (dummy.style[property]) {
  2.         root.classList.add(id);
  3.         return true;
  4.     } else {
  5.         root.classList.add('no-' + id);
  6.         return false;
  7.     }

}

  2. <a name="2ad41034"></a>
  3. ### 关于W3C
  5. <a name="96ac53f1"></a>
  6. #### 规范制定流程
  8. 1. **编辑草案（ED）**：这是一项规范的初始阶段，可能非常粗糙，就像是编辑们想法的大杂烩。对这个阶段没有什么要求，也不保证它会被工作组批准。但它也是各个修订版本的必经阶段——每次变更都是先从一个 ED 中产生的，然后才会发布出来。
  9. 1. **首个公开工作草案（FPWD）**：一项规范的首个公开发布的版本，它应该准备就绪，以接受 WG 的公开反馈。
  10. 1. **工作草案（WD）**：在第一个 WD 之后，还会有更多的 WD 出来。这些 WD 会吸收来自工作组和更广阔的社区的反馈，一版接着一版小幅改进。浏览器的早期实现通常是从这个阶段开始的，厂商们基本不太可能对更早阶段的草案提供实验性的支持。
  11. 1. **候选推荐规范（CR）**：这可以认为是一个相对稳定的版本。此时比较适合实现和测试。一项规范只有具备一套完整的测试套件和两个独立的实现之后，才有可能继续推进到下一阶段。
  12. 1. **提名推荐规范（PR）**：这是 W3C 会员公司对这项规范表达反对意见的最后机会。实际上他们很少在这个阶段提出异议，因此每个 PR 推进到下一阶段（也是最后一个阶段）只是时间问题。
  13. 1. **正式推荐规范（REC）**：一项 W3C 技术规范的最终阶段。
  15. <a name="e24b0679"></a>
  16. #### 为什么会有浏览器前缀？
  18. - 为了能够让开发者尝试早期标准，帮助测试一些没有被广泛应用到生产环境的实验特性。
  19. - 但是因为开发者这些带前缀的属性太好用了，于是就开始滥用，甚至使用这类属性成为了潮流。
  20. - 结果而言：开发者为了及时跟进前缀修改，先发制人的加上所有可能的浏览器前缀，导致一行属性要写四行兼容。
  22. <a name="82e11781"></a>
  23. ##### 常见的前缀
  25. - `-moz-` 火狐
  26. - `-ms-`IE
  27. - `-o-`Opera
  28. - `-webkit-`Safari和Chrome
  30. <a name="6ebd8de8"></a>
  31. ### 让样式更灵活的技巧
  33. 1. 对于字号，使用em/rem取代写死的px，思考想要随字号变化的属性，并将那些属性也使用em/rem，减少重复修改。
  34. 1. 对于类似于`text-shadow`或者`box-shadow`这样的属性，使用往上叠加半透明的黑色或者白色的方式，让这些位置跟随背景颜色一起修改。
  36. <a name="c1b56924"></a>
  37. ### 如何做响应式网页设计
  38. <a name="c670a5d1"></a>
  39. #### 为什么不提倡媒体查询？
  41. 1. 每个媒体查询都会增加代码成本。
  42. 1. 媒体查询只是修补某个特定分辨率下的特定问题，并不是从根本上解决问题。
  44. <a name="734d2f0f"></a>
  45. #### 应该如何做？
  47. - 尽量使用百分比长度来取代固定长度，如果不行的话，也应该尝试vw、vh、vmin、vmax等与视口相关的单位。
  48. - 当需要在较大分辨率下得到固定宽度时，使用max-width而不是width，这样较小的分辨率也能看到。
  49. - 同理，应该为替换元素（典型的例如`<iframe> <video> <embed> <img>`）添加一个max-width，值为100%
  50. - 在使用多列文本的时候，指定colum-width(列宽)而不是colum-count(列数)，就可以在较小的屏幕上自动显示为单列布局。
  52. <a name="cb5dae0a"></a>
  53. ### 简写与单项-列表扩散规则
  55. - css的列表扩散规则（list expansion rules）：如果只为某个属性提供一个值，那它会扩散并应用到列表的每一项。
  56. ```css
  57. /* bad */
  58. background: url(tr.png) no-repeat top right / 2em 2em,
  59.             url(br.png) no-repeat bottom right / 2em 2em,
  60.             url(bl.png) no-repeat bottom left / 2em 2em;
  62. /* good */
  63. background: url(tr.png) top right,
  64.             url(br.png) bottom right,
  65.             url(bl.png) bottom left;
  66. background-size: 2em 2em;
  67. background-repeat: no-repeat;

预处理器

好处

  • 在大型项目中可以让代码更加灵活

    坏处

  • css的文件体积和复杂度可能会失控。

  • 调试难度会增加（SourceMap正是为此而生）。
  • 预处理器在开发过程中引入了一定程度的延时。
  • 抽象带来了更高的学习成本。
  • 抽象泄漏原则：所有重大的抽象机制在某种程度上都存在泄漏的情况。

技巧

半透明边框

参见：background-clip-背景的延伸

多重边框

参见：多重边框

条纹背景

待补充