Privacy policy
Blog
ブログ一覧

ブログ

成長し続けるサイトのCSS設計にPRECSS

開発
2023.02.17 公開
#CSS#CSS設計
Yuko Hashimoto
Yuko Hashimoto デザイナー

機能やページがどんどん増え続けるWEBサイトのCSS設計はどうしたら良いんだ……と悩み続け試行錯誤し続けていますが、しばらくPRECSSを使ってみたら良かったよというご報告です。

PRECSSとは

日本語の公式サイトや経緯と概要をまとめたスライドもあるので、こちらを読んでいただいて……。

PRECSS公式サイト

CSSの新しい設計思想 PRECSSを作りました

BEMやFLOCSSと比べて、検索しても解説や感想が少ないです。あまり使ってる人がいないんでしょうか。

PRECSSとはどのような思想なのか-Qiita

PRECSSを使ってコーディングしてみた感想 | foolish-pine.com

サイトのページが増え続ける時に問題になること

OOCSS：用意していなかったクラスやバリエーションを増やしているうちに競合する、後付けのフレームワークとぶつかる

BEM：スタイルが増えるに従ってクラス名が長く伸びて行き、分類で混乱する

FLOCSS：ProjectとComponentの違いって何やねん！　ネストで組み合わせてるからとりあえずProjectに入れとこ！　そして増えて伸び続けるProjectクラス

特に複数人での作業でルールを決めていないともうごっちゃごちゃです。ルールを決めていてもその場で名前が増えていくと破綻待ったなし、ヤバい。

PRECSSで特に良かったところ

unique（接頭辞 un_）というグループに機能ごと・ページごとのクラスを作って混乱しない

FLOCSSやBEMでありがちな、一つのページだけで使うスタイルの命名に悩んだり、似たようなクラス名で混乱することが防げます。

トップページだけのスタイル、アカウント操作系のページだけのスタイル、一覧画面その1、一覧画面その2…と、スタイルがどんどん増えていく時に、最初から分けて命名しておくことで何とかしやすいです。

同じように見えて少し違うモジュールを使い回すためにプロパティの上書きに上書きを繰り返したり、モディファイアから更にモディファイアが増えて命名に悩む、といったことが少なくなります。

jsで動かす部分にjs_、状態管理のis_を付与して使いやすい

これはSMACSSっぽいですね！

接頭辞を固定しておくことで、後で探しやすかったり、命名を整理しやすいのもポイントだと思います。

接頭辞2文字ルールなので、独自の接頭辞を作って共存させやすい

制作中や運用中に要素が増えてきた時にこれが効きます！

などなど、グループを増やしやすく、そのグループ内で全ページ共通のブロック（bl_）やエレメント（el_）を使用しても混乱しにいです。

使用中のフレームワークのクラスとぶつかりにくい

接頭辞で分けているので、Bootstrapなどのクラスと被りません。

OOCSSだとよくある……。

キャメルケース＋スネークケースで見通しが良い、命名と分類に悩まない

同じような要素をPRECSSとFLOCSSで書いて比べるとこんな感じです。

<!-- PRECSS -->
<ul class="un_listPage_list un_listPage_list__large">
  <li class="un_listPage_listItem is_active">
    <div class="un_listPage_listImgWrap">
      <img src="img.svg" class="un_listPage_listImg">
    </div>
    <p class="un_listPage_listTxt el_txt hp_fontRed">テキスト</p>
  </li>
</ul>
<!-- /.un_listPage_list -->

<!-- FLOCSS -->
<ul class="p-list-page-list p-list-page-list--large">
  <li class="p-list-page-list-item p-list-page-list-item--active">
    <div class="p-list-page-list-image-wrapper p-list-page-list-image-wrapper--list-active">
      <img src="img.svg" class="p-list-page-list-image">
    </div>
    <p class="p-list-page-list-text c-text u-font-color--red">テキスト</p>
  </li>
</ul>

分類がハイフンでつながっているのではなく、キャメルケースでまとまっているので目で探しやすいです。モディファイアもめんどくさそうな時は状態管理クラスにしちゃう。

そして「特定のブロック内でスタイルがちょっと変わるボタン」はProjectとComponentとどっちやねんネスト深くなりすぎても困るしウワーッ！！！と命名時に悩まずに済むのが何より大きいです。

というか上の例でも、FLOCSSは p-list-page-list-text とかわけわかんないことになってますね。同じリストでも一覧ページとそれ以外で出し分けるんや！　ページ名を先頭につけるぞ！　とかやってたらありがち。

ヘルパーの使い所がなんかしっくり来ない

ヘルパー（hp_）がうまく使えないというか、組み合わせていくとあまり美しくないなぁという気が。importantもあまり使いたくないですし……。OOCSSほどスッキリしないのは何だろう？　気持ちの問題な気もしますが……。

なるべく要素ごとに命名してそれぞれにプロパティを持たせるか、モディファイアで分けたいなと思うようになりました。

Angularだとどうなの？

弊社でよく利用するAngularは、CSSをGlobal・Shared・Componentで分けています。

リセットCSSとフレームワークのCSSをGlobalで、変数ファイルやmixinと一部共通部分をSharedにして、それぞれのComponent CSSに必要な Shared CSSを読み込んで作ればスッキリなのでBEMで良さそう…

なんですが、コンポーネントの組み合わせごとのマージン調整をしたいとか、画面ごとに子コンポーネント・孫コンポーネントを使いまわしつつスタイルを変えたいとかでカプセル化を解除した時にクラス名がぶつかることがあります。

また、OOCSSで用意してHTMLを書き換えることでスタイルを変える場合、プログラマとの連携がうまく行かないと思いがけない場所で破綻することもあります。

サイト規模がある程度大きくさらに増え続ける時、クラス名から修正箇所を探したり、新しく命名する時にも迷わないよう、何か接頭辞があればベターかなと思います。

ちょっと命名が長くなりますが、AngularでもPRECSSを候補に考えて良さそうです。

どんなCSS設計が最適なのか考え続けよう

既存のCSS設計から自分が使いやすいようにアレンジして公開している記事もたまに見かけます。自分のチームが頻繁に作るサイトの規模や性質から使いやすいようアレンジを考えても良さそうです。

PRECSSは独自の2文字接頭辞を作れるので元々アレンジしやすいですが、何か他にも良いアレンジがあるかも？　PRECSSを使用した方の記事が増えると良いなあと持っています。

Yuko Hashimoto

Yuko Hashimoto

デザイナー

虚弱と加齢の狭間でよれよれになりながら、使いやすいデザインについて日々ボンヤリと考えています。 手芸、園芸、寺社仏閣や博物館が好きです。 通信制大学を始めました。

ブログ一覧へ