使いやすいWordPressのためのCSSのつくりかた

使いやすいWordPress
のためのCSSのつくりかた
2015.09.12 @WordBench Osaka
2015.09.12 @WordBench Osaka 1

whoami
じこしょうかい

Toro_Unit
占部紘 (うらべひろし)
Frontend Engineer / Plugin Developer /
Web Designer
Github: @torounit
Twitter: @Toro_Unit
Facebook: fb.me/torounit
Blog: http://www.torounit.com

Profile
• 福島県郡山市生まれ。
• 群馬県太田市育ち。
• にじゅうろくさい。
source:
https://commons.wikimedia.org/wiki/
File:Gunma-
NaganoPrefecturalRoad11202.jpg

今日は

長野県松本市からはる
ばるやってきました。
source:
https://commons.wikimedia.org/wiki/
File:
130608MatsumotoCastleMatsumotoNa
ganoprefJapan02bs4.jpg

WordBench大阪初参加です！！
初参加は緊張するものです。
2回目以降の参加の方は、自分の知らない人最低2人、話しかけ
てみましょう！
とのことなので、みなさんよろしくお願いします。

WordPressとの関わり

WordCamp Kansai 2015 Speaker
その節はお世話になりました。

WordPress 4.3 Core
Contributer
追いつけ追い越せKiteさん。

Plugin Development
• Custom Post Type Permalinks
• Simple Post Type Permalinks
• Powerful Post Per Page
• etc...

WordCamp Tokyoでは
CIの話をする予定。(仮)

ですが

今年のWordBench大阪
はテーマの年らしい。

というわけで

全力でCSSの話をします!!!

Today's Agenda.
1. Editor Styleの話
2. CSSの設計について

§1.Editor Styleの話

WordPressでブログを
書いてる人！

テキストエディタでHTMLとか書いて
る人！挙手！

もったいない!!!

もったいない!!!
• 最近のWordPressのビジュアルエディタへの力の入れ方が尋
常じゃない。
• Markdownライクな書き方が出来るようになって、かなり書
きやすくなった。
• HTMLとかCSS大好きですけど、正直書かなくて済むなら書
きたくない。

そんなあなたたちにおくります。

Do you know Editor Style?
おまえはエディタースタイルを知っているか

Editor Style とは。
WordPressのビジュアルエディタに適用されるCSSのこと。
<?php
add_editor_style('./editor-style.css');
?>

これを使うと

これが

こうなる

これは作るしかない!
（デフォルトテーマにも入ってる!）

But...

めんどくさい。

めんどくさい。
• ビジュアルエディタとテーマのHTML構造の違う。
• デザイン変更のたびにeditor-styleも確認する必要。。
• 二重管理だるい。

どうすれば。。。

じゃぁ、テーマで使っているCSSをそ
のまま Editor Style にできれば・・・

add_editor_style('./style.css');

But...

ビジュアルエディタとテーマでは
HTML構造が違う。

ビジュアルエディタのHTML
<html>
<body>
本文
</body>
</html>

テーマのHTML
<html>
<body>
<header>
</header>
<main>
<article>
<h1>タイトル</h1>
本文
</article>
</main>
</body>
</html>

じゃぁどうしよう？

the_contentで挿入される本文から
CSSを作る。

ブログ本文からCSSを作ると。
• ブログ本文からCSSを作ると、本文欄からクラスや、div等を
ある程度減らせる。
• 見出しとかリストとかにいちいちClassを付けたりするとか
が発生しない！

具体的な方法

1.HTML要素へのCSSを、本文のもの
にする。

とりあえずこんな順番でCSSを書いてると思うんです。
1. Reset.css / Normalize
2. HTML要素へのCSS (h1,h2,h3,a,table,ul,li, etc...)
3. クラスとかIDとか (.alignleft,.alignright,.media-object,etc...)

とりあえずこんな順番でCSSを書いてると思うんです。
1. Reset.css / Normalize
2. HTML要素へのCSS (h1,h2,h3,a,table,ul,li, etc...)
3. クラスとかIDとか (.alignleft,.alignright,.media-object,etc...)
本文欄のデザインをタイプセレクタに適用する！

本文（the_contentの中身）のCSS =
サイトのデフォルトのスタイルとして
設計する！

めんどくさい？

そうでもない。

• テーマ側のHTMLには大抵Classとか当ててCSSを書いてる。
そのClassでやれば済む話。
• 最初のタイプセレクタへのCSSをちゃんとサイトのデフォル
トのデザインにしようぜ！ということ。Classで上書きしてた
らあんまり意味が無い。全ての箇所で上書きするようなCSS
とか要らなく無い？
• WYSIWYGエディタを持つCMSであれば、WYSIWYGを使い
倒せるようにCSSを設計するべき。

それでも面倒?

そうか･･･じゃぁ

Sass等で解決。

こんなmixin作っておけば便利かも。
@mixin box-reset() {
display: block;
margin: 0;
padding: 0;
border: none;
color: inherit;
&::before,
&::after {
content: normal;
}
}

とりあえず、見出し周りをちゃんとや
れば何とかなること多い。

2.body_class, post_classを使った
CSSは避ける

• ビジュアルエディターには存在しないクラスを出力する。こ
れらを使うと、編集画面と本番で表示が異なる事態が発生し
がち。
• これに依存すると、同じHTMLを書いたのに挙動がページご
とに変わるというCSSが大量生産される。つらい。

ページごとにCSSを作るという発想を
止めて、モジュールを組み合わせてペ
ージを作るという発想に転換しよう。

3.その他の細かいノウハウ

• トップページや複雑なページから作るとだいたいやらかす。
テーマユニットテストを活用しよう。その後にシンプルな文
章だけのページなどから作ってテストをしていくと良い。プ
ライバシーポリシーとか、法律上の表記とか。
• 見出し周りは複雑になりがち。サイドバー・タイトルなど、
ハードコーディングするものは、基本的にh1を使ってクラス
を当てるようにするといいかも。生のh1を使うケースは意外
に少ないし、ビジュアルエディタ内では基本使わない。

• モジュールの組み合わせで作ると、「TinyMCE Template等
で、特定のパーツを挿入できるようにする」などの拡張も行
いやすい。
• CSSをしっかり設計すると当然、管理画面からの更新もやり
やすくなるよ！
• ブログ書くのがめんどくさくなくなるかも。。。？

第一部完
第二部につづく。

§2.CSSの設計について

初めに言っておきますが･･･

「Web制作者のためのCSS設
計の教科書」(メロン本)にだ
いたい全部書いてあります！
みんな読もう！

突然ですが

CSSって簡単？難しい？

その１

CSSって簡単!
たとえばこんなHTML
<h1 class="title">サイトのタイトル</h1>
<main id="main-contents">
<h1 class="title">ブログのタイトル</h1>
<article class="post">
<header class="headline">
<h1 class="title">記事のタイトル</h1>
</header>
</article>
</main>

CSSって簡単!
.title {
color: red;
}

CSSって簡単!
.title {
color: red;
}
.post .title {
color: orange;
}

CSSって簡単?????
.title {
color: red;
}
#main-contents .title {
color: green;
}
.post .title {
color: orange; /*上書きされる。。。*/
}

CSSって簡単????????????????
.title {}
#main-contents .title {}
.post .title {}
h1.title {}
main#main-contents article .title {}
main#main-contents .headline h1 {}
main article header h1.title {}
main#main-contents .post:first-child h1 {}

CHAOSの予感!!!

その２

CSSって簡単!
.title {
border-left: 10px solid #CCC;
font-size: 2em;
}

CSSって簡単!??
.title {
padding: 0 0 0 5px;
font-size: 2em;
}
.sidebar .title {
background-color: #333;
color: #FFF;
padding: 0;
border: 0;
}

CSSって簡単!??????????
.title {
padding: 0 0 0 5px;
font-size: 2em;
}
.title::before {
content: "§";
}
.sidebar .title {
background-color: #333;
color: #FFF;
padding: 0;
border: 0;
}
.title::before {
display:none;
}

スパゲッティな予感!!!

CSSは簡単に書けるけ
ど、ちゃんとしたCSSっ
て難しい。

ちゃんとしたCSSって？

ちゃんとしたCSSって？
CSS Architecture — Philip Walton
• 原文：http://philipwalton.com/articles/css-architecture/
• 日本語訳：http://article.enja.io/articles/css-architecture.html

良いCSSとは？
• 予測しやすい
• 再利用しやすい
• 保守しやすい
• 拡張しやすい

というわけで

ちゃんとCSSも設計しよう
「とりあえずデザインが実現できればOK」は卒業しよう。

どうやるの？

1.マークアップに依存しない

たとえばこんなHTML
<article>
<p>本文</p>
</article>

たとえばこんなCSS
article {
border: 1px solid #666;
padding: 16px;
}
article h1 {
margin: 0 0 0.5em;
font-size: 1.7em;
}

HTMLが変更になった！
<div>
<p>本文</p>
</div>
CSSが効かない!!

こうしよう。

HTML
<h1 class="post-title">タイトル</h1>
<p>本文</p>
</article>
CSS
.post {
}
.post-title {
}

文書構造とCSSをしっか
り分離する。

2.コンポーネント志向な
CSSを作る。

さっきの例ですが、こうでも良さそうですよね。
.post {
}
.post .title {
}

でも。

.widget {
hoge: piyo;
}
.widget .title {
hoge: piyo;
}

<div class="widget">
<h1 class="title">最近のエントリー</h1>
<h1 class="title">タイトル</h1>
</article>
</div>
Conflict!

クラス名 ≒ グローバル変数

.widget {
}
.widget-title {
}
.post {
}
.post-title {
}
No conflict!!!

3.親セレクタに依存しない

.main-contents {
float: left;
}
.home .main-contents {
float: none;
}
一見良さそうだけど。

.main-contents {
float: left;
display: block;
}
.home .main-contents,
.page .main-contents {
float: none;
}
.blog .main-contents,
.single .main-contents {
float: right;
}

.main-contents {
float: left;
display: block;
}
.home .main-contents,
.page .main-contents {
float: none;
}
.blog .main-contents,
.single .main-contents,
.date .main-contents,
.archive .main-contents {
float: right;
}

同じクラスがHTMLの書き方で次第で
全く別の挙動をする!
とても解りづらい!! 混乱する!
バグの原因になりやすい。
HTMLの祖先要素とか何個あると思ってんの？

こうしよう

.main-contents {
float: left;
}
.main-contents--single-column {
float: none;
}
HTMLのコンテキストを考えなくて済む。

モジュールのことはモジュールに解決
させよう。

ここら辺の話を体系化したものが
所謂CSSアーキテクチャー
と呼ばれているもの。

CSSアーキテクチャー

1.OOCSS
すべてはここからはじまった

OOCSS
元Yahoo!の Nicole Sullivan氏
(@stubbornella)が提唱したCSSの設計原
則。
https://github.com/stubbornella/
oocss/wiki

OOCSSの２大原則
1. 構造と見た目を分離。
2. コンテナとコンテンツの分離。

構造と見た目の分離

.submit-btn {
display: inline-block;
padding: 10px;
color: #FFF;
background: #66C;
}
.link-btn {
padding: 10px;
color: #333;
background: #C90;
}

構造と見た目の分離すると・・・

/*ボタンの構造*/
.btn {
padding: 10px;
}
/*ボタンの見た目*/
.btn-submit {
color: #FFF;
background: #66C;
}
.btn-link {
color: #333;
background: #C90;
}

構造と見た目の分離するメリット
1.コードの重複が避けられる。保守性が上がる。
2.拡張がとても用意になる。

コンテナとコンテンツの分離
<aside class="sidebar">
<div>
<img class="avatar" />
</div>
</aside>
.sidebar .avatar {
width: 200px;
border: 5px solid #FFF;
box-shadow: 0 2px 3px #000;
}

コンテナとコンテンツの分離すると。

<aside class="sidebar">
<div class="sidebar-widget">
</div>
</aside>
.sidebar-widget { /** コンテナ **/
width: 200px;
}
.avatar { /** コンテンツ **/
width: 100%;
}

コンテナとコンテンツの分離するメリット
1.場所、コンテキストに依存しないコードが増える。
2.再利用しやすい！

再利用の例

<article class="comment">
<div class="comment-user">
</div>
</article>
.comment-user {
position: absolute;
width: 100px;
}
.avatar {
width: 100%;
}

OOCSSの例
• Bootstrap
• Foundation

2.SMACSS
元Yahoo!の Jonathan Snook氏
(@snookca)によって提唱されたCSSの設
計方針。
https://smacss.com/

SMACSSの基本
CSSを５種類に分類。
• Base
• Layout
• Module
• State
• Theme

Base
プロジェクトのデフォルトのCSS定義する。class等は使わず
HTML要素に対してCSSを定義する。
例
• Reset / Normalize
• タイプセレクタへのスタイル。プロジェクトのデフォルトの
デザイン。

Layout

Layout
サイトのレイアウトを定義するCSS群。クラスには、.l-main等
のプリフィックスをつける。
例
• メインカラム/サイドバー
• ヘッダー・フッター

Module

Module
ページ内を構成するコンポーネント群。レイアウト以外は基本
的に全てここに属する。SMACSSでCSSを書くと基本的には
Moduleが大量に作られる。
• ボタン
• メディアオブジェクト
• その他もろもろ

Moduleの命名規約
モジュールに属するスタイルの命名は、.{モジュール名}-{スタイ
ル名}とする。
.widget {
}
.widget-title {
}
.widget-body {
}

State

State
.is-active等のJavaScript変更されたりするような、状態を表す
CSS。他のCSSを上書きできるように設計する必要がある。
.navigation-item {
}
.navigation-item.is-active {
}

Theme

Theme
名前の通り、テーマを切り替えたりするときに使う。ブログサ
ービスなどでCSSを切り替えるとか。
• ぶっちゃけあまり使ったことが無い。
• オルタネイトスタイルシートなど。
• 他には、多言語対応でフォントや文字方向を使ったり。。。
むしろ良い使い方教えて下さい。

SMACSSの採用例
• Pure: Yahoo!が作ったCSSフレームワーク
http://purecss.io/
• 昔の web-starter-kit

3.BEM(MindBEMding)

BEM
ロシアのYandexが作った、CSSのセレクタの命名規約、設計方
針。
CSSを Block, Element, Modiﬁerの3つに分類して考える。
MindBEMding – getting your head ’round BEM syntax
http://csswizardry.com/2013/01/mindbemding-getting-your-
head-round-bem-syntax/

Block
所謂、SMACSSで言うところのModule。HTMLを構成するコン
ポーネントの単位。
.block {
}

Element
Blockの子要素。
.block__element {
}

Modifier
BlockやElementの拡張。
.block--modifier {
}
.block__element--modifier {
}

BEMの例
.post { /* Block */
}
.post__title { /* Element */
}
.post--sticky { /* Modifier */
}
.post__title--new {
}

__とか--がきもちわる
い。

• プロジェクトの中で一貫性がとれていれば、なんでも良い。
• ただWordPressはハイフン区切りの命名が多いので、そのま
ま使うのが無難。そのまま使うとBEMなフレームワークとか
も扱いやすい。
• 気持ち悪い分わかりやすい。

• EmmetだとBEMモードがある。それだと、
Block__Element_Modiﬁerになってる。
EmmetのBEMフィルターでBEMるときのHTMLをサクッと書
く | clear sky source:
http://maboroshi.biz/clearskysource/?p=926

BEMのメリット
• とにかくわかりやすい。SMACSSと違い、elementと
modiﬁerの区別が明確。
• 特徴的な命名なので、HTML側で間違ったClassの使い方など
を発見しやすい。
参考：BEMという命名規則とSass 3.3の新しい記法 - アインシュ
タインの電話番号
http://blog.ruedap.com/2013/10/29/block-element-modiﬁer

BEMの例
• Material Design Lite
• Comico http://www.comico.jp/
• NBA.COMの各チームのスケジュール。http://www.nba.com/
spurs/schedule

注意事項
• block__elem1__elem2 とかやらない。マークアップへの依存
を深めることになるので、block__elem1, block__elem2とか
にする。
• もしくは別のBlockに分割する。

応用編

FLOCSS

FLOCSS
日本でCSSと言えばこの人！なサイバー
エージェントの谷拓樹氏（@hiloki）に
よるCSSの構成案.
ドキュメント(日本語):
https://github.com/hiloki/ﬂocss

FLOCSSのCSSのカテゴリー
• Foundation
• Layout
• Object
• Component
• Project
• Utility

FLOCSSのCSSの原則
他のモジュールへのカスケーディングは原則禁止
.c-card > .c-media__title { /* NG!!!!!! */
}
SMACSS等でもこれをやり出すとモジュール同士が密結合にな
ってCSSが腐海化するので避けるべき。

Foundation
• Normalize.css / Reset.css
• プロジェクトのデフォルトスタイル.
• 要はSMACSSで言うところのBase.
Layout
• ヘッダー・フッター・メインカラム・サイドバー等

Object

Component
• 再利用出来るパターン。Bootstrap等で出てくるコンポーネン
トなど。
• Media Object / Button / Card / etc..
• 抽象化されたモジュール群。

Project
• プロジェクト固有のパターン。具体的なモジュール群。
• Projectから、Componentへのカスケーディングは許可
• それでもやっぱりセレクタの詳細度が上がるので、モディフ
ァイアで事足りるならそちらでやる方が無難なケースが多い
かも。
.p-book > .c-media__title { /* OK */
}

Utility
• いわゆる、ヘルパークラス、便利クラス。
• show・hide / 文字サイズとか。
• WordPressの.alignleftとかはここに所属。
• 同じようなモディファイアが大量生産されるときは、ここに
突っ込むと良いかもしれない。

事例
• http://torounit.com
Repository: https://github.com/torounit/torounit2015

補足
• ざっくり言うと、SMACSS + MCSS(Multilayer CSS).
• 内容がかぶるので紹介しませんが、日本語ドキュメントもあ
るので、一見の価値あり。http://operatino.github.io/MCSS/
ja/

ITCSS

ITCSS
CSS界のアイドル、CSS Wizardryこと、
Harry Roberts(@csswizardry)氏による
CSS設計案。
• 情報すくなめ。日本語情報あんまり
ない。たぶん谷さんのスライドくら
い。ただし、元のスライドが素晴ら
しいし、図も多めなので全然読め
る。
スライド：https://speakerdeck.com/
dafed/managing-css-projects-with-itcss

カオスなCSS
引用元: https://speakerdeck.com/dafed/
managing-css-projects-with-itcss

おまえのセレクタで地球がやばい

こうしよう！

ITCSSのレイヤー

Setting: グローバルな変数
Tools: Mixin、Function
Generic: Normalize、Reset
Base: デフォルトのスタイル。要素セレクタ。
Objects: 装飾のないパターン。FLOCSSでいうComponent.
Components: FLOCSSでいうところのProject. プロジェクト固
有のコンポーネントパターン。
Trumps: ユーティリティクラス。便利クラス。

事例
http://csswizardry.com/
• https://github.com/csswizardry/csswizardry.github.com

公式サイト・ドキュメント

スライドを読もう。
サイトは1ページしか無いけど、スライドはかなり詳細なのでわ
かりやすい。英語だけだけど結構わかりやすい。
https://speakerdeck.com/dafed/managing-css-projects-with-
itcss

フレームワーク

inuit.css

一応レポジトリはある。
割とコミットされてる。

Others
• MCSS (http://operatino.github.io/MCSS/ja/)
• SUIT CSS (https://suitcss.github.io/)
• AMCSS (https://amcss.github.io/)

これらをちゃんと運用するために。

• CSSは文法がゆるふわなので、強い自制心が必要!!!
• CSSはすぐ壊れる。常にリファクタリングしながら進める。
• 後でやろうとするとだいたいスパゲッティなCSSになってて
手遅れになる。
• 使わなくなったらいつでも削除出来るような設計が大事。
• 初動が肝心。

• 巨大なモジュールを作ると大抵使い回しが辛い。スクロール
しないで読めるようなモジュールが一番使い勝手が良かった
りする。1つのモジュールの仕事なのかをよく考えること。
• 疎結合大事。モノリシックなCSSを管理できるほど人間は賢
くない。
• 著名なCSSフレームワークはやっぱり参考に出来ることが多
い。

• 基本的にはOOCSSからの派生物。とりあえず、OOCSSの考
え方は身体にたたき込む。
• ドキュメントの整備は重要。それが面倒ならFLOCSSを使う
のが無難。

• IDセレクタは滅ぼそう。IDにはページ内リンクのアンカーと
いう仕事もある。一つのセレクタにいろんな仕事を持たせる
とリファクタリングが大変。
• Sass等を使うと、"&"を使うことでだいぶ書きやすくなる。
• モジュールごとにファイルを分割しないと訳がわからなくな
るので、とりあえずSass使おう。

強い心・クソコードへの憎しみ・CSSへの愛が大事

CSSの設計はまだ発展途上。
柔軟な頭で考えよう。
ドキュメントは大事。せめてコメントに命名規約とか採用する設計を記述しておくのが良いかと。

とりあえず

おまえらCSSもちゃんと設計しろ!!!

余談

• 個人的にはITCSS押し。inuit.cssが小さな単位で独立したレポ
ジトリになっていてnpmで取ってこれるのは楽。
• AMCSSは良いと思うけどセレクタが書きづらい。ここら辺を
解消できるツールがあれば。

• 「Every Declaration Just Once」とかいう話もあるけど、
CMSのように最初にCSSを用意してHTMLを追加していくも
のにはつらいと思う。
• CMSは基本的に、ページが容量の許す限り増やせる。なので
プロジェクトごとにCSSフレームワークを作るくらいの気持
ちでやった方が良い。
• 静的サイトと同じようなデザイン要件だとCMSでやるメリッ
トが薄まるのでそこら辺のコントロールも大切。

• WebComponentsの夢は忘れよう。(Scoped Styleとか)
• でもモジュラーなHTML/CSSというのはこれからもっと必要
な考え方。(ex. React.js)
• プリプロセッサは悩むならSCSS使えば良いと思う。ツールも
情報も採用例も多い。

参考資料
• 谷拓樹氏のスライド全般。http://www.slideshare.net/hiloki/
• 昨今のCSS設計事情からみるCSS設計のあり方とは |
HTML5Experts.jp https://html5experts.jp/hiloki/14372/
• IDを使わないCSSの設計｜Web Design KOJIKA17
http://kojika17.com/2013/09/dont-use-ids.html

参考資料
• CSS 設計の長い夢 - ペパボのフロントエンドスタンダード
http://pepabo.github.io/docs/frontend/standard/css-
architecture/
• なんでCSSすぐ死んでしまうん http://www.slideshare.net/
hayatomizuno/css-41084761

おわり。

使いやすいWordPressのためのCSSのつくりかた

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie 使いやすいWordPressのためのCSSのつくりかた

Ähnlich wie 使いやすいWordPressのためのCSSのつくりかた (20)

使いやすいWordPressのためのCSSのつくりかた