## 小计 隐藏BUG，很难发现 - [去除inline-block元素间间距的N种方法](http://www.zhangxinxu.com/wordpress/2012/04/inline-block-space-remove-去除间距/) - [inline-block 高度问题 bug - 百度搜索](view-source:https://www.baidu.com/s?wd=inline-block+高度问题+bug&ie=UTF-8) https://github.com/uncss/uncss (去除没有用到的css) * * * * * ### css 复用：原子类 和 块 block 复用是指组件可以在其它地方被灵活的复用，就像 bootstrap 中的组件一样。需要注意的是，这里的复用并不是指一个组件里面的某一部分能够被复用，复用是整体的，有的组件设计就是不可被拆分的，是独立的。 我们总是乐观的以为所有 css 都能被复用，甚至认为所有的元素最后都能写成原子类，期望随意组合、一处书写、到处复用，每次总想努力写出最具通用性的类，想要一劳永逸，放之四海内皆准、推之百世而不悖，以为 css 复用 就是万能的银弹。 可是随着经验增加，才发现其实块（组件）只是复用的最小单元而已，除此外就不要期望其它复用了，否则带来的都是麻烦。（当然你也可以把 btn 这个原子类当作最小的块，这也不是不可以，但是不应该含有业务逻辑，它就是原子类） 诚然，原子类很有用，bootstrap 里面大量使用了原子类（原子类就是不带业务的元素类，如 btn），但任何东西都有它的适用范围，原子类解决了大量的非业务属性的样式复用，但是一个项目是由多个业务组成的，页面是由业务组件填充的，所以就要考虑业务组件的复用性，此时原子类就不是银弹了，**如果业务组件的复用依靠原子类，那么代码将变得脆弱难以维护**，会存在大量的样式重写覆盖，作用域层级嵌套计算，这样就会慢慢变成 “[这个CSS重写一遍比修改老文件快](https://www.zhihu.com/question/21935157)” 的情况了。 如果把前端 UI 的开发比作建房子，那么原子类就是水泥，块就是砖、钢筋、地板、门窗等，这些都是可以被复用的，且不可分割，比如门把手离开门就没有意义了，而水泥抹在砖上砌成墙，就如同原子类也经常抹在块上一样。水泥很强大、灵活，哪里需要哪里抹，但是只有水泥，没有砖和门窗也建不成房子，只有灵活使用，互相结合才能发挥最大的效率。 > 以上是没遇见 Tailwind 之前的感想。Tailwind 的原子类就像物理中的原子一样，能够随意组合，形成任何物质。 ---- 我觉得这不是绝对的，语义化和原子类并不是水火不容的，应该融合使用才有更好的效果。 [快速掌握 Tailwind：最流行的原子化 CSS 框架 - 知乎](https://zhuanlan.zhihu.com/p/628433321)  https://tailwindcss.com/ > 越业务无关 ，适用性越强，越稳定。 [Tailwind CSS CSS Utility Classes and "Separation of Concerns" CSS 实用类和“关注点分离” ](https://adamwathan.me/css-utility-classes-and-separation-of-concerns/) > 组件做的事情越多，或者组件越具体，重用就越困难。 [要喷也得先做做功课吧？驳Tailwind不好论 - 掘金](https://juejin.cn/post/7281444255121113103) > 语义化 是高内聚、逻辑主义思维，原子化 是低耦合、发散主义思维。前者是定制，后者推崇的是组合。两者并非水火不容，应当客观看待。BEM 为高内聚思维指定了方向。 [如何看待 CSS 中 BEM 的命名方式？ - 知乎](https://www.zhihu.com/question/21935157) > BEM/OOCSS 风格对维护重用的class有极大帮助,适当的拆分block后组合,威力无穷 > BEM除了是一种新的命令方式之外，我个人认为他还是提出了模块与模块，组件与组件，模块与组件之间的管理方式。如何通过一种命名方式更好的管理和维护他们。 理想的css命名规则，块为单独的个体，块下的所有元素 命名都视为同级的，也就是说 所有元素都是直接从属块的，哪怕有其它层级也不需要在名称和css中体现出来，这样我们就只用关心业务元素，而不用关注元素的层级关系了，这样更灵活，也更易于维护，即 整个块只有二级 css，这样保证了 层级深度不会过深，同时直观的体现了 元素与块的关系，需要注意的是，元素命名需要具体，块下不能冲突，根据 业务类型（所在层级也可以考虑，但名称不要含有层级的语意，不然就又回到原来的问题了，把层级深的问题转移到了名称长的问题上来了）等，但一定要避免名称过长，只要保证块内不冲突就行了。 元素的类名就是它本身的含义，与它的所在层级上下文无关，只与它自己有关，与它自己的存在的意义有关，要关心自己而不是在意别人的看法，这是重点。 元素名称需要包含块名称（为了保证块被别的块嵌套使用时css不会冲突覆盖），css写时 `block block__e {}`，只有两级 这样写出的代码，可以很方便复用（复用块），块可以被复用而不用在乎在页面哪个位置复用，也不用担心在不同位置使用会影响块内元素样式。 约定规则： 1 \_\_ 双下划线代表B和E连接例如 menu\_\_item 2 \_ 单下划线代表B和M或E和M的连接 例如 menu\_active 或 menu\_\_item\_active 3 \- 中划线同英语里做连字符例如 mod-menu 或 mod-menu\_\_item 这里 B或E或M需要多个单词来描述,就使用中划线 约定规则 - 1 使用 双中划线 也可以 `block block--e {}`，`block_m block--e-r_m {}` 不过这样好像有点丑哈，没 `block_m block__e-r_m {}` 好看。  看着这越来越长的类名，你就知道遵循一种命名、组织规范有多重要了。—— 规范不仅是命名规范，而是命名与组织的规范，只不过最容易体现在命名上而已，不要因为这点而忽视了真正的组件与组织的核心意义。 * * * * * 有些类是容器类，有些是业务名词语义类，有些位置方向等类。总之不要忘了，任何事情都可以分门别类，世界绝不是杂乱无章的。 * * * * * css只是css，它只管它代码控制范围能力内的样式，只作用效果在它控制的元素上，它才不管你把它应用于哪里。 任何事情都是那么直白的，**尤其是计算机**，如果你把它当做感性的东西看，那么你就是笨蛋。 这么来看，任何程序的代码都是这样的，比如PHP脚本，你写了它，只是一种形式而已，运行时它被加载到内存了，此时你可以删除它都没问题的，内存中的程序不会受影响，你写的代码只是描述了如何生成内存中的程序而已，所以你要明白，你写的代码只是一种形式的体验而已，最终运行的是加载到内存中的程序。 * * * * * [CSS的诞生](http://mp.weixin.qq.com/s/wYTejsTjHldDMKJ7QqCYBA) [CSS: 潜藏着的 BFC](https://mp.weixin.qq.com/s/5no5IcsgpabgK89ioO8xNQ) * * * * * 小技巧： ```css .sort-group .sort-tag:hover { color: #e4393c; border-color: #e4393c; /* 这个小技巧可使元素触摸时在最上面 */ position: relative; } ``` hover只是临时增加了一个优先级，如果再加个优先级更高的，那么触摸也不行 * * * * * ### 从CSS复用参悟代码的本质 >[info] 见微知著，一叶知秋。 > 越大型的系统，耦合度越高，越容易模块化，越容易复用。 在书写样式时为了提高复用性，一般把共用部分抽取出来做原子类，比如m-l，t-c等。**通常上网站特异性（差异性）的部分占比不大**，几乎68%的css都可以抽出共性做原子类，但是这样就是重(zhong)组合了，显而易见的缺点就是过度使用组合会导致类名过长不好维护。 所以需要在复用这个点上取一个平衡。 我们只把出现频率非常高的共用部分抽取出来做原子类，**大部分代码还是当做特异性部分对待（单独的样式）**。这样虽然没有最大程度的复用代码，但是我们写代码的最终目的不是为了写代码而写代码（不是为了设计而设计，不是为了设计模式而套设计模式），而是为了解决实际问题，并且是要高效地解决问题。理解清楚这一点很重要，这就是写代码这件事物的本质，否则你并不知道自己在干什么。 > 大多数人并不知道自己在干什么。 —— 王垠 关键字：CSS复用，组合，共用部分，特异性部分，原子类，事物的本质 * * * * * ### 选择器层级讨论 先思考选择器、层级有哪些特性 1. 一般来说选择器的层级不能过深，据说过深在解析渲染时会有性能问题 2. 层级会限制作用域，类似于PHP中的命名空间的概念 3. 层级会影响优先级的计算（多一层权值就会多一点） 而我们面临的棘手问题： 1. 命名 2. 作用域 1：我们总是苦苦思索合适的命名，同时不得不担心会与已有的名称发生冲突。 2：我们也讨厌很深的层级，倒是希望所有的都是一层才好，但是这样有两个缺点，**一是不容易区分模块，二是我们常习惯于使用层级作用域来避免样式冲突的问题。** 所以，我们喜欢使用层级，然后再起一个合适的名字。 **但是这个层级到底几层才最合适呢？** ```css 小明爷爷 > 小明爸爸 > 小明 { } ``` 显**然层级很大程度上是由结构关系决定的**，但是说能保证实际结构都很浅呢？ `小明太太爷爷 > 小明太爷爷 > 小明曾爷爷 > 小明爷爷 > 小明爸爸 > 小明` *(完整的html结构关系，实际项目中可能会更复杂)* 虽然我们开发时可以尽量去避免，但是得承认这很难完全的避免。 那这个时候怎么办呢？ 再回想一遍我们的棘手问题，命名似乎不是问题了，那么就剩一个作用域了。 我们要定位这里小明（**局部而非全局的小明**），其实只需要两层就可以了： ```css 小明太太爷爷 > 小明 { } ``` `小明太太爷爷` 就是给 `小明` 充当父级，限制作用域的。 这样我们的目的也达到了，层级不会那么臃肿冗长了。 **而如果不是为了解决冲突，或者说没有冲突要解决的话（只当有冲突出现是才需要父级作用域来解决），那就无需父级来限制作用域，直接一级就可以了：** ```css 小明 { } ``` 这样最简洁直观。css不同于html，它有自己的运行方式，它不需要那么死板，那么固执，那么循规蹈矩的非要套层级结构，根本就没有必写完整的结构嘛。所以不要有思维定性，写css时应该站在css的角度，去考虑css的特性。**（没有必要那么死板，我们把这种方式叫做`节约层级`）** 分析完。 > 补充：尽量少用过深的层级，Google的网站就很简洁，基本上所有元素都是一层，哪怕把类名写长一点，不要为了显示元素的身份（元素的上下文）而故意加上层级关系，不要觉得这样看起来直观一些，这样的层级结构只是人看起来比较直观而已，对计算机来说，没有任何意义。很多时候，人赋予代码的意义，对计算机来说，并不感冒。 > > 另外，避免层级关系可以很方便的实现组合，这也符合了“少用继承，多用组合”的原则。 [好的 CSS 命名规范可以节约 Debug 时间](http://mp.weixin.qq.com/s/xfmGC3K1BnxIULCcsBWFOA) > 如果定义头上的头发，手上的指甲该怎么定义，属于元素吗？ * * * * * ### css的界限 虽然css可以做很多东西，一些ico图标都可以做，那么是不是意味着这些就可以使用css做呢。 这其实就越界了，不是因为能力越大就要做很多事，各司其职，做好自己的事情就好了。 要保持html结构的语义化，高效，简洁。 不能为了表现层样式，而多出一些与结构层无关的东西。 该使用图片时就要使用图片，一个图标就是一个图标，html结构上就是一个标签，<i></i>就可以了，不要多出其它的东西。不论使用字体图标，还是背景图片都可以。 [css动画：纯css实现灰太狼头像制作](https://www.toutiao.com/a6419082584994775297/?tt_from=weixin&utm_campaign=client_share&timestamp=1516060308&app=news_article&utm_source=weixin&iid=22069500288&utm_medium=toutiao_android&wxshare_count=1) > 虽然它也可以做，但是显然，这不是它应该做的事情。为了一个图像弄一大堆dom结构处理不好。 * * * * * ### rem动态尺寸的奥秘所在 相较于px，rem可以是动态的。因为rem是相对于root的，即相对于 `html{font-size:xx}` 的，但仅仅是这样，rem也就和px无异了，也不是动态了。 那怎么说rem是动态的呢？ 答案是：我们可以动态控制 root `html{font-size:xx}`，比如利用 `css媒体查询的响应式` 和 `js` 动态控制 `root font-size` 达到动态rem的效果。因为rem受root影响，root是动态的了，那么rem自然也就成动态的了，**通过控制一个root而影响所有的rem**，这就是rem实现动态的方法。而显然px无法做到这点的，这也就是越来越多的网站在用rem替代px的原因。 ```css /*多分辨率设定rem设定*/ html { font-size : 20px; } /*Note3*/ @media only screen and (min-width: 360px) { html { font-size: 22px !important; } } /*iPhone6*/ @media only screen and (min-width: 376px) { html { font-size: 23px !important; } } /*iPhone6 plus*/ @media only screen and (min-width: 414px) { html { font-size: 25px !important; } } /*big Resolution*/ @media only screen and (min-width: 641px) { html { font-size: 25px !important; } } ``` * * * * * 拼多多手机页面的适配部分 ```css @media only screen and (max-width: 480px) { html { font-size:128px } } @media only screen and (max-width: 414px) { html { font-size:110.4px } } @media only screen and (max-width: 412px) { html { font-size:109.87px } } @media only screen and (max-width: 400px) { html { font-size:106.67px } } @media only screen and (max-width: 393px) { html { font-size:104.8px } } @media only screen and (max-width: 375px) { html { font-size:100px } } @media only screen and (max-width: 360px) { html { font-size:96px } } @media only screen and (max-width: 345px) { html { font-size:92px } } @media only screen and (max-width: 320px) { html { font-size:85.33px } } html { font-size: 26.66667vw; -webkit-text-size-adjust: 100%; -ms-text-size-adjust: 100%; text-size-adjust: 100% } @media only screen and (min-width: 640px) { html { font-size:170.67px } } ``` （注意也用了`vm`） 这些都是通过媒体查询来更改`html的font-size`，不过这样做始终不够灵活，不够细腻，最好的方式还是监听窗口大小，自动更改`html的font-size`那种适配方式，也就是淘宝的Flexible方案。 * * * * * [前端开发 巧用CSS3的calc()宽度计算做响应模式布局](https://www.toutiao.com/a6508875567876538883/?tt_from=weixin&utm_campaign=client_share&timestamp=1515523753&app=news_article&utm_source=weixin&iid=22069500288&utm_medium=toutiao_android&wxshare_count=1) > 只要不固定的东西就是响应式比如 100% [css3的字体大小单位\[rem\]底好在哪？ - 知乎](https://www.zhihu.com/question/20312140) * * * * * ### css类命名思考 命名可以抽象可以具体，一般来说，抽象可以往两个方向抽象，一个是 **具有业务逻辑属性的** ，比如 `.login-box`、`.goods-list` 等，还有一种就是 **不考虑业务属性** ，比较通用的抽象比如 `.nctouch-default-list` 、`.btn`这样的命名 **不含有任何逻辑属性** ，比较通用。 其实不论哪种命名，都在 **带有业务属性** 和 **不带有业务属性** 中间徘徊。 * * * * * ### CSS-in-Javascript 目前 React 社区仍然没有就如何有效管理组件样式这个问题达成共识，即没有标准的解决方案。 如果无需太多自定义的标准样式，可以用 Material UI 或 Ant Design 这样现成的组件工具包。如果需要更高度灵活的自定义，你仍然能使用传统方式：用一个像 Bootstrap 或 Bulma这样的全局 CSS 样式，通过修改组件的 className 属性来达到目的。这样做缺点是组件无法进行自我样式管理，因为样式分布在单独的文件中。 CSS in JavaScript 概念的出现即是为了解决上述问题。 概念本身很简单：既然我们在 React 中己能通过 JavaScript 来同时控制逻辑和模板部分，何不再进一步，连样式也一并管理了呢？ Styled Components 是今年本类别的冠军，它利用 JavasScript 最近新加入的模板字符串特性，让开发者在 React 组件中直接使用标准的 CSS 语法编写样式。 CSS Modules，作为本类别的亚军，则采用了混合的解决方案。它让开发者自己挑选诸如标准 CSS, SASS, NO slug Less, NO slug Stylus等方式编写样式，再以文件的方式导入到组件中。 Mark Dalgleish，CSS Modules的作者，写了一篇有意思的文章来阐述 CSS-in-JavaScript 解决方案：[A Unified Styling Language](http://www.zcfy.cc/original/a-unified-styling-language-seek-blog-medium-2982.html)。如果你对 CSS-in-Javascript 解决方案仍持怀疑态度的话，那此文绝对不容错过。 [2017 年崛起的 JS 项目](https://mp.weixin.qq.com/s/qIfO2hScqVIZ9zkYgkqVBg) * * * * * [优雅地写 CSS](http://mp.weixin.qq.com/s/n_oDJD9zE6DH03dvvEV6Jw) > 我们推荐在创建用于特定 JavaScript 的类名时，添加 .js- 前缀： （这种方法其实也会有弊端，如果js效果很多的地方，那么就需要加很多这种类名了。并且现在基本很多地方都有效果，一两处还好，要是都这样处理那真是太麻烦了） [CSS: 潜藏着的 BFC](http://mp.weixin.qq.com/s/5no5IcsgpabgK89ioO8xNQ) [现代 CSS 进化史](http://mp.weixin.qq.com/s/mPxVFoUV_5ZsyoyxjtPIEQ) > 在我们深入分析CSS规范前，首先要搞清楚是什么让CSS随着时间推移变得更加难维护，关键点是CSS是全局性的——你定义的每个样式都会全局应用到页面的每个部分，用一个命名约定来保证class名称的唯一性或者有特殊的规则来决定指定样式应用到指定元素。CSS规范提供了一个有组织性的方式来避免大量代码时出现的这些问题，让我们按照时间顺序来看看主流的一些规范吧 > 这些命名方式，感觉就是招式，而bootstrap、原子类，修饰类等，把作用域，优先级用得出神入化，感觉就是无招胜有招，没有既定的形式，剑在心中。 [不知道层叠，别说你懂CSS（层叠样式表） - 不挑食的程序员 - SegmentFault 思否](https://segmentfault.com/a/1190000013431781?_ea=3378441) [学习CSS布局](http://zh.learnlayout.com/) [看到这篇，CSS命名从此不在纠结](https://www.toutiao.com/a6533831498968072711/?tt_from=weixin&utm_campaign=client_share&timestamp=1521310025&app=news_article_lite&utm_source=weixin&iid=25315997380&utm_medium=toutiao_android&wxshare_count=1) [CSS-in-JS，向Web组件化再迈一大步](https://www.toutiao.com/a6540411810862858766/?tt_from=weixin&utm_campaign=client_share&timestamp=1522831283&app=news_article_lite&utm_source=weixin&iid=25315997380&utm_medium=toutiao_android&wxshare_count=1) > css广泛使用类名，而类命是具有语义的，根据css的特性，所以css也是具有语义并高度灵活的。但cssjs为了避免css污染，竟然牺牲掉了它的语义性，这样css就丧失灵活性的优点了。 [styled-components —— React 中的 CSS 最佳实践](https://zhuanlan.zhihu.com/p/29344146) * * * * * ### 几个css小细节 ```css -webkit-appearance: none; // 取消浏览器元素默认样式 -webkit-tap-highlight-color: transparent; // 取消移动端点击时出现的高亮颜色 outline: 0; //防止某些浏览器上元素获得焦点时出现轮廓 -webkit-backface-visibility: hidden; // 使用CSS transforms 或者 animations时可能会有页面闪烁的bug ``` [被遗忘的CSS](https://mp.weixin.qq.com/s/OwOfsshZIyn8-JVrsCVDxg) * * * * * [Bootstrap栅格系统详解,响应式布局 - 流风，飘然的风 - 博客园](https://www.cnblogs.com/zdz8207/p/Bootstrap-row-container.html) > Bootstrap 栅格系统的精妙之处, 通过container, row, column都有15px的padding槽边和 row的margin -15px设置，巧妙实现在 column 中嵌套 row进行nesting 扩展(超过12列)，而不需要再套一层 container * * * * * ### 优先级覆盖：媒体查询的书写顺序要注意 ```css @media (min-width: 768px) .container { width: 750px; } @media (min-width: 992px) .container { width: 970px; } @media (min-width: 1200px) .container { width: 1170px; } ``` 因为优先级的原因，大的，值要从小到大写，不然会被覆盖。同理，小的值就要从大到小的顺序来写。 * * * * * 当无法抽出共性的时候先用css选择器分组。 公用，很多页面都会用到的，两个页面共用的，三个页面共用的，...。两个及以上页面共用的，都算共用。任何东西都有一个度，都不是绝对的，公用情况也有一个度，公用率，在0%~100%之间。 * * * * * ### 天生具有自适应特性的元素：img [移动端前端适配方案对比 - 简书](https://www.jianshu.com/p/e5ca5b78e03e) >[danger] 高度定死，宽度自适应（这样会怪怪的，很丑，如果是图片的话会被拉伸的，**反而不固定高度的话，利用图片特有的特性，图片会按照原图宽高比例进行等比缩放，自适应的**，但是这样在图片未加载完毕时没有宽高，会有闪动问题，不过可以利用预先设置好比例的占位图base64形式来做，原本图片也按照相同比例进行处理，这样就解决了闪动问题。同时resize时还能自适应，而无需用js来resize动态计算设置了等比宽高了。） 利用图片这个特殊的元素特性（**只设置宽或者高的话，没被设置的宽/高就会按照原图宽高比例进行自动缩放**，图片拉伸的原因都是违背了原生宽高的比例，**所以尽量不要给图片设置固定的宽或者高，或者不要同时设置，一般只需要设置宽就可以了，宽往往设置为百分比比较好**），设置宽就能自动的缩放，自动算出等比例的高度。利用这点可以做自适应，做一个占位图还可以做出解决图片未加载出来时的闪动问题。并且也是自适应的。 css有个属性能够取得元素的属性，如果能够取的宽，那么再利用计算属性，就能设置自动变化的高度了。不然通常我们很容易设置自适应的宽，但是固定的高就会很丑了。 * * * * * todo：截断问题，手机上查看PC页面不正常。 [为什么不会有CSS4了？](https://mp.weixin.qq.com/s/rQEN6rz2mLtN-Br6wNN-WQ) [不可思议的纯CSS导航栏下划线跟随效果](https://mp.weixin.qq.com/s/27WI_xQTy8-3SDpDTo62Qg) [歪果小姐姐教你用代码画画，真大佬！](https://mp.weixin.qq.com/s/DORExxxpszasCjWOIW4c6g) * * * * * last update：2018-7-1 10:57:28