與安迪·貝爾一起粉碎播客第 19 集：什麼是 CUBE CSS？

今天，我們談論的是 CUBE CSS。 它是什麼，它與 BEM、SMACSS 和 OOCSS 等方法有何不同？ 我與它的創造者安迪貝爾交談，以找出答案。

顯示註釋

• 多維數據集 CSS
• 皮卡利利
• 從零開始學習 11 - 節省 40%！
• 安迪·貝爾和皮卡利利在推特上

注意： Smashing Podcast 的聽眾可以使用代碼SMASHINGPOD在 Andy 的 Learn Eleventy From Scratch 課程中節省高達 40% 的費用。

每週更新

• “維特魯威能教給我們什麼關於網頁設計的知識”
  弗雷德里克·奧布萊恩
• “SWR 簡介：用於遠程數據獲取的 React Hooks”
  易卜拉希瑪·恩道
• “網頁設計師如何幫助餐廳進入數字體驗”
  蘇珊娜·斯卡卡
• “使用 Jest 測試 React 應用程序的實用指南”
  通過 Adeneye 大衛 Abiodun
• “Django 亮點：處理靜態資產和媒體文件（第 4 部分）”
  菲利普·凱利

成績單

Drew McLellan：他是英國的教育家和自由網頁設計師，在設計師網頁行業工作了十多年。 在此期間，他曾與世界上一些最大的組織合作，如 Harley-Davidson、BSkyB、聯合利華、甲骨文和 NHS。 與 Heydon Pickering 一起，他是 Every Layout 的合著者，並經營著 Front-End Challenges Club，該俱樂部專注於通過簡短有趣的挑戰教授前端開發最佳實踐。

Drew：他的最新項目是 Piccalilli，這是一個包含教程和課程的網站時事通訊，可幫助您升級為前端開發人員和設計師。 所以我們知道他是一位經驗豐富的開發人員和教育家，但你知道他是第一個獲准在 Crufts 與熊貓比賽的人嗎？

德魯：我的 Smashing 朋友們，請歡迎，安迪·貝爾。 嗨，安迪，你好嗎？

安迪·貝爾：我太棒了，謝謝。 你好嗎？

德魯：我很好，非常感謝。 今天我想和你談談你在你的網站 Piccalilli 上發布的一些內容，關於你近年來為自己開發的一種 CSS 方法。 首先，我想我們應該探索一下 CSS 方法的含義，因為這對不同的人可能意味著不同的東西。 所以當你想到 CSS 方法論時，它對你來說是什麼？

安迪：德魯，這是一個很好但很難開始的問題。 欣賞，謝謝！

德魯：歡迎！

安迪：這是一個棘手的問題。 所以，就上下文而言，我已經使用 BEM 很長時間了，那就是塊元素修改器。 這已經存在了很長時間。 我對 CSS 方法論的看法是，它不是一個框架，而是一個組織結構。 這就是我喜歡看的方式。 這幾乎就像一個過程。 就像你遇到了一個需要用 CSS 解決的問題，然後你使用這種方法來為你解決它，並使事情保持可預測和有條理。 BEM 之所以具有傳奇色彩，是因為它非常成功。

Andy：那麼你幾乎可以限定樣式組件之類的東西。 你幾乎可以說它們是以方法論為導向的，儘管它們與框架更緊密相關，但它仍然是一種將事物分解成微小分子的方法論。 所以本質上這也是我試圖用 CUBE CSS 做的事情。 一種思維結構，我想我將其描述為。

Drew：所以它是一個關於你如何架構和編寫 CSS 的過程的應用程序，它不是基於工具或任何其他類型的技術的任何東西，它只是一種工作流程。 所以有很多不同的方法。 你提到了 BEM。 有 SMACSS、OOCSS、原子 CSS。 然後你就有了像 ABEM 這樣不尋常的愛子方法。 你見過那個嗎？

安迪：是的。

德魯：為什麼要發表你自己的？

安迪：是的，是的。 為什麼要自己做？ 這是一個非常好的問題。 我想熟悉我的人都知道，我很喜歡逆水行舟。 這主要是因為我也傾向於在不同的團隊中做很多不同的項目。 因此，我發現，與傳統開發人員一起使用 BEM 非常困難，因為他們習慣於將 CSS 用於 CSS 的全部內容：級聯等，這就是為什麼我從語言中偷走了它.

Andy：另一方面，結構化方法較少，與程序員、JS 之類的人一起工作更難，因為他們喜歡結構、組織和小組件，使用他們所使用的語言工作是可以理解的。

安迪：所以我發現自己在這些職位上與不同類型的人一起工作，在不同類型的項目中，一種方法並不完全奏效。 多年來，我一直在玩弄這個關於事情如何發展的想法，然後是我和 Heydon 所做的事情，每個佈局，它強制執行其中的大部分，即 C，作曲部分，然後在過去的六個月裡，我對它進行了非常迅速的改進。

安迪：我寫一篇關於它的文章的唯一原因是因為我只是在做這門課程，我想我最好寫一些補充材料來配合它，以便人們理解它，它絕對被炸毀了。 所以也許我們還沒有結束方法論，德魯。

Drew：所以你一直在整理的課程材料實際上使用 CUBE CSS 作為它的方法，是嗎？

安迪：是的。 因此，有 50% 的課程實際上是前端課程，即使它是無限制的課程。 我們構建前端的方式是如此、如此緊密地交織在一起，以至於我不能只是說，“哦，順便說一句，這就是我寫一個漂亮的 CSS 的方式”，然後就離開了。 我知道人們喜歡深入細節，所以我想，我要做的是，我會寫這篇非常長且非常詳細的帖子，然後如果有人想提高技能並真正了解我們在做什麼，然後他們可以做，剩下的就從那裡開始。 今天我們在這裡，德魯，坐著聊天。

Drew：如果有人已經了解 BEM 並且可能已經在使用 BEM，例如，因為這可能是最廣泛採用的方法之一，不是嗎？ 因此，如果他們已經了解 BEM 並且他們即將加入 CUBE，那麼他們會覺得這很容易採用嗎？ 有很多相似之處還是完全不同？

安迪：是的。 我想說從 BEM 到 CUBE 可能是一個平穩的過渡，尤其是我仍然喜歡為 CUBE 編寫 CSS 的方式。 所以大部分事情都發生在更高的層次上。 所以它發生在級聯級別，它發生在全局 CSS 上，使用實用程序來做很多事情。 但是當你深入了解它的細節時，它是非常類似於 BEM 的組件、塊和元素。 唯一與 BEM 不同的是，我們沒有使用修飾符，而是使用稱為異常的東西，而不是使用 CSS 類，它轉向數據屬性，我認為這提供了很好的分離和真實異常，這就是修飾符應該是什麼。

安迪：我離開 BEM 的部分原因是因為我發現我使用它的方式，尤其是在設計系統中，修改器被主導，它成為一個問題，因為它就像，什麼是在這一點上我的塊的作用？ 因為如果我將它修改到無法定期識別的地步，那麼這種方法是否仍然可以正常工作？

Andy：然後是整個設計令牌的東西，Jina 用我們現在都開始採用的閃電設計系統所做的東西。 實用程序類的東西真正開始對這種方法有意義。 所以我只是把我喜歡別人工作的所有東西都抹掉了，轉而投入到我自己的工作中。

Drew：你談到了 BEM，這種修飾方法有點失控。 這是 CUBE 試圖解決的 BEM 的主要痛點之一嗎？

安迪：是的，絕對的。 我確實喜歡 BEM 的修飾方法，它確實有意義。 我喜歡 BEM 的地方是我仍然在做的事情，它是一個元素的雙下劃線，然後是修飾符的雙破折號。 我喜歡這種組織事物的方式。 這只是一個好的情況，好吧，我實際上可以用實用程序類來解釋很多修飾符，然後是其他位......

安迪：所以我在文章中使用的例子是，假設你有一張卡片，然後卡片被翻轉，所以內容出現在圖像之前。 所以這是有道理的，看到 display: flex 然後你反轉它，反轉順序。 這是有道理的，有一個例外規則，因為它是卡默認狀態的例外，這就是我喜歡看到的方式。 這就像該組件上的受影響狀態，是異常，這是有道理的。

Andy：我最近做的很多東西，帶有響應式 JavaScript 的現代前端堆棧，有很多狀態變化，在 CSS 和 JavaScript 之間適當地處理它是有意義的，因為它們變得越來越不管你喜不喜歡，彼此更纏綿。 這是他們的共同語言。 正如你從我的臉上看到的那樣，幾乎沒有，但你去吧。 你可能在想，“實際上，我最近一直在使用 react 很多，所以我正好相反。” 所以我也可以看到。

Drew：那麼讓我們進入 CUBE。 所以 CUBE 代表 Composition Utility Block Exception。 那正確嗎？

安迪：是的。 就是那個。

德魯：這到底是什麼意思？

安迪：哦，伙計，你應該以前聽過！ 去年我在做一個演講。 我做了一個演講，它被稱為使用可擴展的 CSS 保持簡單，在那裡我介紹了它的早期版本，稱為 CBEUT，它是 Cascade Block Element Utility Token。 那是垃圾。 我討厭它的名字。 我做了幾次，去年的這個演講，我真的不喜歡這個名字。 然後當我今年開始做這些事情時，我想，“我真的需要考慮一下它實際上是什麼以及它叫什麼。” 我認為 CUBE 不那麼垃圾。 我認為這是我能描述它的最好方式。

安迪：但是，這些東西的名字總是很垃圾，不是嗎？ 我的意思是，像 BEM 一樣，這是一個多麼垃圾的名字！ 但我們都這樣做。 看看 Jamstack：這也是一個可怕的名字，不是嗎？

德魯：我的嘴唇被封住了！

安迪：你的老闆會問，“什麼？” 這是真的。 在我們的行業中，它就是這樣，不是嗎。

Drew：似乎很多 CSS 方法都在嘗試解決 CSS 的一些特性，比如級聯。 我的理解是，CUBE 試圖利用 CSS 的這些特性和屬性。

安迪：是的。 一個很好的類比是 SCSS，就像 Sass 一樣，是自然 CSS 語言的擴展，不是嗎？ 你在 CSS 中還是很正確的。 所以CUBE CSS就是這樣。 所以它是CSS的擴展。 所以我們還是應該寫 CSS，就像 CSS 應該的那樣……好吧，它應該是寫出來的。 老實說，它應該是如何編寫的，就是名稱給出了它：級聯樣式表。 所以它再次接受了這一點，因為我發現我已經一路下降到微優化級別。 我一直在走這條路，我看到很多人最近在哪裡……我在文章中也提到了這一點，我可以看到……最近有一些證據。 我發現人們一直在創建間隔組件和類似的東西，我理解這個問題，我一直處於那種情況。

Andy：我修復它的方式是，我沒有深入研究並嘗試進行微優化，而是開始在組合層面上思考問題，因為無論你的組件有多小，在某些時候它們都會運行成為頁面，它們將成為視圖。 你無法避免，事情就是這樣。 因此，不要試圖說，“對，我需要這些小幫手來做這個佈局，”你說，“對，我有一個聯繫人頁面視圖，或者一個產品頁面視圖，這是一個骨架佈局組合。 然後我可以在其中插入任何我想要的組件。” 我們現在有了像 Grid 和 Flexbox 這樣的東西，它們讓這更容易實現，你基本上可以把你想要的任何東西放在骨架佈局中，沒關係。 然後，組件應該按照您希望它們的行為方式運行，無論是否使用容器查詢。

Drew：這是 CUBE 的組成部分，您在其中更多地從宏觀層面看待事物，著眼於如何將組件組合成視圖以創建您需要為網站或應用程序創建的頁麵類型或者你有什麼。

安迪：所以它本質上是在創造規則。 這就像指導。 它試圖為某事獲得指導。 這不像是一個嚴格的規則，比如，你應該這樣做，你應該這樣做。 這本質上就是您對瀏覽器所做的事情，使用這種方法，您是在說……您並沒有強迫它做任何事情。 你說，“看，理想情況下，如果你能像這樣佈置它，那就太好了，但我知道情況可能並非如此，所以這裡有一些界限和一些我們可以使用的上下水平。 盡你所能，加油。” 然後你只需將一些組件放在它上面，讓它做它做的事情。 你在那裡添加足夠的控制讓它看起來不垃圾。

安迪：所以一個很好的例子會看到......我們在每個佈局中做了一個佈局，稱為切換器，它基本上將內聯項目直到某個點，計算出它應該多寬的計算只會將它們堆疊在一起. 但是因為我們為 in-line 和塊添加了邊距，所以它可以工作，不管它的狀態是什麼，它看起來仍然很好。 這就是我們的想法，我們不會告訴瀏覽器說：“您必須將這三列網格分層。” 我們說，“如果你可以將三列網格分層，那就去做吧。 否則，只需堆疊和空間即可。” 所以這是一種讓瀏覽器真正完成其工作的方法。

Drew：過去幾年中出現的許多 CSS 不同的方法都非常關注組件級別的處理，就像處理組件一樣。 CUBE 並沒有過多地淡化組件方面，它只是在獲取這些組件並將它們組合成更大的佈局的頂部給出了這個額外的概念，而不僅僅是說佈局只是另一個組件。

安迪：是的，這是一個很好的觀點，是的。 我認為關於組件要說的是它們很重要，尤其是在現代前端的東西中。 我們做了很多組件的東西，系統的東西。 但我看到組件的方式是，它是擴展已經完成的規則的集合。

Andy：我在文章中的觀點是，當你深入到塊級時，你的大部分樣式實際上已經完成，你的組件正在做的實際上是在 Is 上打點並穿過 T，它是說， “對，在這種情況下……”例如，對於一張卡片，讓圖像的最小高度為 X，並在此處添加一些填充。 做這個，那個和另一個。 在這裡放一個按鈕。 它只是在已經從 CSS 的其餘部分繼承的內容之上的附加規則。 我認為這可能是最好的描述方式。

Andy：而在 BEM 中，組件是事實的來源。 在您將該類放在元素上之前，此時沒有應用任何內容，並且該方法有效。 我剛剛發現我通過這樣做寫了更多的 CSS，以及更多重複的 CSS，我不喜歡這樣做。

德魯：你會考慮排版、顏色、垂直節奏、間距等等，這些都是這個模型中構圖的一部分嗎？

安迪：是的。 在全球 CSS 中，是的，絕對是。 尤其是垂直節奏和流動。 我們在 24 種方式上寫了一篇文章，不是嗎，幾年前，我們是流動和節奏部分。 這也是這種方法的一種抽象，您可以在其中設置一個基本組件，該組件基本上使用了 lobotomized owl 選擇器。 我不知道我將如何在廣播中描述這一點，但我們會的。 我認為，我們將在有關 Heydon 文章或其他內容的節目說明中加入。 但本質上，它選擇子元素……對不起，兄弟元素。

Andy：所以它說，“是的，元素 X 之後的每個元素都有 CSS 成本和屬性值的最高邊距”，然後你可以在組合上下文中設置 CSS 自定義屬性值。 所以你可以說，“對，在這個組件中，如果有流動的流動，我們會將流動空間設置為實際上是兩個 rem，因為我們希望它是漂亮和強大的，寬闊的空間。” 然後在另一個例子中，你可能會說，“實際上，我希望流動空間是半個 rem，因為我希望它是緊湊的。” 這一切都在發生，所有的控制都來自更高的層次，然後你正在做的是，你正在添加上下文覆蓋而不是每次都重新發明它，一遍又一遍地重新發明相同的東西。

Drew：那就是 C，作曲。 接下來我們有U，即Utility。 那麼我們所說的效用是什麼意思呢？

安迪：所以這是一個只做一項工作的課程，而且做得非常好。 這可能是設計令牌的實現……它是屬性的抽象。 通常是顏色或排版樣式、大小和類似的規則。 這個想法是您生成應用這些的實用程序類。 所以你有一個實用程序，它將應用背景原色，就像原色一樣，然後是原色，這是文本顏色。 然後，您可能會為邊緣填充以及所有這些事情生成一些間距標記。 他們只做一項工作。 他們只是添加一個間距規則，一個顏色規則，僅此而已。

安迪：但是你也有其他的實用程序。 所以一個很好的例子是包裝實用程序。 這將做的是，它將在元素上設置最大寬度，然後將左右自動邊距放置在事物的中間。 所以它只是有一份工作，而且它只是高效而出色地完成它。

安迪：所以你已經有了你的全球風格，你已經完成了很多排版設置和很多地板空間。 然後你的作文給出上下文和佈局。 然後，實用程序將標記直接應用於元素，為它們提供您需要的樣式。 例如，就像一個標題，你說，“我希望它有這個大小，我希望它有這個引導，我希望它有這個度量。” 然後到那時……這就是我所說的關於積木的內容……然後你再往下走，你已經完成了大部分工作。

Andy：所以他們為您提供了這種非常有效的工作方式，而且因為 HTML 也可以通過管道流下來，所以將工作負載抽像到 HTML 而不是 CSS 上真的很好，我發現。 我曾經真正進入實用程序類，就像這種舊的脾氣暴躁的風格，“哦，關注點分離”，但我實際上認為這是一種非常體面的工作方式。 我在文章中提到我實際上喜歡 Tailwind CSS。 我認為它確實有效，而且我真的很喜歡用它來進行產品打字，因為我真的可以很快地把東西寫出來。 但我認為它有點太過分了，Tailwind 是這樣，而我喜歡在它超越了僅僅在一個類上應用一個規則時下雨它。 就是這樣，我想。 你？

德魯：所以，是的，你在文章中談到了很多關於設計令牌的內容，這是我們在第三集中與 Jina Anne 在 Smashing Podcast 上討論過的內容，我想是的。 所以聽起來設計令牌是一個非常基本的方面。

安迪：是的。 哦，天哪，是的。 我清楚地記得當 Jina 做閃電設計系統的事情時，因為當時我正在構建一個設計系統，或者類似於設計系統的東西，我們正在努力獲得行政部門的批准。 當閃電設計系統問世時，我真的只是一個接一個地向他們發送鏈接，我說，“這就是我們正在做的。 我們正在建立一個設計系統。 這就是 Salesforce 目前使用它的目的。” 我記得她當時的工作實際上幫助我把東西穿過門。

Andy：那麼設計令牌的東西一直是我應用這些規則的好方法。 因為我是一名設計師，所以我可以看到這種組織以及組織和創建單一事實來源的能力非常有用，因為這是我們在數字設計中真正沒有的東西，尤其是在 Adob​​e在使用 Photoshop 之類的東西的時代，我們沒有那麼奢侈。 我們用 Pantone Book 打印了它，但我們沒有在整個商店裡用隨機十六進制代碼進行數字化。

安迪：所以這很棒。 我喜歡那種程度的控制。 實際上，我認為它有助於創造力，因為你不再考慮不重要的東西，你只是在想你在用它做什麼。

德魯：這些設計令牌的實現對方法特別重要嗎？ 它總是CSS自定義屬性嗎？

Andy：我認為這對 CUBE 來說非常重要。 我得到的一些回應，人們對此有點掙扎。 裡面完全沒有提到技術。 唯一一致的技術是 CSS。 你可以隨心所欲地做。 你可以用人們現在正在做的任何 CSS 和 JS 來做這一切，或者你可以只用 Vanilla CSS。 你可以用 Sass 做到這一點。 我用薩斯做。 少，如果那是你還在做的事情。 所有這些可用的技術，post CSS，所有這些東西。 你想怎麼做都可以，沒關係。

安迪：這個想法是，如果你遵循這些結構，你會沒事的。 這就是它背後的想法。 它是一種非常鬆散的方法，並不像某些方法那樣嚴格。 我特別在 BEM 中看到過，人們對 BEM 的原則根深蒂固，以至於你甚至不再解決問題。 我認為你必須靈活。 我在去年的這個演講中說過。 我當時想，“如果你過於執著於你的槍，從長遠來看，你實際上會給自己帶來問題，因為你試圖遵循一條特定的道路，但你知道它不再起作用了。” 您應該始終保持靈活性並使用系統，而不是按部就班地工作。

德魯：所以B，B就是Block。 你已經談到了這個想法，當你深入到塊級時，大部分東西都應該到位，然後塊級樣式只真正關心特定組件的實際細節。 一般來說，塊的概念是否與人們熟悉的類似？

安迪：哦，當然，是的。 所以想像一下你的 BEM 組件並從中取出所有的視覺內容，這就是你剩下的，基本上，塊。 當我第一次開始考慮這種方法時，這就是我努力表達的內容。 一個塊實際上是一個 C，它是一個組合，但這讓它變得非常困難，因為你在那裡進入了遞歸領域，我認為人們的大腦會爆炸。 但實際上這就是一個塊，它實際上是另一個組合層，但更多的是一種嚴格的上下文，所以就像你的卡片、你的按鈕、你的輪播，如果你仍然喜歡這樣做的話，以及所有這些東西。

安迪：它就像一個特定的東西，一個組件，然後在裡面你為它設置特定的規則，真的忽略了其餘的，所以你不會……你可以在塊中應用令牌，我會這樣做仍然，但實際上它更面向佈局，是一個塊，就我與他們一起工作而言，或者至少獲取令牌並以特定方式應用它，例如按鈕懸停狀態，諸如此類。 因此，當您真正了解它們時，您的塊應該很小，它們根本不應該做太多事情。

Drew：所以它可以像超鏈接一樣小。

安迪：是的。

德魯：但它也可能是其他塊的複合集合？

安迪：是的。 就像一個模塊之類的東西。 你絕對可以這樣做。 因為，再一次，這又回到了它的構圖方面，就是無論進入什麼都不重要。 一個很好的例子就是卡片。 因此，卡片的內容例如是標題、摘要和按鈕。 你不應該真的專門針對這三個元素。 你應該說，“看，任何碰巧在內容中找到自己的東西，裡面都有一些流程規則，並且有一些組合佈局規則，”然後你在裡面放了什麼並不重要。 您可能會決定要將圖像放入該內容中，並且它應該可以正常工作，看起來應該很好。

Andy：這就是使用 CSS 的全部意義所在。 這是使用 CSS 的一種非常寬容的方式。 通過減少僵化，您的生活變得更加輕鬆，因為當某些東西意外地發現自己在某物中時，它會看起來並不可怕，因為如果您對事物更加具體，這就是我所擁有的成立。

Drew：我的 CSS 絕對需要很多寬恕！

安迪：我知道你知道！

德魯：乾杯！ 所以這就是B。最後一件事是E：E是例外。 現在我們不是在談論錯誤消息，是嗎？

安迪：不，不。 這是一種——

Drew：我們不是在談論 JavaScript 異常。

安迪：是的，是的。 在這一點上不應該有這些。 無論如何，我不希望如此，否則你真的在樹林裡：我認為我無法幫助你！ 整個想法是......所以你已經用你的塊創建了上下文，而一個例外就是這樣，它就像規則的一個例外：所以一張翻轉的卡片，或者它可能是一個幽靈按鈕。 所以你知道那些剛剛有邊框和透明背景的按鈕嗎？ 那將是一個例外，因為按鈕可能具有純色背景顏色，然後是標籤顏色。 所以它創造了一種獨特的變化狀態。

Andy：我之所以用數據屬性而不是類來做這件事，是因為 a) 我認為有一個區別很好。 因此，當您掃描大量 HTML 時，您可以看到數據，用連字符連接一些東西，您會說：“好吧，這個元素肯定發生了一些變化。” 另一件事是讓 JavaScript 訪問該狀態非常好，反之亦然。 所以我真的很喜歡在 JavaScript 中應用帶有數據屬性的狀態。 我認為這本質上就是它們的用途，一種通信層。 他們之間的和諧似乎真的很好。

Andy：一個很好的例子是，假設你有一個狀態消息，然後 JavaScript 會添加數據狀態，要么是成功，要么是錯誤，要么是信息，或者其他什麼。 然後，您可以使用 CSS 中的異常樣式來掛鉤。 所以你知道這是狀態組件的一個例外，它違背了它的默認狀態。 所以這只是一種非常方便的處理事物的方式。 它在兩端都是可預測的：它在 CSS 端是可預測的，在 JavaScript 端也是可預測的。

Drew：我想，類名沒有給你的東西是屬性和值，這很好。 因此，如果您想擁有類似狀態的東西，它可以是成功或失敗或警告或您擁有的東西，您可以專門處理該狀態屬性並翻轉它的值。 而對於一大長類名稱列表，例如，如果您在 JavaScript 中對其進行操作，您將不得不查看它們中的每一個並在其中添加業務邏輯，上面寫著：“我只能設置其中之一，”如果將其中兩個類應用於同一個元素會發生什麼？ 您無法使用數據屬性獲得它，它只有一個值。

安迪：是的。 這是一個很好的說法，是的。 我發現，這樣工作非常有幫助。

德魯：這很有趣。 我認為我沒有看到任何其他採用這種方法的方法。 這對 CUBE 來說是完全獨一無二的嗎？

安迪：可能是這樣。 我真的不太注意其他事情，我應該做的。 其他人可能正在這樣做。 我現在告訴你，這是其中最具爭議的方面。 有些人真的不喜歡使用數據屬性的想法。 事情也是如此，我的回應是，做你想做的事。 我們不是告訴你以某種方式做事，這只是建議。 如果你想對 CSS 類做例外，比如修飾符，那就把自己搞砸了。 CUBE 警察不會來敲你的門。 絕對沒問題。

Andy： CUBE 是一種思考的東西，它是一種結構。 您可以應用該結構，但您想應用它，使用您想要的工具或任何您想要的技術。 只要你保持一致，這就是重要的事情。

Drew：所以沒有純粹的 CUBE 這種東西？

安迪：我寫它的方式是純粹的立方體，德魯。 其他人都是假的，只是弱模仿。

Drew：除了你，沒有人可以說，“那不是教科書 CUBE。”

安迪：不，就是這樣。 沒有人可以質疑這一點，真的嗎？ 所以，是的，我會同意的。 給你一點影響力之類的東西，我想，類似的東西。

Drew：您能否將 CUBE 方法與其他方法混合併匹配？ 你能用一點 BEM 嗎？

安迪：是的，我想是的。 我一直在考慮它，因為我很快就會在它上面做更多的事情，因為它變得非常流行，所以人們會想要更多的工作。 我要研究的一件事是如何在現有的東西上使用 CUBE 方法。

安迪：所以天平有兩個相反的末端。 人們提出的一個很好的問題是：“這如何與每個佈局和其他東西一起工作？” 我喜歡，基本上，每個佈局都是 C。這就是每個佈局，它是組合層。 然後有人問，“嗯，這將如何與像 Brad Frost 所做的那樣的 Atomic Web Design 這樣的東西一起工作？ 這就像，好吧，你可以將這些部分分解並在每個級別應用它們。 原子設計一直深入到微觀細節。 它將它抽象為使用，對，好吧，我可以將它與實用程序一起應用，所以我認為是分子。 我可以將它與實用程序一起應用，它會將您已經知道的內容轉化為這種略有不同的工作結構。

安迪：真的，這是對很多東西的重命名。 我在這裡沒有發明任何東西，我只是有點，就像我說的，我只是偷了我喜歡的東西。 我喜歡一些原子設計東西的思考方式。 這真是一些聰明的工作。 和 BEM。 Harry 做的東西，倒三角形 CSS，我覺得真的很酷。 所以我只是從他們每個人中挑選出我喜歡的部分，然後將它們全部縫合到另一個混合的東西中，方法。 我想還會有更多。

Drew： CUBE 方法可以應用於已經有 CSS 的現有項目，還是你真的需要從一個新項目開始？

安迪：這在很大程度上取決於。 所以，如果你有一份像引導工作一樣的工作，而且它只有數千行自定義 CSS，而我之前肯定參與過，那麼我認為你可能會試圖用一瓶水來滅火觀點。 但是如果你……比如說，如果你有一個粗略的 BEM 設置並且它有點分層，你可以使用 CUBE 來重構並真正將它重新拉回原形。

Andy: It depends, the answer to that one. But it's doable, as with everything. If you really want it to work, Drew, you can do it if you want, can't you? The world is our oyster!

Drew: Especially if your BEM site's gone layer-y.

Andy: Yeah. Nothing worse than a layer-y BEM site!

Drew: I've noticed in the examples that you've given… and I've got an eagle eye, I've seen you've been doing this for a while… a lot of your class values in the HTML attribute are wrapped in square brackets.

Andy: Oh, God, yeah. Tell you what, Drew-

Drew: What is that about? 那是關於什麼的？

Andy: I'll tell you what, if there's ever one thing that I've done in my whole career that's just been absolutely outrageously controversial… and you follow me on Twitter, you've seen what comes out of my mouth… it's those bloody brackets! My, God! People either love them or hate them. They're Marmite, they are.

Andy: The reason I do them is a grouping mechanism. So if you look at the way that they're structured, the way I do it is, block at the start and then I'll do a utilities after that. Then what I might do is, in between a block group and a utility group, there might be another block class. So a good example of that would be… we'll go back to the card again. But then say that there's a specific block called a CTA, like a call to action. You might have that applied to the card as well, and then your utilities are enforcing the design attributes, so the colors and all that business. So then you've got three groups of stuff.

Andy: When you come to it, if you've got that order in your head each time, you know, okay, right, this first group's blocks. Oh, that's looks like another block. I've got that one. Then it's like, right, they're definitely utility classes. Then what I might even do is, if there's a lot of design token implementation, have that in a separate group. So it's just very clear what each group is doing, and there's a separation inside of the classes there as well. I've found it really helpful. Some people find it incredibly offensive. It's definitely a do it if you want to do it. Definitely you don't have to do it.

Andy: It's quite funny, when I published that article, so many people finished halfway through to ask me, “What is it with these brackets?” I was like, “Did you finish the article? Because there's a big section at the end where it explains exactly what they're doing,” to the point where I actually had to write a bit in the middle of the article of, “If the brackets are essentially doing your head in, click here and I'll skip you all the way down to that explanation bit so you can just read about them.” It can be quite controversial.

Andy: When I've worked on really, really complex front-ends… and we did a little bit of stuff together, didn't we, last year?

德魯：是的。

Andy: You've seen the sort of design implementation on that project that we were on. It requires that sort of grouping because there's just so much going on at the time, there's so much different stuff happening. I've just found it really, really useful over the years, and also get lots of questions about it, to the point where I was almost going to write just one page on my website that I could just fire people to to answer the question for them.

Drew: Slash, what's with the brackets?

Andy: Yeah. Slash, brackets. Have you seen that new Hey Email thing that's just come out? They've bought a domain of itsnotatypo.com, just to answer the whole Imbox, like im with an M rather than an in. Basically, I was like, “I think I need to do that,” like, whatswiththebrackets.com, and just do a one-pager about it.

Drew: It strikes me that the approach with brackets actually could be something that might be useful when using things like Tailwind or something that has a lot of classes because that can-

Andy: Yeah. Oh, God, yes.

Drew: You have classes that are addressing your break points and what have you, and then you'll have things that are for layout, things that are for color or type, or what have you. So it might also be a useful way of dealing in situations like that.

Andy: I'd definitely agree with that. A good analogy… not analogy. A good bit of info about Tailwind is that I actually quite like Tailwind. I've used that on very big projects. The one thing that really opened my eyes to Tailwind though was when I saw a junior developer try to work out what was going on, and it was really, really eye-opening because they just didn't have a clue what was happening.

Andy: I think that's one problem I've found with these sort of over-engineered approaches, which I think it's fair to say Tailwind is, is that there's a certain skill level that is required to work with it. I know the industry tends to have an obsession with seniority now, but there's still people that are just getting into the game that we need to accommodate, and I think having stuff that's closer to the language itself is more helpful in those situations because they're probably learning material that is the language as it is. So I think it's just a bit more helpful. Especially having a diverse team of people as well. Just food for thought for everyone.

Drew: People might look at all the different methodologies that are out there and say, “This is evidence that CSS is terrible and broken, that we need… all these problems have to be solved by hacking stuff on top. We need tools to fix bits of CSS. We need strict procedures for how we implement it, just to get it to work.” Should the platform be adapting itself? Do we need new bits of CSS to try and solve these problems or are we all right just hacking around and making up funny acronyms?

Andy: I think the power of CSS, I think, is its flexibility. So if you're going to program CSS, a lot of the knowledge is less of the syntax and more of the workings of a browser and how it works. I think that might be a suggestion, that the problem is that people might not have learnt CSS quite as thoroughly as they thought they might have learnt it, who created these problems. I've seen that in evidence myself. I spotted a spacing mechanism that had been invested, which was very complicated, and I thought, “This person has not learnt what padding is because padding would actually fix this problem for them, understanding how padding works and the box model.” That's not to be snidey about it.

Andy: We work in an industry now that moves at an even faster pace than it has done previously and I think there's a lot less time for people to learn things in detail. But, on that front, I think CSS still does have work to do in terms of the working group, who I think do a bloody good job. A great, shining example of their work was the Grid spec which was just phenomenal. The way that rolled out in pretty much every browser on day one, I thought that was so good.

Andy: But we've got more work to do, I think, and I think maybe the pace might need to increase a little, especially with stuff like container queries, we all love talking about them. Stuff like that I think would help to put CSS in a different light with people, I think. But I think CSS is brilliant, I love it. I've never had a problem with it in lots of years really. I do find some of the solutions a bit odd, but there you go.

Drew: What's the response been like to CUBE since you published the article?

Andy: Mind-blowing. I honestly published it as just supporting material, and that's all I expected it to be, and it's just blown up all over the place. A lot of people have been reading it, asking about it, been really interested about it. There's definitely more to come on it.

Andy: I did say in the article, I said, “Look, if people are actually quite interested in this, I'll expand on this post and actually make some documentation.” I've got bits of documentation dotted around all over the place, but to sort of centralize that, and then I was thinking of doing some workshops and stuff. So there's stuff to go. It's how Every Layout started as well. We both had these scattered ideas about layout and then we sort of merged them together. So something like that, I suppose, will come in the future.

Drew: Are there any downsides that you're aware of to using CUBE? Are there problems that it doesn't attempt to solve?

Andy: Yeah. This accent, Drew, it just won't go way, no matter what I do! In all seriousness, I think CUBE's got as close as I can get to being happy with the front-end, which is saying a lot, I think. You never know, things might change again. This has evolved over more recent years. Give it another five years, I'll probably be struggling with this and trying something else. I think that's the key point, is to just keep working on yourself and working on what you know and how you approach things.

Andy: This definitely won't work for everyone as well, I know that for a fact. I know that from my comments. I don't expect it to work for everyone. I don't expect anything to work for everyone. It's the same with JavaScript stuff: some people like the reactive stuff and some people don't. It is what it is. We're all people at the end of the day, we all have different tastes. It's all about communicating with your teammates at the end of the day, that's the important thing.

Drew: I know you as a very talented designer and developer and you, like many of us, you're just working on real projects all day, every day. But you've recently started publishing on this site, Piccalilli, which is where the CUBE CSS introduction article was. So Piccalilli is kind of a new venture for you, isn't it? 這到底是怎麼回事？

Andy: Very kind of you to say, Drew. You've actually worked with me, so that's high praise. But the Piccalilli thing is an evolution. So I'm a freelancer. I do client work, but I think this has become apparent with the pandemic, that that is not the most sustainable thing in the world in some industries. I think freelancing can be very, very tough, as a developer and designer. It's something that I've been doing it for so long now, 10 years… well, 12 years now actually.

安迪：我想做一些不同的事情，應用我所擁有的知識並與人們分享。 我一直非常開放和分享，我想將其正式化。 所以我創建了 Piccalilli 來編寫教程，但主要是針對我正在製作的課程：那是主要的肉和土豆。 然後是時事通訊……人們真的很喜歡時事通訊，因為我每週都會分享我在互聯網上發現的很酷的東西。 這就是它的支柱。 一切都很順利。 我想，隨著歲月的流逝，這基本上就是我希望看到自己做越來越多的全職工作的地方。

德魯：那麼皮卡利利接下來會發生什麼？ 你有什麼要出來的嗎？

安迪：謝謝你打開那裡的門，德魯！ 到此錄音發佈時，第一門課程將上線：從零開始學習 11，這就是我們學習如何構建 Gatsby 網站的地方！ 不，您將學習如何構建 Eleventy 站點。 所以你從一個完全空的目錄開始，裡面什麼都沒有，它是空的，然後在它的最後你將完成這個非常漂亮的代理網站。 我們在其中學到了各種各樣的東西。 您將學習如何與 Eleventy 一起真正進城。 我們從一些地方提取遠程數據。 我們使用 CUBE CSS 為它構建了一個非常好的前端。

Andy：如果你想進入 Jamstack 並且你想進入靜態站點生成器，或者只是想如何構建一個漂亮的網站，我希望這只是一門非常方便的課程。 正如我們所說，它目前正在其生命的一英寸內進行編輯。 我希望它會很酷，而且很有用。 但這是我在過去幾年裡一直在做的很多事情的積累。 所以應該很有趣。

安迪：那就買吧，我打個折扣碼，像smashingpod 40% off，一出來就可以買到。

德魯：太棒了。 我們將把它聯繫起來。 你知道如何可靠地拼寫 Piccalilli 了嗎？

安迪：我和克里斯和戴夫一起參加了 ShopTalk Show，我在那兒說，“如果有什麼事情你想僱用我，那就是第一次不假思索地手寫 Piccalilli，”因為我已經這個詞寫了很多遍，以至於我完全知道如何把它拼出來。 所以你的問題的答案是肯定的。

德魯：嗯，我還在掙扎，我會告訴你這麼多！

安迪：這很難。 天啊。 我完全同情。 我花了很長時間來學習如何拼寫它，但它是我們詞彙表中的單詞之一。 今年我正在嘗試拼寫必要的拼寫而不犯拼寫錯誤！

Drew：所以我一直在學習 CUBE CSS。 你最近在學習什麼，安迪？

安迪：你知道嗎？ 這會讓你大吃一驚，德魯。 MySQL是我最近一直在學習的。 所以，基本上，Piccalilli 完全是自行出版的。 這是一個 Eleventy 網站，但它背後有一個 API，它背後有一個 MySQL 數據庫。 為人們提供他們購買的內容的東西需要一些相當大的查詢。 所以我實際上只是在一些 MySQL 上進行了適當的投資……尤其是連接之間的差異，我實際上並沒有意識到每種連接類型之間存在差異。 所以這真的很有用，它導致了與數據庫的一些非常快速的交互。

Andy：我曾經運行過這個叫做 Front-End Challenges Club 的東西，當我第一次啟動它時，它就崩潰了，因為 MySQL 至少可以說是粗製濫造的。 所以我真的一直在學習如何做到這一點，因為我根本不是後端人員，我是一個像素推動者。 所以這絕對不在我的職權範圍內。 這更像是你的樹林，不是嗎？ 我覺得它真的很酷，MySQL。 其實我真的很喜歡寫。 這是一種非常好的教學語言，不是嗎？

德魯：是的，很棒。 我在學校學過 SQL。

安迪：哇！

德魯：我們現在談論的就像 20 年前一樣。

安迪：那時候他們有電腦嗎？

德魯：他們做到了，是的。 我們不得不風——

安迪：你必須手寫嗎？

德魯：我們不得不把它們收起來！ 我們做到了。 但是，我告訴你，對於開發人員來說，這類似於學習你的乘法表：其中一件事看起來有點麻煩，但一旦你流利了，它就會一次又一次地變得有用。

安迪：是的。 當然。 也確實存在明顯的差異。 你真的看到了速度上的差異。 我真的很喜歡使用 Node，因為它真的很快，但是 Node 和 MySQL 只是……不是一個很常見的選擇，但我認為這是一個不錯的選擇。 我認為它真的很好用。 所以我對此很滿意。 如您所知，我不喜歡編寫 PHP。 所以這永遠不會是一個選擇。

Drew：親愛的聽眾，如果你想從 Andy 那裡聽到更多消息，你可以在 Twitter 上關注他，他在 hankchizljaw。 您可以在 piccalil.li 上找到 Piccalilli，在那裡您還可以找到描述 CUBE CSS 的文章，當然，我們還將在演示說明中添加指向所有這些內容的鏈接。

德魯：謝謝你今天加入我們，安迪。 你有什麼臨別的話嗎？

安迪：注意安全，戴上口罩。