国产激情久久久久影院小草_国产91高跟丝袜_99精品视频99_三级真人片在线观看

CSS預(yù)處理語言的模塊化實踐實例

時間:2020-10-15 14:10:12 CSS 我要投稿

CSS預(yù)處理語言的模塊化實踐實例

  編寫css是前端工作中,一項普通而又頻繁的勞動,由于css并不是一門語言,所以在程序設(shè)計上顯得有些簡陋。對于小型項目來說,css的量還不至于龐大,問題沒有凸顯,而如果要開發(fā)和持續(xù)維護一個較為大型的項目,那就需要對css進行管理和規(guī)范了,否則會發(fā)生不可挽回的后果。

  通過規(guī)范的約束,將css的編寫方式進行了優(yōu)化和改進,形成一種可持續(xù)發(fā)展的路線。但還是遺留了一些問題:冗余。雖然我們通過定義公共模塊和私有模塊,來委婉地分擔(dān)common的體積,但common的體積還是太大了,而且從設(shè)計上考慮,我們應(yīng)該盡量多地提煉公共模塊,以便更好地實現(xiàn)復(fù)用。最理想的情況是,所有的模塊都寄存在一個公共的庫里,哪里需要用到就從庫中直接調(diào)過來。這個美好的愿望不是不可實現(xiàn)的,借助預(yù)處理語言,我們可以很輕易地完成這事情。

  預(yù)處理語言是一種類css的語言,我們知道css本身不是語言,而預(yù)處理語言的誕生,就是為填補這一部分語言功能。它實現(xiàn)了變量、函數(shù)、混合的定義,以及文件的引用、合并、壓縮功能,使得css也能面向?qū)ο,?yīng)付復(fù)雜龐大的業(yè)務(wù)。

  目前流行的預(yù)處理語言主要有兩種:less和sass。作為學(xué)習(xí),兩者都可以入門一下,而作為工作,盡量熟悉一種。我比較常用sass,所以以下內(nèi)容都是以sass為基本語言做介紹,兩者在特性上有很多相似的地方,所以大家不必?fù)?dān)心實現(xiàn)上有什么千差萬別。

  sass

  基本語法可以到官方網(wǎng)(英語)或者w3cplus sass guide(中文)查看學(xué)習(xí),我們這里只簡單地過一遍,講一些我們需要用到的內(nèi)容,不會面面俱到。

  sass有兩種后綴名文件:一種后綴名為sass,不使用大括號和分號;另一種就是我們這里使用的scss文件,這種和我們平時寫的css文件格式差不多,使用大括號和分號。而本教程中所說的所有sass文件都指后綴名為scss的文件。在此也建議使用后綴名為scss的文件,以避免sass后綴名的嚴(yán)格格式要求報錯。 ——摘自w3cplus sass guide

  1、嵌套(非常重要的特性)

  sass的嵌套包括兩種:一種是選擇器的嵌套;另一種是屬性的嵌套。我們一般說起或用到的都是選擇器的嵌套。 ——摘自w3cplus sass guide

  選擇器嵌套 所謂選擇器嵌套指的是在一個選擇器中嵌套另一個選擇器來實現(xiàn)繼承,從而增強了sass文件的結(jié)構(gòu)性和可讀性。在選擇器嵌套中,可以使用&表示父元素選擇器。 ——摘自w3cplus sass guide

  // index.scss

  .g-index {

  ...

  .g-hd {

  ...

  .m-nav { ... }

  }

  .g-bd {

  ...

  .m-news { ... }

  }

  .g-ft {

  ...

  .m-copy_right { ... }

  }

  .m-dialog {

  display: none;

  &.z-active { // 留意此處&的用法

  display: block;

  }

  }

  }

  編譯后:

  /* index.css */

  .g-index { ... }

  .g-index .g-hd { ... }

  .g-index .g-hd .m-nav { ... }

  .g-index .g-bd { ... }

  .g-index .g-bd .m-news { ... }

  .g-index .g-ft { ... }

  .g-index .g-ft .m-copy_right { ... }

  .g-index .m-dialog {

  display: none;

  }

  .g-index .m-dialog.z-active { // 留意此處&的編譯結(jié)果

  display: block;

  }

  是不是爽歪歪?再也不用一遍一遍地去復(fù)制和修改一大堆的選擇器,也不需要去整理它們之間的關(guān)系,只需要嵌套一下,所有的關(guān)系就如同直接看dom一樣簡單明了了!解放雙手,解放雙眼,同時還提高效率。值得留意的是,我們書寫sass的時候,應(yīng)該盡量保持sass的嵌套順序與dom一致,注意,是嵌套順序一致,而不是層次一致,因為并不是dom里的所有元素都需要寫樣式。

  我們再來提一個場景,說明sass的嵌套寫法利于維護,假設(shè)g-bd下原本有個模塊m-article_box,現(xiàn)在我們要把m-article_box從g-bd遷移到g-hd中(當(dāng)然這個需求有些不合理~),我們來看原始代碼:

  

  

  

  

  titleindex/title

  

  

  


  


  


  


  最新文章

  

  


  


  


  

  


  


  文章標(biāo)題

  

  

文章簡介

  

  

  

  

  


  


  1

  2

  3

  4

  

  

  

  

  

  

  

  .g-bd { ... }

  .g-bd .m-article_box { ... }

  .g-bd .m-article_box .hd { ... }

  .g-bd .m-article_box .bd { ... }

  .g-bd .m-article_box .bd .list { ... }

  .g-bd .m-article_box .bd .list .item { ... }

  .g-bd .m-article_box .bd .list .item .cover { ... }

  .g-bd .m-article_box .bd .list .item .info { ... }

  .g-bd .m-article_box .bd .list .item .info .title { ... }

  .g-bd .m-article_box .bd .list .item .info .desc { ... }

  .g-bd .m-article_box .ft { ... }

  .g-bd .m-article_box .ft .page { ... }

  .g-bd .m-article_box .ft .page .pg { ... }

  按照css的方式,我們就要把所有跟m-article_box有關(guān)的部分,從g-bd全部復(fù)制到g-hd里去。這還是在模塊的書寫符合規(guī)范的情況下,如果這個模塊書寫不符合規(guī)范,沒有把全部結(jié)構(gòu)都掛在m-article_box類下,那真的就是災(zāi)難了~而現(xiàn)在使用sass的話,我們只需要把m-article_box的區(qū)塊整個從g-bd剪切到g-hd就完事了(這里為了突出修改的工作量大,我特地把整個模塊結(jié)構(gòu)都寫全了——才不是為了湊字?jǐn)?shù)。。。):

  // 修改前

  .g-hd { ... }

  .g-bd {

  .m-article_box {

  .hd { ... }

  .bd {

  .list {

  .item {

  .cover {

  ...

  }

  .info {

  .title {

  ...

  }

  .desc {

  ...

  }

  }

  }

  }

  }

  .ft {

  .page {

  .pg { ... }

  }

  }

  }

  }

  // 修改后

  .g-hd {

  .m-article_box {

  .hd { ... }

  .bd {

  .list {

  .item {

  .cover {

  ...

  }

  .info {

  .title {

  ...

  }

  .desc {

  ...

  }

  }

  }

  }

  }

  .ft {

  .page {

  .pg { ... }

  }

  }

  }

  }

  .g-bd { ... }

  非常方便,而且不容易出錯。

  2、變量(variable)

  咱們直接上代碼:

  // index.scss

  $fontSize: 16px;

  $grey: #ccc;

  .m-nav {

  font-size: $fontSize;

  color: $grey;

  }

  編譯結(jié)果:

  /* index.css */

  .m-nav {

  font-size: 16px;

  color: #ccc;

  }

  寫過代碼的人都熟悉 參數(shù) 的用法吧,太簡單太直白了不想說太多,自己意會吧。

  3、函數(shù)(function)

  // pixels to rems

  @function rem($px) {

  @return $px / 640 * 16rem;

  }

  太簡單了直白了不想說太多,自己意會吧。

  4、混合(mixin)

  混合,顧名思義,就是混合的意思。。。也就是我們可以事先定義一段代碼塊,在需要使用到的地方,直接引用(include),而在引用之前,這段代碼都不會出現(xiàn)在編譯文件中,也就是不會生成任何內(nèi)容。

  這也是非常重要的一個特性!我們知道common的體積非常大,而體積大的根本原因是它存放了許許多多的模塊。我們設(shè)想一下,如果將每一個模塊都打包成mixin,那common不就減肥成功了?!多年的頑疾終于看到希望,沒有比這更讓人驚喜的了!我們這就上車:

  /* common.css */

  .m-nav { ... }

  .m-news { ... }

  .m-copy_right { ... }

  改造后

  // common.scss

  @mixin m-nav {

  .m-nav { ... }

  }

  @mixin m-news {

  .m-news { ... }

  }

  @mixin m-copy_right {

  .m-copy_right { ... }

  }

  // index.scss

  .g-index {

  @include m-nav;

  @include m-news;

  @include m-copy_right;

  }

  5、import

  這個屬性很眼熟?沒錯,事實上,css本身就有這個屬性實現(xiàn),我們可以在css文件中直接使用import來引入其他文件。那么css的import和sass的import有什么區(qū)別?從含義和用法上來說,沒有區(qū)別,區(qū)別在于工作原理。css的import是阻塞的,而sass的import在編譯后,其實是合并文件,最后只產(chǎn)出一個css文件,而css則沒有合并,該多少個文件就還是多少個文件。

  注意:

  只有import一個.sass/.scss文件的時候,才可以省去后綴名,如果是直接import一個.css文件,要補全文件名;

  import之后的分號;不要漏寫,會報錯;

  sass如果import的是一個.css文件的話,那它的作用就跟css原生的import作用一樣,只有import一個sass文件的時候,才是合并文件。

  如下:

  // index.scss

  @import 'common';

  @import 'a.css';

  編譯結(jié)果:

  /* index.scss */

  .m-nav { ... }

  .m-news { ... }

  .m-copy_right { ... }

  @import url('a.css');

  css的import之所以沒有被普遍使用是有原因的。我們可以大概猜到它的工作原理:a.css import b.css以后,當(dāng)瀏覽器加載到頁面中的a.css的時候,已經(jīng)準(zhǔn)備按照a.css的內(nèi)容來渲染頁面了,剛解析到第一行,發(fā)現(xiàn)a.css居然還import了一個b.css,于是它不得不先放下a.css(既阻塞a.css),去加載b.css,直到b.css加載完,并且優(yōu)先解析它,然后才開始回來解析a.css——鬼知道b.css會不會又import了c.css……這直接導(dǎo)致了渲染工作滯后,引發(fā)性能問題。

  說實話我還不如直接用兩個link標(biāo)簽去同步加載a.css和b.css,效率會高一些。

  所以css的import基本是被拋棄了的屬性。

  sass的import主要的好處就是把文件合并了,減少了請求。原本需要link好幾個css文件的頁面,現(xiàn)在只需要一個。

  模塊化

  終于要開始干點正事了,首先我們來回顧一下,上一節(jié)我們以規(guī)范為基礎(chǔ)構(gòu)建的模塊化項目,遺留了一些什么問題。

  冗余 體積龐大的common;

  使用cm-模塊區(qū)別m-模塊,使得后期開發(fā)過程中,m-模塊向cm-模塊轉(zhuǎn)變過程比較繁瑣;

  ……

  好像,問題也不是特別多,我們一個一個解決。

  為了方便,在這里我們把每個頁面所對應(yīng)的scss文件叫做 頁面scss;把變量、函數(shù)、混合等(沒有被引用或者執(zhí)行的情況下)編譯后不產(chǎn)生實際內(nèi)容的代碼叫做 定義類代碼 ,那么相對應(yīng)的其他內(nèi)容就是 實際內(nèi)容代碼。

  1、mixin.scss

  我們知道,一方面,在common中過多地添加模塊最終會導(dǎo)致common的體積過大,使得資源冗余,另一方面,為了方便維護,我們又希望盡量多地把模塊公有化。

  這是一對矛盾,僅靠css本身是無法解決的,但sass可以!如果我們使用mixin來代替直接書寫模塊,由于mixin并不直接生成代碼,而是通過主動引用,才能生成對應(yīng)內(nèi)容,那么理論上,common就可以無限多地存放模塊而不必占用一點空間!

 。ㄗ⒁猓@里說的是理論上,實際應(yīng)用中,文件太過龐大的話,免不了還是要受到命名沖突的限制的,不過這問題不大。)

  說干就干,我們把common中的模塊全部打包成mixin:

  /* common.css */

  .m-nav { ... }

  .m-news { ... }

  .m-copy_right { ... }

  改造后

  // common.scss

  @mixin m-nav {

  .m-nav { ... }

  }

  @mixin m-news {

  .m-news { ... }

  }

  @mixin m-copy_right {

  .m-copy_right { ... }

  }

  調(diào)用方式如下:

  // index.scss

  @import 'common'; // 記得先引入common

  .g-index {

  @include m-nav;

  @include m-news;

  @include m-copy_right;

  }

  原本我們會在每個需要用到公共模塊的頁面中,先引用common,然后再引用頁面css,而現(xiàn)在,我們只需要在頁面scss中直接@import common;就可以了。

  使用common:

  

  

  

  

  titleindex/title

  link rel="stylesheet" type="text/css" href="./style/common.css"/

  link rel="stylesheet" type="text/css" href="./style/index.css"/

  

  

  ...

  

  

  改造后:

  // index.scss

  @import 'common';

  

  

  

  

  titleindex/title

  link rel="stylesheet" type="text/css" href="./style/index.css"/

  

  

  ...

  

  

  很完美,

  ——至少目前為止是這樣。

  我們思考一個問題,common除了存放模塊之外,還有沒有其他內(nèi)容?答案是肯定的,大家一定知道有個東西叫做css reset(或者normalize.css),這肯定是全局的;另外,如果是做后臺管理系統(tǒng)的話,可能還會有bootstrap。當(dāng)然,還有一些自定義的全局的樣式,比如常見的.clearfix,等等。

  這些東西目前我們也堆積在common當(dāng)中,而且合情合理,因為它們都是全局的樣式。但是對比起mixin來說,這些實際內(nèi)容代碼顯得很少量,有種被淹沒的感覺,使得整個common看上去就像只有mixin。但是這些實際內(nèi)容代碼的作用卻又非常重要。為了使common的構(gòu)成更加直觀,我們把mixin全部都抽離出來,單獨存放一個叫做mixin.scss的文件中,然后在common引用它,這樣,mixin的管理更加的規(guī)范,而且common的結(jié)構(gòu)也更加清晰了。

  抽離mixin還有另外一個重要原因,后面會講到的,我們希望mixin作為一個純粹定義類代碼文件,隨處可以引用而不會生成多余的代碼。

  原本我們會在每個需要用到公共模塊的頁面中,先引用common,然后再引用頁面css,而現(xiàn)在,我們只需要在頁面scss中直接@import mixin;就可以了。

  使用mixin:

  // index.scss

  @import 'common'; // 引入common,如果有需要,common里一樣可以引入mixin

  @import 'mixin'; // 引入mixin

  .g-index {

  ...

  }

  

  

  

  

  titleindex/title

  link rel="stylesheet" type="text/css" href="./style/index.css"/

  

  

  ...

  

  

  2、common.scss

  好,抽離了mixin之后,我們現(xiàn)在來重新看回common,common里應(yīng)該是些什么樣的內(nèi)容。上面的內(nèi)容我們稍稍提到了一點,我們來展開一下。

  2.1、css reset(normalize)

  我們知道瀏覽器千差萬別,各瀏覽器的默認(rèn)樣式也是不盡相同,最常見的比如body的默認(rèn)內(nèi)邊距,p標(biāo)簽的默認(rèn)內(nèi)邊距,以及ul/ol等等。這些不統(tǒng)一的默認(rèn)樣式經(jīng)常讓我們感到頭疼,所以就有人提出一開始寫樣式就先把它們消除的想法,于是就催生了后來非常流行的reset.css。

  起初的reset.css很簡單,大概是這樣的:

  html, body, h1, h2, h3, h4, h5, h6, p, dl, dt, dd, ul, ol, li, p {

  margin: 0;

  padding: 0;

  }

  沒錯,就是把幾乎所有會用到的標(biāo)簽都給去了內(nèi)邊距和外邊距,簡單粗暴,這樣所有的標(biāo)簽就都統(tǒng)一了,而且在不同的瀏覽器下也是統(tǒng)一的。

  其他的部分每個人有各自的補充,比如有人會把h1~h6的所有字號給定義一遍,以保證在不同瀏覽器下他們有統(tǒng)一的大;有人會給a標(biāo)簽設(shè)置統(tǒng)一的字體顏色和hover效果,諸如此類等等。

  很好,沒毛病。我們把這些統(tǒng)稱為css reset,然后再統(tǒng)一封裝到一個叫做reset.css的文件中,然后每個頁面都引用。

  這種方式一直以來都挺實用,而且大家也都這么用,沒出過什么問題。只是后來有人提出,這種方式太過粗暴(居然還心疼瀏覽器了)。。。而且會降低頁面渲染的性能,最重要的是,這使得我們原本設(shè)計出來的表達各種含義的標(biāo)簽兒們,變得毫無特點了。。。

  說的好有道理,如果你家里所有人名字不一樣但是都長一個樣,還有啥意思。

  于是,就出現(xiàn)了normalize.css,normalize的目的同樣是為了統(tǒng)一各個瀏覽器下各不相同的默認(rèn)樣式,不過它并不是簡單粗暴地全部抹平,而是根據(jù)規(guī)范,來人為地把那些不符合規(guī)范的默認(rèn)樣式“扶正”,從而達到統(tǒng)一各個瀏覽器默認(rèn)樣式,同時保留各個標(biāo)簽原有特點的目的。

  我們不能說reset與normalize這兩種思想孰好孰壞,只能說各有各的特點和作用,它們的存在都是為了解決同樣的問題。

  2.2、插件

  一般來說,一個ui插件都會至少包括一個css文件,像bootstrap、datepicker等等。假設(shè)我們項目中需要以bootstrap為基礎(chǔ)框架,實現(xiàn)快速開發(fā),那么這時候我們就需要在項目中全局引入bootstrap.min.css,當(dāng)然,還有bootstrap.min.js。說到全局暴露,我們第一時間想到的是common,沒錯,我們可以在common中引入。

  有人問,插件的.css文件怎么import?額,改一下擴展名為.scss就可以了,scss是兼容原生css語法的~

  所以最終,我們的common大概是這樣子的:

  // common.scss

  @import './reset';

  @import './bootstrap.min';

  @import './mixin';

  事實上,如果我們不需要使用到 mixin.scss 中的變量和mixin的話,我們可以不引用它。

  那么我們的頁面scss應(yīng)該是這樣的:

  // index.scss

  @import './common';

  @import './mixin';

  .g-index {

  ...

  }

  干凈,整潔。

  3、mixin編寫規(guī)范

  每添加一個新角色,我們就要及時給它設(shè)置規(guī)范,好讓它按照我們的期望工作別添亂。我們接下來來歸納一下mixin的書寫規(guī)范。

  場景一:項目里有mixin.scss、a.scss(假設(shè)這是某個功能文件)、index.scss三個文件,mixin中定義了一個變量$fontSize: 16px;,a中定義了一個變量$color: #ccc;,我們在index中同時引用這兩個文件,那么我們在index中是可以直接使用$fontSize和$color這兩個變量的——我的意思是,盡管在index中我們并沒有看到這兩個變量的聲明和定義,但它們就這么存在了。

  這是好事還是壞事呢?直覺告訴我,這可能有問題。沒錯,這是不是跟我們之前討論過的 污染 很像?只不過我們之前是引用了common之后,index什么都還沒寫就已經(jīng)被占用了很多模塊名,而現(xiàn)在是因為引用了其他文件,而占用了index的很多變量名。另外,就維護的角度來看,這也是有問題的,如果我不事先告訴你,或者你不事先看過一遍mixin和a,你知道index中的$color是哪里來的嗎?假設(shè)我們需要字體大小,你知道去哪個文件修改嗎?另外,你怎么保證同時引用mixin與a的時候,他們之間有沒有可能存在同名的變量?那誰覆蓋誰呢?這些問題看起來很小,但是當(dāng)你項目規(guī)模大的時候,這可能是無法挽回的災(zāi)難(嚇唬誰呢???)。

  場景二:假設(shè)我們的項目有一個主題色,邊框、tab背景、導(dǎo)航欄背景,以及字體顏色等等,都是這個主題色,為了方便使用,不想總是用取色器去取值,于是我們在mixin中定義了一個全局變量$color: #ff9900,然后就可以愉快地到處使用了!

  整個網(wǎng)站開發(fā)完了,一個月后,設(shè)計師突然過來跟你說:“老板說,這個主題色要改改,有點土,咱們換個大紅!,于是你一臉不情愿然而內(nèi)心卻竊喜地打開mixin,把$color的值改成了大紅,然后得瑟地對設(shè)計師說:“幸好我早有準(zhǔn)備,搞定了,你看看吧!,保存,打開頁面一看,設(shè)計師和你的臉都綠了,頁面怎么這么丑,有些字原本是主題色,但背景是紅色,而現(xiàn)在一改,整塊都變成紅的,內(nèi)容都看不清了,有些邊框原本就是紅色的,但是字體是原本的主題色,然而現(xiàn)在一改,邊框跟字體都變成紅的了。

  設(shè)計師:“不不不,我只是想把背景顏色改一下!

  你:“你不是說改主題色嗎?那就是所有的地方啊!

  設(shè)計師:“不用,改背景就好了。”

  你:“不行啊。。!

  設(shè)計師:“為什么不行,不就是改個背景顏色嗎?怎么設(shè)置的就怎么改回來呀!

  你:“不是你想的那么簡單。。。”

  ……

  好吧我就是嚇唬你的,你要是特能折騰那么這些都不叫事兒。

  所以我們需要對(全局)變量進行管理,就像我們當(dāng)初管理mixin那樣,不能想在哪里定義就在哪里定義,也不能動不動就修改一個全局變量:

  全局變量只在mixin中定義,其他scss文件定義的變量(無論是暴露到全局還是局部)都只看作局部變量,不在當(dāng)前文件以外的地方使用(即便是在能引用到的情況下,也避免使用);

  需要使用全局變量的.地方直接import mixin;

  一般來說,定義全局變量應(yīng)該慎重,全局變量的數(shù)量應(yīng)該盡量少;

  盡可能不改動,如果需求變動,除非是對用途十分確定的情況,否則請新增一個全局變量來逐步替換需要修改的地方;

  不要使用太過籠統(tǒng)的名詞來作為全局變量,比如color,建議直接是用色值的描述,比如$orange: #ff9900,這使得我們在維護上更方便擴展,如果色值需要修改,但是又不是所有的地方都需要修改,那么我們可以新定義一個變量來擴展它,比如$red: red。

  這些點說起來都有點飄忽,事實上也確實很難說明白為什么要這么做,畢竟都是經(jīng)驗總結(jié),所以大家不妨先熟悉使用sass一段時間之后,再來細(xì)細(xì)思考這些問題。

  注意,以上講的這些都不是死規(guī)定,在某些時候,這個規(guī)范是需要根據(jù)實際項目而做調(diào)整的,就比如我們之后要講到的SPA。十全十美的項目是不存在的,也不存在能適用所有項目的開發(fā)模式,因地制宜才能更好地解決問題。而且我們目前提到的問題都不是致命的,致命的問題在上一節(jié)我們制定規(guī)范的時候已經(jīng)避開了。

  調(diào)用模塊

  問題,在哪里調(diào)用模塊?

  答,頁面scss。

  在頁面scss中調(diào)用模塊是一個好習(xí)慣,它使得我們在每個頁面所用到的模塊既是一致的又是互相隔離的,不像在common中直接引用模塊那樣,使得一個頁面scss還沒有內(nèi)容的時候就已經(jīng)被很多模塊名污染了。

  再提個問題,在頁面scss的哪里調(diào)用模塊?

  例一,根類外:

  // index.scss

  @import './common';

  @import './mixin';

  @include m-nav;

  @include m-news;

  @include m-copy_right;

  .g-index {

  ...

  }

  例二,根類內(nèi):

  // index.scss

  @import './common';

  @import './mixin';

  .g-index {

  @include m-nav;

  @include m-news;

  @include m-copy_right;

  ...

  }

  目前為止,這兩種方式都是可以的,至于我為什么用“目前為止”這個詞,那是因為我們后面將要講到的SPA,如果用例一的方式是有問題的。所以我比較鼓勵使用例二的方式。當(dāng)然,我說了,目前為止例一也是沒問題的。

  性能優(yōu)化

  目前為止,我們的模塊化工作已經(jīng)算是完成了,其實已經(jīng)可以收工了。不過我們還是可以稍微做一下優(yōu)化。

  1、緩存

  我們需要考慮一個問題:緩存。

  緩存是我們web開發(fā)中最常見的情況之一,很多時候我們都需要跟緩存打交道,特別是在做性能優(yōu)化的時候。

  一般來說,靜態(tài)資源在被加載到瀏覽器之后,瀏覽器會把它本地緩存下來,以便下次請求同個資源的時候可以快速響應(yīng),不需要再去遠(yuǎn)程服務(wù)器加載。

  我們就css來說,假設(shè)我們按照原來的方式,使用多個link去加載reset、bootstrap、common、index這幾個文件的話,這幾個文件都會被緩存下來,以使得下次再訪問這個頁面,這個頁面的加載速度會快很多。

  如果是從index頁面跳轉(zhuǎn)到about頁面呢?你會發(fā)現(xiàn)也很快,因為about頁面的全局css(reset、bootstrap、common)和index頁面是一樣的,而它們在你訪問index的時候,已經(jīng)加載過了,得益于緩存的作用,之后的頁面打開都快。

  我們現(xiàn)在的方式是,一個頁面所用到的所有css文件都被合并成一個,也就不存在相同的文件可以利用緩存這樣的優(yōu)勢了。

  那我們有辦法改進嗎?有的!我們只需要把common獨立出來,那么common就可以做為被緩存的公共文件了。最終我們從一個頁面只引用一個文件變成了一個頁面引用兩個文件,即common和頁面css:

  // common.scss

  @import './reset';

  @import './bootstrap.min';

  @import './mixin';

  // index.scss

  @import './mixin';

  .g-index {

  ...

  }

  注意,不同于之前,我們這里的index.scss不再引入common.scss,所以我們最終是得到了兩個css文件,而common.css是在所有頁面中通過link標(biāo)簽引入的。

  如此一來,我們就實現(xiàn)了既能夠合并文件,減少請求數(shù),又可以利用緩存,提高加載速度。

  2、壓縮

  代碼壓縮是優(yōu)化工作中最基本的一步,css的壓縮空間是很大的,尤其是我們這種 垂直的書寫方式 ,壓縮起來是相當(dāng)高效的。

  在sass中這很簡單,sass在編譯的時候提供了幾種模式,其中的compressed模式是最高效的壓縮模式,記得在編譯打包的時候選擇compressed模式就行了。

  總結(jié)

  總的來說,預(yù)處理語言在使我們編程更加美好的同時,也使得規(guī)范更加的完善。在css本身無法實現(xiàn)的情況下,我們通過工具來完成了模塊化開發(fā)。

【CSS預(yù)處理語言的模塊化實踐實例】相關(guān)文章:

jquery獲取css中的選擇器用法實例講解11-11

div+css必看的css重則11-13

CSS實用教程:CSS命名11-20

css 書寫技巧 CSS 技巧教程簡介11-21

jQuery css方法動態(tài)修改CSS屬性11-12

css的基本語法11-13

CSS制作教程11-20

css基礎(chǔ)教程之CSS基礎(chǔ)語法欣賞11-21

css的入門教程11-20