移動優(yōu)先的設計方法很棒——它專注于對用戶真正重要的東西，它被很好地實踐，并且多年來一直是一種常見的設計模式。所以開發(fā)你的 CSS 移動優(yōu)先也應該很棒……對吧？

嗯，不一定。經(jīng)典的移動優(yōu)先 CSS 開發(fā)基于覆蓋樣式聲明的原則：您從默認樣式聲明開始您的 CSS，并在min-width為更大的視口添加斷點時覆蓋和/或添加新樣式（有關詳細概述，請參閱“什么是移動優(yōu)先 CSS 以及它為何如此受歡迎？ ”）。但是所有這些異常都會造成復雜性和低效率，這反過來又會導致測試工作量增加和代碼庫更難維護。承認吧——我們當中有多少人愿意這樣做？

在您自己的項目中，移動優(yōu)先的 CSS 可能仍然是這項工作的最佳工具，但首先您需要根據(jù)您正在處理的視覺設計和用戶交互來評估它的適用性。為了幫助您入門，以下是我解決您需要注意的因素的方法，如果移動優(yōu)先似乎不適合您的項目，我將討論一些替代解決方案。

移動優(yōu)先的優(yōu)勢

移動優(yōu)先 CSS 開發(fā)的一些優(yōu)點——以及為什么它長期以來一直是事實上的開發(fā)方法——很有意義：

發(fā)展層次。毫無疑問，您從移動優(yōu)先中獲得的一件事是一個很好的開發(fā)層次結構——您只需專注于移動視圖并開始開發(fā)。

嘗試和測試。這是一種久經(jīng)考驗的方法，多年來一直有效：它很好地解決了問題。

優(yōu)先考慮移動視圖。移動視圖是 最簡單 的，也可以說是最重要的，因為它包含所有關鍵的用戶旅程，并且通常占用戶訪問的更高比例（取決于項目）。

防止以桌面為中心的開發(fā)。由于開發(fā)是使用臺式計算機完成的，因此最初專注于桌面視圖可能很誘人。但是從一開始就考慮移動設備可以防止我們以后陷入困境；沒有人愿意花時間改造以桌面為中心的網(wǎng)站以在移動設備上工作！

移動優(yōu)先的缺點

設置樣式聲明然后在更高的斷點處覆蓋它們可能會導致不良后果：

更復雜。你去的斷點層次越遠，你從較低的斷點繼承的不必要的代碼就越多。

更高的 CSS 特異性。在類名聲明中已恢復為其瀏覽器默認值的樣式現(xiàn)在具有更高的特異性。當您想讓 CSS 選擇器盡可能簡單時，這對于大型項目來說可能是一件令人頭疼的事情。

需要更多的回歸測試。在較低視圖中對 CSS 的更改（例如添加新樣式）需要對所有較高的斷點進行回歸測試。

瀏覽器無法優(yōu)先考慮 CSS 下載。在更廣泛的斷點處，經(jīng)典的移動優(yōu)先min-width媒體查詢不會利用瀏覽器按優(yōu)先級順序下載 CSS 文件的能力。

屬性值覆蓋問題

覆蓋值本身并沒有錯。CSS 就是為此而設計的。盡管如此，繼承不正確的值是沒有幫助的，并且可能是繁重且效率低下的。當您必須覆蓋樣式以將其重置為默認值時，它還可能導致樣式特異性增加，這可能會在以后引起問題，尤其是在您使用定制 CSS 和實用程序類的組合時。我們將無法將實用程序類用于已以更高特異性重置的樣式。

考慮到這一點，我現(xiàn)在開發(fā)的 CSS 更多地關注默認值。由于沒有特定的順序，也沒有要跟蹤的特定值鏈，這讓我可以同時開發(fā)斷點。我專注于在封閉的媒體查詢范圍（即具有max-width集合的任何范圍）中尋找常見樣式并隔離特定異常。

這種方法開辟了一些機會，因為您可以將每個斷點視為一張白紙。如果一個組件的布局看起來應該在所有斷點處都基于 Flexbox，那很好，可以在默認樣式表中編碼。但是，如果 Grid 看起來更適合大屏幕，而 Flexbox 更適合移動設備，那么當 CSS 放入封閉的媒體查詢范圍時，這些都可以完全獨立完成。此外，同時開發(fā)要求您預先對所有斷點中的任何給定組件都有很好的理解。這有助于在開發(fā)過程的早期發(fā)現(xiàn)設計中的問題。我們不想陷入為移動設備構建復雜組件的兔子洞，然后在獲得桌面設計時發(fā)現(xiàn)它們同樣復雜且與我們?yōu)橐苿右晥D創(chuàng)建的 HTML 不兼容！

盡管這種方法并不適合所有人，但我鼓勵您嘗試一下。有很多工具可以幫助并發(fā)開發(fā)，例如Responsively App、Blisk等等。

話雖如此，我覺得訂單本身并不是特別相關。如果你習慣于專注于移動端視圖，對其他斷點的需求有很好的理解，并且更喜歡一次在一臺設備上工作，那么一定要堅持經(jīng)典的開發(fā)順序。重要的是識別常見的樣式和異常，以便您可以將它們放入相關的樣式表中——一種手動搖樹的過程！就個人而言，我發(fā)現(xiàn)在跨斷點處理組件時這會更容易一些，但這絕不是必需的。

實踐中的封閉媒體查詢范圍

在經(jīng)典的移動優(yōu)先 CSS 中，我們會覆蓋樣式，但我們可以通過使用媒體查詢范圍來避免這種情況。為了說明區(qū)別（為了簡潔起見，我使用 SCSS），讓我們假設有三種視覺設計：

• 小于 768
• 從 768 到 1024 以下
• 1024及更大的

舉個簡單的例子，塊級元素的默認padding值為“20px”，在平板電腦上被覆蓋為“40px”，在桌面上設置回“20px”。

經(jīng)典min-width移動優(yōu)先：

.my-block {
  padding: 20px;
  @media (min-width: 768px) {
    padding: 40px;
  }
  @media (min-width: 1024px) {
    padding: 20px;
  }
}

封閉媒體查詢范圍：

.my-block {
  padding: 20px;
  @media (min-width: 768px) and (max-width: 1023.98px) {
    padding: 40px;
  }
}

細微的區(qū)別在于，移動優(yōu)先的示例將默認設置padding為“20px”，然后在每個斷點處覆蓋它，總共設置了 3
次。相比之下，第二個示例將默認值設置padding為“20px”，并且僅在它不是默認值的相關斷點處覆蓋它(在這種情況下，tablet 是例外)。

目標是：

• 僅在需要時設置樣式。
• 不要讓他們期望以后一次又一次地覆蓋它們。

為此，封閉的媒體查詢范圍是我們最好的朋友。如果我們需要對任何給定視圖進行更改，我們會在適用于特定斷點的 CSS 媒體查詢范圍內進行更改。我們將不太可能引入不需要的更改，并且我們的回歸測試只需要關注我們實際編輯的斷點。

以上面的例子為例，如果我們發(fā)現(xiàn).my-block桌面上的間距已經(jīng)被該斷點處的邊距考慮了，并且由于我們想要完全刪除填充，我們可以通過將移動設備設置padding在封閉的媒體查詢范圍內來做到這一點。

.my-block {
  @media (max-width: 767.98px) {
    padding: 20px;
  }
  @media (min-width: 768px) and (max-width: 1023.98px) {
    padding: 40px;
  }
}

我們塊的瀏覽器默認值為“0”，因此我們可以將移動設備包裝在封閉的媒體查詢中padding，而不是添加桌面媒體查詢并使用unset或“0”作為值（移動優(yōu)先）因為它現(xiàn)在也是一個例外）所以它不會在更寬的斷點處被拾取。在桌面斷點處，我們不需要設置任何樣式，因為我們需要瀏覽器默認值。paddingpaddingpadding

捆綁與分離 CSS

過去，由于瀏覽器的并發(fā)請求數(shù)限制（通常約為 6 個），將請求數(shù)保持在最低限度非常重要。因此，圖像精靈和 CSS 捆綁的使用成為常態(tài)，所有 CSS 一次性下載，作為具有最高優(yōu)先級的一個樣式表。

隨著 HTTP/2 和 HTTP/3 的出現(xiàn)，請求的數(shù)量不再是過去的大問題。這允許我們通過媒體查詢將 CSS 分成多個文件。這樣做的明顯好處是瀏覽器現(xiàn)在可以請求它當前需要的 CSS，其優(yōu)先級高于它不需要的 CSS。這更高效并且可以減少頁面呈現(xiàn)被阻塞的整體時間。

您使用的是哪個 HTTP 版本？

要確定您使用的 HTTP 版本，請訪問您的網(wǎng)站并打開瀏覽器的開發(fā)工具。接下來，選擇網(wǎng)絡選項卡并確保協(xié)議列可見。如果“h2”列在Protocol下，則表示正在使用 HTTP/2。

注意：要在瀏覽器的開發(fā)工具中查看協(xié)議，請轉到網(wǎng)絡選項卡，重新加載頁面，右鍵單擊任何列標題（例如，名稱），然后檢查協(xié)議列。

此外，如果您的網(wǎng)站仍在使用 HTTP/1...為什么？??！你在等什么？對 HTTP/2有很好的用戶支持。

拆分 CSS

將 CSS 分成單獨的文件是一項有價值的任務。使用相關屬性鏈接單獨的 CSS 文件media允許瀏覽器立即識別哪些文件是需要的（因為它們是渲染阻塞的），哪些可以延遲?；诖?，它為每個文件分配適當?shù)膬?yōu)先級。

在以下在移動斷點上訪問的網(wǎng)站示例中，我們可以看到移動和默認 CSS 以“最高”優(yōu)先級加載，因為當前需要它們來呈現(xiàn)頁面。其余的 CSS 文件（打印、平板電腦和桌面）仍會下載以備日后需要，但優(yōu)先級為“最低”。

使用捆綁的 CSS，瀏覽器必須先下載 CSS 文件并對其進行解析，然后才能開始渲染。

雖然，如前所述，將CSS 分成不同的文件，鏈接并用相關media屬性標記，瀏覽器可以優(yōu)先考慮它當前需要的文件。使用封閉的媒體查詢范圍允許瀏覽器在所有寬度上執(zhí)行此操作，而不是經(jīng)典的移動優(yōu)先min-width查詢，其中桌面瀏覽器必須以最高優(yōu)先級下載所有 CSS。我們不能假設桌面用戶總是有一個快速的連接。例如，在許多農(nóng)村地區(qū)，互聯(lián)網(wǎng)連接速度仍然很慢。

媒體查詢和單獨的 CSS 文件的數(shù)量將根據(jù)項目要求因項目而異，但可能類似于下面的示例。

根據(jù)項目的部署策略，對一個文件（mobile.css例如 ）的更改只需要 QA 團隊在該特定媒體查詢范圍內的設備上進行回歸測試。將其與部署單個捆綁site.css文件的前景進行比較，這種方法通常會觸發(fā)完整的回歸測試。

繼續(xù)

移動優(yōu)先 CSS 的采用是 Web 開發(fā)中一個非常重要的里程碑。它幫助前端開發(fā)人員專注于移動 Web 應用程序，而不是在桌面上開發(fā)網(wǎng)站，然后嘗試對其進行改造以在其他設備上工作。

我認為沒有人想再次回到那種開發(fā)模式，但重要的是我們不要忽視它所強調的問題：如果我們優(yōu)先考慮一種特定設備（任何設備），事情很容易變得復雜且效率低下。其他。出于這個原因，專注于 CSS 本身，始終注意什么是默認設置和什么是異常，似乎是很自然的下一步。我已經(jīng)開始注意到我自己的 CSS 以及其他開發(fā)人員的 CSS 進行了一些小的簡化，并且測試和維護工作也更加簡化和高效。

一般來說，盡可能地簡化 CSS 規(guī)則的創(chuàng)建最終是一種比繞著覆蓋循環(huán)更干凈的方法。但無論您選擇哪種方法，它都需要適合項目。移動優(yōu)先可能會（也可能不會）成為所涉及內容的最佳選擇，但首先您需要充分了解您要進行的權衡取舍。