重新加工CSS年鑑

CSS-Tricks Almanac煥然一新！

想必您已經熟悉CSS-Tricks的這個龐大的部分——Almanac（年鑑）。在這裡，我們發布CSS選擇器和屬性的參考文檔。自古以來……或者至少自2009年（大部分原始工作完成之時）以來，我們只發布了這些內容。在網頁年代，那幾乎就是時間的開端。我們甚至可以稱之為響應式設計之前的第1年（BR），或者響應式設計後的第14年（AR）。

您無需我告訴您，如今在響應式設計後的第14年編寫CSS與以往大不相同。簡而言之，Almanac並沒有跟上CSS的發展步伐，而CSS遠不止是屬性和選擇器。事實上，我們一直不願修改Almanac，因為它在後端的配置方式，而且我敢肯定，當我觸碰它時，在那裡看到了一兩個幽靈。

現在訪問Almanac，您會發現更廣泛的CSS信息，除了現有的屬性和選擇器部分外，還包括偽類選擇器、函數和@規則的專用部分。我們還有很多工作要做（您應該幫忙！），但架構已經存在，如果需要，還有空間可以擴展。

這項工作並非易事，也像我想像的那樣令人害怕。讓我帶您了解我所做的一些事情。

現狀

我們自第一天起就自豪地運行WordPress。這有很多好處，尤其是在模板方面。它可能不是每個人的最愛，但我對此非常滿意，並毅然投入——不顧一切！

如果您熟悉WordPress，那麼您知道內容主要分為兩種類型：頁面和文章。兩者之間的區別微乎其微——幾乎無法區分，因為它們都使用相同的編輯界面。當然，也有一些細微差別，但頁面的主要區別在於它們是分層的，這意味著它們最適合建立父子頁面關係，從而創建一個結構良好的站點地圖。同時，文章更側重於元數據，我們可以通過添加標籤或將它們放入類別組或我們觸手可及的任何自定義分類法來組織內容。

Almanac是基於頁面構建的，而不是文章。頁面擅長分層結構，而Almanac是一個高度結構化的區域，具有典型的站點地圖式流程，它恰好遵循字母順序。例如，CSS屬性的條目，比如aspect-ratio，路徑為：Almanac → 屬性 → A → Aspect Ratio。

這聽起來不錯，對吧？不錯，但是頁面在模板中的查詢比文章更困難，文章有更多可用於過濾等的元數據。另一方面，頁面則不然。 （至少不是顯而易見的。）它們通常作為結構化對象返回，因為，你知道，分層結構。但這也意味著我們必須手動創建所有這些頁面，不像標籤和類別那樣會自動生成歸檔。為字母“A”創建一個空頁面，它是“屬性”頁面的子頁面——本身是Almanac的子頁面——感覺太傻了，僅僅是為了有一個邏輯位置來插入以字母A開頭的屬性。這對於屬性和選擇器都必須這樣做。

真正的問題是Almanac的功能不足。我們想在那裡發布其他CSS內容，例如函數和@規則，但Almanac最初只構建用於顯示兩組內容。這就是為什麼我們從未發布其他任何內容的原因。這也是為什麼通用選擇器和偽選擇器在同一個桶裡的原因。

擴展空間以容納更多內容是我工作的範圍，我知道我將有機會在此過程中調整樣式。

一個模板統治所有

事情就是這樣做的。最初的做法是使用單個模板來處理Almanac索引和列出選擇器和屬性的字母頁面。這很巧妙。頁面首先檢查當前頁面是否是位於頁面層次結構頂部的Almanac頁面。如果是該頁面，則模板會在同一頁面上的兩列中輸出選擇器和屬性的結果。

該查詢非常令人印象深刻。

<?php function letterOutput($letter, $selectorID, $propertyID) {
  $selector_query = new WP_Query(array(
    'post_type' => 'page',
    'post_status' => 'publish',
    'post_parent' => $selectorID,
    'posts_per_page' => -1,
    'orderby' => 'title',
    'order' => "ASC"
  ));

  $html = '<div>';
  $html .= '<div><a>' . $letter . '</a></div>';
  $html .= '<div>';

  while ($selector_query->have_posts()) : $selector_query->the_post();

    $html .= '<details><summary>';
    $html .= '<h2><code>';
    $html .= get_the_title();
    $html .= '</code></h2>';
    $html .= '</summary>';
    $html .= get_the_excerpt();
    $html .= '<code>';
    $html .= get_post_meta(get_the_id(), 'almanac_example_code', true);
    $html .= '</code>';
    $html .= '<a href="'%20.%20get_the_permalink()%20.%20'">Continue Reading</a>';
    $html .= '</details>';
  endwhile;

  $html .= "</div>";
  $html .= "</div>";

  return $html;
}

這實際上只是一半的代碼片段。請注意，它只標記為$selector_query。它會再次循環遍歷$property_query。

從那裡，該函數需要調用26次：字母表中的每個字母一次。它需要三個參數，即字母（例如A）和“A”頁面的頁面ID（例如14146、13712），它們是選擇器和屬性的子頁面。

<?php echo letterOutput("A", 14146, 13712);
  // B, C, D, E F, G, etc.
?>

如果我們當前不在索引頁面上呢？模板會輸出該特定部分（例如屬性）的子頁面的字母列表。一個模板就足夠了。

查詢子頁面

我可以修改letterOutput()函數以獲取更多頁面ID來顯示其他部分的字母頁面。但老實說，我只是不想那樣做。我選擇改為將函數減少為一個頁面ID參數，而不是兩個，然後拆分模板：一個用於主索引，一個用於“子部分”（如果有的化）。是的，這意味著我的WordPress主題目錄中會有更多模板，但這主要針對我個人，我不介意。我可以檢查我所在的子頁面（是屬性索引、選擇器索引、@規則索引等），並分別獲取這些子頁面的內容。

函數的另一個問題是什麼？所有生成的標記都夾在while()語句中。即使我想按部分解析查詢以保留單個模板架構，也不像我想在其中任何地方放置if()語句而不會導致PHP致命錯誤或通知。再說一次，我對徹底修改該函數不感興趣。

字母歸檔

發布所有這些部分的字母的空子頁面，然後將它們附加到正確的父頁面，這是一項大量的手工工作。我知道，因為我做過。當然有更好的、甚至是編程的方式，但是將內容從頁面轉換為文章並從這個角度出發並沒有吸引我，而且我當時時間緊迫。我們並不總是能夠找到一種“理想”的方式來做事。

根據WordPress的說法，將這些字母頁面中的任何一個稱為“歸檔”是一種誤稱，但這正是我看待不同部分的子頁面的方式——如果這些內容是作為文章而不是頁面構建的，那就會是這樣。如果我有一個偽選擇器部分，那麼我將需要A到Z的各個頁面，這些頁面反過來充當各個偽選擇器的父頁面。三個新的部分，每個部分有26個字母，這意味著我創建了78個新頁面。太棒了。

您可以通過Almanac頁面的麵包屑（例如，aspect-ratio屬性的此頁面）或單擊任何部分中的大寫字母（例如，屬性的此頁面）來訪問字母頁面。

我們從未認真對待這些頁面。它們是為了結構而存在的，但並不是很多人會訪問它們。它們本質上是佔位符。有用，是的，但仍然是佔位符。我們對這些頁面如此不認真，以至於我們從未正式為它們設置樣式。這是一個CSS繼承的模型，告訴你什麼。

這就是我抓住機會在視覺上進行潤色的地方。自從幾個月前回到這份工作以來，我一直都在處理設計中龐大而粗獷的事物。例如，您看到的超大標題和厚厚的陰影。

這不是我的自然審美觀，但我認為它與CSS-Tricks很搭配……也許，只是也許，Chris Coyier臉上會流下欣喜的淚水。也許吧。

導航

在主索引頁面上顯示的導航中添加了另一個增強功能。我將頂部的字母導航替換為一個導航，它可以帶您到每個部分，現在我們可以直接在WordPress中編輯頁面，而無需繞過開發。

唯一讓我困擾的是，我將它硬編碼了，而不是將其製作成一個合適的WordPress菜單，我可以從管理界面進行管理。 [在他的待辦事項列表中添加一個TODO。 ]

自從我將Almanac索引從完全顯示選擇器和屬性列表中解放出來後，我就可以真正地將其用作我們正在添加的大量部分的索引。

我們可能需要在某個時候讓主頁面內容與導航的冗餘度降低，但我認為這是一個良好的開端，我們可以從中構建。此外，就標題而言，它現在與網站主菜單中鏈接的其他“頂級”頁面更加一致，這不會壞事。

哦，對了，當我們談論導航時，新的部分已添加到各個Almanac頁面的現有左側邊欄中，以幫助跳轉到任何部分中的其他條目，而無需返回索引。

快速參考內容

我將要提到的最後一個增強功能很小，但我認為它帶來了積極的影響。如果您轉到索引的任何子頁面——即選擇器、屬性、偽類、函數、@規則——則無需跳轉到完整頁面，即可隨時獲得每個條目的代碼片段和高級定義。

我們一直非常重視“快速訪問示例”，我認為這在很大程度上幫助了這一目標。

“你也可以做[x]……”

是的，還有很多機會來改進。我唯一的目標是將事情改變得足夠多，以便Almanac涵蓋的內容不僅僅是選擇器和屬性，並且可能在這里和那裡進行一些樣式調整。我還想做很多事情，也許我們會做到，儘管是逐步進行的。

什麼樣的事情？好吧，首先是那個硬編碼的索引導航。但更重要的是，我想繼續推動主頁面。它以前發揮著巨大的作用，而我幾乎把它抹去了。找到一種方法來列出所有條目的方法——對於所有部分——在我們只有兩個部分時所做的那樣，將會很好。這是我計劃研究的事情。

是的，我們想在那裡涵蓋更多CSS內容，例如通用術語、媒體和用戶首選項查詢，可能是規範……您明白了。 Almanac對我們團隊來說是一個資源，就像對您一樣，我們每天都會參考它。我們希望它充滿有用的信息。

就是這樣。

您現在可以停止閱讀，直接前往Almanac進行虛擬漫步。

以上是重新加工CSS年鑑的詳細內容。更多資訊請關注PHP中文網其他相關文章！