フロントエンド
フロントエンドの開発効率をあげるテンプレートと
その使い方やルールを説明します
1
株式会社スタジオ・アルカナ
開発フォーマット
目的
「一貫性を持たせる」
開発、命名、フォルダ構造にルールを定めることで、
共通の語彙を持つことができ、プロジェクトを1人の開発者
に依存しないようにします
2
対象
• プロジェクトに関わる人全般
• HTML / CSSの知識があることを前提とする
• 静的なページのみのコーディングを想定とする
3
使用ツール(事前知識)
• CSS Preprocessor: Sass(scss記法)
• Reset CSS: sanitize.css
• HTML Template Engind: Jade
• TaskRunner: Gulp
• VersionControlSystem: Git
4
得られる恩恵
1. コードの品質の安定
慣例・定石の例をまとめることで品質(拡張性, メンテナンス性, 可読性, バ
グの回避)を担保する
2. コミュニケーションコストの削減
ルールに沿った書き方をする事で連絡や質問事項を減らす
3. 経験値の共有
HTML/CSSの仕様上起きやすいミスを防ぐ
5
環境設定
6
CSSのルール
HTMLのルール
HTML/CSS共通ルールGitのルール
アジェンダ
画像のルール
環境設定
7
CSSのルール
HTMLのルール
HTML/CSS共通ルールGitのルール
環境設定
画像のルール
準備すべき環境
• Node.js(v5.4.1)
• Git
• Gulp(4.x)
• Sass
• Jade
• EditorCoding
8
使用方法
9
1. ファイルを作業フォルダに落とす
$git clone https://github.com/KodairaKenya/web-starter-kit.git
2. パッケージをインストール
$npm install
3. 実行
$gulp
ディレクトリ構造
10
少し見えずらいけど、
この構造が大切になります!
!
環境設定
11
CSSのルール
HTMLのルール
HTML/CSS共通ルールGitのルール
Gitのルール
画像のルール
Git(コミットのルール)
バージョン管理ツールの主流とされているGit
コミットメッセージに一定のルールを与えることで、
共同開発者が何を行なったかを一目でわかるようにします
(今回は日本語でのコミットを想定します)
12
原則
• 1行目に全体的説明(タイトル)を50 字以内で記述
• 2行目は空白行
• 3行目以降に変更内容の詳細(何をなぜ)を記述
13
コミットメッセージの原則的なルール
1行目の記述フォーマット
• 【Fix】 :バグ修正
• 【Add】 :新規機能(ファイル)追加
• 【Change】 :仕様変更
• 【Remove】:削除(ファイル)
14
日本語でのコミット例
【動詞】ページ名 / 説明の形にする
15
$ git commit -m "【Fix】about / フッターリンクを修正" -m "(空白)" -m "リンク先をAからBに修
正"
(例) aboutページのfooterのリンクを修正
(例) contactページの住所の欄を追加
$ git commit -m "【Add】contact / 住所の欄を追加" -m "(空白)" -m "データーベースに合わせて
住所を入力する欄を追加する"
.gitignore
基本的にgulpで処理した後のファイルはgitで管理しない
下記のファイルはアップしないようにする
16
/.DS_Store
/node_modules
/build
/npm-debug.log
環境設定
17
CSSのルール
HTMLのルール
HTML/CSS共通ルールGitのルール
HTMLのルール
画像のルール
HTML(基本の書式ルール)
HTMLの書式のルールを定義します
コードの品質が維持される場合に限り、難読化、最小化、
コンパイルするのは自由です
18
一般的な書式
ブロック要素ごとに改行し、
子要素にはインデント(スペース2つ)をつける
(a、span、imgなどの最小の位置にでは改行は適宜対応)
19
理由
可読性の向上
(例)
20
/* NG */
<div>
<ul>
<li><a href="/">Moe</a></li>
<li>Larry
<li>Curly
</ul>
</div
スペースは2つ
プロトコル
2つのプロトコル(http:/ https:)をまたがって使わざるを得な
い限り、画像や他のメディアファイル、スタイルシート、
スクリプトのURLからプロトコル部分を省く
21
理由
ファイル容量を少なくできる
(例)
22
/* NG */
div {
background: url(http://www.google.com/images/example);
}
/* OK */
div {
background: url(//www.google.com/images/example);
}
<!-- NG -->
<script src="http://www.google.com/js/gweb/analytics/autotrack.js"></script>
<!-- OK -->
<script src="//www.google.com/js/gweb/analytics/autotrack.js"></script>
http:が省略されてい
る
スペース
インデントはスペース2つ
(エディタの設定でtabでスペース2つ入力されるように設定
しておく)
23
理由
見た目を綺麗に揃えるため
エンコーディング
エンコーディングを明記する
meta charset=”utf-8″ のように明記
24
理由
文字エンコーディングを指定しないと、日本語で作成され
たウェブページに英語版のブラウザでアクセスした場合な
どに文字化けが起きることがある
コメント
「何のため誰が入れたのか」をコメントとして記述する
参考URLがあればそれを貼り付ける
(コメントが多くなったら命名やコードを見直すこと検討)
25
理由
コメントを明確に残すことで、他の開発者も触れるように
する
正しいHTMLを使う
悩んだらW3Cに目を通してみる
http://momdo.github.io/html5/dom.html#dom
26
理由
W3Cの規定に沿うコーディングを目指す
SEOの考慮と対立した場合は、W3Cの規定を優先する
構造の分離
プレゼンテーション(スタイル)と
振る舞い(スクリプト)は、
ストラクチャ(マークアップ)から分離する
27
理由
メンテナンス性の向上
ファイルが分割し依存しないことで安易に修正が行える
(例)
28
<!-- NG -->
<h1 style="font-size: 1em;">HTML sucks</h1>
<!-- OK -->
<link rel="stylesheet" href="default.css">
<h1>My first CSS-only redesign</h1>
外部ファイルから
スタイルを当てている
文字参照
「<」や「&」のようにHTMLで特別な意味を持つものや、
特殊スペースのような「見えないもの」以外で文字参照を
使うことを避ける
29
理由
文字参照は主に「<」「>」が必要になってくる場面で使用
することは許容するが、対応していない機種なども考慮す
るとそれ以外ではあまり使うべきではない
(例)
30
<!-- NG -->
The currency symbol for the Euro is “&eur;”.
<!-- OK -->
The currency symbol for the Euro is “€”.
なるべく文字参照
はNG
マルチメディアの設定
alt属性でアクシビリティー向上のために画像が何を意味し
ているのか記載する
31
理由
画像に対して代替として動作するテキストをユーザーに提
供できる
(例)
32
<!-- NG -->
<img src="spreadsheet.png">
<!-- OK -->
<img src="spreadsheet.png" alt="Spreadsheet screenshot.">
alt属性の入力は
ユーザーへの気遣い
type属性
CSSとJavaScriptのtype属性は省略
33
理由
HTML5からtype属性は省略可能になったので、ファイル容
量の削減
(例)
34
<!-- NG -->
<link rel="stylesheet" href="//www.google.com/css/maia.css" type="text/css">
<!--OK -->
<link rel="stylesheet" href="//www.google.com/css/maia.css">
type属性は必要な
い
aタグ
リンクはルート相対パスを基本とする
(注意:案件によって柔軟に変更する)
35
理由
ファイル容量の削減
記述方法の統一化
HTMLクォーテーション
属性値に使うクォーテーションは、
シングル(”)よりもダブル(””)が好ましい
36
理由
JavaScriptはHTMLの中で使用するのが想定されるため、
HTMLはダブルクオーテーション("")でJavaScriptはシング
ルクオーテーション('')を使用するのを推奨している
(例)
37
<!-- NG -->
<a class='maia-button maia-button-secondary'>Sign in</a>
<!-- OK -->
<a class="maia-button maia-button-secondary">Sign in</a>
HTML内ではダブル("")にす
る
環境設定
38
CSSのルール
HTMLのルール
HTML/CSS共通ルールGitのルール
CSSのルール
画像のルール
CSS(基本の書式ルール)
39
CSS設計(前提知識)
CSSの教科書
http://goo.gl/MspHyM
CSS設計手法
CSS設計はFLOCSSを使用する
https://github.com/hiloki/flocss
40
CSSファイル
1つのコンポーネントごとにファイルを分割する
ファイル名はコンポーネントに使用しているクラス名を用
いる
41
理由
保守性が向上するため
IDとClassの命名
IDとクラス名にはちゃんと意味の分かる名前を使う
見た目を反映したものやそれが何を表しているか不可解な
名前ではなく、要素の目的や役割を反映した名前を付ける
42
理由
制作した当事者以外が把握できるようにするため
修正に耐えやすいため
(例)
43
/* NG クラス名だけだと把握できない */
.table01 {}
/* NG: 見た目を表してる */
.btn-green {}
/* OK */
.btn-primary {}
/* OK: 役割を表してる */
.gallery {}
.login {}
.video {}
何を示しているのかがわかる
命名を意識する
IDとクラスの命名スタイル
意味の分かる範囲でできるだけ短いIDとクラス名を使う
注意:短くしすぎて意味がわからなくなるようなのはNG
44
理由
ファイルサイズ節約のため
(例)
45
/* NG */
#navigation {}
.atr {}
/* OK */
#nav {}
.author {}
※.atrだと省略しすぎ
ID
IDは原則使用せずクラスで対応する
(ページ内リンクで使用する場合は例外とする)
46
理由
再利用性が低下するため
(詳細度が高くなり管理しづらいため)
タイプセレクタの記述
IDとクラス名にタイプセレクタは記述しない
47
理由
限定された要素以外に適用できなくなり、再利用性が低下
するため
(例)
48
/* NG */
ul.example {}
div.error {}
/* OK */
.example {}
.error {}
要素に依存しないように
する
ショートハンドプロパティ
ショートハンドを適宜使用する
49
理由
ファイル容量の節約のため
(例)
50
/* NG */
padding-bottom: 2em;
padding-left: 1em;
padding-right: 1em;
padding-top: 0;
/* OK */
padding: 0 1em 2em;
ショートハンドプロパテ
ィで記述量を減らす
「0」と単位
値が「0」なら単位を省略する
51
理由
ファイル容量の節約のため
(例)
52
/* NG */
margin: 0px;
padding: 0px;
/* OK */
margin: 0;
padding: 0;
小数点の頭の「0」
小数点の頭の「0」は省略する
53
理由
ファイル容量の節約のため
(例)
54
/* NG */
font-size: 0.8em;
/* OK */
font-size: .8em;
.数字にして記述量を減
らす
URI値の引用符
url()での指定において、
("")ダブルコーテーション、('')シングルコーテーション
のURI値の引用符を省略する
55
理由
ファイル容量の節約のため
(例)
56
/* NG */
background-image: url("//www.google.com/css/.css");
/* OK */
background-image: url(//www.google.com/css/.css);
("")を省略する
カラーコード
カラーコードで3文字で表記できるものは3文字にする
57
理由
ファイル容量の節約のため
(例)
58
/* NG */
color: #ffffff;
/* OK */
color: #fff;
CSS書式ルール
59
理由
可読性向上のため
ブロック単位のインデント
階層がわかるようにブロック単位でコードをインデントす
る
(例)
60
@media screen {
html {
background: #fff;
color: #444;
}
}
インデントは半角スペース2
つ
プロパティの終端
61
理由
可読性向上のため
すべてのプロパティの終端はセミコロンを書くこと
(例)
62
/* NG */
.test {
display: block;
height: 100px
}
/* OK */
.test {
display: block;
height: 100px;
}
プロパティの終端には
必ずセミコロン(;)を書くようにす
る
プロパティ名の終端
63
理由
可読性向上のため
すべてのプロパティ名の終端にはコロンの後にスペースを
入れること
(例)
64
/* NG */
h3 {
font-weight:bold;
}
/* OK */
h3 {
font-weight: bold;
}
半角スペースを一つ空ける
セレクタの終端
65
理由
可読性向上のため
"{"の位置は、セレクタと同じ行に記述する
セレクタとの間にはスペースをいれること
(例)
66
/* NG */
.sample
{
color: #399;
}
/* NG */
.sample{
color: #399;
}
/* OK */
.sample {
color: #399;
}
記述方法を統一する
セレクタとプロパティの分離
67
理由
可読性向上のため
別々のセレクタとプロパティは改行して書くこと
(例)
68
/* NG */
h1, h2, h3 {
font-weight: normal;
line-height: 1.2;
}
/* OK */
h1,
h2,
h3 {
font-weight: normal;
line-height: 1.2;
}
CSSルールの分離
69
理由
可読性向上のため
別々のCSSルールは改行して一行間を空けて書く
(例)
70
/* NG */
html {
background: #fff;
}
body {
margin: auto;
}
/* OK */
html {
background: #fff;
}
body {
margin: auto;
}
改行を1つ空けるようにする
コメント
71
理由
当事者以外が把握しやすくするため
必要に応じてコードを説明する
コードにTODOを入れ、何のためのものか誰が入れたのか
をコメントとして記述する
BEMのセパレーター
72
理由
こちらの方が普及してるため
本来のBEMよりもセパレータが識別しやすいため
MindBEMdingを採用する
block__element--modifier
BEMの粒度
73
理由
冗長なクラス名をさけるため
参考:
http://qiita.com/hiloki@github/items/4fa99b8755a22878449e
block__element__element は使用しない
blockとの関係性を明示していれば問題ない
(例)
74
/* NG */
<ul class="navList">
<li class="navList__item">
<a class="navList__item__link" href=""></a>
</li>
</ul>
/* OK */
<ul class="navList">
<li class="navList__item">
<a class="navList__link" href=""></a>
</li>
</ul>
冗長にならないようにする
クラスの命名
75
理由
プレフィックスとモディファイアを認識しやすくする
BEMを採用するとクラス名が冗長になるので少しでも短く
するため
クラス名にはキャメルケースを使用し、
プレフィックスとモディファイア以外でハイフンは使用し
ない
(例)
76
/* NG */
.c-ghost-btn--primary
/* OK */
.c-ghostBtn--primay
ghostBtnがキャメルケースで
記述されている
マルチクラス
77
理由
CSSでで重複する記述が減らせるため
ファイル容量が減るため
ルールセットの再利用性があがるため
保守性が向上するため
コンポーネント設計のアプローチはマルチクラスを採用
(@extendを使用したシングルクラス設計の場合は可)
スタイルの打ち消し
78
理由
ファイル容量の節約のため
スタイルを打ち消さずにコンポーネントを定義する
打ち消しが発生する場合、1つのルールに過剰なスタイルを
追加しているので設計を見直す
(例)
79
/* NG */
.headline {
font-size: 2rem;
margin-bottom: 10px;
border-bottom: 1px solid #333;
}
.no-border {
border: none;
}
/* OK */
.headline {
font-size: 2rem;
margin-bottom: 10px;
}
.headline--border {
border-bottom: 1px solid #333;
}
絶対値
80
理由
不要なCSSを減らせるため
柔軟に対応できるようにするため絶対値は原則使用しない
(例)
81
/* NG */
h1 {
font-size: 2.4rem;
line-height: 32px;
}
.siteTitle {
font-size: 3.6rem;
line-height: 48px;
}
/* OK */
h1 {
font-size: 2.4rem;
line-height: 1.333;
}
.siteTitle {
font-size: 2.4rem;
}
HTMLへの依存
82
理由
HTML内のタグが変更された際にCSSに影響がでないよう
にするため
保守性が向上するため
可能な限りHTMLに依存させないように定義する
(例)
83
/* NG */
<div class="contents">
<div class="wrap">
<h2>Contents Title</h2>
<p>Contents の本文が入ります。</p>
</div>
</div>
.contents .wrap h2 {
font-size: 2.4rem;
}
/* OK */
<div class="contents">
<div class="wrap">
<h2 class="headline">Contents Title</h2>
<p>Contents の本文が入ります。</p>
</div>
</div>
.headline {
font-size: 2.4rem;
}
環境設定
84
CSSのルール
HTMLのルール
HTML/CSS共通ルールGitのルール
HTML/CSS共通ルール
画像のルール
HTML/CSSの共通ルール
85
HTMLファイル、CSSファイルの共通ルール
英数字のみを使用する
86
理由
開く環境によっては、文字化けする可能性があるため
ファイル名には日本語を使用せず、英数字にする
機種依存文字の使用禁止
87
理由
記号と同様、エラーを引き起こす原因と成り得るため
機種に依存した文字を使用するのを禁止する
(GoogleChromeなら変換時に右側に△マークがつくもは使
用しないようにする)
必ずアルファベットから始める
88
理由
数字から開始しているid・class名は、認識されないため
必ずアルファベットからはじめ、数字から始めない
ファイル名のスペースを禁止
89
理由
ファイルを正常に処理出来なくなる可能性があるため
ファイル名をつけるときにスペースの使用を禁止する
(動作はするので注意が必要)
特定の文字を使用禁止
90
理由
Windowsでファイル名に使用することが出来ないため
(その他の記号も使用をする際には注意が必要)
「」,「/」,「:」,「?」,「<」,「>」,「|」,「$」
上記のの文字の使用禁止
環境設定
91
CSSのルール
HTMLのルール
HTML/CSS共通ルールGitのルール
画像のルール
画像のルール
画像のルール
92
画像ファイルの命名に一定のルールを与えることで、
名前からその画像が何を示すのかを判断できるようにする
ディレクトリ
93
共通で使い回す画像 → imgディレクトリ直下
ページ固有の画像 → ページ名でフォルダを作成
画像における命名規則
94
「種類」と「詳細」をアンダーバーでつなげる
種類_詳細.拡張子
(例)
menu_contact.jpg
デバイスごとに画像を分ける
デバイスごとに画像を別にする際は、デバイスを追加する
種類_詳細_番号_デバイス.拡張子
(例)
menu_contact_pc.jpg
menu_contact_sp.jpg
95
種類を6つに分類
96
bg : 背景
btn : ボタン
icon : アイコン
txt : テキスト
ttl : タイトル
img : 画像
詳細
97
種類に対して詳細な説明をする
icon_arrow.png
複数単語を使用したい場合はキャメルケースでつなげる
icon_arrowPrev.png
番号
98
同じ用途の画像が複数あった場合に、番号を付ける
icon_arrow_01.png
※svgにすることで1つの画像でまかなえる場合はsvgを
使用する
画像のパス表記
99
理由
どの階層にあっても同じパスで指定できるため
(インクルードしたファイルでもルート相対パスであれば
問題なく表示される)
ルート相対パスを基本とする
(例)
100
// NG
<img src="../img/test.png">
<img src="http://test.com/img/test.png">
// OK
<img src="/img/test.png">
相対パスのほうが記述量が
少ない
最後に
まとめ(余談)
102
• ルールは作ることより、浸透させることのほうが難しい
• それでも項目一つ一つの認識を明文化することが大事
• 一貫したルールを守って作業を進めることは、将来的な
選択に多大な幸福をもたらしてくれる
• READMEはプロジェクト毎に管理をして、柔軟にルール
は変更するべきである
参考文献
103
• メンテナブルCSS
https://www.cyberagent.co.jp/techinfo/techreport/report/id=7926
• Harry Roberts氏によるCSSガイドライン
https://github.com/kiwanami/CSS-Guidelines
• 「Google HTML/CSS Style Guide」を適当に和訳してみた」
http://re-dzine.net/2012/05/google-htmlcss-style-guide/
• HTML5日本語訳
http://momdo.github.io/html5/Overview.html
• 新人コーダーに知っておいて欲しい命名規則の考え方[画像・ID・class名]
http://html-coding.co.jp/knowhow/tips/naming-rule/
• Jade
https://gist.github.com/japboy/5402844
• こんなHTMLとCSSのコーディング規約で書きたい
http://qiita.com/pugiemonn/items/964203782e1fcb3d02c3
多くの方々の知恵を参考とさせていただきました
心より感謝いたします
• Code smells in CSS
http://article.enja.io/articles/code-smells-in-css.html
• CSS設計の基礎を見直す
http://gihyo.jp/dev/serial/01/js-foundation/0009
• 100年後も崩れないCSS勉強会 第1回「詳細度」
http://pepabo.github.io/css/specificity/
• 100年後も崩れないCSS勉強会 第2回「コンポーネント」
http://pepabo.github.io/css/component/
• [CSS] Object Oriented CSSを学んで綺麗なコードを書く
http://www.yoheim.net/blog.php?q=20141201
• SMACSS 読んだ
http://chroma.hatenablog.com/entry/2013/07/22/120818
• BEMとは何か?
https://github.com/juno/bem-methodology-ja/blob/master/definitions.md
• 使いやすいWordPressのためのCSSのつくりかた
http://www.slideshare.net/Toro_Unit/wordpresscss
104

2016年版 フロントエンド開発フォーマット