デザイナーが考えるCSS設計

第４章では、⼀点もののスペシャルコンテンツを専⽤CSSを使って作り続ける日経:Visual Dataチームのデザイナーが、BEM というCSS 設計思想に⾏き着くまでの考えを綴ります。

全章を一括して購入されたい方はこちらの記事をご購入ください。
https://note.mu/nikkei_staff/n/n44623c9b9ab4

日経ビジュアルデータのコンテンツデザイン・コーディングを担当してる安田翔平/@nyasushoです。

CSS は不思議な⾔語です。Web で表⽰される情報を⾒やすく整え、時に⽬的に沿って華々しく彩ります。ですが単純な構⽂と仕組みゆえに、とっつきやすく⾒えて簡単に破綻する脆さと常に付き合わなければいけません。⼀点ものスペシャルコンテンツを専⽤CSS を使って作り続けるチームのデザイナーが、BEM というCSS 設計思想に⾏き着くまでの考えを綴ります。

4.1 ⽇経ビジュアルデータの制作体制とコンテンツの特徴

⽇経ビジュアルデータ*1は、データ可視化を軸にしたWeb コンテンツ群です。⽇経電⼦版本体で扱えないようなリッチ表現を⽤いた特集記事、分析記事、データを活⽤したツールなど、最先端のジャーナリズム表現と体験を提供します。2017 年GoodDesign 賞⾦賞受賞しました！*2

⽇経ビジュアルデータ制作チームがあるメディア戦略部は、デジタル事業ではなく、新聞記者と同じ編集局に所属しています。サービス開発よりもデジタル媒体における新しいジャーナリズム表現を⽤いたコンテンツの企画開発に強みを発揮するチームです。

具体的には取材、記事執筆、データ分析、データ可視化、フロントエンド、情報デザイン、視覚伝達デザインなどなど、情報伝達に必要なスキルを持った記者・エンジニア・デザイナーが中⼼となり、全員がジャーナリストとして⼒を発揮しています。

コンテンツを供給する編集局と、それをユーザーに提供するサービスを開発するチームとの橋渡しなどを⾏う⽴ち位置のチームでもあります。

コンテンツ制作時はエンジニアとデザイナーと記者の三者と、それを統括し記事のクオリティを管理するデスクが制作しています。記者がデータから伝えるべきことを⾒つけ、デザイナーが体験・UI・視覚伝達設計、エンジニアがデータ可視化をはじめとしたフロントエンドを担当します。三者で密に連携しながらコンテンツの完成を⽬指して⾏きます。

コンテンツは記者が伝えたいことによりさまざまな表現の形に変化します。

• ⽂章・写真主体で世界観を作り上げることで没⼊してもらうイマーシブコンテンツ
• インフォグラフィックスとデータビジュアライゼーションを⽤いた解説記事
• ⼤量のデータから読者が必要なものを提供するツールコンテンツ

このように多様なコンセプトと要件を持った⼀点物コンテンツが中⼼となっています。そのため、テーマに沿った機能性や表現に⼒を⼊れるとどうしてもデザインもそれを表現するHTML、CSS も専⽤品になります。

4.2 デザイナーはCSS というものをどう捉えているのか

設計の説明に⼊る前に、デザイナーの⽴場から⾒るとCSS はどのように⾒えるのでしょうか？

たとえば私はSketch やPhotoshop などのグラフィック・プロトタイプツールの延⻑であるような捉え⽅しています（図4.1）。

このように塗りと線、ドロップシャドウなどをひとつのエレメントに値として持たせられる点は似ています。これらデザインツールの機能とCSS の機能を重ね合わせて考えてるところがあります。特にsketch はコードに起こすところまで考えられたツールなのでイメージしやすいです。

イラストレーターやSketch を使いなれたデザイナーにとって、要素のプロパティに何か値を⼊れると、そのとおりに⾒た⽬がすぐに変わるというのはとても親しみやすいものです。⼀⽅でそのような捉え⽅をした結果、切⽻詰まると急いでグラフィックツールを使うように、とりあえずデザインが再現されている状態の場当たり的な脳筋コードを書いていました。

整理されていないイラレやSketch データは他⼈が、時には⾃分でも扱いにくいものです。

同様に、ただ勢いに任せて書かれたCSS は読むのも書き⾜すのもつらいです。無限に詳細度が深くなりクラス名も無秩序に増加します。⾏数が増えるほど、上書きすべき場所を探すのに⼿間取り、⼯数が増⼤していきました。メンテもレビューも困難なCSS のでき上がりです。そうしたCSS の無秩序さを経験し、イラレやフォトショでレイヤーやアピアランスを管理するのと同様に、CSS にも制約が必要なのではと考え、CSS を設計する分野を勉強し始めました。

4.3 そもそもCSS を書くには簡単か。

CSS を書くこと⾃体は簡単なのですが、ちゃんと書くのはとても難しいというのが私の⾒解です。ちゃんと書くことを困難にする理由は、CSS の特徴にあります。

• スコープ？ そんなものはない
• ブラウザごとに解釈が違う
• 詳細度インアビス
• 処理を使い回す機能がない

よくいえば始めるハードルは低く、⼆次元的視覚表現における⾃由度が⾼い⾔語だと私は考えていますが、適当に書くと簡単に破綻してしまいます。SASS が流⾏っていることからも、⼀部エンジニアさんが⽋陥⾔語と呼びたくなるのも分かる気がします。

ここで極端に悪い例を⾒てみましょう（図4.2）。

CSS には後に記述されたスタイルの⽅が優先され、idを使ったり親要素を遡って記述するほど優先されていく詳細度という概念があります。また、そしてそれらを全て無視して無条件でスタイルを適⽤する最終兵器、!importantという記述が存在します。

図4.2 のコードは⾏数が少ないので⼤したことないように⾒えるかもしれません。しかし、このような調⼦で場所に依存させながら、無秩序に先祖を遡りながら指定するようなスタイルの上書き（汚染）を1000 ⾏以上のCSS の中で繰り返すとどうなるでしょう。今ひとつひとつの要素に適⽤されてるスタイル記述が何⾏⽬のどれなのか不明になり、破綻します。

先述の私の経験のように、⼩規模なページならある程度は筋⾁で書いても気合いでデザインの再現まではなんとかなります。

それでも書けば書くほど⼯数が増えるし後からメンテしづらいし重いしでいいことはないです。

4.4 いいCSS とは何か？

では、いいCSS とは何でしょうか？ 昨今のCSS 設計思想を参考に考えられるよいCSS とは

1. 平坦な詳細度
2. 少ない上書き
3. 場所と構造と⾒た⽬の情報が分かれている

この三つがクリアになったものと考えています。

平坦な詳細度

詳細度が⼀定ならば、上書きする機会は⼤幅に減ります。場所・構造・⾒た⽬をごっちゃに書くと詳細度が⾼くなりやすいです。.container .list .rowのような「. どこの. 何の. どれ」のような指定の仕⽅だと、クラスひとつで指定する場合に⽐べ詳細度が三段階も⾼くなってしまっているのがわかります。

少ない上書き

同じ要素に何度もスタイルを上書きすることを前提とした書き⽅は、よい書き⽅とはいえません。スタイルを上書きするためにより詳細度が⾼くなる書き⽅を繰り返し、際限なく詳細度が深くなっていきます。何度も同じ要素への指定が登場するのも⾏数の無駄です。!importantの使⽤は極⼒避けましょう。

場所と構造と⾒た⽬の情報が分かれている

位置と構造と⾒た⽬、全ての情報がひとつのセレクタに集中していると、要素の使い回しがきかずに⾏数がいたずらに増えます（図4.3）。

サンプルコードでは、.logoが配置される場所ごとにその位置と⾒た⽬が定義されていますが、これは好ましくありません。サイト全体共通の.logoという要素のスタイルを定義してから、場所ごとに「.logo というパーツの別バリエーション」として場所に依存しない作りにすることが⼤切です（図4.4）。

このようにCSS の脆さをおぎない、いいCSS を⽬指すためにHTML とCSS をどう組み合わせてコードを設計すればよいのか考えるようになります。

4.5 いいCSS を実現するCSS の設計

昨今ではOOCSS はじめさまざまなCSS 設計思想が存在します。OOCSS（Object Oriented CSS）とはCSS を設計する際にオブジェクト指向の概念を取り⼊れようとする考え⽅で、現在の数あるCSS 設計思想の基礎となったものです。これはページ全体をパーツごとに分けて考え、個々にユニークなclass を割り当てることから始まります（図4.5）。

これらのパーツをCSS オブジェクトと呼び、組み合わせることでページを組み⽴てます。前途の悪い書き⽅のひとつ、場所に依存した書き⽅を解消することができます。これがいいCSS を実現するためのベースとなる考え⽅です。

この考え⽅は昨今流⾏りのWeb・アプリデザインの考え⽅である、Atomic Designにとても似ています。

Atomic Design は、ページ全体〜細部という今までのデザインプロセスとは逆のアプローチで、コンポーネント毎の最⼩単位（元素:Atomic）を複数を組み合わせることでサイト全体のデザインを構築しようというものです。先ほどのOOCSS をベースとしたCSS設計思想と組み合わせることで、デザイン〜実装までスムーズな開発が可能になり、コンポーネントごとにデザインラフとコードを⼀元管理・流⽤が可能になります（図4.6）。

ページをデザインせずにコンポーネントシステムをデザインするこの考え⽅は、今までのWeb デザインとは⼀線を画すものです。

4.6 ではなぜBEM なのか

OOCSS から派⽣したCSS 設計思想は、SMACCS・MCSS・FLOCSS・RSCSS など多岐に渡りますが、その中でも、BEM（Block Element Modifier）はクラスの命名規則によってのみ要素の所属と属性を⽰すのが特徴です。モジュール全体を指すBlock、その中の⼦要素のElement、Block やElement の派⽣パターンであるModifier という三つの要素から成り⽴ちます（図4.7）。

図4.7 のカードコンポーネントcard というBlock のtitle、text など所属と機能がひとつのclass ですぐに判別できます。

図4.7、図4.8 のように、BEM の最⼤の利点は⼦要素からモディファイアまで、全てがシングルクラス指定になりながらもクラス名だけで親⼦関係が分かる点です。

親から最深のエレメントまで全てシングルクラス指定になるため、詳細度が⼀定になり、汚染されにくいCSS が簡単に実現します。そして、タグの種類にネストが依存しないため、マークアップの変更に柔軟に対応できます。

もうひとつは、SASS との相性の良さです。BEM の命名規則をSASS で表現すると、次のようになります。

Block〜Element、やModifire を& で繋げるだけで書くことができ、ネスト関係もよりわかりやすくなります。

そしてBEM のこれらの利点はプロジェクト規模を問わずに便利です。命名規則のみを制約とするため、⽇経ビジュアルデータコンテンツのようなスモールプロジェクトから、そこそこの規模のサイトまでカバーできる設計思想だと考えます。

クラスの命名規則のみでつくるルールは、コーディング初⼼者にもとっつきやすく、その縛りのおかげでDOM 構造の無駄なネストを減らす様に考える様になります。コーディングスキルレベルによらずにドキュメント構造が最適なものに統⼀されやすくなるのです。

4.7 コンテンツにあったアレンジ

⽇経ビジュアルデータコンテンツでは、このBEM に少しだけアレンジを加え、配置・要素・状態・装飾の概念にコンポーネントとレイアウトを司る要素を分けて考える構造になっています。

Layout（位置）

特定の⾒た⽬を持たず、これ⾃体がコンポーネントの親となり位置の属性を司る。記法はBEM のままですが、原則レイアウト関係のスタイルのみを指定します。

Element（要素）

レイアウトを司るスタイルは記述されず、⾒た⽬やコンポーネント内のパーツの位置のみ記述される。BEM でいうところのBlock に当たります。

Status（状態）

active、visible、hover などユーザーの操作で動的に切り替わる状態に⽤います。BEM のModifier からの派⽣したものです。

Modifier（装飾）

元となる要素のスタイルを継承しつつ、複数のバリエーションを管理するのに⽤いる。BEM のModifer とほぼ同義です。

読み物コンテンツ、ツールコンテンツ共に使われる要素⾃体はあまり変わりませんが、内容によってレイアウトは⼤きく変わります。そのため、レイアウトの⾃由度を上げるために、レイアウトとコンポーネントを専⽤クラスで分け、分離して考えられる様にすると同時に、既存のコードを積極的に流⽤できるようにしています。

スマートフォンではboxを縦積みに、タブレットサイズ以上でcontent__section内のboxを⾃由にレイアウトを変えられるような仕組みになっています。逆にcomponentsには位置に関わるスタイルはできる限り書かないように制限しています。こうすることで、components の中⾝を差し替えるだけで原稿が機能させられるDOM 構造にしています。

これはチーム内のコーディングスキルレベルの差異を埋めながら、品質を担保するのに⼤きな助けとなりました。

デザインチーム内での必死の布教活動により、無事浸透しつつあります。やったね。

BEM に限らず、CSS の設計は制約と誓約です。⾃由度が⾼いCSS という⾔語においてやらないことを決めるというのがもっとも重要なことです。そしてプロジェクト規模やチームのスキルレベルでも選択すべき設計思想は変わりますし、そのまま導⼊してもうまく回らないケースもあります。

うまく⾃分達に合った形にアレンジし、最適な制約を探すのが良さそうです。

当然私たち⽇経ビジュアルデータチームのCSS 設計思想も、⽇経ビジュアルデータのあり⽅やデザインの⽅向性が変われば、今後アップデートされていく可能性は⾼いでしょう。BEM でなく、他のものをベースに考える時もくるかもしれません。そのプロジェクトやチームの今いる状況に合わせて、柔軟に考える必要があると思います。

4.8 デザイナーがCSS を書く意味

かつては、ページデザインと実装する⼈間は分かれていたのが普通でしたが、その流れも終わりに近づいていると考えています。

CSS 設計を真剣に学ばなくても、CSS フレームワークに頼る⼿もあります。

しかし、⽇経ビジュアルデータのような⼩規模ページの場合、bootstrap やfoundationのような有名どころのフレームワークを使わないcss の⽅が多いほど⼤きく、使いづらい印象です。学習コストも無視できません。そしてコンテンツに最適な表現を突き詰めるとフレームワークでは巻き取れず再現しきれず、結局たくさん上書くことになります。⾃分が設計した⾒た⽬まで最短でたどり着くように書けるに越したことはないのです。

CSS はWeb の⾒た⽬の象徴です。視覚情報でユーザーとコミュニケートするWeb デザインにおいては、最後までデザインに責任をもつ意味でデザイナーが書くことはある程度必要だと僕は考えています。CSS は視覚情報、情報設計はデザイナーの仕事です。デザインと共にそれを実際に表⽰させるコードを管理できた⽅が、はるかに効率的ですよね。

4.9 おわりに

⾊々と書きましたが、なによりもDOM 要素の⾒た⽬をコントロールして柔軟な表現が可能なCSS が私は⼤好きなのです。デザイナーの⽅でまだ触ったことのない⽅、最初はどんなパワーコードでもいいので書いてみてください。DOM との組み合わせでさまざまな視覚表現がパズルのようにできて楽しいはずです。そしてぜひCSS について語らいましょう。

では、よいCSS（SASS）ライフを！

著者：安⽥翔平/ @nyasusho
デザインで⾷べてバイクで遊ぶ⼈。⽇経ビジュアルデータのコンテンツデザイン、UIデザイン担当してます。SCSS 依存症。

140年の歴史ある会社が、AIやデータを駆使した開発を現場で実践しています。是非疑問や感想を #nikkei_dev_book をつけてツイートしてください！

全章を一括して購入されたい方はこちらの記事をご購入ください。
https://note.mu/nikkei_staff/n/n44623c9b9ab4

この記事を購入すると、この下に第４章だけのダウンロードリンクが表示されます。