未來的主題：設計框架和主主題

WordPress 主題有著悠久的歷史。 多年來，主題作者為該平台帶來了大量功能。 部分原因是他們經常不得不解決 WordPress 的基本問題，以創建最終用戶想要的功能。

所有主題作者今天使用的帖子和正文類？ 這些最初是在一個名為沙盒的主題中。

特色圖片？ 這些在十年前被雜誌主題所普及。

你認為帖子格式起源於 Tumblr？ WordPress 的共同創建者 Matt Mullenweg 在 2004 年教我們如何在主題中創建旁注，但在此之前它們就存在了。

WordPress 功能通常始於主題世界。 我們有時認為主題作者投入工作的想法多年的實驗和迭代是理所當然的。 甚至塊編輯器也在處理傳統上屬於主題設計領域的項目。 蓋塊就是一個很好的例子。 多年來，主題作者為帶有文本和按鈕的基本英雄圖像構建了主題選項。 結果通常很笨拙，對用戶來說並不理想。 通過將此功能引入核心，它使用戶能夠將此覆蓋塊放置在任何允許的塊區域中。

許多主題功能使其成為核心的原因是它們在標準化時工作得更好。 用戶知道會發生什麼，主題作者可以專注於設計方面，而不是解決用戶體驗問題。

過去的部分問題是核心採用的每個新特性都沒有遵循任何標準的設計模式或命名方案。 設計 WordPress 主題的一項巨大技能是將數百個類的混搭提交到記憶中。

塊編輯器處於獨特的位置，可以通過創建通用設計框架來改變這一點。

WordPress 需要前端設計框架嗎？

隨著未來的塊模式和之後某個時候的全站點定制，主題作者想知道這艘船到底在哪裡航行。 這是令人興奮的，因為最終用戶的可能性是無限的。 對於將自己的帝國建立在一種做事方式上的主題作者來說，這是令人恐懼的，但發展更多的是適應而不是其他任何事情。

有了對景觀正在變化的預知，這是主題作者需要聯合起來在基於區塊的世界中塑造他們的未來的時刻。

在我參與的一個開發人員小組中，有一個笑話說核心開發人員不是主題作者。 從主題作者的角度來看，有時似乎想法是隨意組合在一起的，沒有考慮 CSS 設計系統。

哦，我看到了一些 BEM。 為什麼這個子元素不遵循相同的命名方案？ 等待。 那是一個 38 個字符的實用程序類嗎？

WordPress一直缺乏的是一個通用的前端設計系統。 有時，這是一件好事。 它允許主題作者使用他們喜歡的框架。 任何參與遊戲時間足夠長的主題作者都會告訴你，那種靈活性很棒......直到它不是。 您是否嘗試過向小部件添加上下文類？ 向評論表單包裝器添加一個實用程序類怎麼樣？ 你需要一片阿司匹林。 或者兩個。

使用 WordPress，有些東西是一成不變的，而另一些則是可插拔的。 一些特性遵循標準的類命名方案，而另一些則沒有意義。 主題的結果通常是臃腫的 CSS，試圖與各種組件爭吵。

如果不重新創建核心功能，幾乎不可能在主題中完全使用像 Tailwind CSS 這樣的實用程序類框架。

這在很大程度上源於多年的遺留代碼堆積和 WordPress 對向後兼容性的承諾。 但是，未來不必與過去相似。 我們正處於一個新時代的門檻，現在是前端設計師參與對話的時候了。

WordPress 需要一個可靠的前端設計框架。

那是一個加載的語句。 如果你把 20 位設計師放在一個房間裡，讓他們討論設計框架，這可能是打架的秘訣。 我傾向於是一個樂觀主義者，並希望辯論能取得成果。

古騰堡已將我們部分推向這個方向，但還遠遠不夠。 隨著未來的全站點編輯，需要一種更全面的方法來解決這個問題。

最重要的是，我們需要更多的前端設計師參與對話。 沒有辦法.has-subtle-pale-green-background-color應該作為實用程序類存在於.bg-pale-green 、 .bg-green-100甚至.background-pale-green類的東西上，如果你想要更詳細。 該決定中沒有優化的概念。 在開發人員在千兆互聯網連接上運行的時代，很容易忘記世界大部分地區都在以較慢的速度跟進。

具有健康劑量的實用程序類的基於組件的命名方案是一種可以達到幾個最佳位置的選項。 這不是一個 CSS 框架優於另一個的論據。 有許多好的現有選擇。 WordPress 應該通過借鑒其他項目奠定的基礎並創建獨特的 WordPress 來解決這個問題。 它應該是該領域的領導者。

設計框架也與插件有關。 自主題系統出現以來，兩人一直在進行一場持續的戰爭，主題領域有一些交叉。 主題和插件之間的戰場上到處都是好主意的死亡。 太多的人從未獲得進入核心區所需的支持。 某種通用設計標準可以阻止大量問題並呼籲停火。

例如，輸出自定義前端組件的插件無法知道當前主題如何處理垂直節奏。 它使用上邊距還是下邊距？ 使用的值和單位是什麼？ 這是基本的東西，當插件嘗試添加自定義 CSS 來處理它時，它幾乎總是被破壞。

WordPress 需要一個設計框架或語言，它允許其所有移動部分在前端和諧地結合在一起。 我相信我們會在某個時候到達那裡。 我希望它比過去的隨機組件和命名方案更具凝聚力。 我們還應該有一個明確的路線圖來填寫一些技術細節，以便開發人員和設計人員做好準備。

單一主題的未來可能嗎？

Rich Tabor 在他的文章 A Look at WordPress Themes of the Future 中提出核心 WordPress 可以提供單一父主題的論點。 這個想法是主題作者將被降級為為這個“主”主題創建一個子主題。

許多人的直覺反應是它不起作用，主題會失去個性，我們將生活在一個千篇一律的設計世界中。

現實情況是，我們正朝著一個單親或主主題的想法成為一個認真考慮的未來發展。

大多數主題是幾乎所有主題中都存在的標準元素的自定義分組。 除了風格問題之外，還有一些決定會使主題彼此不同，例如標題的佈局。 一個主題可能在一個塊中有一個站點標題和導航菜單。 另一個可能有一個導航菜單、標題和下面的第二個導航菜單。 然而，另一個主題可能會顯示一個搜索框。 在全站點定制屬於用戶的世界中，這些決定成為用戶體驗的一部分，而不是開發人員體驗的一部分。

主題需要通過調色板、排版和他們自己的古怪品牌脫穎而出——這是 CSS Zen Garden 時代的回歸，但規模要大得多。

我不會為此難過。 看到該領域頂級設計師之間的競爭會很有趣。 它還可能將 WordPress 主題帶回到一個任何人都可以通過一點 CSS 知識和決心來做的時代。

雖然我們還沒有為一個主題統治所有主題的未來做好準備，但它是一個開始對話的地方。 如果我們為這個潛在的未來設計 WordPress，即使我們從未實現過主主題，路線圖會是什麼樣子？ 有什麼阻礙？ 可行嗎？