Gutenberg專案負責人Matías Ventura早些時候在Make Core部落格上宣佈了通往5.9版本的初步道路。涵蓋了幾個大圖片專案，每個專案包括幾個子點。他還連結到一個GitHub問題，其中包含需要工作的特定任務和工單。
該帖子包括了關於區塊模式、導航選單、theme.json介面（全域性樣式）、設計工具和塊主題的編輯流程的註釋。有很多資訊可以獲取，並且有足夠的領域來涵蓋各種興趣。
WordPress 5.9最令人興奮的焦點可能只是在區塊級別更深入地研究響應式設計，無論是底層程式碼還是通過UI可用的區塊選項。
“對於模式和主題構建者來說，最大的問題點之一是缺乏區塊級可用的響應工具，”文圖拉寫道。“這需要以一種不會不成比例地增加介面複雜性的方式來解決。”
使用區塊的內在網頁設計
Ventura分享的移動設計模式。
人們很容易對過去幾年響應式區塊選項的緩慢進展感到不滿。我並不完全不滿意，因為我希望團隊有條不紊，並以面向未來的方式來解決這個問題，至少在它可以做到的範圍內。
很多時候，我們在請求甚至第三方外掛中看到的是使用基於視口的媒體查詢來控制塊如何響應不同的裝置（例如，桌上型電腦、平板電腦和移動裝置）。雖然此類控制元件有時可能是完成工作的正確工具，但它們並不總是基於元件的設計的正確途徑。
媒體查詢傾向於支援整體設計方法。然而，基於元件的設計是網路的現代面孔。區塊只是另一個元件，因為開發人員甚至使用者可以將它們放置在整體設計中的任何位置，我們必須比瀏覽器視口更多地處理它們如何響應周圍環境。
“區塊模型是應用一些內在設計原則的一個很好的例子，因為區塊可以在許多不同的佈局和容器中佔據一席之地，對於這些，不考慮上下文的規定媒體查詢是不靈活的，”Ventura寫道。
一個簡單的例子是核心WordPress欄目區塊。我們可以輕鬆地為每個內部欄目區塊中斷時新增媒體查詢選項。但是，排版應該如何響應三列與四列以及不同寬度的情況？這是容器大小而不是視口的函式。
而且，當列巢狀在另一個列中時，此類媒體查詢如何工作？如果您將佈局控制元件交到使用者手中，這將成為一個需要解決的更復雜的問題。在響應式塊選項上按下快進按鈕目前可能感覺很好，但它也可能會產生遺留的包袱，當更好的解決方案出現時，這些包袱將難以丟棄。
在設計使用者輸入時，即使是像基本網站標題這樣看似簡單的東西也可能變得複雜。例如，對於主題設計者來說，無法知道站點標題中有多少字元，或者導航選單中有多少項。通過允許終端使用者加入其他未知數，區塊系統可以使情況進一步複雜化。
“每個區塊區域都應該具有內在的響應能力，允許區塊組合在一起、包裹、堆疊和組織自己以適應不同的空間和螢幕，”文圖拉寫道。“為了讓這個工作良好，容器區塊需要吸收更多的佈局控制元件。”
他還提到，當未來瀏覽器完全支援容器查詢時，容器查詢是一個可能的擴充套件點。Chrome Canary目前有一個支援標誌來啟用該功能。
容器查詢對設計師來說有點像聖盃。正如網頁設計師 Ethan Marcotte四年前所寫：
也許我會從這裡開始：在過去的幾年裡，我的設計工作更多地關注模式，而不是“頁面”。與其將響應式設計視為一個整體的、統一的事物，其中佈局的每個部分都以相同的速度變化和適應，不如將響應式佈局分解為更小的、可重用的設計部分，包括諸如“刊頭、 ”、“頁尾”、“影象標題”等。
換句話說，我的設計過程涉及將響應式設計視為小型佈局系統的網路。這些元件中的每一個本身都是小型響應式設計，具有自己的斷點集。
聽起來有點熟？是的，WordPress區塊系統建立在相同的小型佈局元件基礎上。
WordPress今天在UI級別所做的任何事情都需要考慮到未來的容器查詢。或者，至少利用現有的工具，可以複製的功能在某些方面，比如min()，max()和clamp()CSS功能。
麻煩的是弄清楚哪些功能應該作為區塊選項公開，而不是在後臺處理。開發團隊必須在使用者體驗和設計師的靈活性之間取得平衡。有些東西應該“開箱即用”，而其他東西應該根據具體情況進行配置。
這應該是WordPress 5.9週期中需要解決的更有趣、複雜、令人沮喪和有益的問題之一。對於那些尋求挑戰的人來說，這可能是一個完美的切入點。
評論留言