[譯] CSS 思惟模式

CSS 思惟模式

啊,是的,CSS。它幾乎每一個星期都是網絡上熱議的話題。它太難了。它太簡單了。它沒法預測。它過期了。此處應該有一張 Peter Griffin 折騰百葉窗的惡搞圖。css

我不知道爲何 CSS 會在開發者中激發出如此多的不一樣情緒,但我有一種直覺,爲何有時候它看起來不合邏輯或使人沮喪:你須要一種特定的思惟模式才能寫出好的 CSS。前端

如今,您可能須要一個編碼的思惟模式,但 CSS 的聲明性使其特別難以掌握,尤爲是當您用「傳統」編程語言的思惟來思考它的時候。android

其餘編程語言一般在受控的環境中工做,例如服務器。它們但願某些條件始終爲真,從而做爲程序應該如何執行的具體指令。ios

另外一方面,CSS 在一個永遠沒法徹底可控的地方工做,因此默認狀況下它必須是靈活的。它不只僅用於「編寫外觀」,還用於將設計轉換爲一組傳達其背後意圖的規則。留出足夠的空間,瀏覽器將爲您完成繁重的工做。git

對於大多數專業編寫 CSS 的人來講,他的思惟模式在一段時間後天然而然地造成了。在事情終於有成效的時候,許多開發者都有那樣一個「啊哈!」的時刻。這不只僅是瞭解全部技術細節,更多的是關於語言背後的思想的一種感受。github

我試着在這裏列出一些思惟模式。編程

全都是矩形

這看起來很明顯,由於盒子模型多是人們學習 CSS 的時候接觸到的第一個東西。可是將每一個 DOM 元素描繪成一個盒子對於理解事物佈局方式相當重要。它是內聯的仍是塊級的?它是彈性的嗎?它將如何在不一樣的環境中拉伸/收縮/包裹?後端

打開你的開發者工具並將鼠標懸停在元素上,觀察它們繪製的盒子。或使用像 outline: 2px dotted hotpink 這樣的顯式樣式來顯示其隱藏的邊框。數組

級聯是你的朋友

級聯 —— 一個可怕的概念,我懂。在鏡子前說三次「級聯」,在某個地方,一些不相關的樣式會失效。瀏覽器

雖然有合理的理由避免級聯,但這並不意味着它的一切都是很差的。事實上,若是使用得當,它可讓您的生活更輕鬆。

重要的是要知道哪些樣式屬於全局做用域,哪些樣式更適合於組件。它還有助於瞭解傳遞的默認值,避免聲明沒必要要的樣式規則。

儘量必要,儘量少

旨在編寫實現設計所需的最少許的代碼。較少的屬性意味着更少的繼承、更少的限制和更少的覆蓋帶來的麻煩。想一想你的選擇器應該作什麼,而後嘗試就那樣表達它。在已是塊級別的元素上聲明 width: 100% 是沒有意義的。若是您不須要新的堆疊上下文,則無需設置 position: relative

避免沒必要要的樣式,你就避免了意外後果。

簡寫有很大的影響

一些 CSS 屬性能夠用「簡寫」方式書寫,這使得一塊兒聲明一組相關屬性成爲可能。雖然這很方便,請注意,使用簡寫還將爲未顯式設置的每一個屬性聲明默認值。寫上 background: white; 將有效地致使全部這些屬性被設置:

background-color: white;
background-image: none;
background-position: 0% 0%;
background-size: auto auto;
background-repeat: repeat;
background-origin: padding-box;
background-clip: border-box;
background-attachment: scroll;
複製代碼

樣式最好是明確的。 若是要更改背景顏色,請使用 background-color

永遠要靈活

CSS 處理大量未知的變量:屏幕大小、動態內容、設備功能 —— 這個列表還在繼續。若是你的樣式過於狹隘或受限,那麼這些因素中的某一個極可能會讓你栽跟頭。這就是爲何寫好 CSS 的一個關鍵方面就是接受它的靈活性

你的目標是編寫一套足夠全面的指令來描述你想要實現的頁面,但足夠靈活,讓瀏覽器本身理解清楚怎麼作。這就是爲何一般最好避免 「神奇數字」

神奇數字是隨機的固定值。好比:

.thing {    width: 218px; /* why? */}
複製代碼

每當你本身在開發工具中點擊箭頭鍵並調整一個像素值使之適合的時候 —— 均可能會有一個神奇數字。它們不多能解決 CSS 問題,由於它們將樣式限制在特定的使用案例中。若是約束髮生變化,那麼該數字將會失效。

相反,想一想在那種狀況下你真正想要實現什麼。對齊?寬高比?分配等量的空間?全部這些都有靈活的解決方案。在大多數狀況下,最好爲目的定義一個規則,而不是採用硬編碼的計算方案。

語境是關鍵

對於許多佈局概念,必須瞭解元素與其容器之間的關係。大多數組件是父節點和子節點的集合。應用於父級的樣式會影響子孫級,這可能會使它們忽略其餘規則。彈性盒子,柵格佈局和 position: absolute 是此類錯誤的常見來源。

當疑惑某個特定元素的表現與您指望的不一樣時,請查看它所在的上下文。多是它祖先級的某些因素影響了它。

內容會改變

始終要注意,您所看到的只是在大範圍中的一種 UI 狀態。不要在屏幕上設置樣式,而是嘗試構建組件的「藍圖」。而後確保不論你把它放在什麼場景,都不會使你的樣式失效。

字符串可能比預期長或包含特殊字符,圖像可能缺失或具備奇怪的尺寸。顯示的樣子可能很是窄或很是寬。這些都是您須要預測的狀態。

設計師和開發者犯的第一個錯誤就是假設事情老是像它們在靜態模型中那樣。我能夠向你保證,它們不會。

發現模式並複用它們

當您打算將設計模型實現爲代碼時,首先盤點出所包含的不一樣模式一般頗有幫助。分析每一個屏幕的場景,注意任何出現一次以上的概念。它多是一些小的東西,好比排版樣式,或者大的東西,好比某種佈局模式。

什麼能夠抽象?什麼是特有的?將設計中的各個部分視爲獨立的東西使它們更易於理解,並有助於劃分組件之間的界限。

使用一致的命名

總的來講,至關多的一部分程序有不錯的命名。在 CSS 中,它有助於遵照約定。像 BEMSMACSS 這樣的命名方案很是有用;但即便你不使用它們,也要堅持使用一致的詞彙。


👉 免責聲明
全部這些對我來講都是很重要的,可是基於你的我的經歷,什麼最重要多是不一樣的。你有沒有你的「啊哈」時刻讓你更好地理解 CSS?告訴我!

延伸閱讀

若是發現譯文存在錯誤或其餘須要改進的地方,歡迎到 掘金翻譯計劃 對譯文進行修改並 PR,也可得到相應獎勵積分。文章開頭的 本文永久連接 即爲本文在 GitHub 上的 MarkDown 連接。


掘金翻譯計劃 是一個翻譯優質互聯網技術文章的社區,文章來源爲 掘金 上的英文分享文章。內容覆蓋 AndroidiOS前端後端區塊鏈產品設計人工智能等領域,想要查看更多優質譯文請持續關注 掘金翻譯計劃官方微博知乎專欄

相關文章
相關標籤/搜索