2023年04月19日
【それでもCSSは破綻する】 CSSの設計手法と書き方を考える
はじめに
それでもCSSは破綻する。書くこと自体はとても簡単なCSSですが、その一方で、CSSの設計が簡単に破綻してしまいます。破綻しないためにCSSの設計手法と書き方のノウハウをご紹介できればと思います。
以前の記事とかぶるとこも結構あるのですが、全体的にまとまっているので特に初心者〜中級者の方に見てもらえたら嬉しいです。
CSSは簡単!CSSできる!って言っている人はだいたいうそ
これは極端な言い方ですが、今まであったデザイナーでCSSできると言った人で本当にできる人あまりいないです。
どちらかというとCSSは難しいと言った人の方ができる方が多いです。
CSSを書くこと自体は簡単
CSSが簡単だと思われてしまう要因の一つがCSSを書くこと自体は言語としてはかなり簡単な部類に入ります。
p{
color: #f00;
}
このようなコードをツラツラ書いていけばHTMLに対してスタイルをつけられますよね。
書き方としてはごくごくシンプルです。シンプルであるがゆえに管理するのが難しいのです。
前置きはこれくらいにしてここから先はCSSがいかに難しいことについて触れていきたいと思います。
CSSは破綻しやすい
何が難しいかと言うと一つだけです。そう「破綻」しやすいんです。
では、「**CSSの破綻**」とはなんでしょう?
例えば
「新しくスタイルを書いたのに適用されない」とか
「!importantが乱用されている」とか
が挙げられます。
破綻というとなかなか難しいですが、複数人で複数人で同じCSSファイルを編集していると起こりやすいです。
具体的には・・・
同じようなコードが複数箇所ある場合がある
似たようなコードもしくは同じコードが重複してしまっている状態。
セレクタ名が被りやすい
セレクタ名が同じものが乱立している状態。
スタイルの詳細度問題
上記を解消するために詳細度を深くしてなんとかスタイルを割り当てている状態だったり「!important」を乱用している状態。
上記のようなことが起きているようなCSSのコードは完全に破綻しています。
良いCSSのコードとは
では**「破綻のしない」良いCSSのコード**ってどんなのなんでしょう。よく言われるのが・・・
- 予測しやすい
- 再利用しやすい
- 保守しやすい
- 拡張しやすい
予測しやすい
セレクタ名には.aとか.cなど自分だけがわかるものは基本NGです。あとは、クラスセレクタに日付が書いてあったり、「new」とか書いてあるのが見かけることがあります。もうこれは末期ですね。おそらく破綻してます。
例えばタイトルならば.title、バナーを配置する場所なら.banner-areaなどクラス名を見ただけでなんとなくどんな使い方がされているかわかるものがいいです。
再利用しやすい
サイト内のどこに配置しても大丈夫なように作られている方がいいでしょう
保守しやすい
詳細度と関連してくるのですが、詳細度を深くしすぎるとのちのちスタイルの上書きする際に困ります。
拡張しやすい
例えばタイトルであれば、文字の大きさの違うパターンや色違いパターンなどが作りやすい方がいいです。
CSSを書く上で気をつけるべきこと
ポイントは5つあります。一つずつご紹介します。
CSSのプロパティはまとめられるものはまとめる
まとめられるものがあるならばまとめた方がいいですね。ファイルサイズ節約にもなります。
運用の時に付け足す時もそっとまとめてあげるといいですよね!!
//Bad
h1 {
padding-bottom: 2em;
padding-left: 1em;
padding-right: 1em;
padding-top: 0;
}
// Good
h1 {
padding: 0 1em 2em;
}
意味のないセレクタ、スタイルは作らない
下記のコードは実際に僕が出くわしたコードです。見た時正直びっくりしました。以前担当していた方が書いたんでしょうけど、同じスタイルじゃん・・・。なんでこうなったかは理解に苦しむんですが、これもクラス一個で各ページ使い回せばいいだけですよね。
// Bad
.regist .error p{
color: #f73265;
font-weight: bold;
font-size: 13px;
margin: 8px 0;
padding-bottom: 3px;
border-bottom: 2px solid #f73265;
}
.memberinfo #main .error-message{
color: #f73265;
font-weight: bold;
font-size: 13px;
margin: 8px 0;
padding-bottom: 3px;
border-bottom: 2px solid #f73265;
}
// Good
.error-message{
color: #f73265;
font-weight: bold;
font-size: 13px;
margin: 8px 0;
padding-bottom: 3px;
border-bottom: 2px solid #f73265;
}
マークアップが変わっても問題のないセレクタにする
idセレクタ、クラスセレクタ、タイプセレクタと異なるセレクタが混在していると、マークアップが変わった時に対応ができません。
// Bad
#hoge .menu ul{}
#hoge .menu ul li{}
// Good
.menu{}
.menu__item{}
こちらはBEMという書き方をしていますが、後ほど詳しくご紹介します。
余計なタイプセレクタは使わない
下記の「Bad」のやり方はわかりやすいっちゃわかりやすいんですが、再利用性に欠けます。というのもh1にしか使えないので、たとえば、マークアップ的にh2の方が適切の場合はスタイルを適用できないですね。
// Bad
h1.title{}
// Good
.title{}
親要素のセレクタに依存したセレクタにしない
cssのテクニックとして「body」タグにクラスをつけてコンテンツのスタイルをページごとに変更したりします。でもこれって「body」タグにクラスに依存しすぎてしまっていて再利用しづらいし、拡張もしにくいですよね。
たとえば、デフォルトのヘッダーとメニュー詳細ページでヘッダーのスタイルを変更したい場合、以下のような書き方をします。でもこれって、運用していくなかで新しくページを追加して(LPとかね)詳細ページと同じヘッダーでって場合どうしますか?
パターンとしてはdetailと同じスタイルをLP用につくるか、LPのbodyにdetailを付与ですよね?
後者の場合ってめちゃくちゃ気持ち悪いですよね。detailページでもないのにbodyにdetailって・・・
// Bad
.header{
width: 100%;
background: #000;
}
.detail .header{
width: 100%;
background: #fff;
}
.lp .header{
width: 100%;
background: #fff;
}
// or
.detail .header, .lp .header{
width: 100%;
background: #fff;
}
このパターンでCSSを書くとページが増える度にセレクタを書き加えなければいけませんね。
これをBEMでセレクタを書くとめっちゃわかりやすくなります!!ポイントはページ単位で切り分けないでプロパティごとに切り分けた方がいいかなと思います。
// Good
.header{
width: 100%;
background: #000;
}
.header--bg-white{
background: #fff;
}
それでもCSSは破綻する
これまでのことを気をつけても更新作業などをしていればほぼ100%破綻します
次に紹介するのは**CSSの設計**です。自由に書けるCSSだからこそルールを設けてみんなで守りましょうというものです。
CSS設計の手法
実はCSS設計の手法ってたくさん存在しています。それぞれ特徴があったりしますが基本的な考え方としては**破綻のしにくいCSSのコード**を書きましょうというのは変わりません。
自分のやりやすいものやそのWEBサイトにあったものを選ぶのがいいと思います。今回は「**FLOCSS**と**BEM**」をご紹介します。
FLOCSSとBEMのCSS設計
FLOCSSというのは、日本人が考えたCSSの設計手法です。実は、「Web制作者のためのCSS設計の教科書 モダンWeb開発に欠かせない「修正しやすいCSS」の設計手法」という本を書いた谷さんという方が考えたものです。
BEMは、セレクタの書き方の考え方です。賛否両論ありますが、HTMLのタグを見ただけでどんなスタイルかわかりやすいというメリットがあります。
デメリットとしてはセレクタが長くなりがちです。
ディレクトリ構成
まずはFLOCSSの基本としてサイトのCSSディレクトリの中身を分けます。これで、どこにどんなスタイルを書くかわかりやすくなりますね。
ちなみに、今回はSassを使っている想定にしています。これはなぜかと言うと`import`する際にCSSの場合
@import url('foundation/base.css');
@import url('foundation/reset.css');
・・・
と言うように書くのですが、このimport文だとサイトの読み込みに時間がかかってしまうんですね。そこでSassを使うと実際にページに読み込まれる時にはいimportし終わっていて一つにまとめられたCSSファイルが生成することができます。importの書き方は
@import "foundation/base";
@import "foundation/header";
・・・
と言うようにできます。Sassを使う方がメリットもたくさんあるので興味のある方はぜひ使ってみてください。
横道にずれてしまいましたが、ディレクトリの構成は以下のようになります。
├── foundation
│ └── base.scss
│ └── reset.scss
├── layout
├── object
│ ├── component
│ ├── project
│ └── utility
└── app.css
foundationとは
ここはbase.scssやreset.scssなどサイト全体の下地になる部分を書きます。
layoutとは
ここはサイトの基本レイアウトを書く場所です。例えばheaderやfooterなど
objectとは
ここではサイト全体で再利用性の高いスタイルを書きます。
component
componentは再利用性の高いパーツを書く場所です。特徴としてはどんなサイトでも大概あるパーツを書くことが多いです。
例えば、ボタンスタイル、タブスタイル、見出しスタイルなど
project
projectも再利用性の高いパーツを書く場所なんですが、componentととの違いは、このサイト特有のパーツの場合はここに書きます。
例えば、グラフスタイル、ドロップゾーンなど
utility
ここはいつでもどこでも使えるスタイルです。基本的には1セレクタに1プロパティになることが多いです。
.u-mb-8{
margin-bottom: 8px;
}
.u-pt-16 {
padding-top: 16px;
}
app.scss
app.scss内に各ファイルをimportします。
@import "foundation/base";
@import "foundation/header";
・・・
接頭辞
FLOCSSではなんの属性なのかHTMLのコードを見ただけですぐにわかるように接頭辞をつけることを義務付けしています。
どこのディレクトリにあるか表す接頭辞
.l- // layout
.c- // component
.p- // project
.u- // utility
状態を表す接頭辞
こちらはjQueryなどと併用する時によく使われます。例えばボタンを押すと出てくるUIなどは.is-showなどのクラスセレクタをつけたりします。
.js-はjs(jQuery)と関わっているのか表す接頭辞です。
.is-
.js-
これはJSで動くなど何かしら操作したときなどにセレクタで呼び出しますが、その際はスタイルで定義されたセレクタを使うのではなく必ず「.js-hoge」などで行うことを義務付けします。そうすることで文書構造、スタイル、スクリプトを完全に分離することができてHTMLを見るだけで何が行われているのか、残さなければいけないセレクタなのかわかりやすくなります。
<div class="c-drawer">
<button class="c-drawer__btn js-drawer-btn">開く</div>
<div class="c-drawer__content is-open">
// 内容
</div>
</div>
セレクタについて
基本的にクラスを使う
idセレクタとクラスセレクタが基本的にはよく使われるセレクタですが、idセレクタはあまり使わない方がいいです。実はidセレクタには問題点があります。
idセレクタの問題点
- 詳細度が強すぎる
- 1ページに一回しか使えない
というのも詳細度と関連してくるのですが、基本的にidセレクタは詳細度がかなり強いです。なので、スタイルを上書きしなければいけない場合にどうしてもそれ以上の詳細度にしなければいけません。さらに、1ページに一回しか使えないので、再利用性にかけます。
書き方はBEM
先ほどのdrawerのコードであまり見かけないセレクタの書き方がありました。これが実はBEMの書き方です。
そしてBEMのセレクタの書き方には3つの要素でできています。その頭文字をとってBEMと言います。
Block
これはdrawerなどのパーツなどの塊を表します。FLOCSSではこのBlockごとにCSSのファイルを書いていくのがいいでしょう。
Element
これはBlock内に存在する要素を表します。drawerで言えばボタンやコンテンツですね。
Modifier
これは状態を表します。例えば、背景の色が違うパターンなど
注意!.is-や.js-とは使い方が違います。
.c-drawer--right {
}
.c-drawer--left {
}
BlockとElementのつなぎ方
セレクタでBlockとElementのつなぐ方法はアンダースコアを二つつけます。
Block or ElementとModifierを繋ぐ
Modifierの前にハイフンを二つつけます。
BEMの失敗パターン
先ほどもご紹介したようにBEMのデメリットはセレクタが長くなりすぎます。
<ul class="menu">
<li class="menu__item">
<a class="menu__item__content" href="#">
<h3 class="menu__item__content__title menu__item__content__title--red">タイトル</h3>
<div class="menu__item__content__thumb"><img src="hoge.png" alt=""></div>
<div class="menu__item__content__meta">
<span class="menu__item__content__meta__date">2015/12/31</span>
</div>
</a>
</li>
</ul>
.menu{}
.menu__item{}
.menu__item__content{}
.menu__item__content__thumb{}
.menu__item__content__title{}
.menu__item__content__title--red{}
.menu__item__content__meta{}
.menu__item__content__meta__date{}
こういったケースが頻発するのでcomponentを小分けしていくといいです。そうすると小さい単位のcomponentごとに各componentを組み合わせて使いまわすことが可能になります。
// menu.css
.menu{}
.menu__item{}
// media.css
.media{}
.media__title{}
.media__title--red{}
.media__thumb{}
// meta.css
.meta{}
.meta__date{}
<ul class="menu">
<li class="menu__item">
<a class="media" href="#">
<h3 class="media__title media__title--red">タイトル</h3>
<div class="media__thumb"><img src="hoge.png" alt=""></div>
<div class="meta">
<span class="meta__date">2015/12/31</span>
</div>
</a>
</li>
</ul>
それでもCSSは破綻する
ここまでやっても**CSSは破綻**します。そうですねこれでも80%以上の確率で破綻します。複数人いる場合には特に!!
ガイドライン
そのサイトやサービスに置けるルールを記します。
記載する内容は作る人や企業によってまちまちですが、基本的なものとしては
- 対応ブラウザについて
- クラスセレクタの書き方(BEMであればセパレートはアンダースコアなのかとか)
- 禁止事項など
スタイルガイド
よく使われるcomponentに関してはコードをまとめておくといいです。
下記のは僕が作ったフレームワークのものですが、なんとなくの雰囲気はつかめるかなと思います。
[Document](http://takumi0901.github.io/flanky/)
ここまでやってやっと破綻のしにくいCSSになる
あくまで「しにくい」です。せっかく作ったガイドラインを無視したりする人がいれば「破綻」します。大体の企業では何かサービス作るにあたってあらかじめガイドラインが設けられていることが多いです。なので、そのサービスに途中から参加する場合などはガイドラインを読み込み、実際のCSSコードを追って理解を深めるのがいいと思います。
この記事をシェアする
お気軽にご相談ください
会社のホームページが欲しい!名刺がわりになるコーポレートサイトが欲しい!などお気軽にご相談ください。
またパートナー企業をお探しの制作会社様や、フロントエンド開発もご連絡お待ちしております。
最近の投稿
Jamstack開発の下請けをお探しですか?ブラキオがあなたの強力なパートナーに
Web制作の世界は常に進化しており、新しい技術が次々と登場しています。その中でもJamstackは、より高速でセキュア、そしてスケーラブルなウェブサイトを実現するための革新的なアプローチとして注目を集めています。しかし、新技術の導入は不安や挑戦を伴うもの。そんな時、ブラキオがパートナーとして、皆さんのJamstackにおける挑戦を全力でサポートします。ブラキオは、フロントエンド開発における豊富な実績を持ち、Jamstack開発においても皆さんをテックリードとして支援できます。コーポレートサイトからwebサービスまで、あらゆるフロントエンド開発のお手伝いをします。また、コーディングだけのお仕事も大歓迎です。プロジェクトの成功は、良いコミュニケーションから始まります。ZoomでのオンラインMTGや、Slackなどのチャットツールを通じて、いつでも柔軟に対応させていただきます。まずはお問合せいただければ、お見積もりを含め、具体的なご提案をさせていただきます。Jamstackでのウェブサイト制作は、多くの可能性を秘めています。ブラキオと一緒に、新たな挑戦に踏み出しませんか?あなたのビジョンを現実のものとするために、全力でサポートさせていただきます。
2024.04.10
Next.jsにおけるページ内スクロールの実装ガイド
Next.jsを使用したウェブサイトで、ページ内スクロールを実現したいと思ったことはありませんか?例えば、ウェブサイトのナビゲーションバーに「SERVICE」や「ABOUT」のようなリンクがあり、ユーザーがそれらをクリックすると、ページ内の対応するセクションに自動的にスクロールするといった機能です。弊社の上部にあるメニューがこのページ内スクロールを実装しています。よろしければ試してみてくださいね。まずは、実際に試してみて、その振る舞いを体験してみましょう。このような機能を簡単に実装するためには、というライブラリを利用するのがおすすめです。まずは以下のコマンドでインストールしましょう。そして、以下のように呼び出して使用します。ここでのimport文では、という形でエイリアスを設定しています。これは、という名前がNext.jsの と名前が重複してしまい、混乱を避けるためです。そして、メニューリンクからスクロールさせたい要素への移動を設定するために、その要素にのようなIDを指定します。これにより、ページ内スクロールを簡単に実装することが可能となります。以上がNext.jsでのページ内スクロール実装の基本的な手順です。この方法を試して、ウェブサイトのナビゲーション体験をより良いものにしましょう。
2023.05.14
なぜJamstackでWEB制作の仕事を受けようと思ったのか
私自身もともとWordPressでweb制作の仕事を受けていた。プラグイン依存、CSS設計問題、サーバー代などのコスト面 etc。賛否両論あると思うけど、個人的にはしんどかった。また、業務委託先でReactでサービス開発をずっとやっているのでJamstackでできたらと思っていた。なので、趣味でGatsbyやったりNetlifyCMSやったりして試していたりはしたが、趣味では良いけどクライアントに納品するものとしてと考えると難しいなという印象だった。特に基本が英語なので、どうしても敷居が高くなってしまう。あとはリテラシーが高くないと無理かなとも率直に思った感じ。Jamstackを実際の案件でやりたいけど二の足を踏んでいたという状態だった。そうこうしているうちにmicroCMSの存在を知って「あ、これなら案件でいける」と思い、実際の案件に投入することに決めた。なぜJamstackでWEB制作の仕事を受けようと思ったのかは「microCMS」が比重を多く占めるのだけれど、Jamstack案件をここ数ヶ月で立て続けに3サイト作ったので実際の業務でやったプラクティス的なことをまとめる。フロントエンドエンジニア御用達のprettier、eslint、TypeScriptが使えるの最高。ReactやVueでサービス開発をしたことある人なら問題なくJamstackいける。これはかなりの利点だと思っていて、ある程度フロントをかじった人ならweb制作で受注をして稼ぐことが容易になったと思う。firebase, Amplifyなどがあるけど迷うならNetlifyで良い。デプロイの設定が楽だし迷うこともない。また、お問合せが簡単に作れるのも魅力。ちなみに、firebaseでお問合せを作ろうと思うとCloud Functionsに書かなければいかず有料になってしまう。Amplifyもそんな感じかな??やったことないからわからない。例えばDBに溜め込むとかしたいならfirebaseを選ぶけど、一般的な中小企業のコーポレートサイトならほぼほぼNetlifyで良い。またそういったコーポレートサイトであれば無料で済む。ただ、泣きどころはTokyoリージョンがNetlifyにないため若干遅い。これはゆくゆくは解決されるのではと思っているけど・・・。デプロイの可否をSlackに通知できたり、お問合せがあったらなど各種連携が取りやすいので運用フェーズに入った時に絶対に必要になるから必ず設定すべし2021/01/14 追記どうやら以前の価格改定により無料枠ではSlackやメールなどの通知ができなくなっている。ちなみに、無料枠である私のアカウントはできる。もしかしたら改訂前にアカウント持っていた場合は通知ができるのかもしれない。アカウント持っている方はホスティングしたサイトを選択 > Site settings > Build & Deploy > ページ下部のDeploy notifications > Add notification で確認した方が良い。notificationができるのであれば下記のように選べるようになっている。もし今後アカウントを取得してNetlifyで通知したい場合は「pro」にしなければならない。microCMSのまわし者みたいだけど、まじでmicroCMSが今のところ一番良い日本語だし、UIも日本人にわかりやすく受け入れられやすいどのクライアントにも言われたけど「記事作成したんだけどプレビューできないんですか?」そんなに難しいことをせずに実装できるので絶対に入れるべし`[https://your-service-name.netlify.app/draft/?id={CONTENT_ID}&draftKey={DRAFT_KEY}](https://your-service-name.netlify.app/draft/?id=%7BCONTENT_ID%7D&draftKey=%7BDRAFT_KEY%7D)` を叩くプレビュー用のページがあれば良いだけ。APIのエンドポイントごとの設定なので注意すべしこれやっておかないと「記事更新したのにサイトに反映されてないんですけど!」と連絡来てしまう。私はNextJSでしか開発をしていないが多少の知識があれば満点ないしかなりの高得点は簡単に出る基本的にはlighthouseで採点 > 注意されたとこを直すフローで良いが、service-workerに関してはプラグインを入れればすぐに解決できてオフラインでも閲覧できるようになる。あとは、やはり画像は重いことが多いので、画像サイズには注意する必要がある。画面いっぱいまで画像を広げたい時などは、簡単に済ますなら画質をある程度落としてしまうし、もしくはsrcset属性を使って最適化するように心がける。また、[TinyPNG](https://tinypng.com/)などを使って圧縮もするようにする。これはstg/prdで分けて開発をしにくい点にあると思う。プレビュー機能の実装である程度は補えるとしても、開発者としてはstgは欲しいなと思う。graphcmsではenvironment-endpointsとして `master` と `dev` でエンドポイントのだしわけが可能なよう。が、残念ながら思いっきり英語なので実務では難しい。(microCMSさんお願い!!!)## 個人的に今後やっていきたいこと今後は案件をもっと獲得できるようにするつもり。また、それに合わせて外注も増やさざるをえないかなと思っていて、外注しても一定の品質が保てるようにしたいので開発フローの整備等をしていきたい。
2023.04.20
【それでもCSSは破綻する】 CSSの設計手法と書き方を考える
それでもCSSは破綻する。書くこと自体はとても簡単なCSSですが、その一方で、CSSの設計が簡単に破綻してしまいます。破綻しないためにCSSの設計手法と書き方のノウハウをご紹介できればと思います。以前の記事とかぶるとこも結構あるのですが、全体的にまとまっているので特に初心者〜中級者の方に見てもらえたら嬉しいです。これは極端な言い方ですが、今まであったデザイナーでCSSできると言った人で本当にできる人あまりいないです。どちらかというとCSSは難しいと言った人の方ができる方が多いです。CSSが簡単だと思われてしまう要因の一つがCSSを書くこと自体は言語としてはかなり簡単な部類に入ります。このようなコードをツラツラ書いていけばHTMLに対してスタイルをつけられますよね。書き方としてはごくごくシンプルです。シンプルであるがゆえに管理するのが難しいのです。前置きはこれくらいにしてここから先はCSSがいかに難しいことについて触れていきたいと思います。何が難しいかと言うと一つだけです。そう「破綻」しやすいんです。では、「**CSSの破綻**」とはなんでしょう?例えば「新しくスタイルを書いたのに適用されない」とか「!importantが乱用されている」とかが挙げられます。破綻というとなかなか難しいですが、複数人で複数人で同じCSSファイルを編集していると起こりやすいです。具体的には・・・似たようなコードもしくは同じコードが重複してしまっている状態。セレクタ名が同じものが乱立している状態。上記を解消するために詳細度を深くしてなんとかスタイルを割り当てている状態だったり「!important」を乱用している状態。上記のようなことが起きているようなCSSのコードは完全に破綻しています。では**「破綻のしない」良いCSSのコード**ってどんなのなんでしょう。よく言われるのが・・・セレクタ名には.aとか.cなど自分だけがわかるものは基本NGです。あとは、クラスセレクタに日付が書いてあったり、「new」とか書いてあるのが見かけることがあります。もうこれは末期ですね。おそらく破綻してます。例えばタイトルならば.title、バナーを配置する場所なら.banner-areaなどクラス名を見ただけでなんとなくどんな使い方がされているかわかるものがいいです。サイト内のどこに配置しても大丈夫なように作られている方がいいでしょう詳細度と関連してくるのですが、詳細度を深くしすぎるとのちのちスタイルの上書きする際に困ります。例えばタイトルであれば、文字の大きさの違うパターンや色違いパターンなどが作りやすい方がいいです。ポイントは5つあります。一つずつご紹介します。まとめられるものがあるならばまとめた方がいいですね。ファイルサイズ節約にもなります。運用の時に付け足す時もそっとまとめてあげるといいですよね!!下記のコードは実際に僕が出くわしたコードです。見た時正直びっくりしました。以前担当していた方が書いたんでしょうけど、同じスタイルじゃん・・・。なんでこうなったかは理解に苦しむんですが、これもクラス一個で各ページ使い回せばいいだけですよね。idセレクタ、クラスセレクタ、タイプセレクタと異なるセレクタが混在していると、マークアップが変わった時に対応ができません。こちらはBEMという書き方をしていますが、後ほど詳しくご紹介します。下記の「Bad」のやり方はわかりやすいっちゃわかりやすいんですが、再利用性に欠けます。というのもh1にしか使えないので、たとえば、マークアップ的にh2の方が適切の場合はスタイルを適用できないですね。cssのテクニックとして「body」タグにクラスをつけてコンテンツのスタイルをページごとに変更したりします。でもこれって「body」タグにクラスに依存しすぎてしまっていて再利用しづらいし、拡張もしにくいですよね。たとえば、デフォルトのヘッダーとメニュー詳細ページでヘッダーのスタイルを変更したい場合、以下のような書き方をします。でもこれって、運用していくなかで新しくページを追加して(LPとかね)詳細ページと同じヘッダーでって場合どうしますか?パターンとしてはdetailと同じスタイルをLP用につくるか、LPのbodyにdetailを付与ですよね?後者の場合ってめちゃくちゃ気持ち悪いですよね。detailページでもないのにbodyにdetailって・・・このパターンでCSSを書くとページが増える度にセレクタを書き加えなければいけませんね。これをBEMでセレクタを書くとめっちゃわかりやすくなります!!ポイントはページ単位で切り分けないでプロパティごとに切り分けた方がいいかなと思います。これまでのことを気をつけても更新作業などをしていればほぼ100%破綻します次に紹介するのは**CSSの設計**です。自由に書けるCSSだからこそルールを設けてみんなで守りましょうというものです。実はCSS設計の手法ってたくさん存在しています。それぞれ特徴があったりしますが基本的な考え方としては**破綻のしにくいCSSのコード**を書きましょうというのは変わりません。自分のやりやすいものやそのWEBサイトにあったものを選ぶのがいいと思います。今回は「**FLOCSS**と**BEM**」をご紹介します。FLOCSSというのは、日本人が考えたCSSの設計手法です。実は、「」という本を書いた谷さんという方が考えたものです。BEMは、セレクタの書き方の考え方です。賛否両論ありますが、HTMLのタグを見ただけでどんなスタイルかわかりやすいというメリットがあります。デメリットとしてはセレクタが長くなりがちです。まずはFLOCSSの基本としてサイトのCSSディレクトリの中身を分けます。これで、どこにどんなスタイルを書くかわかりやすくなりますね。ちなみに、今回はSassを使っている想定にしています。これはなぜかと言うと`import`する際にCSSの場合と言うように書くのですが、このimport文だとサイトの読み込みに時間がかかってしまうんですね。そこでSassを使うと実際にページに読み込まれる時にはいimportし終わっていて一つにまとめられたCSSファイルが生成することができます。importの書き方はと言うようにできます。Sassを使う方がメリットもたくさんあるので興味のある方はぜひ使ってみてください。横道にずれてしまいましたが、ディレクトリの構成は以下のようになります。ここはbase.scssやreset.scssなどサイト全体の下地になる部分を書きます。ここはサイトの基本レイアウトを書く場所です。例えばheaderやfooterなどここではサイト全体で再利用性の高いスタイルを書きます。componentは再利用性の高いパーツを書く場所です。特徴としてはどんなサイトでも大概あるパーツを書くことが多いです。例えば、ボタンスタイル、タブスタイル、見出しスタイルなどprojectも再利用性の高いパーツを書く場所なんですが、componentととの違いは、このサイト特有のパーツの場合はここに書きます。例えば、グラフスタイル、ドロップゾーンなどここはいつでもどこでも使えるスタイルです。基本的には1セレクタに1プロパティになることが多いです。app.scss内に各ファイルをimportします。FLOCSSではなんの属性なのかHTMLのコードを見ただけですぐにわかるように接頭辞をつけることを義務付けしています。こちらはjQueryなどと併用する時によく使われます。例えばボタンを押すと出てくるUIなどは.is-showなどのクラスセレクタをつけたりします。.js-はjs(jQuery)と関わっているのか表す接頭辞です。これはJSで動くなど何かしら操作したときなどにセレクタで呼び出しますが、その際はスタイルで定義されたセレクタを使うのではなく必ず「.js-hoge」などで行うことを義務付けします。そうすることで文書構造、スタイル、スクリプトを完全に分離することができてHTMLを見るだけで何が行われているのか、残さなければいけないセレクタなのかわかりやすくなります。idセレクタとクラスセレクタが基本的にはよく使われるセレクタですが、idセレクタはあまり使わない方がいいです。実はidセレクタには問題点があります。というのも詳細度と関連してくるのですが、基本的にidセレクタは詳細度がかなり強いです。なので、スタイルを上書きしなければいけない場合にどうしてもそれ以上の詳細度にしなければいけません。さらに、1ページに一回しか使えないので、再利用性にかけます。先ほどのdrawerのコードであまり見かけないセレクタの書き方がありました。これが実はBEMの書き方です。そしてBEMのセレクタの書き方には3つの要素でできています。その頭文字をとってBEMと言います。これはdrawerなどのパーツなどの塊を表します。FLOCSSではこのBlockごとにCSSのファイルを書いていくのがいいでしょう。これはBlock内に存在する要素を表します。drawerで言えばボタンやコンテンツですね。これは状態を表します。例えば、背景の色が違うパターンなど注意!.is-や.js-とは使い方が違います。セレクタでBlockとElementのつなぐ方法はアンダースコアを二つつけます。Modifierの前にハイフンを二つつけます。先ほどもご紹介したようにBEMのデメリットはセレクタが長くなりすぎます。こういったケースが頻発するのでcomponentを小分けしていくといいです。そうすると小さい単位のcomponentごとに各componentを組み合わせて使いまわすことが可能になります。ここまでやっても**CSSは破綻**します。そうですねこれでも80%以上の確率で破綻します。複数人いる場合には特に!!そのサイトやサービスに置けるルールを記します。記載する内容は作る人や企業によってまちまちですが、基本的なものとしてはよく使われるcomponentに関してはコードをまとめておくといいです。下記のは僕が作ったフレームワークのものですが、なんとなくの雰囲気はつかめるかなと思います。[Document](http://takumi0901.github.io/flanky/)あくまで「しにくい」です。せっかく作ったガイドラインを無視したりする人がいれば「破綻」します。大体の企業では何かサービス作るにあたってあらかじめガイドラインが設けられていることが多いです。なので、そのサービスに途中から参加する場合などはガイドラインを読み込み、実際のCSSコードを追って理解を深めるのがいいと思います。
2023.04.19
WordPressとJamstackの違いについて
WordPressとJamstackは、ウェブサイトやウェブアプリケーションの構築に使用される異なる技術です。それぞれの主な違いは以下の通りです。それぞれの技術にはメリットとデメリットがあります。以下に、WordPressとJamstackの主なメリットとデメリットをまとめました。
2023.04.14