## 小計 隱藏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