欲練JS，必先攻CSS——前端修行之路

　　今天我講的主題是css，具體聊一下我大概的css學習歷史，分享一些乾貨，但願此次分享對你們有所啓發和幫助。

我的的css歷史：

　　說說本身的css學習的歷史，12年，當時是老師手把手1對1教我div+float的固定佈局，全部元素所有用float，作了學生會網站的所有前端頁面，由於有段時間學PS比較多，也是本身作的UI，很醜，老師說第一次作成這樣很不錯了，那時老師就以爲我有作前端的天賦，我就是從這個時候開始接觸前端的。畢業設計本身一我的作了一個全棧的web，作完整個畢業設計後，我就決定出來要作前端，感受本身更喜歡。14年出來工做，那時候還不會用什麼less，就是直接寫css，那時候主要仍是寫固定佈局的pc頁面，14年末本身在項目裏折騰，用了一下JQmobile，超級難用。15年作一個移動端項目的時候，調研了幾個css庫，學習了bootstrap和它部分源碼，還用到了webfont，使用流式佈局這一次提高很大再後來學習了rem，並用到了項目中，至此個人css就到了一個緩慢成長期，或者說就沒有特地學習css了。

乾貨

下面來講一些，我平時比較注意的細節、技術點，和一些你們可能不是很熟悉的知識點。

 

1.box-sizing: border-box

　　box-sizing主要有兩個值content-box和border-box，先看下官方的解釋：

 

通俗一點來講，默認狀況下，padding和border是會額外佔據空間的，假如元素寬是10px，若是設置了1px border邊框，實際的寬就是12px，padding同理。那麼這樣會致使，佈局的寬高很差控制，計算也特別麻煩。因此咱們會給全局的元素用上border-box， 只要設置了寬高，那麼border和padding不管怎麼變化，元素的寬高都不會變，這樣方便佈局和計算。

 

2.左邊固定 右邊自適應

在佈局的時候，好比一些列表頁，經常左邊是一個固定大小的縮略圖，右邊剩餘部分展現標題，如圖

那咱們就叫左邊固定右邊自適應的佈局吧，個人方法 100%寬的div用padding-left把左邊圖片的位置留出來，div元素內容的部分就是標題，圖片絕對定位到padding-left區域，這樣就實現了左固定右自適應，（前提是box-sizing必須是border-box，不然padding加上100%寬會超出屏幕寬度），大體代碼以下：

 

3.僞類的 content attr

僞類before,after的content屬性，是用來插入內容的，咱們能夠經過attr 傳入一個當前元素的屬性名，把屬性值，載入進僞類內容，這個是一種寫法，但實際應用場景可能並很少，就當瞭解一下吧

 

4.中文符號居中效果

對於動態輸出文字能夠不用在乎，某些頁面可能會有相似提示文案的地方，用英文標點符號，對於居中效果比較友好。

 

 

5.元素的上下間距

佈局的時候從上往下開始寫頁面，通常都是寫下一個的元素margin-top來決定和上一個元素的間距，那麼就儘可能不要又是寫margin-top又是寫margin-bottom，若是混着用，後期很差維護，好比某一塊區域須要摞位置，或者是一個組件可能會被不少地方共用，混着寫的話後期在改的時候，可能會麻煩一點，這裏致使的問題能夠說不痛不癢，可是無論是js仍是css，注重細節並養成好的習慣，是代碼能力的一種體現。

 

6.字體顏色透明

有時候設計師，在配置字體顏色的時候可能用透明的百分比，來設置幾種不一樣的顏色，好比主色是#000，淺灰色#000 80%的透明度，這種狀況下不建議web寫透明度，而是讓設計師給到對應的顏色值，由於透明色會根據背景的不一樣，好比如今看到的這種狀況，這樣擴展性就比較差。

 

 

7.命名

命名是一個讓人最糾結的事情，先看第一種,這樣命名的更詳細能夠一目瞭然的知道當前類的意思，可是長度比較長，增長代碼量。

 

第二種使用縮略命名，會使代碼更短，寫起來更快，可是不易讀。

 

 

若是用縮略命名，能夠約定文檔，有約定和熟悉成本，可是熟悉之後更高效，類的命名也會變得更規範和統一

 

8. 0.5px邊框的理解誤區

我以前寫邊框的時候就發現，只要讓邊框的顏色更淡，邊框看起來就更細，因此當設計師問我爲何邊框看起來比較粗的時候，我都告訴他們顏色調淺一點就行了，這個技巧我一直在實際使用。網上有博客說經過css3 transform的縮放scale 50%，能夠實現0.5px邊框，我一直很奇怪，1px實際是物理的最小單位，怎麼可能實現0.5px，就這樣我作了個實驗，我設置了1px顏色爲000的邊框（黑色）,如圖，

 當我使用scale縮放50%的時候，顏色變成了c5c5c5，可是實際仍然有1px。如圖，

我用的是拾色工具會精確到像素，確實仍是1px，因此這種方式並不能實現0.5px而是顏色變淺了。還有些手機屏幕上1px是按照2px來的展現，因此這種方式可讓2px縮放爲1px，讓1px的邊框變得更淡，這種方式確實能讓邊框變細，但不能說是0.5px。

 

9.user-select:none

該屬性讓區域內容沒法被選中,能夠阻止用戶長按複製,也能夠避免用戶複製無關內容，好比下面我只但願用戶複製6655驗證碼，除了6655我都設置了user-select:none，長按其餘部分並不會出現複製按鈕，按鈕數字就能夠，而且第三幅圖的左右下標只能在6655間拖動

 

10.js-class

在爲dom綁定事件的時候，你們可能會直接綁定當前有樣式的class，這樣會由於修改或者替換class名稱，影響JS，而若是定義一個無樣式的js前綴的類 專門用來綁定事件，這樣就解除了樣式和邏輯的耦合，在讀代碼的時候，也能一會兒看出哪些元素綁定了事件的。

 

11.公共類組合寫法

 　　好吧，這是我本身命名的，咱們先看下第一種寫法，這很常規，全部樣式寫在一個class裏

再看下第二種，定義一個公共類，經過less在樣式裏直接引入這個類，第二種效率會高一點（少寫幾個字母），可是須要熟悉和維護公共類

 

 再看第三種，把公共類寫在元素的class裏，這一種比較靈活，好比我如今要寫兩個item的元素，一個左浮動，一個右浮動，那麼這種就能不改動item，而直接使用不一樣的類實現不一樣的樣式，就像JS的代碼去重同樣，傳入一個不一樣的參數進行區分，同樣的地方共用。

第四種公共類所有寫在元素裏， 在寫dom的時候都不用去寫css了，直接把想要的類寫進dom，是否是有點像JS裏的組件化，這種寫法在特定狀況下比較高效，好比PC後臺類項目，對UI要求不高，就比較適合，這個高效也取決於公共class類是否全面，對項目中的class是否熟悉，可是也要注意不要讓元素的長度太長，儘可能保持在4個類之內，超出的話就不該該用這種寫法。

 

這四種寫法其實均可以，在一個項目中，針對不一樣的部分均可以用不一樣的寫法，能夠很是靈活的選擇想要的方式。

 

12.rem佈局的文字大小

你們都知道瀏覽器通常不會讓文字小於12px，若是設置小於12px瀏覽器都會顯示12px， 咱們在用到rem佈局的時候，元素是會根據屏幕寬度等比例縮放的，好比設計師給到750px的設計稿，若是某一個元素文字是22px，那麼當用戶的屏幕寬度是375的時候，文字會縮放爲11px，實際瀏覽器就會顯示爲最小12像素，那麼其餘非字體元素比例仍然會縮小，這個時候字體可能和其餘元素的比例就不是原設計稿的比例了，若是用戶屏幕是320px，那麼和原設計稿元素間的比例就差更多了。因此咱們必定要根據本身的狀況告訴設計師，在寬是750像素的設計稿裏，字體最小應該是多少像素。

 

 

13.object-fit: cover

咱們在作列表頁的時候，圖片都是固定的大小，好比是一個100px*100px的正方形圖片，可是頗有可能拿到的圖片並非正方形的，這個非正方形圖片放到正方形的img標籤裏，就會變形若是使用object-fit：cover  能夠裁剪超出比例的部分，這樣圖片看起來就不會是變形或者拉伸的了，可是這樣會致使圖片殘缺，根據圖片的不一樣，可能裁剪掉關鍵部分的內容，可是鑑於列表原本就是縮略圖，因此仍是能夠加上這個屬性的,是一個比較折中的辦法。

 

14.圖片的約定

說到圖片拉伸的問題, 就要說說對於圖片的約定，由於無論是拉伸仍是裁剪都會致使圖片的殘疾，拉伸影響視覺，裁剪懼怕關鍵部位丟失，若是不嚴格按照約定的規範來，確定是不能兼容全部狀況的，所以在作項目的一開始就要和產品運營們約定好圖片比例，建議約定爲正方形。

 

小結

總得來講，學好css，須要長期推敲，長期注重和完善代碼的細節，在每一次項目實戰中，抽出一點點時間優化、嘗試，日積月累成爲我的的體系，
我的的風格。這種體系和風格，通常來講你本身都習慣了，會習覺得常，甚至總結的時候都不知道應該說什麼，可是當你去維護或者看別人的代碼的時候，你就能體會出，
原來這個地方別人可能會這樣用，你提出本身的看法，就能對團隊和周圍的同事產生好的影響，若是本身的有問題同事指出來，也能夠反過來，提高本身的認識。

 

和設計師。。。

要作好css，寫好頁面，和設計師的溝通也是很重要的一個技能，由於設計師決定頁面最終要呈現的樣子，要經過項目驗收，也必需要設計師驗收經過才行。

情景1：
設計師給過來一個交互效果，前端拿到，一想交互效果還能夠，可是實現成本比較高，功能都作不完，不想作這麼細，而後就直接說沒時間這個作不了，設計師一想這個交互很難嗎，別人都能作，你爲何不作，就這樣來回幾句就鬧矛盾了，鬧到產品那裏去了，最後可能交互效果還得作，時間也耽誤了。其實這個是不少前端會遇到的問題，時間壓得緊，功能可能都要延期，還來作這些交互，天然會有點抱怨，情緒一上來，把產品和設計都得罪了，最後仍是要作，長此以往矛盾愈來愈深，溝通就愈來愈困難。 換個思路想問題，設計師大部分時候時間也很緊，要對產品和設計領導有所交代，前端又在催，好不容易作出來了，你這也不能實現那也不能實現，你這樣我也無法交代啊。那麼咱們換個溝通方式，好比這樣說：咱們這邊時間確實有點緊，這個交互比較麻煩，比較費時間，我作是能夠作，只是可能會影響項目進度，你看要不我先作簡單點，等到提測的時候有時間再加上這個交互，實在不行能不能等到上線以後，我單獨再優化一下這個地方，很快就能上線。

　　設計師們仍是講道理的，根據web上的一些特性，設計師設計出來的一些樣式一些想法或許無法實現，又或者實現成本過高，咱們就得說服他們這個地方爲何不能實現，由於他們不懂，因此懼怕你忽悠他們（實際有時候就有人忽悠他們），因此要想說服別人，本身必定要把問題搞清楚，把知識點理清楚，不能實現的理由對設計師說清楚，而且要有理有據，同時最好網上找到相關博客或者官方解釋進行佐證。有不少矛盾和問題，就在於咱們疏忽了溝通，又或者說是咱們本身偷懶了，其實當本身把知識點能給外行說清楚了，這也說明是理解透了，也是對本身能力的提高。設計師辛苦設計的稿子必定要儘可能達到他們的效果，也要考慮擴展性和可實現性，態度很重要，不要讓人以爲是在敷衍他們，什麼是敷衍，不解釋清楚就說不作，就是敷衍，不然碰一鼻子灰只有怪本身。技術點要搞清楚，要不解釋不清楚，別人不買單，在發現設計稿有問題的時候，耐心提醒其中一些不合適的地方，多幫別人承擔一點，前端和設計師要友好相處。

 

再隨便聊聊

不要兼容IE低版本（我以爲兼容11以上就好了），特別是創業公司，對創業公司來講，性價比極低，自己創業公司沒技術、沒沉澱、活下去都是一個問題，兼容IE就是甚至浪費人力成本，好比說IE8不支持圓角，得用圖片代替，
沒有placeholder，得用JS來模擬。對於我的來講，技術的更新換代是大勢所趨，咱們要往前看，有的是東西給你學，不要在這個地方浪費青春。

有空你們都去看看bootstrap源碼，看一些核心的部分就夠了，好比變量variable等一些最經常使用的部分，源碼其實不難，能獲得不少啓發。

 

最後附上碼易直播回放地址  看不了的話，複製連接在微信打開吧！