Sass 樣式指南:關於如何編寫更好的 CSS 代碼的 Sass 教程
已發表: 2022-03-11編寫可以很好地擴展的一致且可讀的 CSS 是一個具有挑戰性的過程。 尤其是當樣式表變得更大、更複雜、更難維護時。 開發人員可以用來編寫更好的 CSS 的工具之一是預處理器。 預處理器是一個程序,它獲取一種類型的數據並將其轉換為另一種類型的數據,在我們的例子中,CSS 預處理器是編譯成 CSS 的預處理語言。 前端開發人員推薦和使用的 CSS 預處理器有很多,但在本文中,我們將重點介紹 Sass。 讓我們看看 Sass 提供了什麼,為什麼它比其他 CSS 預處理器更受歡迎,以及如何以最佳方式開始使用它。
什麼是 Sass,為什麼要使用它?
對於那些不知道什麼是 Sass 的人,最好的起點是訪問 Sass 官方網頁。 Sass 是 Syntactically Awesome StyleSheets 的首字母縮寫,它是 CSS 的擴展,為基本語言增添了力量和優雅。
Sass 是一個具有許多強大功能的 CSS 預處理器。 最顯著的特性是變量、擴展和混合。
變量存儲可以在以後重用的信息,例如顏色或其他常用值。 擴展可幫助您創建允許規則繼承的“類”。 Mixins,你可以把它想像成“函數”。 與其他預處理器相比,Sass 還具有其他一些令人驚嘆的特性,例如使用邏輯語句(條件和循環)、自定義函數、與 Compas 等其他庫的集成等等。 僅這些功能就可以幫助您和您的團隊提高工作效率並最終編寫出更好的 CSS。
為什麼需要 CSS 樣式指南
不幸的是,即使是預處理器也無法修復所有問題並幫助您編寫好的 CSS 代碼。 每個開發人員都面臨的問題是當前的 Web 應用程序變得越來越大。 這就是為什麼代碼需要具有可擴展性和可讀性,並且需要避免意大利麵條式代碼和未使用的代碼行。 為避免上述問題,您的團隊在日常工作中需要某種標準。 什麼是意大利麵條代碼,它是如何發生的? 意大利麵條代碼是糟糕、緩慢、重複和不可讀代碼的名稱。 當一個團隊在沒有明確的指導方針或標準的情況下編寫大型應用程序時,每個開發人員都會編寫他需要的內容以及他想要的方式。 此外,當開發人員編寫大量錯誤修復、修補程序和補丁時,他們傾向於編寫能夠解決問題的代碼,但沒有時間以最佳方式編寫代碼。 在這些情況下,通常會得到很多不再在應用程序的任何部分中使用的 CSS 行。 開發人員沒有足夠的時間來清理代碼,他們被迫盡快發布修復程序。 另一個反復出現的情況是,為了快速修復損壞的東西,開發人員使用了很多!important
,這導致代碼非常hacky,難以維護,導致很多意外行為,並且需要稍後重構。 如前所述,隨著代碼的增長,情況只會變得更糟。
本文的想法是分享編寫更好的 Sass 的規則、技巧和最佳實踐。 將這些 Sass 技巧和最佳實踐組合在一起可以用作 Sass 風格指南。 本樣式指南應幫助開發人員避免上述情況。 規則被分組為邏輯段以便於參考,但最終您應該全部採用並遵循它們。 或者至少,他們中的大多數。
時尚指南
本風格指南中的一組規則和最佳實踐是基於與許多團隊合作的經驗而採用的。 其中一些來自試錯,另一些則受到 BEM 等流行方法的啟發。 對於某些規則,沒有具體的原因以及如何設置它們。 有時以過去的經驗作為唯一的理由就足夠了。 例如,為了確保代碼可讀,所有開發人員都以相同的方式編寫代碼是很重要的,因此存在括號之間不包含空格的規則。 我們可以爭論是否最好在括號之間包含空格。 如果您認為括號之間有空格會更好看,請根據您的喜好調整此樣式指南和規則。 最後,風格指南的主要目標是定義規則,使開發過程更加規範。
一般 CSS 規則
應始終遵守一般規則。 他們主要關注如何格式化 Sass 代碼以帶來代碼的一致性和可讀性:
- 對於縮進,使用空格而不是製表符。 最佳做法是使用 2 個空格。 您可以使用此選項運行自己的神聖戰爭,您可以定義自己的規則並使用製表符、空格或任何最適合您的方式。 重要的是定義一個規則並在保持一致的同時遵循該規則。
- 在每個語句之間包含一個空行。 這使得代碼更具人類可讀性,並且代碼是由人類編寫的,對吧?
- 每行使用一個選擇器,如下所示:
selector1, selector2 { }
- 不要在括號之間包含空格。
selector { @include mixin1($size: 4, $color: red); }
- 使用單引號將字符串和 URL 括起來:
selector { font-family: 'Roboto', serif; }
- 以分號結束所有規則,之前不帶空格:
selector { margin: 10px; }
選擇器規則
接下來,我們將遵循一組在處理選擇器時使用的規則:
- 避免使用 ID 選擇器。 ID 過於具體,主要用於 JavaScript 操作。
- 避免
!important
。 如果您需要使用此規則,則意味著您的 CSS 規則總體上存在問題,並且您的 CSS 結構不合理。 具有許多!important
規則的 CSS 很容易被濫用,最終導致混亂且難以維護的 CSS 代碼。 - 不要使用子選擇器。 此規則與 ID 規則具有相同的推理。 子選擇器過於具體,並且與您的 HTML 結構緊密耦合。

保持你的 Sass 規則井井有條
保持代碼的一致性很重要。 規則之一是您需要保持規則的順序。 通過這種方式,其他開發人員可以更深入地閱讀代碼,並且將花費更少的時間來尋找他們的方式。 這是建議的順序:
- 首先使用
@extend
。 這首先讓您知道這個類從其他地方繼承規則。 - 接下來使用
@include
。 將你的 mixins 和函數包含在頂部是很好的,並且還可以讓你知道你將覆蓋什麼(如果需要)。 - 現在您可以編寫常規的 CSS 類或元素規則。
- 將嵌套的偽類和偽元素放在任何其他元素之前。
- 最後,編寫其他嵌套選擇器,如下例所示:
.homepage { @extend page; @include border-radius(5px); margin-left: 5px; &:after{ content: ''; } a { } ul { } }
一些命名約定
樣式書的命名約定部分基於在開發人員中流行的兩個現有的 BEM 和 SMACSS 命名約定。 BEM 代表塊、元素、修改器。 它由 YANDEX 團隊開發,BEM 背後的想法是幫助開發人員了解項目中 HTML 和 CSS 之間的關係。 另一方面,SMACSS 代表 CSS 的可擴展和模塊化架構。 它是構建 CSS 以實現可維護性的指南。
受它們啟發,我們的命名約定規則如下:
- 為每種類型的元素使用前綴。 為您的塊添加前綴,例如:佈局 (
l-
)、模塊 (m-
) 和狀態 (is-
)。 - 每個塊的子元素使用兩個下劃線:
.m-tab__icon {}
- 為每個塊使用兩個破折號作為修飾符:
.m-tab--borderless {}
變量
使用變量。 從顏色等更通用和全局變量開始,並為它們創建一個單獨的文件_colors.scss
。 如果您注意到您在樣式表上多次重複某個值,請為該值創建一個新變量。 請乾燥。 當您想更改該值以及僅需要在一個地方更改它時,您將不勝感激。
此外,使用連字符來命名變量:
$red : #f44336; $secondary-red :#ebccd1;
媒體查詢
使用 Sass,您可以將媒體查詢編寫為元素查詢。 大多數開發人員在單獨的文件中或在我們的規則底部編寫媒體查詢,但不建議這樣做。 使用 Sass,您可以通過嵌套媒體查詢來編寫類似以下示例的內容:
// ScSS .m-block { &:after { @include breakpoint(tablet){ content: ''; width: 100%; } } }
這會生成一個這樣的 CSS:
// Generated CSS @media screen and (min-width: 767px) { .m-block:after { content: ''; width: 100%; } }
這個嵌套的媒體查詢規則讓您可以非常清楚地知道您要覆蓋哪些規則,正如您在使用命名媒體查詢的 Sass 代碼段中看到的那樣。
要創建命名媒體查詢,請像這樣創建您的 mixin:
@mixin breakpoint($point) { @if $point == tablet { @media (min-width: 768px) and (max-width: 1024px) { @content; } } @else if $point == phone { @media (max-width: 767px) { @content; } } @else if $point == desktop { @media (min-width: 1025px) { @content; } } }
您可以在以下文章中閱讀有關命名媒體查詢的更多信息:命名媒體查詢和使用 Sass 編寫更好的媒體查詢。
其他注意事項
最後,您還應牢記並遵循以下一些其他注意事項:
- 永遠不要寫供應商前綴。 改用自動前綴。
- 在嵌套規則中使用最多三層深度。 嵌套級別超過三個,代碼將難以閱讀,也許你正在編寫一個糟糕的選擇器。 最後,您正在編寫 CSS 代碼以與您的 HTML 相結合。
.class1 { .class2 { li { //last rules } } }
- 不要編寫超過 50 行的嵌套代碼:或者更好的是,不要編寫超過 X 行的嵌套代碼。 設置您自己的 X,但 50 看起來是個不錯的限制。 如果您通過了該限制,則代碼塊可能不適合您的文本編輯器窗口。
- 編寫一個主文件,您將在其中導入所有塊、部分和配置。
- 首先導入供應商和全局依賴項,然後是編寫的依賴項,然後是佈局、模式,最後是部件和塊。 這對於避免混合導入和覆蓋規則很重要,因為我們無法管理供應商和全局規則。
- 不要害羞,並在盡可能多的文件中破壞您的代碼。
結論
這個風格指南背後的想法是給你一些關於如何改進你編寫 Sass 代碼方式的建議。 請記住,即使您不使用 Sass,如果您使用 Vanilla CSS 或其他預處理器,本樣式指南中提供的提示和規則也適用並建議遵循。 同樣,如果您不同意任何規則,請更改規則以適應您的思維方式。 最後,由您和您的團隊決定是否調整此樣式指南、使用其他樣式指南或創建一個全新的指南。 只需定義指南,然後開始編寫很棒的代碼。