在項目開發(fā)周期中,構(gòu)建一個 CSS 項目可能會是你遇見的最困難的事情之一。構(gòu)建完成后,保持整體結(jié)構(gòu)的一致性并使所有設(shè)置有意義,則更加困難。
幸運的是,使用 CSS 預(yù)處理器的一個最主要好處就是可以拆分代碼庫到幾個文件中,而又不會影響性能(正像 CSS 指令 @import 的功能)。感謝 Sass 重載了 @import 指令,在開發(fā)中即使使用大量文件都是安全的(實際上非常推薦),部署時所有文件都會被編譯進(jìn)一個單一樣式表。
最重要的是,我無法形容我是多么需要設(shè)置大量的文件夾——即使是小項目中。這就像是在家里,你不會將所有的紙片放在同一個盒子中。你可以使用文件夾:一個為房產(chǎn),一個為銀行,一個為賬單,等等。沒有理由在構(gòu)架 CSS 項目時不這么做。拆分代碼庫到多個有意義的文件夾,當(dāng)你回頭來找東西的時候就會發(fā)現(xiàn)是那么容易。
有很多[受歡迎的構(gòu)建 CSS 項目的體系結(jié)構(gòu)]((http://www.sitepoint.com/look-different-sass-architectures/) ):OOCSS, Atomic Design, Bootstrap 式, Foundation 式...它們各有優(yōu)劣,難分伯仲。
我自己使用的方式,與 Jonathan Snook 的 SMACSS 非常相似,其致力于保持代碼簡潔易見。
我認(rèn)為,項目之間的結(jié)構(gòu)是極其具體的。你完全可以隨意摒棄或調(diào)整建議方案,擁有最適合自己需求的體系系統(tǒng)。
首先,在可以運行和運行良好兩種狀態(tài)之間存在著巨大的差別。其次,CSS 是一個相當(dāng)容易被混淆的語言。使用的 CSS 越少,工作會越愉快。沒人想處理兆字節(jié)量的 CSS 代碼。保持樣式表簡短而高效,就不會有諸多詭異。將接口視為組件的集合來使用往往是非常棒的思維。
組件可以是任意的,前提是遵循以下規(guī)范:
例如,搜索框就應(yīng)該被視為一個組件,可以在不同位置、不同頁面、多種環(huán)境下重復(fù)使用。它不應(yīng)該受限于 DOM 中的位置(頁腳、側(cè)邊欄、主內(nèi)容區(qū)...)。
幾乎所有的接口都可以被視為小組件,而且強(qiáng)烈建議堅持這種模式。這不僅僅會精簡整個項目中 CSS 的代碼量,而且也會比維護(hù)一個到處無邏輯的爛攤子容易得多。
理想情況下,每個組件都應(yīng)該擁有自己的文件夾(存在于 components 文件之下,詳見7-1 模式),比如 components/_button.scss。每個組件的樣式應(yīng)該包含以下內(nèi)容:
如果你希望可以定制組件的主題(主題文件置于 themes/ 文件夾之內(nèi)),可以限制樣式中可以被修改的種類,比如尺寸、內(nèi)間距、外間距以及對齊方式等等,可以開放顏色、陰影、字體、背景等方面的樣式。
一個組件文件內(nèi)可以存在與該組件密切相關(guān)的變量、占位符、混合宏甚至是函數(shù),但是要牢記,應(yīng)該避免對其他組件樣式的引用,否則將會讓項目整體的依賴關(guān)系變得難以維護(hù)。
下面是一個 Button 組件的示例:
// Button-specific variables
$button-color: $secondary-color;
// … include any button-specific:
// - mixins
// - placeholders
// - functions
/**
* Buttons
*/
.button {
@include vertical-rhythm;
display: block;
padding: 1rem;
color: $button-color;
// … etc.
/**
* Inlined buttons on large screens
*/
@include respond-to('medium') {
display: inline-block;
}
}
/**
* Icons within buttons
*/
.button > svg {
fill: currentcolor;
// … etc.
}
/**
* Inline button
*/
.button--inline {
display: inline-block;
}
感謝 David Khourshid 對本節(jié)做出的技術(shù)支持。
回到結(jié)構(gòu)這個話題上來,好嗎?通常我使用自稱為 7-1 模式的結(jié)構(gòu):7 個文件夾,1 個文件?;旧希阈枰獙⑺械牟考胚M(jìn) 7 個不同的文件夾和一個位于根目錄的文件(通常命名為 main.scss)中——這個文件編譯時會引用所有文件夾而形成一個 CSS 樣式表。
abstracts/base/components/layout/pages/themes/vendors/當(dāng)然還有它:
main.scsshttp://wiki.jikexueyuan.com/project/sass-guidelines/images/4.1.png" alt="" />
壁紙來源自 Julien He
理想情況下,目錄層次如下所示:
sass/
|
|– abstracts/
| |– _variables.scss # Sass Variables
| |– _functions.scss # Sass Functions
| |– _mixins.scss # Sass Mixins
| |– _placeholders.scss # Sass Placeholders
|
|– base/
| |– _reset.scss # Reset/normalize
| |– _typography.scss # Typography rules
| … # Etc.
|
|– components/
| |– _buttons.scss # Buttons
| |– _carousel.scss # Carousel
| |– _cover.scss # Cover
| |– _dropdown.scss # Dropdown
| … # Etc.
|
|– layout/
| |– _navigation.scss # Navigation
| |– _grid.scss # Grid system
| |– _header.scss # Header
| |– _footer.scss # Footer
| |– _sidebar.scss # Sidebar
| |– _forms.scss # Forms
| … # Etc.
|
|– pages/
| |– _home.scss # Home specific styles
| |– _contact.scss # Contact specific styles
| … # Etc.
|
|– themes/
| |– _theme.scss # Default theme
| |– _admin.scss # Admin theme
| … # Etc.
|
|– vendors/
| |– _bootstrap.scss # Bootstrap
| |– _jquery-ui.scss # jQuery UI
| … # Etc.
|
`– main.scss # Main Sass file
文件命名要遵循如上統(tǒng)一的命名規(guī)則:使用連字符界定。
base/文件夾存放項目中的模板文件。在這里,可以找到重置文件、排版規(guī)范文件或者一個樣式表——定義一些 HTML 元素公認(rèn)的標(biāo)準(zhǔn)樣式(我喜歡命名為_base.scss)。
_base.scss_reset.scss_typography.scss如果你的項目中使用了大量的 CSS 動畫, 那么你有必要考慮添加一個 \_animations.scss 文件來統(tǒng)一管理這些動畫。如果只是偶爾使用一些動畫,也可以將這些動畫融入到調(diào)用它們的文件中。
layout/ 文件夾存放構(gòu)建網(wǎng)站或者應(yīng)用程序使用到的布局部分。該文件夾存放網(wǎng)站主體(頭部、尾部、導(dǎo)航欄、側(cè)邊欄...)的樣式表、柵格系統(tǒng)甚至是所有表單的 CSS 樣式。
_grid.scss_header.scss_footer.scss_sidebar.scss_forms.scss_navigation.scsslayout/ 文件夾也會被稱為 partials/, 具體使用情況取決于個人喜好。
對于小型組件來說,有一個 components/ 文件夾來存放。相對于 layout/ 的宏觀(定義全局線框結(jié)構(gòu)),components/ 更專注于局部組件。該文件夾包含各類具體模塊,基本上是所有的獨立模塊,比如一個滑塊、一個加載塊、一個部件……由于整個網(wǎng)站或應(yīng)用程序主要由微型模塊構(gòu)成,components/ 中往往有大量文件。
_media.scss_carousel.scss_thumbnails.scsscomponents/ 文件夾也會被稱為 modules/, 具體使用情況取決于個人喜好。
如果頁面有特定的樣式,最好將該樣式文件放進(jìn) pages/ 文件夾并用頁面名字。例如,主頁通常具有獨特的樣式,因此可以在 pages/ 下包含一個 _home.scss 以實現(xiàn)需求。
_home.scss_contact.scss取決于各自的開發(fā)流程,這些文件可以使用你自己的前綴命名,避免在最終樣式表中與他人的樣式表發(fā)生合并。一切完全取決于你。
在大型網(wǎng)站和應(yīng)用程序中,往往有多種主題。雖有多種方式管理這些主題,但是我個人更喜歡把它們存放在 themes/ 文件夾中。
_theme.scss_admin.scss這個文件夾與項目的具體實現(xiàn)有密切關(guān)系,并且在許多項目中是并不存在的。
abstracts/ 文件夾包含了整個項目中使用到的 Sass 輔助工具,這里存放著每一個全局變量、函數(shù)、混合宏和占位符。
該文件夾的經(jīng)驗法則是,編譯后這里不應(yīng)該輸出任何 CSS,單純的只是一些 Sass 輔助工具。
_variables.scss_mixins.scss_functions.scss_placeholders.scss當(dāng)項目體量龐大工具復(fù)雜時,通過主題而不是類型分類整理可能更有幫助,比如排版(_typography.scss)、主題(_theming.scss)等。每一個文件都包含所有的相關(guān)信息:變量、函數(shù)、混合宏和占位符。這樣做可以讓維護(hù)更加單,特別針對于文件較長的情況。
abstracts/ 文件夾也會被稱為 helpers/ 或 utilities,具體使用情況取決于個人喜好。
最后但并非最終的是,大多數(shù)的項目都有一個 vendors/ 文件夾,用來存放所有外部庫和框架(Normalize, Bootstrap, jQueryUI, FancyCarouselSliderjQueryPowered……)的 CSS 文件。將這些文件放在同一個文件中是一個很好的說明方式:"嘿,這些不是我的代碼,無關(guān)我的責(zé)任。"
_normalize.scss_bootstrap.scss_jquery-ui.scss_select2.scss如果你重寫了任何庫或框架的部分,建議設(shè)置第 8 個文件夾 vendors-extensions/ 來存放,并使用相同的名字命名。
例如,vendors-extensions/_boostrap.scss 文件存放所有重寫 Bootstrap 默認(rèn) CSS 之后的 CSS 規(guī)則。這是為了避免在原庫或者框架文件中進(jìn)行二次編輯——顯然不是好方法。
主文件(通常寫作 main.scss)應(yīng)該是整個代碼庫中唯一開頭不用下劃線命名的 Sass 文件。除 @import 和注釋外,該文件不應(yīng)該包含任何其他代碼。
文件應(yīng)該按照存在的位置順序依次被引用進(jìn)來:
abstracts/vendors/base/layout/components/pages/themes/為了保持可讀性,主文件應(yīng)遵守如下準(zhǔn)則:
@import引用一個文件;@import單獨一行;@import 'abstracts/variables';
@import 'abstracts/functions';
@import 'abstracts/mixins';
@import 'abstracts/placeholders';
@import 'vendors/bootstrap';
@import 'vendors/jquery-ui';
@import 'base/reset';
@import 'base/typography';
@import 'layout/navigation';
@import 'layout/grid';
@import 'layout/header';
@import 'layout/footer';
@import 'layout/sidebar';
@import 'layout/forms';
@import 'components/buttons';
@import 'components/carousel';
@import 'components/cover';
@import 'components/dropdown';
@import 'pages/home';
@import 'pages/contact';
@import 'themes/theme';
@import 'themes/admin';
這里還有另一種引入的有效方式。令人高興的是,它使文件更具有可讀性;令人沮喪的是,更新時會有些麻煩。不管怎么說,由你決定哪一個最好,這沒有任何問題。 對于這種方式,主要文件應(yīng)遵守如下準(zhǔn)則:
@import@import之后都斷行@import
'abstracts/variables',
'abstracts/functions',
'abstracts/mixins',
'abstracts/placeholders';
@import
'vendors/bootstrap',
'vendors/jquery-ui';
@import
'base/reset',
'base/typography';
@import
'layout/navigation',
'layout/grid',
'layout/header',
'layout/footer',
'layout/sidebar',
'layout/forms';
@import
'components/buttons',
'components/carousel',
'components/cover',
'components/dropdown';
@import
'pages/home',
'pages/contact';
@import
'themes/theme',
'themes/admin';
在計算機(jī)編程中,通配符擴(kuò)展模式通常使用通配符來匹配多個文件名,比如 *.scss,其工作機(jī)制是通過表達(dá)式而不是文件名列表來匹配文件組。在 Sass 中,可以在入口文件中通過通配符擴(kuò)展的形式導(dǎo)入其他文件,導(dǎo)入后的入口文件類似如下所示:
@import 'abstracts/*';
@import 'vendors/*';
@import 'base/*';
@import 'layout/*';
@import 'components/*';
@import 'pages/*';
@import 'themes/*';
Sass 并不直接支持通配符擴(kuò)展的機(jī)制,這是因為 CSS 樣式是對聲明順序非常敏感的,當(dāng)我們使用通配符擴(kuò)展的形式導(dǎo)入文件時,文件通常按照字典序?qū)?,這種方式無法控制文件的導(dǎo)入順序,繼而會引起樣式的錯亂。
也就是說,在一個嚴(yán)格基于組件構(gòu)成的架構(gòu)中,必須十分注意組件之間的樣式順序,避免遺漏和錯誤覆蓋任何樣式。所以必須保證文件順序?qū)邮經(jīng)]有影響,方能使用通配符擴(kuò)展模式。使用通配符擴(kuò)展模式最大的好處就是無需再花費時間處理入口文件中文件的增加和刪除。
在 Ruby Sass 中有一個 sass-globbing 包可以用于解析通配符擴(kuò)展機(jī)制。如果使用的是 node-sass,可以使用 Node.js 或者構(gòu)建工具(Gulp,Grunt等 等)來解析通配符擴(kuò)展機(jī)制。
另一個有意思的方面,由業(yè)內(nèi)已流行的 Harry Roberts, Dave Rupert 和 Chris Coyier 引起的,那就是將所有的CSS聲明、Hack行為和我們不支持的行為放入一個 shame file。該文件命名為 _shame.scss,在所有文件之后被引用,放在所有樣式表的最后。
/**
* Nav specificity fix.
*
* Someone used an ID in the header code (`#header a {}`) which trumps the
* nav selectors (`.site-nav a {}`). Use !important to override it until I
* have time to refactor the header stuff.
*/
.site-nav a {
color: #BADA55 !important;
}