一昨日、「FLOCSSがわかりにくい」「Atomic Designの思想でフレームワークを作ってみたい」という記事を書いたところ、とてもたくさんの感想をいただきました。
【Webdesign】Atomic Designの思想で、文系でもわかるCSSフレームワークを作りたい | ウェビンブログ
大半がフロントエンドエンジニアからの突っ込みです。著名な方々にもたくさん意見をいただいただのでまとめました。ありがとうございます。
「Atomic Designの思想で、文系でもわかるCSSフレームワークを作りたい」に識者たちの鋭すぎる突っ込みが入る – Togetterまとめ
Atomic DesignがCSS設計に適していない理由
ピクセルグリッドの高津戸さんによると、そもそもAtomic DesignはCSSやJSの設計とは全く関係ない
そうですが、よく考えてみると、たしかに厳密な階層構造を持っているAtomic Designの設計は、デザインレベルからの意思統一が可能な環境でなければ破綻してしまいます。
私はデザインを外部に発注することが多いですし、CMSベースで構築すると、どうしてもマークアップやクラスの命名に手を出せない箇所が出てきます(※)。
そんなこんなで、Atomic Designを採用することは諦めて、既存のCSS設計を、専門のマークアップエンジニアではなくても理解しやすくする方向で考え直すことにしました。
FLOCSSについて
皆さんの指摘を受けて改めて見直してみると、FLOCSSのディレクトリ構造は実に柔軟です。
ウェブサイトは改修を繰り返すほど「モジュール」にあたる独立パーツが多くなってしまいますが、FLOCSSでは「object」という曖昧なディレクトリの下に複数の下層ディレクトリを配置する構造なので、ディレクトリ内がSCSSファイルだらけになるという事態は抑止できます。
また、あくまで設計方針であるため、objectディレクトリの下層は増えても減ってもいいようです。
ディレクトリ名が英語に慣れていないと難解になる件については、やはりドキュメントの共有しかないわけで
- SCSSファイルの冒頭に、コメントで日本語ドキュメントへのリンクを記載する
- 中見出しコメントに、そのグループの役割を日本語で記載する
- 見やすく探しやすいスタイルガイドを添付する
という基本的なことになってきそうです。
c-とかp-とかu-の件
FLOCSSの接頭辞が不満なのは、感覚的な部分を覗いては以下の理由からです。FLOCSSのディレクトリ構造を使うにしても、やはり避けたいと考えています。
- 再利用性の低下
- サイトによってprojectがcomponentに変更される場合はありえ、その場合HTMLとCSS両方の修正が必要になる
- HTML構造との乖離
- 各要素がどの分野に属しているかをHTML側で知ることができないため、クラスに接頭辞を付与する実用的な意味が薄れる
状態クラスのみ接頭辞がつかないという例外も、どうも納得がいきません。
SMACSSとBEM
今の私のコーディングは、各ブロックを起点とした、SMACSSに近いものとなっています(今見ているサイトは4年前に作ったので参考にしないでください…)。これはCMSのテーマ設計との相性が良く、長年使ってきました。
しかし、クラス名の接続がすべてハイフンだと、子要素・バージョン・状態の切り分けがわかりづらいというのが最近の不満でした。
そうなるとBEMですが、とにかくクラス名が冗長です。
いろいろ調べた結果としては、BEMの命名規則から状態のみを分離した、MindBEMdingが私にはしっくり来るかなと思っています。この法則だと、現在のマークアップからの移行コストも低くなりそうです。
なお、Drupal8はコーディングガイドラインにSMACSSを採用しているそうです。こちらもきちんと読み込まなくては…
CSS | Coding standards | Drupal.org
CMS特有の問題
現実面として、何が入るかわからない・素人がコーディングに介入する箇所が多いCMSでは、完全にOOCSSに従うのは難しくなっています。典型的なのが「本文内にh2やh3やulをクラスなしで書けてしまう問題」です。
最新のコーディングでは、やや強引な方向ですがこのような感じになっています。CMSの自由文に当たる箇所には.entry-columnで包括し、かつその中で「クラスを指定していない要素」は自動装飾されるようにしています。
HTML
<div class="post-contents entry-column"> <h2>ウィジウィグで書いた見出し</h2> </div>
CSS
.entry-column h2:not([class]) { /* 自由分の見出しの装飾 */ }
.entry-columnはa-blog cms公式テーマの影響なので、もっと汎用的な命名を探したいところです。また、これだと「jQueryのライブラリ依存のクラスをつけるとスタイルが切れる問題」(スーパーレアケースですが)がまだあります。
まとまりがなくなってきたのでこの辺にして、資料を読みつつ手を動かそうと思います。
この仕事を長く続けるほど「英語が読めない」というのが課題になってきています。検索を英語でもしてみる習慣をつけたほうが良さそうです。
※余談になりますが、私がWordPressよりもMovable Typeやa-blog cmsを重視しているのは、マークアップの自由度(=テーマ製作者への依存度)が高く、受注案件でもコーディングの統制が取りやすいからです。これらは、WordPressのような外部プラグイン(制御が難しいHTMLを出力する)への依存が少ないことが背景としてあります。