CSS設計手法「FLOCSS」を適用して出てきた疑問を自分なりに考えて進めた結果と得た知見と失敗と

1. はじめに

本記事は普段業務でサーバサイドをやっている筆者が、フロント知識ほぼゼロから独学で勉強を進めながらポートフォリオ制作を始め、素人ながらもCSS設計手法「FLOCSS」を適用して得た知見等を記す。
本題のFLOCSSの話の前に、読むうえで必要になりそうな知識(CSS設計手法/HTML/CSS等)+αも2～4章にまとめているため必要がある方のみ読んで頂ければと思う。必要ない方は5章(FLOCSSの話)まで飛ばして頂ければと思う。
本章では、FLOCSSを適用するに至った経緯を記す。

1.1. CSS設計手法を知ったきっかけ

ポートフォリオ作成に取り掛かり始めた頃のある日にtwitterのTLでふいに流れてきた以下記事がきっかけである。（感謝の言葉しかありません）

【参考記事（Qitta）】

各CSS設計手法を取り入れる上でのメリット・デメリットをまとめてみた

1.2. CSS設計手法の導入を決めた理由

CSS設計手法を使わずに我流な書き方にて１頁分CSS（Sass）を作成してみた結果、このまま作成を続けると以下のようなコードになってしまうと悟った。

• コード共通化が上手くできず、コピペで同じコード量産（効果的なやり方が分かっていない）
• １ファイルのコード量肥大化（ファイルの適切な分け方が分かっていない）
• 後から一部修正すると思わぬ箇所に影響が及ぶコードができあがりそう（詳細度、組み合わせの管理破綻）

そのため、なにかしらの設計手法を適用し、（設計手法の理解が足らず100%準拠はできなかったとしても）ある程度メンテナンス性を確保する必要があると考えた。

2. CSS設計手法について

2.1. 各CSS設計手法の概要

CSS設計手法についていくつか簡単に紹介する。詳細は参考サイトをご参照。

■ OOCSS（Object Oriented CSS）
オブジェクト指向にもとづいて考案された設計思想

■ BEM（Block Element Modifier）
独特な命名規則「MindBEMding」からなる設計思想。「.Block__Element--Modifier」という命名ルールに従いクラス名を決定。

■ SMACSS（Scalable and Modular Architecture for CSS）
OOCSSやBEMの流れをうけて考案された設計思想。BEMより緩い命名規則と、OOCSSのようなマルチクラス設計が特徴

■ MCSS（Multilayer CSS）
OOCSSとBEMの原理を基に作成された設計思想。CSSモジュール（及び、その内部ブロック）をレイヤー毎に分離し、各レイヤー上から順に重ねるイメージ。

■ SuitCSS
コンポーネントベースの設計手法。BEMに加えて汎用クラスを利用する。

■ FLOCSS
上記の設計手法の良い所取りをした設計手法

以下、各設計手法についての参考及び引用元サイト
・OOCSS、BEM、SMACSS、FLOCSS、RSCSSを比較して自分にあった設計思想をみつける
・各CSS設計手法を取り入れる上でのメリット・デメリットをまとめてみた
・より良いCSSを書くための様々なCSS設計まとめ
・SUIT CSS
・CSS設計を学ぼう

2.2. FLOCSSを選択した理由

以下の理由から、SMACSS、MCSS、FLOCSSに絞り込んだ

• （個人開発のもののため）規模が大きくはないこと
• オブジェクト指向に慣れ親しみがあるので、OOCSSを取り入れたい
• 我流で書いていたやり方がレイヤ毎に分ける手法に近いため、馴染むのに大きなコストはかからない(はず)

絞り込んだ３つの中で最初はMCSSを選択した。理由は「CSS設計に慣れてない人でも理解はしやすい」ことがメリットとしてあり、CSS設計素人の自分でもできると推測したため。
しかし、MCSSを適用して書いたコードを書き換えようとすると、（ググっても参考になるものがあまり出てこなかったこともあり）書き方が分からず詰まった。このまま進めてもスピード感が出ないと判断して、MCSSも選択肢から除外することとした。

情報量という点についてはMCSS以外はどちらも十分と判断し、FLOCSSには「Component にするか Project にするかで迷う」という素人には重荷になりそうなデメリットがあるため、順当に考えればSMACSSが良いかと考えた。しかし、最終的に「学習の幅がある」「挑戦」という面を重視して以下の理由からFLOCSSを選択した。

• FLOCSSは、SMACSSの考え方も含むため、FLOCSSをやってもSMACSSの考え方をある程度は学べる。
• 可能ならば自分なりの見解を出せるような挑戦要素が欲しいと考えていたため、以下２点に挑戦要素があると考えた。
  • デメリットの「Component にするか Project にするかで迷う」という点
  • 割と新しめの設計手法である点
• デメリットの「Component にするか Project にするかで迷う」点について、最悪できなかったとしても、ComponentとProjectに分けなければ自分でもできると判断したため。（そうしても、SMACSSより１レイヤ分少なくなるため、管理もしやすいと考えていた。結局ComponentとProjectは分けて最後まで通した。）

3. FLOCSSとは

FLOCSSでは大きく以下の３つの層に分けて管理する（Object層にはさらに３つの子レイヤーに分かれる）。命名規則には、MindBEMdingを採用している。

・Foundation : normalize.cssなど
・Layout : レイアウトのスタイル
・Object : コンポーネントのスタイル
　・Component : 再利用可能なコンポーネント
　・Project : プロジェクト毎のスタイル
　・Utility : clearfixやmarginなどの小さなスタイル

詳細は以下、公式サイトをご参照。

公式ドキュメント：https://github.com/hiloki/flocss
公式設計デモ：https://github.com/tacrow/flocss-demo

4. 本題の前に押さえておきたいHTML/CSS基礎知識＋α

HTML/CSSもほぼ１から学習したため、個人的にまとめておきたい点をまとめておく。

4.1. HTMLはブロック構造で考える

HTMLを書く際は、「ブロック分け」が重要なキーになり、レイアウトするために過剰にCSSを書くようなことも防げる。

※詳細は以下サイトがとても参考になると思われるので必要な方はご参照されたし。

参考サイト：CSSができる人とできない人では何が違うのか？(レイアウト編)

本記事でも以下に例を載せる。
（左：HTML/CSSで実装したサンプル、右：実際のHTML上のブロック分け）

4.2. レスポンシブなレイアウトに頼もしいFlexBox/GridLayout

FlexBox、GridLayoutについて簡単にまとめる。

FlexBoxは、柔軟なレイアウトを実現可能。
FlexBoxの基本的な使い方は以下サイトが参考になると思われるのでご参照されたし。

参考サイト：css display flex の 使い方（中央寄せなど）

GridLayoutは、行と列を持つグリッドベースのレイアウトが可能。
GridLayoutの使い方は以下記事が参考になると思われるのでご参照されたし。

参考Qiita記事１：CSS Grid Layout を極める！（基礎編）
参考Qiita記事２：CSS Grid Layout を極める！（場面編）

レイアウトを調整する際は、Floatも含めて使い分けが重要である。
以下サイトが参考になると思われるのでご参照されたし。

FlexBox/GridLayout/Float使い分け参考サイト：
特徴で使い分けたいCSSレイアウト手法

レスポンシブレイアウトを実現するために、メディアクエリを使用するが、FlexBoxやGridLayoutだけでレスポンシブなレイアウトにすることも可能である。

参考サイト：CSS GridとFlexboxを使ってメディアクエリなしでレスポンシブにレイアウトする方法

※蛇足
上記参考サイトだと、FlexBoxやGridLayoutを適用したブロック内の要素のサイズも画面幅に応じて変化してしまうので、メディアクエリとGridLayoutを組み合わせてブロックの幅のみ画面幅に応じて変化し、ブロック内の要素のサイズは固定となる例を作ってみた。

サンプル：https://sympathia.hatenablog.com/entry/2019/06/08/011613

4.3 SassというCSSをプログラミング言語のような書き方ができる便利な形式

Sassとは、CSSをプログラミング言語っぽく書くことができるメタ言語（ある言語について何らかの記述をするための言語）である。HTML/CSSはあまり触ったことないがCやJava等なにかしらプログラム言語に触れたことがあるという方にはとっつきやすい。

・変数定義

$fontColor = #333;
$baseWidth = 960px;

・親子関係

.parent {
  width: 100px;
  p {
    font-size: 16px;
  }
}
// 実際に生成されるcss
// .parent {
//   width: 100px;
// }
// .parent p {
//   font-size: 16px;
// }

・継承

%box{
  width: 100px;
  height: 100px;
}
.color {
  background-color: bule;
}

.block{
  @extend %box;
  @extend .color;
}
// 実際に生成されるCSS
// .block {
//   width: 100px;
//   height: 100px;
//   background-color: bule;
// }

・関数化

@mixin grad($start: red, $end: blue){
  background: liner-gradient($start, $end);
}

.mixSample1{
  @include grad();
}
.mixSample2{
  @include grad(green, yellow);
}
//実際に生成されるCSS
// .mixSample1 {
//   background: liner-gradient(red, blue);
// }
// .mixSample2 {
//   background: liner-gradient(green, yellow);
// }

など、他にも色々できる。
ちなみにSassにはSASSとSCSSの２種類あり

・SASS記法（VBA/Ruby/Pythonなどと同じ書き方）

.class
  width: 100px;

・SCSS記法（C/Java/JS/PHPなどと同じ書き方）

.class {
  width: 100px;
}

4.4 要素の縦/横/中央揃えは良く使ったので押さえておいて損はない

ググるといくつか方法が見つかるが分かるまでは使い分け方がよく分からなかったため簡単にまとめておく。

(1) インライン要素　横方向中央寄せ

p {
  text-align: center;
}

(2) インライン要素　縦方向中央寄せ

// この方法だと2行以上に渡るテキストに対しては使えない
.parent {
  height: 100px;
}
.parent p {
  line-height: 100px;  //親要素のheightと同じ値にする
}

(3) ブロック要素　横方向中央寄せ

.block {
  margin: 0 auto;
}

(4) インライン要素/ブロック要素共通 縦方向中央寄せ

.parent {
  height: 200px;
  position: relative;
}
.child {
  position: absolute;
  top: 50%;
  transform : translateY(-50%);
}

(5) インライン要素/ブロック要素共通 中央配置

.parent {
  height: 200px;
  position: relative;
}
.child {
  position: absolute;
  top: 50%;
  left: 50%;
  transform : translate(-50%, -50%);
}

以下は、FlexBoxとGridLayoutを使用した場合の例である。
(6) Flexboxを使用した中央配置

.parent {
  display: flex;
  justify-content: center; //横方向中央寄せ
  align-items: center;     //縦方向中央寄せ
}

(7) GridLayoutを使用した中央配置

.parent {
  display: grid;
  grid-template-columns: 100px;
  grid-template-rows: 100px;
 
  .child {
    justify-self: center;  //横方向中央寄せ
    align-self: center;    //縦方向中央寄せ
  }
}

詳細は以下のサイトをご参照されたし

参考サイト1：CSSで中央寄せする9つの方法（縦・横にセンタリング）
参考サイト2：[CSS]要素を上下左右の中央に配置、最近主流になっている実装方法のまとめ

5. 本編：CSS素人がFLOCSSを試してみて出た疑問と知見と失敗と

FLOCSSを適用して詰まった点、悩んだ点、考えたこと、気付き事項などをまとめておく。

5.1. Layout層とObject層の境界すら迷子になった件

境界が迷子になる事案が主に２点あった。

(1) FLOCSSを取り入れた当初は、Layout層とObject層の境界の基準が良く分からなかった。
これを解消するのに、以下のイメージが役立った。

イメージ図引用サイト：FLOCSSを扱いきれないあなたに贈る、スリムなCSS設計の話

Layout層で、以下の図のように頁全体のレイアウト決め（土台となるブロックへの分割）を行えばよいかと考える。

(2) Layout層とObject層が重なったり、Objectの中にLayoutが入り込むケースがある
project層のブロック内の要素を横並びにしたい場合に、display:flexを使うとする。これは様々な箇所で良く使うので以下のように共通化するとして、「プロジェクト共通の(コンテナー)ブロックのスタイル」はLayout層なので、以下のようにしてみる。

.l-flex {
  display: flex;
  flex-flow: column;
  justify-content: space-around; //均等配置
}

そうすると、以下のようにLayoutとprojectが重なったり、Object層の中にLayoutがある状態になるケースが出てきた。

（例1）

<div class="l-main">
  <div class="l-flex p-block">
    <div class="p-block__element1">横</div>
    <div class="p-block__element2">並</div>
    <div class="p-block__element3">び</div>
  </div>
</div>

（例2)

<main class="l-main">
  <div class="p-block">
    <div class="l-flex p-block-sub">
      <div class="p-block-sub__element1">横</div>
      <div class="p-block-sub__element2">並</div>
      <div class="p-block-sub__element3">び</div>
    </div>
  </div>
</main>

これに関しては、(人の趣向等により)管理方針が以下３つ程上げられるかと考える。
※筆者は、display:～は一律Layout層内だけに存在するようにし、それをどこに適用しているか俯瞰して見れた方が良いと考えたため、②で管理することとした。

① Layout層ではなく、utility層で定義する
② 上記の例のように、Layout層としてhtmlに記述する（l-flexのような共通スタイルは、idがhtml内で1度しか使えないのでclassで定義せざるを得ない）。
③ cssにて、使用するObjectに対して継承する（例は以下を参照）。

// （例1）の場合
.p-block {
  width: 90%;
  @extend .l-flex;
}
// （例2）の場合
.p-block-sub {
  font-size: 20px;
  @extend .l-flex;
}

5.2. 後から気付いたLayout層はこうすれば良かった説

レスポンシブ対応とGridLayoutの使いどころを押さえるのを後回しにしていために起きた悲劇を紹介する。

GridLayoutはある程度自由にブロック分けできるので、以下図のようにGridLayoutで表示するコンテンツの各領域となるブロックに分ける、というのをLayout層で行うのが賢いやり方だと後から気付いた。
（筆者はGridLayoutを使わずに以下図のようなレイアウト調整を行ってしまった）

5.3. やはりProject層とComponent層の分類が曖昧になった件

公式のサンプルを見ているproject層とcomponent層の分け方には、以下のパターンが見受けられた。

(1) project層の中にproject/component

<div class="p-block">
  <div class="c-heading">～</div>
  <div class="p-block-body">
    ：(略)
  </div>
</div>

上記例の".p-block-body"の中にまたproject/componentがある構造となっているようなものもあった。

(2) project層のelementをcomponentに合わせる

<div class="p-block">
  <input type="button" class="p-block__element c-button" />
    ：(略)
</div>

FLOCSSでは、各層のモジュールを独立させることで再利用性を保つようにしているが
Project層がComponent層のモジュールを変更することだけは許容している。上記の例のようにすることで、CSSの優先度により、".c-button"のスタイルを".p-block__element"で上書きする(変更する)ことができる。

(3) projectもcompoentも別々

<div class="p-block">
  <div class="p-block__element">
     :
  </div>
</div>

<div class="c-media">
  <div class="c-media__element">
     :
  </div>
</div>

上記例のように最小単位のボタン等の部品をいくつか含むブロックをcomponentとするケースもあるようだが、そうすべきケースまでは分かっていない。最小単位をどう定義するか次第だと考える。

projectとcomponentの分け方の考えた方については以下記事が参考になるかと思われる。

参考サイト：　FLOCSSを使ったCSS設計での悩みどころと解決案

以下、自分でこうすればよいか？と考えたproject層/component層の分け方の独自方針について記述する。
主な方針は以下の通りとした。

• 部品を使用するページや媒体(PC,タブレット,スマフォ等)が変わっても、スタイルを変えないプロパティ(または基準とするプロパティ)はcomponentに配置
• 逆に変える必要があるプロパティ(またはcomponentで定義した基準を上書いて変更するプロパティ)はprojectに配置

こうすることで、Objectを別のページで使用する場合（スタイルの変更が必要なケース）やレスポンシブ対応のためにメディアクエリでコードを書く際に、componentはそのまま使用でき、projectだけ既に書いたコードを流用しつつスタイルの値を修正するだけで済むので実装がしやすくなると考えたためである。
デメリットとしては、projectとcomponentがセットで扱うことを意識する必要があること（projectとcomponentのどのクラスが結びついているか名称やコメントで管理せざるを得ない、projectのクラスにcomponentのクラスを継承(extend)して管理した方がよいかもしれない）。

<div class="c-article p-article">
  <div class="c-article__img p-article__img"></div>
  <div class="c-article__title p-article__title"></div>
  <div class="c-article__date　p-article__date"></div>
</div>

.p-article {
  width: 150px;
  height: 200px;
  margin: 5px;
  
  .p-article__img {
    width: 150px;
    height:100px;
  }
  .p-article__title {
    height: 80px;
    display: flex; 
  }
  .p-article__text {
    line-height: 18px; //行間の幅指定
  }
}

.c-article {
  background-color: white;
  border: 1px solid #333;

  .c-article__img {
    margin: 0 auto;  //横中央揃え
  }
  .c-article__title {
    font-size: 16px;
    text-align: center;
  }
  .c-article__text {
    font-size: 13px;
    text-align: center;
  }
}

もしもproject層とcomponent層は分け方が分からない場合かつ作成物のデザインが複雑でない、規模が大きくないならば、無理に分けずにまずはProject層とComponent層を１つの層（例えばObject層）としても良いと思われる。

5.4. 実はObject層のProjectとUtilityの分け方も若干迷った件

marginとpaddingは、ブロックの外側または内側の余白を作るためのスタイルで、公式ではutilityになっているように取れる（「Object自体が持つべきでない」がどこまでか線引きが曖昧なため）

Object自体が持つべきではないmarginの代わりに.mbs { margin-bottom: 10px; }のようなUtility Objectを用いて、隣接するモジュールとの間隔をつくるといった役割を担います

（HTMLとCSSを並行して作成していた可能性もあるが少なくとも）要素に対するmarginとpaddingに関しては、project層に配置する方が管理しやすいと感じた。理由は以下の３つである。

• サイズ調整/修正がしやすかった（微調整のためにHTML(下部例のようなケースだとclassのu-mg-tb5を変更要)とCSS(下部例のようなケースだと.p__btnの幅/高さや位置を修正要)を行ったり来たりする必要があるので非効率に感じた）。
• HTMLに書くとレスポンシブ対応を考えた際に融通が利かずutility層の汎用性が落ちる（端末毎で要素間のmarginを変える場合、下部例だとutitlity層のクラスにメディアクエリを適用する必要が出てくる）
• 以下のようなケースの場合に、htmlに書くとコードが冗長だと感じてしまう

例（画面表示/HTML/CSS）：

<div class="l-flex p-block">
  <div class="p-block__btn c-btn u-mgn-tb5">ボタン１</div>
  <div class="p-block__btn c-btn u-mgn-tb5">ボタン２</div>
  <div class="p-block__btn c-btn u-mgn-tb5">ボタン３</div>
  <div class="p-block__btn c-btn u-mgn-tb5">ボタン４</div>
</div>

.mgn-tb5 {
  margin: 5px 0; //上下5px
}
// Layout層、Project層、Component層は省略

以上からmarginとpaddingはProject層に入れてもいいのではと考える。前述の通り、以下のようにすることでproject層のファイルを見るだけで、要素のサイズに対するプロパティを集約できる（個人的には以下例のようにmarginのプロパティのみ定義しているクラスを継承しても、そのクラスの内容を確認するためにUtility層のファイルを見る必要があり可読性が落ちるため、marginのプロパティを直接記述した方が良いと考える）。

.p-block {
  width: 50px;
  @extend .u-mgn-tb5;  //もしくは margin: 5px 0; と記述してしまう
}

5.5. 最終的にUtility層はスカスカになった件

筆者がプログラミング経験者のため、コーディングの際に不要なものは実装しないという固定観念から必要なスタイルのみを実装したが、公式のサンプルを見ると必要/不要に関わらず何パターンも実装していた。

// margin
.u-m0 {
margin: 0;
}
.u-m1 {
margin: 1px;
}
.u-m2 {
margin: 2px;
}
.u-m3 {
margin: 3px;
}
.u-m4 {
margin: 4px;
}
.u-m5 {
margin: 5px;
}
// 以下続く

上記のようにすることで、他のWebサイトを新規に作成する際にもそのままUtility層のファイルは流用できる。
そのため、必要になりそうなものは事前に実装した方がよいと考える。

※ただ、(Sassファイルから生成される)CSSファイルに、実際には使用していないクラスも含まれてしまい、ブラウザで表示する際に、HTML上の各要素に使用されているクラスをCSSファイルから検索する際に検索する母数が増えるので表示速度が落ちるではないか？（HTML/CSSを読み込んでブラウザに表示する際の詳細な仕組みまで押さえれていないため前提が間違っていたらすみません）それなら、使用しないクラスをCSSファイルに入れないよう工夫した方が良いと考えるが、それを実現する方法をすぐに思い付かなかったため割愛


### 5.6. ファイルの分け方を誤ってしまった件

以下図のように、概ねLayout層でブロック分けしている領域毎に対応するようProject/Component層のファイルを作成した。

![ファイル名.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/319263/89048444-441f-5d2a-c761-3b1f632373a5.png)

Component層は類似部品ベースでファイルを分けるべきであった。複数頁に渡って共通で使用できる部品が少なかったため問題とまではいかないものの再利用性に欠ける部分があるのは否定できない。こうなった理由は次節で述べる。
またLayout/Project/Component層で同じ名前のファイルが存在したため、編集しているファイルがどの層のものか常に確認しながら行うという手間が発生したため、ファイル名はどの層のものか一目で分かるように工夫した方が良いと思う。

### 5.7. うまく行かなかった要因の１つは最初から基本的な進め方から反れていたから説

実装の際、ある程度しっかり作ったデザインを基に、HTMLを少し書く→そこに対応するCSSを記述、といった具合にHTMLとCSSを交互に少しずつ作成していった。HTML/CSS実装経験がなかったため、どう実装すれば思い通りの配置になるかイメージできなかったため、確認しながら進めたからである。（そのためスピードも出なかった）

本来は、以下作業は分けて行うのかと思う。
・HTML実装
・CSS設計
・CSS実装

デザインを見て、HTMLのブロック構造をどうすればいいかイメージできれば、上記の作業を１つずつこなせるかと思う。前述の通り、経験値がないためHTMLのブロック構造をイメージできず、上記作業を並列に行ったためにそれがファイルを適切に分けられなかった一番の要因に繋がったと考える。

### 5.8. 設計手法に曖昧な部分があるからこそ管理しやすいように独自ルールを考えてもいい説

調べる中で、いくつか拝見したが、開発を行いやすくする目的で独自のルールを導入するケースが見受けられた（なので、自分も管理しやすくする目的で5.3節で紹介した独自ルールを考えてみた）。
これらの先人達の手法の中から個人もしくはチームで作成する物に合ったルールを探してみるのもよいと考える。

・他設計手法にもあるレイヤーを増やすのもあり
>参考：[CSSの設計 – FLOCSSをベースにしたファイルの構成と命名規則を考える](https://www.tam-tam.co.jp/tipsnote/html_css/post10205.html)

・独自のレイヤーを追加する
>参考：[【CSS設計】FLOCSSを導入してみて気づいた８つのポイント](https://www.indival.co.jp/2016/08/26/3102/)

・細部に独自のルールを追加する
>参考：[FLOCSSベースのオレオレCSS設計の紹介](https://latele.co.jp/blog/front-end/2018/0903_11)

## 6.最後に
HTML/CSSをほぼ１から学習し、CSS設計手法「FLOCSS」を適用して出くわした問題や失敗内容についてまとめた。FLOCSS及びポートフォリオ制作に関しての個人的な今後の課題は以下の通りである。

・Compoent層とProject層の分け方
公式ドキュメント作成者が執筆した以下の本があるため、こちらも読んで勉強する必要がある。
>[【PDF版】柴犬でもわかるFLOCSS](https://mamehiko.booth.pm/items/1033385)

・Component層とProject層のファイルの分け方
部品ベースでのファイルを分けるべきであった。ただ、どのページで使用している部品かをある程度把握しやすいようにしておきたいため、どう折り合いをつけるかは検討が必要である。

・命名規則「MindBEMding」について
Block部分の命名の決め方が途中から分からなくなり、独自の命名ルールで進めたため、こちらも要確認。

・CSSフレームワーク（Bootstrap/Fomantic UI等）
(仕事/残業/勉強会参加しながらのためでもあるが)開発スピードが出てないため、スピード向上のため次作品以降はCSSのフレームワークの導入することを検討する必要がある。
有名なBootstrap以外にいくつか存在し、とある勉強会で存在を知ったSemantic UI(現在はForkされてFomantic UIとして開発が進められている)には、Bootstrapより画面分割数が多く、JQuery、React、Vueに対応した版もあるとのことなので試してみたい。

~~他にも、ポートフォリオ制作に関して以下実装が必要である。
・レスポンシブ対応
・画面の動的処理実装
・画面とサーバサイド間の非同期通信
・サーバサイド実装~~

~~最後に、本記事はHTML/CSS/FLOCSSの学習の総集編のようなものにしてしまったため、ボリュームが大きくなってしまった。今後はもう少し小出しにすることを意識したい。
直近はPHP/Laravelの学習とCI/CDの仕組みづくりに取り組むため、次はこれらの記事を何か書ければと思う。~~

以上。

**【2020/8末追記】
開発物を変え、本記事の続きにあたる記事を書いたため、こちらも一読頂ければ幸いです。
5章の疑問等が解消できたため、その点を中心に記載しています。**

**[1年前に素人がFLOCSS使って直面した疑問/失敗に対し、PRECSSを学んで解消 / 前進できた話](https://qiita.com/SYM_simu/items/9d653155fd98e12a641c)**

## 参考サイト一覧
・[各CSS設計手法を取り入れる上でのメリット・デメリットをまとめてみた](https://qiita.com/nezurika/items/a964e21d3596b0ee4c9a)
・[OOCSS、BEM、SMACSS、FLOCSS、RSCSSを比較して自分にあった設計思想をみつける](https://kuroeveryday.blogspot.com/2017/03/css-structure-and-rules.html)
・[各CSS設計手法を取り入れる上でのメリット・デメリットをまとめてみた](https://qiita.com/nezurika/items/a964e21d3596b0ee4c9a)
・[より良いCSSを書くための様々なCSS設計まとめ](https://uxmilk.jp/43386)
・[SUIT CSS](https://github.com/suitcss/suit/blob/master/doc/design-principles.md#modularity)
・[CSS設計を学ぼう](https://www.marineroad.com/staff-blog/13023.html)
・[FLOCSS公式ドキュメント](https://github.com/hiloki/flocss)
・[FLOCSS公式設計デモ](https://github.com/tacrow/flocss-demo)
・[CSSができる人とできない人では何が違うのか？(レイアウト編)](https://blog.mitsuruog.info/2018/03/how-to-learn-css-1)
・[css display flex の 使い方（中央寄せなど）](http://katoon.net/css3_flexbox-2017-06-07/)
・[CSS Grid Layout を極める！（基礎編）](https://qiita.com/kura07/items/e633b35e33e43240d363)
・[CSS Grid Layout を極める！（場面編）](https://qiita.com/kura07/items/486c19045aab8090d6d9)
・[特徴で使い分けたいCSSレイアウト手法](https://ics.media/entry/15921/)
・[CSS GridとFlexboxを使ってメディアクエリなしでレスポンシブにレイアウトする方法](https://parashuto.com/rriver/development/responsive-layout-with-css-grid-and-flexbox)
・[CSSで中央寄せする9つの方法（縦・横にセンタリング）](https://saruwakakun.com/html-css/basic/centering)
・[[CSS]要素を上下左右の中央に配置、最近主流になっている実装方法のまとめ](https://coliss.com/articles/build-websites/operation/css/absolute-centering-with-css.html)
・[FLOCSSを扱いきれないあなたに贈る、スリムなCSS設計の話](https://webnaut.jp/technology/20170407-2421/)
・[FLOCSSを使ったCSS設計での悩みどころと解決案](https://qiita.com/uggds/items/d904b2f9a103c37a25fa)
・[CSSの設計 – FLOCSSをベースにしたファイルの構成と命名規則を考える](https://www.tam-tam.co.jp/tipsnote/html_css/post10205.html)
・[【CSS設計】FLOCSSを導入してみて気づいた８つのポイント](https://www.indival.co.jp/2016/08/26/3102/)
・[FLOCSSベースのオレオレCSS設計の紹介](https://latele.co.jp/blog/front-end/2018/0903_11)
・[【PDF版】柴犬でもわかるFLOCSS](https://mamehiko.booth.pm/items/1033385)
・[Fomantic UI](https://github.com/fomantic/Fomantic-UI)