代碼作為文檔：CSS網格的新策略

Supercool，一家快速發展的網頁設計公司，為藝術客戶創建定製網站，並使用現成的Craft CMS系統；它具有高規格的圖形設計，以及相對苛刻的排版和藝術指導。在過去的幾個月裡，我們一直在轉向CSS Grid。我們正在緩慢過渡，允許自己發現新的範例和設計方法，而不是簡單地將舊習慣移植到新的語法中。

到目前為止，我們已經開發出了一些非常有用的策略來跟踪佈局。我已經編寫了一些非常巧妙的mixin，使用了命名區域和模板，並且我們已經找到了一些基本約定來創建高度可讀的代碼。我認為，逐步講解使用grid的單個主要組件的完整生產實現，深入探討它提出的一些設計問題，並引導您避免我們遇到的陷阱，將非常有價值。 CSS Grid是一個大型規範，有很多可能的方法和很多正確的方法，但在某個時刻，您必須確定您的方法並使其上線。

我期望您對CSS、Sass、BEM有一定的了解，並且對在緊迫的時間表（例如一周）內，使用Sketch或Photoshop類型的文檔，原型化完全實現的、可訪問的、自定義框架（包含50多個組件）的任務感興趣。

首先，讓我們識別並分離出設計中的不同編碼任務，並規劃我們將如何處理它們：

1. 字體:設計師已經定義了一個字體系統。
2. 顏色:首先，我們構建一個主題模型，然後將其包含在部分中。
3. 內容:此塊中包含哪些元素？它的變體是什麼？這就是我們的BEM mixin發揮作用的地方。
4. 佈局:這就是內容在此塊中的放置方式。您可能希望直接跳到此步驟。
5. 約定:這正是我們選擇編寫上述所有內容的方式。 CSS中有很多正確答案，因此重要的是我們都同意一個約定，即規則。這確實應該排在第一位，但為了本文的緣故，我們將在最後總結。

字體系統

我們使用實用程序類（例如h-text--h1、h-text--badge）來設置字體樣式。一個項目中可能有一百種字體樣式。我們使用Typex將這些樣式從Sketch直接導出到我們的Patternlab中。這本身就是另一篇文章的內容，所以讓我們假設字體已經處理完畢。我們不會將字體引入我們的組件部分。

顏色使用

主題化只需添加幾個微小的mixin，因此理想情況下，我們不會在部分中看到大量的顏色規則。我們將它們全部存儲在“Mixin和模型”庫中的_themer.scss部分中，這樣我們可以確保遵循網站的設計系統。這樣，當有人稍後返回構建時，他們就有一個關鍵的參考部分來描述設計和品牌規則。當在大致相同的市場中構建和維護許多網站時——但每個網站都有不同的品牌規格——您必須確保不會將一個品牌與另一個品牌混淆！因此，與字體一樣，我們將顏色規則從部分中抽像出來。從本質上講，在我們的_header.scss文件中，我們實際上只關注佈局（盡可能多）。

鑑於我們同意始終使用我們的mixin進行主題化，這就是如何在元素上包含它的方式：

 <code>@include var($property, $value);</code>

然後，我們將設置一個主題模型，說明顏色在此特定網站上的工作方式，並將其應用於組件：

 <code>@include theme;</code>

這是我們將與此頁面標題一起使用的示例主題模型。它非常簡單。

我們將顏色與黑色或白色配對。我們依賴於對比度規則，並為強調它們進行翻轉，可能是在事件（如懸停）或突出顯示的號召性用語上。這就是我們實現這一目標所需做的全部工作，現在我們有了關於顏色在此網站上實際工作方式的文檔。如果我們需要調試或擴展UI，我們可以訪問並檢查它。

我們還希望準備繼承以幫助我們，因此讓我們確定一些有用的約定：

• 在您的管道中將SVG圖標的填充設置為currentColor（順便說一句，在CSS中默認大小為width: 1em; height: 1em; font-size: inherit; ）。
• 在基礎處設置<a></a>為currentColor。
• 編寫簡寫，繼承邊框（例如1px solid或1px solid currentColor ）。

使用此主題模型，我們可以生成任意數量的主題，也許將它們存儲為實用程序類，或者在組件內循環遍歷修飾符列表，或者只允許用戶直接在CMS中的塊上設置變量。當IE 11在我們統計數據中的佔比低於1%時，我們可以使用變量做更多的事情，但這對於我們目前的用途來說已經足夠了。

讓我們不要偏離主題。 Grid怎麼樣？ ！

內容組件

Grid讓我們能夠以一種新的方式精確地描述每個部分中我們擁有的內容。對於為每個項目構建新UI的設計機構來說，這確實是一個改變遊戲規則的東西，並且在我們探索的過程中，我們正在發現它的新（且有趣）的應用。

為了提供上下文：我們使用Craft CMS為我們的客戶定制每個界面，並創建自定義字段以滿足他們的特定需求和他們的內容模型。我們擁有內部工具，可以從票務API中提取事件並從中創建條目，然後可以在CMS中編輯和擴展這些條目（或完全創建）。客戶可以在永久頁面區域中填寫或編輯命名字段，並且還可以將整個設計好的、品牌的塊添加到每個頁面的佈局中，因為他們正在構建它們。

有很多UI。客戶對內容有很大的控制權，而我們對HTML有很大的控制權，因此我們可以確保頁面上具有高質量的可訪問的語義代碼。我們在發現過程中共同開發內容模型，然後讓他們自由創建內容。他們添加他們想要的內容，我們確保它有效並且始終看起來正確。比正確更好！超級。 （對不起！:P）

因此，作為一名開發人員，我必須權衡相互競爭的優先事項：

• 可訪問性、可用性
• 品牌和圖形設計
• 性能
• 維護和代碼庫健康

讓我們逐一查看它們：

可訪問性

可訪問的、邏輯的HTML是我的最愛。至少，我的項目需要在Lighthouse評分中獲得綠色可訪問性評分。 （我在開玩笑，我想要那個美味的100！）核心路徑和頁面使用一些屏幕閱讀器（鍵盤選項卡、鍵盤導航）、低視力模擬器、Dasher、語音訪問和二進制開關進行測試。 （我還為Robots and Cake工作，所以這是我開發工作的重要組成部分。）我一遍又一遍地將巨大的可點擊電話號碼和電子郵件地址添加到頁面中。我只是想讓人們到達他們想去的地方。

我一直擔心內容可以通過grid（以及flexbox）重新排序的方式。現在我已經完成了幾個構建，我實際上認為grid可以幫助我們解決這個問題。使用CSS Grid，沒有理由為了佈局而移動HTML。我們可以回到將整個文檔視為邏輯的線性序列作為我們首要關注點。

品牌與性能與維護

藝術場所需要高規格的圖形設計，在印刷品和網絡上統一，並且需要不斷更改的材料（例如節目、手冊、門票、海報、微型網站等）來向他們的觀眾分發，包括必須滿足的合同營銷義務。正如您所能想像的，我們有很多高質量的大圖像需要優先處理，並且通常帶有強大的以印刷為主導的品牌。這意味著我們可能需要向頁面提供大約十五種自定義字體（包括粗細變化、顯示字體等）以及復雜的CSS。我們必須讓自己盡可能精簡。我們目前正在發送大約20 KB nano Gzipped的CSS，但我正在努力進一步減少它。

但是，我們確實通過在PostCSS任務中將reduce標識符設置為false來保持grid區域名稱的完整長度。在DevTools中擁有可用的佈局圖比節省那些少量字節更有用。為了維護、自文檔化以及您未來在Sowerby Bridge的一列延誤的火車上沒有repo訪問權限的情況下調試此網站的未來的自己的緣故：保留地圖。

代碼健康

平衡所有這些相互競爭需求的方法是闡明並達成約定，以便在測試中需要修復的內容更少，並且已解決的問題保持解決。我們檢查我們構建的所有組件，並確保它們始終以標題開頭，鏈接指向位置，按鈕觸發操作，可計數的對像作為列表交付並在前面加上地標標題，導航是<nav></nav>，時間是<time></time>，div湯是早餐——基礎知識。

使用CSS Grid，沒有理由為了佈局而移動HTML 。您的內容始終可以邏輯地流動，而佈局更改則發生在CSS中。並且，由於不需要邊距或填充來創建間距，您可以簡單地聲明：

 <code>.o-grid .o-grid { width:100%; }</code>

……以確保任意數量的嵌套組在視覺上都佔據相同的頁面網格。 HTML可以更清晰地指導事物真正是什麼：更接近文檔。

在標題和操作之間有很多內容需要管理，我的挑戰是跟踪所有這些組件中的所有這些字段，同時確保我忠實地執行設計規範，使其可遍歷、可掃描、可線性化並易於以某種邏輯的、可理解的方式讀取。

讓我們引入我的第一個、令人驚訝的有用的grid mixin。

 <code>@mixin template($elements...) { @each $element in $elements { &__#{$element} { grid-area: $element; } } }</code>

在任何地方使用此mixin意味著：

1. 每個組件部分現在都以其所有可能的元素列表開頭，這是一個非常方便的文檔，尤其是在Twigging實際前端組件時。
2. mixin負責分配grid區域。
3. 元素和組件名稱在Sketch、CSS和HTML中保持一致，任何不一致之處都將非常明顯，因為佈局將失敗。我態度堅定，但公平。
4. BEM命名會自動強制執行，但不會在部分中弄亂事情。

現在，在部分中，我們將只聲明grid-template-areas，使用普通的英語單詞，為我們提供一系列佈局地圖，這些地圖也與數據庫字段匹配。超級易讀！

以下是如何使用此mixin的示例：

我們決定堅持使用命名區域進行內部網格，因為我在這個網站上讀到一篇很棒的文章，解釋瞭如果您堅持使用列出的受支持屬性，Autoprefixer 如何處理IE 11的grid——並且它在大多數情況下確實如此。如果您在瀏覽器測試中使用應用了Autoprefixer的超級有用的調試模式查看此測試用例，您將看到它正在工作。

但是有陷阱！您必須將內聯元素設置為塊以確保它們始終在IE 11中作為grid單元操作。註釋掉示例中的標記行以查看否則會發生什麼：

哎喲！小心那些塊。您可能會發現某些版本的IE 11甚至不會拾取此修復程序，在這種情況下，您可能會嘗試只使用普通的<div>標籤……嘆息。<p>我沒有在此mixin中包含<code>display: grid ，因為在某些情況下，實際的grid是在內部容器上設置的，例如，但我們仍然希望grid-areas與正確的BEM類匹配。

所以：

 <code>.c-header{ @include template(title, pretitle, posttitle, producer, venue, credit, quote, nav, infobar, search); }</code>

讓我們來佈局這些東西。

佈局

讓我們確定一些額外的規則，以確保此組件可以輕鬆滑入頁面佈局。在撰寫本文時，沒有可用的子網格（但會有！），因此此組件不知道它所在的父網格。這恰好與BEM組件方法很好地匹配——因為每個組件都是扁平的、孤立的，以限制繼承。我在這裡不是提倡BEM（或者我們顯然使用的BEM- ish ）——我只是說，如果您已經在使用它，這是一個額外的好處。

在此示例中，設計師設置了一個頁面佈局，該佈局具有12列網格和20px（1.25rem）間距，全站範圍內，沒有偏移部分。我們的組件是一個頁面區域，將佔據所有12個網格列。在這個過渡時期，我們仍在使用這種類型的設置網格，因為我們有很多仍然基於這個想法的系統需要與之集成。因此，這是此條件下的約定：對於全寬區域，刪除網格間隙並將網格模板列寫為12的分數單位（fr）。

這樣做意味著：

1. 此內部網格的視線大致遵循其所在的網格；
2. 輕鬆查看代碼中的底層設計規則；以及
3. 如果需要，可以輕鬆地將事物精確地對齊。

關於“對齊”的快速說明

等等……我的意思是“精確對齊”是什麼意思？它難道不是已經精確對齊了嗎？

嗯，不是。分數單位方法完美地劃分空間，因此您最終會進入間距。兩列均勻的列會讓您位於間距的中間。其中一列為2/3而另一列為1/3的兩列將在該間距的1/3處分割，依此類推。

修復對齊並不難，因為我們知道頁面網格間距的寬度。例如，在均勻分割上，我們可以包含網格間隙。

但是，我們不能對任何其他分割這樣做。我們可以做的是將該間隙添加為邊距——無論您設置了什麼盒大小，邊距都會在內部添加。在此示例中，我們有三列（兩個命名區域和一個空空間），將我們的間距分成三份：

這就是計算這些邊距的方法：確保fr單位的總和結果為12。將網格間隙除以父網格中的列數，然後像這樣相乘：

n的右邊距乘數等於n右側fr單位的總和。 n的左邊距等於n左側fr單位的總和。

因此，對於grid-template-columns值為2fr 3fr 2fr 4fr 1fr ：

<code> 2 3 2 4 1 0/10 2/7 5/5 7/1 11/0</code>

如果您發現自己經常編寫calc() ，您甚至可以將其編寫為mixin。例如，以下是如何將內部網格與父網格對齊：

……以及以下是如何在名稱在內部指定但數字在網格外指定時自動計算邊距：

我相信您可以想到其他解決方案，例如切換到命名行，或添加額外的固定寬度列，甚至使用12個命名區域每行編寫所有地圖。有很多方法可以處理這個問題，但我認為很多方法都消除了命名區域的優勢。區域為我們提供了一個可讀的佈局圖，其中包含我們未來的自己需要知道的內容。它是代碼作為文檔。

需要明確的是，我正在引導我們解決的設計問題不是對齊問題。使用grid，對齊很容易。問題不在於解決直接的、微不足道的佈局問題，而在於以一種支持我們目標的方式解決它，即能夠在六個月後理解：

1. 組件中包含哪些元素。
2. 它們的佈局方式。
3. 為什麼代碼以這種方式編寫。

grid規範非常龐大，很容易迷失在選項中。也許更好的計劃是重置為12列網格，並在需要絕對對齊時使用數字規範（即明確鏈接到我們的頁面網格，該網格使用數字規範）——但我確實覺得有一個更智能、更簡單的解決方案有待發現。對於此網站，我們最終編寫了一個頁面網格對象，並使用類向其添加了嵌套的內部網格單元： .o-page-grid\_\_sidebar 。

你們怎麼看？我肯定預見到對此會有不同的看法。 ?‍♀️

真實的grid！

我們可以使用它來創建一個通用的頁面標題：

或者，我們可以創建一個主頁的變體：

那麼，一個超出我們容器的英雄標題呢？當然！或者我們也可以在容器外提供它：

接下來是什麼？一個帶有全寬信息欄（粘貼）和一個與父網格上的側邊欄對齊的內部按鈕的主題化事件標題？沒錯。我將包含一個父網格，以便更容易查看：

那麼帶有居中對齊的搜索呢？讓我們使用折疊列技術：

以下是所有這些變體作為單個部分的演示。是的，它是一張地圖！它是一個包裝！

約定

哇，我們涵蓋了很多內容！但是您可以看到像這樣的系統有多靈活和自文檔化，對吧？

1. 字體由單獨的字體系統處理。
2. 顏色由一個主題部分處理，該部分描述設計的底層顏色規則，而不是簡單地臨時著色元素。
3. 元素被稱為它們是什麼，用英語，並在部分頂部使用模板mixin作為列表包含。此列表可以作為參考包含在Twig或模板中。
4. 始終使用正確的HTML，並且嵌套不會破壞grid。這意味著您可以通過設置約定將任意數量的嵌套grid應用於相同的佈局空間。
5. 精確的對齊是在數字規範中完成的，而不是名稱規範（但請注意，可以使用名稱規范進行對齊）。
6. 支持IE 11。

我還有一張快速說明和另一個使用命名區域構建的組件示例。在此示例中，卡片不是區域，而是放置在網格中的組件，因此沒有理由使用12的fr約定。您可以預期媒體對象部分如下所示：

 <code>.c-card { &--news { align-content: start; grid-template-areas: "image" "datetime" "title"; } &--search { justify-content: start; grid-template-columns: 1fr 3fr; grid-template-areas: "image page" "image title" "image summary"; } &--merchandise { grid-gap: 0; grid-template-columns: $b 1fr 1fr $b; grid-template-areas: "image image image image" ". title title ." ". summary summary ." ". price action ."; } &--donations { // donations thanks button is too long and must take up more space than input grid-gap: 0; grid-template-columns: $b 1fr 2fr $b; grid-template-areas: "image image image image" ". title title ." ". summary summary ." ". input action ."; } } // ...</code>

以上是代碼作為文檔：CSS網格的新策略的詳細內容。更多資訊請關注PHP中文網其他相關文章！