惇志の個人サイトHubSpotやCSS設計に明るい半田のウェブサイトです。ウェブサイトの本質は情報を伝えることですので、それを言い訳にデザインは全体的に工事中です。半田について提供サービスブログお問い合わせ2024/05/09*TechnologyHTML/CSSCSS設計とは何だったのか?と、コンポーネント環境との関わりシェア:みんな大好き、あるいは大嫌いなCSS設計。そんな言葉が生まれてから久しく、JavaScriptフレームワーク(以後JSフレームワーク)を始めとする技術が提供するスコープ付きのコンポーネント環境の登場によって、そのなりを潜めている気がしなくもない。そんなCSS設計とは何だったのか、をちょっと小難しく振り返ってみます。本記事では、区別のためCSS設計が「再利用可能なパーツ」とみなす単位を(あるいは慣習的に)「モジュール」、JSフレームワークにより提供される単位を「コンポーネント」と呼びます。いう形式の長ったらしいクラス名を付けることだ、とパッと思うかもしれません。これはCSS設計が行っていたことのごく一部に過ぎず、CSS設計が行っていたことを大別すると次のようになります。名前設計スタイリング設計これらについて、それぞれ見ていきます。カスケード設計カスケード設計では、まずCSSにグループ/レイヤーという概念を導入することで、コードの順序を管理することを狙います。componentsutilityのような形で、スタイリングの目的に合わせてCSSを分類します。後に行けば行くほどカスケードの力関係が強く、下部のレイヤーは必ず上部のレイヤーのスタイリングを上書きできる、という思想を多かれ少なかれ提供します。セレクタ利用のルールを統一すること、一言で言えばクラスセレクタの利用を基本とする、という考え方も、このカスケード設計の一部と言えます。カスケード設計が行っていたことは、「重要度や詳細度を管理することで、期待通りにスタイリングする」ということであり、プログラミング一般の考え方に照らし合わせると予測可能性の設計である、と言えます。プログラムの動作や出力が事前に予測できることを指す。意図した通りに動作することが期待できる。コードがわかりやすく読みやすいため、修正や拡張が容易である。Opusによるモジュール設計CSS設計の次の仕事であるモジュール設計は、主に「ビジュアルをどのように分解し、どのような粒度でモジュールとして独立させるか」という設計を指します。わかりやすく例を挙げると、例えば同一ウェブサイト内の異なる10ページを10人がよーいどん、で一斉に構築をすると、10ページの構築にかかる合計時間は肥大化し、非常に効率の悪い進め方となるでしょう(並列処理をしているので、完了までの時間は短いかもしれません)。ボタンなどの共通パーツを、全員がそれぞれ構築してしまうからです。この状況を防ぐためにモジュール設計が存在します。共通である、あるいは再利用可能な部分をなるべく小さい単位で見い出し、全体の構築を容易・効率的にするのがモジュール設計の役割です。悪いと、このボタンモジュールを再利用しようと頑張るより、それぞれが別々にボタンを構築してしまった方がかえって早いかもしれません。設計が下手だとそんなこともあり得る訳ですが、それは原因がCSS設計ではなく人間のスキル不足にあるため、ここでは別問題とします)ここでもプログラミング一般の考え方に完全に一致ではないにせよある程度照らし合わせると、つまりモジュール設計が行っていたことは分割統治の設計である、と捉えることができます。簡単に解けるサイズにした上で解いていく方式。次にCSS設計と言えばこれ、みんな大好き(大嫌い)名前設計です。方式)させることで擬似的にスコープを形成しスコープを防ぐことを目的とします。それだけでなく「そもそもモジュールにどういった名前を付けるか」というのもこれに該当します。」とするのか、みたいな話です。「名が体を表すために、名をどうする」ですね。これは言わずもがな、プログラミング一般の考え方においても名前空間の設計に近いと言えます。つけなければ識別できない範囲のこと。意識しなくて良いようにしたもの。最後にスタイリング設計です。これは1番泥臭いというか経験則が支えになる部分で、「モジュールとしての機能を十分に満たすために、モジュールのルート要素にどういったスタイルを当てないべきか」を管理するものです。付けるな、問題がこれに当たります。プロパティを付け直さなければならない、とっても使いづらいボタンの完成です。スタイリング設計はそれだけでなく、「モジュールの子要素はどのように制御すべきか」も管理します。Caseとしてまとめているので、いまいち想像が付かない方は合わせてご覧ください。これはつまりプログラミング一般の考え方で言えば「関心の分離の設計」に近しいものになります。構成要素に分割するという設計の原則。依存せず自身の責任に集中する。変更の影響範囲が限定される。OpusによるつまりCSS設計が行っていたこととはCSS設計が行っていたことを、4つに分けて解説しました。それぞれに対して毎度わざわざプログラミング一般で言えばどういった概念が近いかも添えました。関心の分離の設計をしていた、ということです。して、CSS設計によって人類はCSSを御する力を手に入れ、CSS界隈には平和が訪れたと思った?残念でした!きちんと行うには、CSS設計はあまりにも複雑過ぎたのです。一応セオリー通りに頑張れば誰でも6割くらいは出来ると思いますが、その先をどこまできっちりできるかは、はっきり言ってこれは適正の世界です。ウェブデザインというのは建築デザイン等と違い、物理法則がありません。物理法則がないので、論理的合理性が働く力も必然的に弱くなりがちです。論理的合理性が弱いものの中から、それでもパターンを見出し、コードという論理的合理性の塊に押し込めるのは、かなり骨の折れる作業です(普通は無理矢理押し込められる方の骨が折れそうなもんですけどね。この場合骨が折れるのは押し込める方です)。そんな中、JSフレームワークによるスコープ付きのコンポーネント環境が登場しました。コンポーネント環境が吸収したことコンポーネント環境が登場したことにより、CSS設計というのはフロントエンドエンジニアの関心ごとではなくなり、若干なりを潜めたように思います。関心の分離の設計の幾つかは、コンポーネント環境が代わりに担うようになったためです。全部が全部コンポーネント環境が担ってくれたかと言うとそうではなく、むしろまともに担ってくれたのは1つ程度だったりします。CSSなどCSSの書き方もさることながら、「CSS設計が担っていたがコンポーネント環境が担っていない範囲、及びその狭間で曖昧になっているもの」を楽観視しないこと、というのが私の持論です。予測可能性の設計(カスケード設計)スコープ機能により、よっぽど特大コンポーネントを作っていない限りは詳細度はそこまで気にしなくてよい。レイヤー分けの発想は引き続き重要。理解していないと、使いづらい負債コンポーネントが簡単に出来上がるコンポーネント環境により子要素を外から無理矢理制御する、なんてことはしづらくなったが、それでもやろうと思えば出来てしまうので注意まとめ以上、駆け足でしたがCSS設計とは何だったのか?と、コンポーネント環境が登場して、CSS設計はどうなったのか、コンポーネント環境が何をしているのか、をざっくり解説しました。Niteにてオンラインでお話します。