アンディベルとポッドキャストエピソード19を壊す：CUBE CSSとは何ですか？
公開: 2022-03-10今日はCUBECSSについてお話します。 それは何ですか、そしてそれはBEM、SMACSS、OOCSSなどのアプローチとどのように異なりますか？ その作成者であるAndyBellに話を聞いて調べました。
メモを表示
- CUBE CSS
- ピカリリ
- ゼロから11を学ぶ-40％節約！
- Twitterのアンディ・ベルとピカリリ
注： Smashing Podcastのリスナーは、コードSMASHINGPODを使用して、AndyのLearn Eleventy From Scratchコースを40％節約できます。
毎週の更新
- 「ウィトルウィウスがウェブデザインについて教えてくれること」
フレデリック・オブライエン - 「SWRの概要：リモートデータフェッチ用のReactフック」
IbrahimaNdaw著 - 「Webデザイナーがレストランのデジタル体験への移行をどのように支援できるか」
スザンヌ・スカッカ - 「Jestを使用してReactアプリケーションをテストするための実用的なガイド」
Adeneye DavidAbiodun著 - 「Djangoのハイライト：静的アセットとメディアファイルのラングリング（パート4）」
フィリップ・カイリー
トランスクリプト
Drew McLellan：彼は英国を拠点とする教育者であり、フリーランスのWebデザイナーであり、10年以上にわたってデザイナーWeb業界で働いてきました。 その間、彼はハーレーダビッドソン、BSkyB、ユニリーバ、オラクル、NHSなどの世界最大の組織のいくつかと協力してきました。 ヘイドンピカリングと並んで、彼はEvery Layoutの共著者であり、短くて楽しいチャレンジを通じてフロントエンド開発のベストプラクティスを教えることに焦点を当てたフロントエンドチャレンジクラブを運営しています。
Drew：彼の最新のベンチャーは、フロントエンドの開発者およびデザイナーとしてレベルアップするのに役立つチュートリアルとコースを備えたWebサイトニュースレターであるPiccalilliです。 彼は経験豊富な開発者であり教育者でもありますが、彼がCruftsでパンダと競争することを許可された最初の人物であることをご存知ですか？
ドリュー：私のスマッシングの友達、ようこそ、アンディ・ベル。 こんにちは、アンディ、お元気ですか？
Andy Bell：私は壊している、ありがとう。 元気ですか？
ドリュー：私はとても元気です、どうもありがとうございました。 今日は、あなたがサイトに投稿したもの、Piccalilliについて、ここ数年で自分で開発したCSS方法論についてお話ししたいと思います。 まず第一に、CSS方法論が何を意味するのかを探る必要があると思います。なぜなら、それは人によって異なることを意味する可能性があるからです。 では、CSSの方法論について考えるとき、それはあなたにとって何ですか？
Andy：そもそも、それは良い、難しい質問です、Drew。 感謝します、ありがとう！
ドリュー：ようこそ！
Andy：それはトリッキーなものです。 ですから、文脈上、私は長い間BEMを使用してきました。それが、Block ElementModifierです。 それは長い間存在しています。 私がCSS方法論を見る方法は、フレームワークではなく、組織構造です。 それが私がそれを見るのが好きな方法です。 それはほとんどプロセスのようなものです。 これは、CSSで解決する必要のある問題があり、その方法論を使用して問題を解決し、予測可能で整理された状態に保つようなものです。 BEMは大成功を収めているため、その伝説的な存在です。
Andy：そうすれば、スタイルコンポーネントやそのようなもののようなものをほぼ修飾することができます。 フレームワークが少し絡み合っていても、方法論指向であると言っても過言ではありませんが、それでも、物事を小さな分子に分解する方法論です。 つまり、基本的には、それがCUBECSSでも実行しようとしていることです。 思考構造、私はそれを次のように説明したと思います。
Drew：つまり、これは、CSSを設計および作成する方法のプロセスのアプリケーションであり、ツールやその他の種類のテクノロジーに基づくものではなく、一種のワークフローにすぎません。 ですから、そこにはさまざまなアプローチがあります。 あなたはBEMについて言及しました。 SMACSS、OOCSS、AtomicCSSがあります。 そして、あなたはABEMのようなこの種の珍しいラブチャイルドアプローチを持っています。 あれを見たことがありますか？
アンディ：うん。
ドリュー：なぜあなた自身を公開するのですか？
アンディ：うん、うん。 なぜあなた自身を作るのですか？ それはとても良い質問です。 私のことをよく知っている人は、私が潮に逆らって航海するのが好きだということをよく知っていると思います。 それは主に、私がさまざまなチームでさまざまなプロジェクトを行う傾向があるためです。 ですから、従来の開発者と一緒にBEMを使用するのは非常に難しいことがわかりました。なぜなら、CSSのすべてにCSSを使用することに慣れているからです。カスケードなどです。そのため、言語からそれを盗んだのです。 。
Andy：反対に、構造化されていない方法論では、プログラマー、JSのような人と一緒に作業するのは難しいです。なぜなら、彼らは構造と組織、そして小さなコンポーネントが好きだからです。
Andy：それで、私はさまざまなタイプの人々、1つの方法論がうまく機能していなかったさまざまなタイプのプロジェクトで働いていたこれらの立場にいることに気づきました。 何年にもわたって、私は物事がどのように進むかについてこのアイデアをいじくり回してきました、そしてそれから私とHeydonがしたこと、Every Layoutがあり、それはその大部分、つまりC、構成部分を強制しました、そして私は過去6か月間でそれを非常に急速に進化させました。
Andy：それについての記事を書いた唯一の理由は、私がこのコースをやっていたばかりで、人々がそれを理解できるように、それに合わせて補足資料を書いたほうがいいと思ったからです。 ですから、方法論はまだ終わっていないのかもしれません、ドリュー。
ドリュー：それで、あなたがまとめているコース資料は、実際にその方法論としてCUBE CSSを使用していますか？
アンディ：うん。 したがって、コースの50％は、無制限のコースですが、実際にはフロントエンドです。 そういうわけで、フロントエンドを構築する方法に深く絡み合っているので、「ああ、ちなみに、これが私が素敵なCSSを書く方法です」と言うことができず、そのままにしておきます。 私は人々が詳細に入るのを好むことを知っているので、私がすることは、私がやっていることです、私は本当に長くて本当に詳細なこの投稿を書きますそして誰かがスキルアップして私たちがしていることを本当に理解したいなら、それから彼らはすることができます、そして残りはそこからです。 そして、ここに私たちは今日、ドリュー、座ってそれについておしゃべりしています。
ドリュー：たとえば、誰かがすでにBEMを理解していて、おそらくすでにBEMを使用している場合、それはおそらく最も広く採用されている方法論の1つですよね？ それで、彼らがすでにBEMを理解していて、彼らがCUBEに来るのであれば、それは彼らが採用しやすいものでしょうか？ 多くの類似点がありますか、それとも完全に異なりますか？
アンディ：うん。 BEMからCUBEへの移行は、おそらくスムーズな移行だと思います。特に、CUBE用のCSSを作成する方法は特にそうです。 したがって、大部分のことはより高いレベルで起こっています。 つまり、カスケードレベルで発生し、グローバルCSSで発生し、ユーティリティを使用して多くのことを実行します。 しかし、その要点を理解すると、それは非常にBEMに似たコンポーネント、ブロック、および要素です。 BEMとは少し異なるのは、修飾子を使用する代わりに、例外と呼ばれるものを使用することです。これは、CSSクラスを使用する代わりに、データ属性に変換されます。これにより、かなりの分離と実際の処理が可能になると思います。例外、これは修飾子がどうあるべきかです。
Andy：私がBEMから離れた理由の一部は、特に設計システムでBEMを操作する方法が、モディファイアが支配的であり、それが問題になったためです。この時点での私のブロックの役割は？ 定期的に認識できない程度に変更している場合、この方法論は想定どおりに機能しているのでしょうか。
Andy：それから、デザイントークンのすべてがあります。これは、JinaがLightning Design Systemで行ったもので、私たち全員が今採用し始めています。 ユーティリティクラスのものは、そのアプローチで本当に意味をなし始めました。 だから私は他の人の仕事について好きなことをすべてつぶして、代わりに自分の仕事に割り込んだ。
ドリュー：あなたはBEMと話します。これは、制御不能になるようなモディファイアアプローチの一種です。 これは、CUBEが対処しようとしているBEMの主な問題点の1つでしたか？
Andy：ええ、もちろんです。 私はBEMの修飾子アプローチが好きです、それは理にかなっています。 BEMについて私が気に入っているのは、今でも行っていることです。要素の二重アンダースコアと、修飾子の二重ダッシュがあります。 私は物事を整理するその方法が好きです。 それは大丈夫の場合でした、まあ、私が実際にユーティリティクラスと他のビットで説明できる多くの修飾子…
Andy：この記事で使用している例は、カードを持っていて、カードを裏返すと、画像の前にコンテンツが表示されると想像してみてください。 したがって、それは理にかなっています。表示を確認するには、フレックスしてから逆に、順序を逆にします。 それは、カードのデフォルト状態の例外であるため、そのための例外ルールを持つことは理にかなっています。それが私がそれを見るのが好きな方法です。 これは、そのコンポーネントの影響を受ける状態のようなものであり、例外であり、それは理にかなっています。
Andy：私が最近やったことの多く、リアクティブJavaScriptを備えた最新のフロントエンドスタックでは、状態が変化することが多く、CSSとJavaScriptの間で適切に処理するのは理にかなっています。あなたがそれを好むかどうかにかかわらず、お互いにもっと絡み合っています。 それは彼らにとって共通の言語です。 あなたが私の顔で見ることができるように、ほとんどそうではありませんが、あなたはそこに行きます。 あなたはおそらく、「実際、私は最近、reactでかなり多くの作業をしているので、その逆です」と考えているでしょう。 だから私もそれを見ることができます。
ドリュー：それでは、CUBEに入りましょう。 したがって、CUBEはComposition Utility BlockExceptionの略です。 そうですか？
アンディ：うん。 それだ。
ドリュー：それは一体どういう意味ですか？
アンディ：ああ、メイト、あなたは前にそれを聞いたはずです！ 去年話をしていました。 私は話をしました、そしてそれはスケーリングするCSSでそれをシンプルに保つと呼ばれました、そしてそこで私はカスケードブロック要素ユーティリティトークンであるCBEUTと呼ばれるそれの以前のバージョンを紹介しました。 がらくたでした。 私はそれの名前が嫌いでした。 去年のこの話で、私はそれを数回やりました、そして私はその名前が本当に好きではありませんでした。 それで、今年このようなことをするようになったとき、「私はそれが実際に何であるか、そしてそれが何と呼ばれるかについて本当に考える必要がある」と思いました。 CUBEは少しゴミが少ないと思います。 それが私がそれを説明できる最良の方法だと思います。
Andy：でも、そうすると、名前はいつもこれらのことでゴミになりますね。 つまり、BEMのように、なんてごみの名前なのでしょう。 しかし、私たちは皆それをします。 Jamstackを見てください。それもひどい名前ですね。
ドリュー：私の唇は封印されています！
アンディ：あなたの上司は「何？」 それは本当です。 私たちの業界では、それはまさにその通りです。
ドリュー： CSSの方法論の多くは、カスケードなど、CSSの機能のいくつかを回避しようとしているようです。 私が読んだことからの私の理解は、CUBEはCSSのそのような機能とプロパティを利用しようとしているということです。
アンディ：うん。 それの良い例えは、SassのようなSCSSであり、自然なCSS言語の拡張ですよね。 あなたはまだCSSでかなり正しいです。 つまり、CUBECSSはそのようなものです。 つまり、CSSの拡張です。 したがって、CSSを作成する必要があります。CSSを作成する必要があります…まあ、それは作成されるはずです。 正直に言うと、それがどのように書かれるべきかということは、その名前がそれを与えることです：カスケードスタイルシート。 ですから、私が見つけたのは、マイクロ最適化レベルまでずっと下がったということです。 私は最近多くの人が下がっているのを目にする道を進んできました…そして私はこれについても記事で言及しました、そこで私は見ることができます…最近それのいくつかの証拠があります。 私は人々がスペーサーコンポーネントやそのようなものを作成しているのを見つけました、そして私はその問題を理解しています、私はその状況にありました。
Andy：私が修正した方法は、ドリルダウンしてマイクロ最適化を試みる代わりに、コンポーネントがどれほど小さいかは問題ではないので、実際には構成レベルで物事を考え始めました。ページになるには、ビューになります。 あなたはそれを避けることはできません、それはそれがどうなるかです。 つまり、「そうです、このレイアウトを行うには、これらの小さなヘルパーが必要です」と言う代わりに、「そうです、連絡先ページビューまたは製品ページビューがあります。これは、骨格のレイアウト構成です。 次に、その中に、必要なコンポーネントをスロットに入れることができます。」 現在、GridやFlexboxのようなものがあり、これをはるかに実現可能にしています。基本的に、必要なものを骨格レイアウト内に配置できます。問題はありません。 次に、コンポーネントは、その時点で、コンテナクエリの有無にかかわらず、コンポーネントが希望どおりに動作する必要があります。
Drew：これはCUBEの構成部分であり、マクロレベルで物事を調べ、コンポーネントをビューに構成して、サイトまたはアプリ用に作成する必要のある種類のページを作成する方法を確認します。またはあなたは何を持っていますか。
Andy：つまり、基本的にルールを作成しているのです。 それはガイダンスのようなものです。 何かのガイドラインを取得しようとしています。 それは厳格なルールのようなものではありません、例えば、あなたはこれをするべきです、あなたはそれをするべきです。 これは基本的に、この方法論でブラウザを使用して行っていることです。つまり、ブラウザに何も強制することはありません。 あなたはこう言っています。「理想的には、このようにレイアウトできれば素晴らしいのですが、そうではないかもしれないことを理解しているので、ここで作業できるいくつかの境界といくつかの上限と下限を示します。 できることをして、応援してください。」 次に、いくつかのコンポーネントをチャックして、それが行うことを実行させます。 ゴミに見えないように、そこに十分なコントロールを追加します。
Andy：良い例がわかります…スイッチャーと呼ばれるすべてのレイアウトでレイアウトを実行します。これは基本的に、アイテムの幅を計算する計算でアイテムを積み重ねる特定のポイントまで、アイテムをインライン化します。 。 ただし、インラインとブロックにマージンを追加するため、状態に関係なく機能しますが、それでも問題なく表示されます。 これは、ブラウザに「この3列のグリッドを階層化する必要がある」と言っているのではないという考えです。 「3列のグリッドを重ねることができるなら、それを実行してください。 それ以外の場合は、代わりにスタックしてスペースを空けてください。」 つまり、ブラウザに実際にその仕事をさせるという、そのような方法論です。
ドリュー：過去数年間にCSSに採用されてきたさまざまなアプローチの多くは、コンポーネントのようにすべてを処理するコンポーネントレベルに非常に重点を置いてきました。 CUBEは、そのコンポーネントの側面をそれほど軽視していません。レイアウトが単なる別のコンポーネントであると言うのではなく、これらのコンポーネントを取得してより大きなレイアウトに構成することに加えて、この追加の概念を提供するだけです。
Andy：ええ、それは良い点です、ええ。 コンポーネントについて言うことは、特に現代のフロントエンドのものでは重要だと思います。 私たちは多くのコンポーネントやシステムを行っています。 しかし、私がコンポーネントを見る方法は、それはすでに行われたことを拡張するルールのコレクションです。
Andy：この記事で私が指摘しているのは、ブロックレベルに到達するまでに、ほとんどのスタイリングが実際に行われているということです。実際にコンポーネントが行っているのは、Isに点を付け、Tを交差させることです。 「そうです、この文脈では…」たとえば、カードの場合、画像の最小高さをXにし、ここに少しパディングを追加します。 これ、あれ、そして他のことをしなさい。 ここにボタンを置きます。 これは、CSSの残りの部分からすでに継承されているものに加えて、一種の追加のルールです。 それがおそらくそれを説明するための最良の方法だと思います。
Andy： BEMでは、コンポーネントが信頼できる情報源です。 そのクラスを要素に配置するまで、その時点では何も適用されておらず、そのメソッドは機能します。 私はそれを行うことでより多くのCSSを作成し、それを行うのが好きではない、より反復的なCSSを作成したことに気づきました。
ドリュー：タイポグラフィ、色、垂直方向のリズム、間隔など、このモデルの構成のアイデアの一部であると思いますか？
アンディ：うん。 グローバルCSSでは、ええ、絶対に。 特に縦のリズムと流れ。 それについての記事を24通りの方法で作成しましたが、数年前はフローとリズムのコンポーネントでした。 これは、このアプローチからの一種の抽象であり、基本的にロボトミー化されたフクロウセレクターを使用する基本コンポーネントを設定します。 ラジオでどう説明するかわかりませんが、説明します。 ヘイドンの記事か何かについてのショーノートに入れるだけだと思います。 しかし、本質的には、子要素を選択します…申し訳ありませんが、兄弟要素です。
Andy：つまり、「要素Xに続くすべての要素には、CSSコストとプロパティ値のマージントップがあります」ということです。その美しさは、CSSカスタムプロパティ値を構成コンテキストにも設定できることです。 つまり、「このコンポーネントでは、外出先でフローがある場合は、フロースペースを実際には2レムに設定します。これは、広いスペースを美しく、力強くしたいからです。」 次に、別の例では、「実際には、フロースペースをタイトにしたいので、フロースペースを0.5レムにしたい」と言うかもしれません。 これはすべて起こっており、すべてのコントロールはより高いレベルから来ています。そして、あなたがしていることは、毎回それを再発明するのではなく、コンテキストオーバーライドを追加し、同じことを何度も何度も再発明することです。
ドリュー：それがC、コンポジションです。 次に、ユーティリティであるUがあります。 では、効用とはどういう意味ですか？
Andy：それで、それは1つの仕事をするクラスであり、それは本当にうまくいきます。 これは、プロパティの抽象であるデザイントークンの実装である可能性があります。 通常、それは色やタイポグラフィのスタイル、サイズ、およびそのようなルールです。 アイデアは、それらを適用するユーティリティクラスを生成することです。 つまり、原色のような背景の原色を適用し、次にテキストの色である原色を適用するユーティリティがあります。 次に、マージナルパディング用のいくつかのスペーシングトークン、およびそれらすべての種類のものを生成する場合があります。 彼らはただ1つの仕事をします。 彼らはただその1つの間隔ルール、その1つの色ルールを追加するだけで、それだけです。
Andy：でも、他のユーティリティもあります。 したがって、良い例はラッパーユーティリティです。 これにより、要素に最大幅が設定され、次に左右の自動マージンが配置されて、要素が中央に配置されます。 つまり、1つの仕事しかなく、効率的かつ適切に実行しているだけです。
Andy：グローバルなスタイルができたので、タイポグラフィの設定とフローリングのスペースをたくさん使いました。 次に、コンポジションがコンテキストとレイアウトを提供します。 次に、ユーティリティはトークンを要素に直接適用して、必要なスタイルを要素に与えます。 たとえば、見出しのように、「これをこのサイズにし、このリードを入れて、このメジャーを設定したい」と言っているのです。 次に、その時点で…これがブロックについて私が言っていたことです…次に、スタックをさらに下に移動すると、その時点でほとんどの作業がすでに完了しています。
Andy：つまり、この非常に効率的な作業方法を提供します。HTMLのようなストリームもパイプを流れるので、CSSではなくHTMLにワークロードを抽象化するのは本当に素晴らしいことです。 以前は、この種の古い「関心の分離」のような古いcurmudgeonスタイルのように、ユーティリティクラスに実際に参加していましたが、実際には、それは本当にまともな作業方法だと思います。 私は実際にTailwindCSSが好きだと記事で述べています。 私はそれがうまくいくと思います、そして私は本当に何かを本当に速く出すことができるのでそれを製品タイピングに使うのが本当に好きです。 しかし、Tailwindは少し行き過ぎだと思いますが、クラスに1つのルールを適用するだけでは不十分な場合は、雨が降るのが好きです。 以上だと思います。 あなたは？
ドリュー：そうですね、あなたはこの記事でデザイントークンについてたくさん話します。これは、エピソード3でジナアンとのスマッシングポッドキャストで話しましたが、そうだったと思います。 つまり、デザイントークンは本当に基本的な側面のようです。
アンディ：うん。 ああ、神様、ええ。 当時、私がデザインシステムやデザインシステムに似たものを作っていたので、ジーナがライトニングデザインシステムの仕事をしていたときのことをとても鮮明に覚えています。 Lightning Design Systemが登場したとき、私は文字通りリンクを次々と送信し、「これが私たちが行っていることです。 設計システムを構築しています。 これは、Salesforceが現在使用している目的です。」 当時の彼女の仕事は、実際に私がドアから物を手に入れるのを助けてくれたのを覚えています。
Andy：それなら、これらのルールを適用するための本当に良い方法であるとして、デザイントークンのものは常に私に固執しています。 私は貿易によるデザイナーなので、その組織と、信頼できる唯一の情報源を整理して作成する機能は、デジタルデザイン、特にAdobeでは実際にはなかったものであるため、非常に便利です。 Photoshopなどを使用する時代には、そのような贅沢はありませんでした。 Pantone Bookで印刷しましたが、店全体にランダムな16進コードを含むデジタルではありませんでした。
Andy：それは素晴らしいことです。 私はそのレベルの制御が大好きです。 実際、重要でないことについてはもう考えていないので、それは創造性に役立つと思います。あなたはそれを使って何をしているのかを考えているだけです。
ドリュー：これらのデザイントークンの実装は、特にアプローチにとって重要ですか？ それは常にCSSカスタムプロパティですか？
Andy：それはCUBEにとって本当に重要なポイントだと思います。 私が受けた反応のいくつかは、人々はこれに少し苦労しています。 その中にはテクノロジーについての言及はまったくありません。 一貫性のある唯一のテクノロジーはCSSです。 あなたはそれを好きなように行うことができます。 これはすべて、人々が現在行っているCSSやJSの処理を使用して行うことも、VanillaCSSだけを使用して行うこともできます。 あなたはサスでそれを行うことができます。 私はサスでそれをします。 それがあなたがまだしていることなら、もっと少ないです。 これらすべての利用可能なテクノロジー、CSS後、これらすべてのもの。 あなたはそれをやりたいと思う方法で行うことができます、それは問題ではありません。
Andy：アイデアは、そのような構成に従うと大丈夫だということです。 それがその背後にある考え方です。 方法論のいくつかがそうであるように、それは非常に緩く、厳密ではありません。 特にBEMで見たことがありますが、人々はBEMの原則に深く根付いており、問題をもう解決していないように見えます。 柔軟でなければならないと思います。 去年のこの講演で言いました。 私は、「銃に固執しすぎると、特定の道をたどろうとして、それが機能しなくなったことを知っているので、長期的には実際に問題を引き起こす可能性があります」と言っていました。 あなたは常に柔軟性があり、システムへの手紙に取り組むのではなく、システムで作業する必要があります。
ドリュー：つまり、B、Bはブロックです。 あなたはこのアイデアについて話しました。ブロックレベルに到達するまでに、ほとんどすべてが適切に配置されているはずです。ブロックレベルのスタイリングは、特定のコンポーネントの実際の詳細にのみ関係します。 一般的に、ブロックの概念は、人々が精通しているものと似ていますか？
アンディ：ああ、絶対にそうだね。 したがって、BEMコンポーネントを想像して、そこからすべての視覚的なものを取り除いてください。これが、基本的にブロックに残されているものです。 これは、私がこの方法論を最初に考え始めたときに明確にするのに苦労したことです。 ブロックは実際にはCであり、構成ですが、再帰的な領域にいるため、人々の脳が爆発するので、それは非常に困難です。 しかし、実際にはそれがブロックであり、実際には別の構成レイヤーですが、カード、ボタン、カルーセルなどの厳密なコンテキストのようなものです。
Andy：それは特定のもの、コンポーネントのようなもので、その中であなたはそれが従うべき特定のルールを設定し、残りを本当に無視するのであなたはそうではありません…あなたはブロックにトークンを適用するかもしれません、そして私はそれをしますそれでも、実際にはレイアウト指向であり、私がそれらを操作する限り、または少なくともトークンを取得して、ボタンのホバーステータスなどの特定の方法で適用する限り、ブロックです。 ですから、実際には、あなたが彼らにたどり着くまでにあなたのブロックは小さいはずです、彼らは実際にはほとんど何もしていないはずです。
ドリュー：ハイパーリンクと同じくらい小さいかもしれません。
アンディ：うん。
ドリュー：しかし、それは他のブロックの複合コレクションである可能性もありますか？
アンディ：うん。 モジュールのようなものです。 あなたは間違いなくそれを行うことができます。 繰り返しになりますが、それはある種の構成的な側面に戻るので、そこに何が入っていても問題ではないということです。 その良い例はカードのようなものです。 つまり、カードの内容は、たとえば、見出し、要約、ボタンのようなものです。 これらの3つの要素を具体的にターゲットにするべきではありません。 「コンテンツに含まれているものはすべて、そこにいくつかのフロールールがあり、ある種の構成レイアウトルールがある」と言う必要があります。そうすれば、そこに何を入れてもかまいません。 そのコンテンツに画像を入れたいと思うかもしれませんが、それはうまくいくはずです、それはうまく見えるはずです。
Andy：それがCSSでの作業の要点です。 これは、CSSを操作するための非常に寛容な方法です。 物事が偶然何かに自分自身を見つけたとき、それはあなたが物事についてより具体的であった場合のように恐ろしく見えないので、あなたはあなたの人生をはるかに楽にします。見つかった。
ドリュー： CSSの周りには間違いなく多くの許しが必要です！
アンディ：そうだね！
ドリュー：乾杯！ これがBです。最後はEです。Eは例外です。 今、私たちはエラーメッセージについて話していませんね？
アンディ：いや、いや。 それは一種の-
ドリュー： JavaScriptの例外について話しているのではありません。
アンディ：うん、うん。 この時点では、そのようなことはないはずです。 私はとにかく望んでいないはずです、さもなければあなたはその時点で本当に森の中にいます：私はあなたを助けることができるとは思わない！ これの全体的な考え方は…つまり、ブロックを使用してコンテキストを作成しました。例外は、まさにそれです。これは、ルールの例外のようなものです。つまり、カードをめくったり、ゴーストボタンにしたりすることができます。 それで、あなたはちょうど境界線と透明な背景を持っているそれらのボタンを知っていますか？ ボタンの背景色が単色で、次にラベルの色が付いている可能性があるため、これは例外です。 つまり、ある種の明確な変化の状態を作り出しているのです。
Andy：クラスではなくデータ属性を使用してこれを行う理由と、それが理由です。a）区別するのは良いことだと思います。 したがって、大量のHTMLをスキャンしていると、データが表示され、何かがハイフンで表示されます。「そうですね、この要素で何かが確実に変更されました」のようになります。 もう1つは、JavaScriptにその状態へのアクセスを許可することは非常に便利であり、その逆も同様です。 だから私はJavaScriptでデータ属性を使って状態を適用するのが本当に好きです。 それが本質的に彼らの目的であり、一種のコミュニケーション層だと思います。 それらの間の調和は本当にうまくいくようです。
Andy：良い例は、ステータスメッセージがあり、JavaScriptがデータの状態を追加するということです。これは、成功、エラー、情報などのいずれかです。 次に、CSSの例外スタイルを使用してそれにフックできます。 つまり、これはステータスコンポーネントの例外であり、デフォルトの状態に反していることがわかります。 ですから、それは物事を扱うのに本当に便利な方法です。 両端で予測可能です。CSS側で予測可能であり、JavaScript側でも予測可能です。
ドリュー：クラス名があなたに与えないものがプロパティと値であることは非常に素晴らしいことだと思います。 したがって、状態であるようなものが必要であり、それが成功、失敗、警告、またはあなたが持っているもののいずれかである場合は、その状態プロパティに具体的に対処し、その値を反転させることができます。 クラス名のリストが非常に長いのに対し、たとえばJavaScriptでそれを操作する場合は、それぞれを調べて、そこに次のようなビジネスロジックを追加する必要があります。これらの1つ」と、これらのクラスの2つが同じ要素に適用された場合はどうなりますか？ データ属性ではそれを取得できません。値は1つだけです。
アンディ：うん。 ええ、それはそれを言う良い方法です。 そのように働くことは非常に役に立ちます。
ドリュー：それはとても興味深い。 そのアプローチを採用している他の方法論は見たことがないと思います。 それはCUBEに完全に固有のものですか？
Andy：そうかもしれません。 私は他のことにあまり注意を払っていません。 他の誰かがおそらくそれをやっています。 私は今あなたに話します、それはそれの最も物議を醸す側面でした。 一部の人々は、データ属性を使用するというアイデアを本当に嫌いでした。 物事も同様であり、私がどのように対応するかは、あなたが望むことをすることです。 私たちはあなたに特定の方法で物事を行うように言っているのではなく、それは単なる提案です。 修飾子などのCSSクラスの例外を実行する場合は、自分をノックアウトします。 CUBE警察はあなたのドアをノックするつもりはありません。 それは絶対に大丈夫です。
Andy： CUBEのことは思考のことであり、構造です。 その構造をどのように適用したいか、必要なツール、または必要なテクノロジーを使用して適用します。 物事の一貫性を保つ限り、それは重要なことです。
ドリュー：それで、純粋なCUBEのようなものはありませんか？
Andy：私が書く方法は、純粋なCUBE、Drewです。 他の誰もがただの偽物であり、それはただの弱い模倣です。
ドリュー：あなたを除けば、誰も「それは教科書のキューブではない」と言うことはできません。
Andy：いいえ、それだけです。 誰もそれについて本当に異議を唱えることはできませんね。 だから、ええ、私はそれで行きます。 ちょっとした影響力か何かを与えてくれると思います、そのようなものです。
ドリュー： CUBEアプローチを他の方法論と組み合わせて組み合わせることができますか？ BEMのビットを使用できますか？
Andy：そうだね。 かなり人気が出てきたので、もう少しやろうと思っていたので、もっと仕事が欲しくなると思います。 私が見ようとしていることの1つは、既存のものを使用してCUBE方法論を使用してアプローチする方法です。
Andy：つまり、スケールの両端が2つあります。 人々が尋ねた良い質問は、「これはすべてのレイアウト、他のものでどのように機能するのですか？」です。 基本的に、すべてのレイアウトはCのようです。それがすべてのレイアウトであり、構成レイヤーです。 次に、他の誰かが尋ねました。「まあ、これは、Brad Frostが行ったような、Atomic WebDesignのようなものでどのように機能するでしょうか。 それは、まあ、それらの部分を分割して、各レベルでそれらを適用することができるようなものです。 アトミックデザインは、細部に至るまで続きます。 それを抽象化して使用することで、そうですね、ユーティリティでこれを適用できるので、分子だと思います。 私はそれをユーティリティで適用することができます、そしてそれはあなたがすでに知っていることをこのわずかに異なる働きの構造に変換しています。
Andy：本当に、それは多くのことの名前の変更です。 私はここで何も発明していません、私が言うように、私はちょうど私が好きなものを盗んだだけです。 アトミックデザインのいくつかの考え方が大好きです。 それは本当に賢い仕事です。 そしてBEM。 ハリーがやったこと、逆三角形のCSS、それは本当にクールだと思いました。 だから私はそれらのそれぞれから好きなニックの入ったビットを並べ替えて、この他のハイブリッドなもの、アプローチにそれらをすべてつなぎ合わせました。 もっと来ると思います。
Drew： CUBEアプローチは、CSSがすでに導入されている既存のプロジェクトに適用できますか、それとも新しいプロジェクトで開始する必要があるものですか？
Andy：それは非常に異なります。 ですから、もしあなたがブートストラップの仕事をしていて、それが数千行のカスタム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. それが現実さ。 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.
Andy：少し違うことをして、自分が持っている知識を応用して、実際に人々と共有することを夢見ました。 私はいつもとてもオープンで共有してきました、そしてそれを形式化したかったのです。 そこで、チュートリアルを書くためにピカリリを作成しましたが、主に私が作成しているコース用です。それが主な肉とジャガイモです。 そして、ニュースレターがあります…毎週インターネットで見つけたクールなものを共有しているので、人々はニュースレターを本当に楽しんでいます。 それがそのバックボーンです。 本当にうまくいっています。 それは本質的に、年が経つにつれて、私が自分自身がますますフルタイムでやっているのを見たいところだと思います。
ドリュー：では、ピカリリの次は何が来るのでしょうか？ 出てきたものはありますか？
アンディ：ドアを開けてくれてありがとう、ドリュー！ このレコーディングが終了するまでに、最初のコースがライブになります。「ゼロから11を学ぶ」では、ギャツビーのWebサイトを構築する方法を学びます。 いいえ、あなたは11のサイトを構築する方法を学びます。 つまり、完全に空のディレクトリから始めて、そこには何も入っておらず、空であり、最後に、この本当に見栄えの良い代理店サイトで終わります。 私たちはその中であらゆる種類を学びます。 あなたは本当に11で町に行く方法を学びます。 場所からリモートデータを取得します。 CUBE CSSを使用して、非常に優れたフロントエンドを構築します。
Andy： Jamstackに参加して、静的サイトジェネレーターに参加したい場合、または優れたWebサイトを構築する方法に参加したい場合は、非常に便利なコースです。 私たちが話しているように、それは現在その人生の1インチ以内に編集されています。 それはクールになるだろう、私は願っています、そして役に立つでしょう。 しかし、それは私が過去数年にわたってやってきたたくさんのことの蓄積です。 だからそれは楽しいはずです。
Andy：それで、それを買ってください、そして、私は割引コードをします、40％オフのsmashingpodのようにします、そしてそれが出たときにあなたはそれを手に入れることができます。
ドリュー：すごい。 それをリンクします。 ピカリリを確実に綴る方法をもう理解しましたか？
Andy：私はShopTalk ShowでChrisとDaveと一緒にいました。そこで、「私を雇いたいことが1つあるとしたら、それは、ピカリリを考えずに初めて手で書くことです」と言いました。その言葉を何度も書いたので、私はそれを心から綴る方法を正確に知っています。 だからあなたの質問への答えはイエスです。
ドリュー：まあ、私はまだ苦労しています、私はあなたにそれだけ教えます！
Andy：難しいですね。 ああ、神様。 私は完全に共感します。 綴り方を学ぶのに長い時間がかかりましたが、それは私たちの語彙のそれらの単語の1つです。 今年はつづりを間違えずに必要なつづりをしようとしています！
ドリュー：それで、私はCUBECSSについてすべてを学んでいます。 アンディ、最近何を学んでいますか？
アンディ：あなたは何を知っていますか？ これはあなたを驚かせるでしょう、ドリュー。 MySQLは私が最近学んでいることです。 したがって、基本的に、ピカリリは完全に自費出版されています。 これは11のサイトですが、背後にAPIがあり、背後にMySQLデータベースがあります。 彼らが購入したコンテンツを人々に与えるものは、かなり重いクエリを必要とします。 だから私は実際にいくつかのMySQLに適切に投資しました…特に結合間の違いは、実際には各タイプの結合の間に違いがあることに気づいていませんでした。 これは非常に便利で、データベースとのやり取りが非常に高速になりました。
Andy：以前はFront-End Challenges Clubと呼ばれるものを実行していましたが、最初に起動したときは、MySQLが控えめに言っても見苦しいため、崩壊して死んでしまいました。 ですから、私はバックエンドの人間ではなく、ピクセルプッシャーであるため、その方法を実際に学んでいます。 ですから、それは間違いなく私の任務ではありません。 それはあなたの森の首ですよね？ MySQL、本当にかっこいいと思います。 私は実際にそれを書くのが本当に好きです。 それは本当に素晴らしい、教育的な言語ですよね？
ドリュー：そうですね、素晴らしいです。 私は学校でSQLを学びました。
アンディ：うわー！
ドリュー： 20年前のように話している。
Andy：当時彼らはコンピューターを持っていましたか？
ドリュー：そうだね。 私たちは巻き上げなければなりませんでした-
Andy：手で書く必要がありましたか？
ドリュー：私たちはそれらを巻き上げる必要がありました！ しました。 しかし、開発者にとっては、九九を学ぶことに似ています。ちょっとした雑用のように見えますが、流暢になると、何度も何度も役立つようになります。
アンディ：うん。 確かに。 目に見える違いもあります。 あなたは本当に速度の違いを見る。 Nodeを使用するのは非常に高速であるため、私は本当に好きですが、NodeとMySQLは…あまり一般的な選択ではありませんが、かなり良い選択だと思います。 私はそれが本当に、本当にうまくいくと思います。 だから私はそれに満足しています。 ご存知のように、私はPHPを書くのが好きではありません。 したがって、それがオプションになることは決してありません。
ドリュー：親愛なるリスナーであるあなたがアンディからもっと聞きたいのなら、彼がハンクチズルジャウにいるツイッターで彼をフォローすることができます。 Piccalilliはpiccalil.liにあります。ここには、CUBE CSSについて説明している記事もあります。もちろん、ショーノートにそれらすべてへのリンクも追加します。
ドリュー：今日はご参加いただきありがとうございます、アンディ。 別れの言葉はありましたか？
Andy：安全を確保し、マスクを着用してください。