CSS 如何模塊化，工程化

時間 2019-12-06

標籤 css 如何模塊化工程欄目 CSS 简体版

原文原文鏈接

前端架構是一系列工具和流程的集合，旨在提高前端代碼的質量，並實現高效、可持續的工做流。今天主要分享的是其中的前端中CSS如何進行模塊化開發。css

過去處理HTML的方法

過去，HTML一般被分爲兩大陣營：程序式和靜態式。html

程序式HTML：自動化程度100%，可控制程度接近爲0

這一般適合因爲前端團隊參與項目以前，項目的功能開發（包括HTML輸出）已經進行了幾周甚至幾個月了（例如使用jsp，頁面也是後端進行輸出的）。若是標記源碼被複雜的渲染過程打亂，並且還來自不一樣的模版，那麼狀況就會變的更加糟糕。前端

這意味着，對於任何不是後端複雜性的人而言，更新HTML會變得異常困難。而每每到了這個適合，後端開發者已經開始着手別的任務了，沒有事件回過頭來進行任何重大的修改。後端

這種制約因素的影響是，爲了把內容更好的嵌入HTML中，編輯人員和後端開發者寧肯寫一堆標記和CSS類名。最終，他們編寫的代碼可能會是這樣：架構

<div id="header" class="clearfix">
    <div id="header-screen" class="clearfix">
        <div id="header-inner" class="container-122 clearfix">
            <div id="nav-header" role="navigation">
                <div class="region region-navigation">
                    <div class="block block-system block-menu">
                        <div class="block-inner">
                            <ul class="menu">
                                <li class="first leaf">
                                    <a href="/start">Get Started</a>
複製代碼

這段代碼顯示了一個簡單的頁面頂部，即便在填充內容以前均可以包含10層嵌套，更可怕的是，在實際開發中這仍是特別誇張的現象，經驗告訴咱們，他還能嵌套更多。框架

之前，這種「div亂燉」或許確實有助於咱們把靜態ps圖像作成HTML頁面，可是隨着咱們的需求日漸成熟，咱們急需更好的方法來駕馭它們。jsp

靜態標記：自動化程度接近於0，可控程度100%

若是咱們的項目規模比較小，或者任務只是開發的一個須要填充一大塊主題區域的頁面，那麼編寫靜態HTMl會更爲方便一點。雖然這種狀況靈活性很大，可是也意味着咱們必須負責維護全部的代碼，當需求變動是咱們須要每一個頁面單獨手動修改，因此咱們的代碼會是這樣的：模塊化

<header>
    <section>
        <nav>
            <div>
                <ul>
                    <li>
                        <a href="products">Products</a>
                        <ul>
                            <li>
                                <a href="/socjs">Socks</a>
複製代碼

爲了保持簡潔，語義化是首選，應用樣式因此來的是HTML5元素名稱和他們的層級關係，而非CSS類名。咱們的HTML中沒有css類名，主導航的樣式會自動繼承到二級導航的錨地按上面，最終咱們每每會添加後代選擇起：工具

header > section > nav > div > ul > li > a {
    color: white;
}
header > section > nav > div > ul > li > ul > li > a{
    color: blue;
}
複製代碼

過去，這種靜態標記的方式使得對於任何一個懸停狀態或者激活狀態選擇器，代碼至少得寫那麼長。你根本不想看三級導航會被寫成什麼樣子，更不要想四級甚至五級導航了...佈局

平衡可控性和自動化

咱們都在追求的理想狀態是，網站上的每一行HTML都是有程序自動生成，而做爲前端開發人員，咱們只須要管理好這個用來產生HTML的模版和流程。遺憾的是顯示並不是如此，即便實在最好的狀況下，也須要用戶去生成內容，而這些內容是沒法自動添加css類名的。咱們只能經過模版來決定相似表格，表單和導航欄這樣的HTML，這樣也算是給我門帶來了必定的靈活性和必要的自動化。

模版化和靜態化的區別在於，程序執行完成以後，咱們還能夠經過一套類名系統給html添加css類名，而且不在經過元素標籤和層級關係來決定視覺外觀。

<nav class="nav">
    <ul class="nav__container">
        <li class="nav__item">
            <a class="nav__link" href="/products">
                <ul class="nav__container--secondary">
                    <li class="nav__item--secondary">
                        <a class="nav__link--secondary" href="/socks">
複製代碼

上面的這種方案彷佛至關冗長，其實這必定沒有什麼好辯解的，可是咱們給每一個元素都添加了對應的css類名，這樣看起來更加清晰一點，更加模塊化一點，並且具備複用性。咱們能夠做爲通用模版去使用。

CSS模塊化

要使用這種模塊化方法去定義html，咱們須要先改變構建頁面的方法和思路。單獨的靜態網頁其實壓根就不存在，所謂的網頁都已經成爲了過去。

現在，css理論幾乎和css或者js框架同樣繁多，可是css或js框架的用法比較繁瑣，並且必須成套使用，而css理論更可能是闡述html和css之間的關係，而不是預編譯的代碼庫，所以使用起來會更爲靈活。

固然，沒有那個方法論是完美的，你可能會發現，一個項目與某個方法比較契合，可是另外一個項目可能更適合另一種方法。因此你徹底能夠創造一套本身的方法論，或者將現有的理論根據本身的需求進行一些修改，所以當你猶豫不決，不知道該使用那個方法論的時候，不如先看看一些比較接觸的方法論，而後再根據本身手裏的項目進行分析。

OOCSS方法

分離結構和外觀

將視覺特性定義爲可複用的單元，好比simpleclass就表明使用直角，complex則表示使用圓角甚至還加了陰影。
分離容器和內容

再也不將元素位置做爲樣式的限定詞。和在容器內標記的CSS類名不一樣，咱們如今使用的是可複用的CSS類名，好比toggle-title，他應用於相應的文本處理上，可是無論這個文本的元素是什麼。這種方式下若是沒有應用別的CSS類名，你可讓標籤以默認的樣式呈現。

SMACSS方法

Scalable and Modular Architecyure for CSS，模塊化架構的可擴展CSS方法。

基礎

若是不添加css類名，標記會以什麼外觀呈現。
佈局

把頁面分紅一些區域。
模塊

設計中的模塊化、可複用的單元。
狀態

描述在特定的狀態或者狀況下，模塊或佈局的顯示方式。
主題

一個可選的視覺外觀層，可讓你更換不一樣的主題。

BEM方法

Block Element Modifier,塊元素修飾符

BEM使咱們要看到第三個方法，是SMACSS的另一個方面。BEM只是CSS類名命名規則。它並不涉及如何書寫你的CSS的結構，而只是建議每一個元素都添加帶有以下內容的CSS類名。

塊名

所屬組建的名稱。
元素

元素再塊裏面的名稱。
修飾符任何與塊或者元素相關聯的修飾符。

BEN使用很是簡潔的約定來建立CSS類名，而這些字符串可能會至關長。元素名加在雙下滑線後（例如toggle__details），修飾符加在雙橫槓後面（如toggle__details——active）。這裏的details是元素，active是修飾符，這個約定使得CSS類名便得很是清晰。使用雙橫綱是爲了不呢塊名被混淆成修飾符。這個方法在OOCSS或者SMACSS裏使用的好處時候，每一個CSS類名都能詳細地描述了它實現了什麼。在代碼中沒有open或者is-active這樣只在特定背景下才能理解的CSS類名。若是單獨看open和is-active這連個名字，咱們並不知道他們的含義是什麼。雖然BEM方法看起來很累贅、很冗餘，可是當看到toggle__details--active的CSS類名，咱們就知道它是表示：這個元素的名稱是details，位置在toggle組件裏，狀態爲激活狀態。