Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
FLOCSSの知見と独自解釈
Search
TakuyaTaniguchi
August 29, 2019
Programming
360
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
FLOCSSの知見と独自解釈
TakuyaTaniguchi
August 29, 2019
Other Decks in Programming
See All in Programming
Apple Intelligence を用いた個人情報誤送信防止、及びユーザーリクエスト体験の改善について
yukiny
0
350
AIで開発が速くなった先で、開発チームは何を目指すか
shihochan
1
1.6k
當我們開始不讀 Code - AI Agent 時代,Code Review 與 Clean Code 還剩下什麼?
jame2408
1
260
KiroのSpecで「五目並べ」を作ってみる
satoshi256kbyte
1
380
Next.js: The final boss of Web Performance
guaca
0
280
Agentic Software Factoryに、すごく賢いIF文を。 / super smart IF statement into the Agentic Software Factory.
rkaga
8
2.3k
【加筆修正版】Laravel のアプリケーションをどこにデプロイするか #phpcon_ehime
akase244
0
150
APNsからLive Activityを開始する話
yumnumm
0
170
複雑なUIコンポーネントとの ⻑い付き合い⽅:波及するバグからテスト戦略を経て、安全な再設計へ
mixplace
0
430
Everything will be SERVERLESS — 信じて運用した10年の経験値 / Everything Will be Serverless — Lessons Learned from 10 Years of Operational Experience
seike460
PRO
1
1.1k
Simple Storage Service(S3) is not simple
iwatsukayura
0
290
Herb in Rails 8.2: Your ERB views, now HTML-aware @ Rails World 2026, Austin, Texas
marcoroth
0
220
Featured
See All Featured
XXLCSS - How to scale CSS and keep your sanity
sugarenia
250
1.3M
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
28
3.7k
AI Search: Implications for SEO and How to Move Forward - #ShenzhenSEOConference
aleyda
1
1.4k
Marketing Yourself as an Engineer | Alaka | Gurzu
gurzu
0
330
Optimizing for Happiness
mojombo
378
71k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
9
1.6k
Test your architecture with Archunit
thirion
2
2.4k
Marketing to machines
jonoalderson
1
5.9k
How GitHub (no longer) Works
holman
316
150k
Tell your own story through comics
letsgokoyo
1
1.1k
How to Align SEO within the Product Triangle To Get Buy-In & Support - #RIMC
aleyda
2
1.8k
Digital Ethics as a Driver of Design Innovation
axbom
PRO
1
460
Transcript
FLOCSS の知⾒と独⾃解釈 FLOCSS の知⾒と独⾃解釈
はじめに はじめに 簡素な静的サイトや、CMS を組み合わせた中規模程度のサイトで約⼀年ほど、 FLOCSS を使⽤してきました。 本スライドでは、その中で感じた利点、公式ドキュメントとは違った運⽤⽅法 や知⾒を共有したいと思います。 ※ 必ずしも本スライドに書いてある事が正しいというわけでありません。
また後述に記載している、Github の公式ドキュメントを読み終わっている前提 で記載しています。 環境構築⽅法や、CSS,SCSS の書き⽅などには⾔及していません。
FLOCSS とは FLOCSS とは BEM,SMACSS などを取り⼊れつつ, モジュラーなアプローチのためのCSS 構成案 です。 アイデア集的な要素もあり、FLOCSS
の考え⽅を基本としながらも、 開発現場によって独⾃に拡張しやすいのが特徴です。 コーポレートサイトやLP などデザインパーツが多彩なプロジェクトに適して いると感じています。 github 書籍 https://github.com/hiloki/flocss https://mamehiko.booth.pm/items/1033385
FLOCSS の利点 FLOCSS の利点 設計ルールが単純なため、プロダクト途中の参加や引き継ぎが容易 ファイル構成と命名規則が明確なため、別のプロジェクトにもデザインパ ーツを移植しやすい。 js フレームワークの恩恵が無い( ファイル単位でCSS
のスコープが持てない) 環境でも難解な上書きが発⽣しにくい。 クラスの影響範囲が予測しやすい。
設計概要 設計概要 簡単な設計概要を説明します。 下記の3 つのレイヤーとObject レイヤーの⼦レイヤーから構成されます。 クラス名にそれぞれのモジュールのプレフィックスをつけて管理します。 F Foundation L
Layout (l-layout.scss) O Object | ー project (p-project.scss) | ー component (c-component.scss) | ー utility (u-utility.scss)
Foundation Foundation Foundation レイヤー reset.css やベース、フォント⽤のCSS を定義します。 variable などの変数管理もこちらに定義します。 プロジェクトごとの基本設定が該当します。
Layout Layout Layout レイヤー ヘッダーやフッター, サイドバーなどを定義する際に使⽤します。 後述しますが、なるべくカラーなどの装飾寄りのCSS プロパティを含まないよ うにします。
<header class='l-header'> <div class='l-header_inner'></div> </header> <aside class='l-sidebar'> <div class='l-sidebar_inner'></div> </aside>
<footer class="l-footer"> <div class="l-footer_inner"></div> </footer>
Project Project Project レイヤー FLOCSS に置いてもっとも重要で、判断が難しいデザインパーツです。 component が集まって構成されるパーツや、プロダクト固有のものを定義しま す。 恐らく、ファイル数がもっとも増えるレイヤーになります。
ファイル名もあえて、汎⽤性を意識しないことが多く、たとえ似通ったデザイ ンであっても, ⽤途が違えばファイルごと複製する事が多いです。 少しイメージしにくかもしれませんが、component は必要最低限のパーツであ り、project はcomponent が複数集まった塊です。 ただし、project ⼀つのレイヤーで完結する場合もあります。
<div class='p-event'> <div class='p-event_item'> <div class='p-event_title c-title'>EVENT</div> </div> </div> <div
class='p-news'> <div class='p-news_item'> <div class='c-title'>NEWS</div> </div> </div> <div class='p-banner'> <p class='p-banner_text'>売 出 中!!!</p> </div>
/* p-event.scss */ .p-event{ &_item{} &_title{} } /* p-news.scss */
.p-news{ &_item{} } /* p-banner.scss */ .p-banner{ &_text{} }
component component Component レイヤー 汎⽤性の⾼いパーツに利⽤します。 プロジェクト内で複数使われるデザインや、ボタン、リンクなどもこのレイヤ ーに該当します。 下記の"c-card" の例のように、複数利⽤前提の場合は、 ラップする要素を含めて⼀つの
モジュールとして扱うと都合が良い場⾯が多 いです。
<div class='c-card'> <div class='c-card_item'> <div class='c-card_title'> <p> </p> </div> </div>
<div class='c-card_item'> <div class='c-card_title'> <p> </p> </div> </div> </div> <button class='c-button'>CLICK</button>
Utility Utility Utility レイヤー Utility は例外⽤のヘルパーレイヤーになります。 マージンの調整や、アニメーションなどの⽤途に使う事が多いです。
FLOCSS の設計ルール FLOCSS の設計ルール FLOCSS を使⽤する上で、もっとも重要な部分になります。 提唱されているルールを守ることで, 堅牢かつ変更に耐えやすい設計になりま す。 FLOCSS
の主な設計ルール ・ファイル名とクラス名は統⼀する ・⼀つのCSS ファイルに対して、⼆つ以上のクラスを追加しない。 ・モジュール同⼠のネストは禁⽌ ・Object レイヤーは Project Compoent Utilty の順番に追記する。 ・同レイヤーのクラスの重ねがけは禁⽌
ファイル名とクラス名は統⼀する。 ファイル名とクラス名は統⼀する。 ファイル名とクラス名を統⼀をすることで、視認性と検索の精度が⾼まりま す。 クラス名に変更があった際は、必ず合わせてファイル名も変更するようにしま しょう。
⼆つ以上のクラスブロックを追加しない。 ⼆つ以上のクラスブロックを追加しない。 ⼀つのCSS ファイルに⼆つ以上のクラスブロックを定義するのはNG です。 CSS の影響範囲の予測が困難になり、検索精度も下がります。 ⾔葉だとわかりにくいかと思いますので、例を確認してください。
/*c-card.scss*/ /* NG */ .c-card{ &_title{} } .c-title{ }
モジュール同⼠のネストは禁⽌ モジュール同⼠のネストは禁⽌ 組み合わせによってセレクタの優先度が変わってしまうため モジュール同⼠のネストは禁⽌です。
/* NG */ .c-card{ &_title{} /* 別 読 込 */
.c-article{ &_title{} } }
Object レイヤーは Project Compoent Utilty の順番に Object レイヤーは Project Compoent
Utilty の順番に 記載します。 記載します。 別レイヤー同⼠で、クラス名を追記する時は P > C > U の順番で書くと 視認性が⾼まります。( より左あるクラスの⽅が詳細度が⾼い) ※ 公式の書き⽅は逆になります。
<div class='l-contents'> <div class='l-contents_inner'> <div class='p-news'> <div class='p-news_title c-title u-textGradation
</div> </div> </div>
同レイヤーの重ねがけは禁⽌ 同レイヤーの重ねがけは禁⽌ 詳細度の特定が困難になるため、同⼀レイヤーの重ねがけはNG です。
<!-- NG --> <div class='l-contents l-header'> <div class='l-contents_inner'> <div class='p-news
p-event'> <div class='p-news_title p-titleStrong'>TITLE</d </div> </div> </div>
悩みどころと独⾃解釈 悩みどころと独⾃解釈 FLOCSS を実際に書いていく中で、悩んだところ、 また独⾃に解釈し運⽤を進めた箇所を記載します。 FLOCSS はある程度、開発側に柔軟に変更する余地を与えているので、それぞ れの環境に適した対応が可能です。 ・layout のproject
か ・project かcomponent か ・モディファイアの扱い⽅ ・js のターゲットクラス
layout か project か layout か project か ヘッダーなどをlayout レイヤーで作成する際に、付随するロゴやナビゲーショ
ンをlayout レイヤーにするのか、puroject レイヤーで作成するのか、悩みどこ ろです。 ここは、個⼈的な解釈になりますが、project で作成する⽅が管理がしやすいと 思います。 layout にまとめると、⼀つのCSS ファイルが肥⼤化してしまいFLOCSS の利点が 薄れてしまいます。 あくまでlayout は" サイト構造のCSS" を記述するだけに留め、" 装飾を⽬的とし たCSS" はporoject レイヤーに担ってもらうべきという考えです。
<!--GOOD--> <div class='l-header'> <div class='l-header_inner'> <div class='p-logo'> <img class='p-logo_img' src='/src/hoge.png'
alt= </div> </div> </div> <!--NG--> <div class='l-header'> <div class='l-header_inner'> <div class='l-header_logo'> <img class='l-header_logo_img' src='/src/hoge.pn </div> </div>
project か component か project か component か project を"
プロダクト固有のものを定義" 、component を" プロジェクト内で複 数使われるデザイン" と書きましたが 実際に書き始めると⼆つのレイヤーの区別に悩んでしまうものです。 この場合の解決策として、最初は" 迷ったらproject レイヤー" にする。という⽅ 針で進めていました。 FLOCSS は常にリファクタリングしながら構築する必要があり、project レイヤ ーに同じCSS を書き続けている事があれば、都度抜き出して、component レイ ヤーに書き出す⽅法が⼀番無難かと思います。
モディファイアの扱い⽅ モディファイアの扱い⽅ layout,project,component それぞれにモディファイアクラスが必要になる場⾯が あります。 ここは好みによるのですが、モディファイアは" ハイフン" で始めるクラス名に 統⼀しています。 ⼀つのファイルにモディファイアが増えていると感じたらファイル切り出しの
合図です。 その他にもモディファイアを付与したクラスにさらにネストしてスタイルを付 与する場合は、別のモジュールに切り出す⽅が無難です。 ⾔葉ではわかりにくいので例を確認してください。
/* NG */ /* c-card.scss */ .c-card{ &_inner{ &.-is-block{ /*
付与 必要 */ .c-card_title{} .c-card_desc{} } } &_title{} &_desc{} } /* OK */
js のターゲットクラス js のターゲットクラス クラス名をトリガーにDOM 操作などを⾏う場合は、"js-" のプレフィックスを付 きのクラスを作成します。 このクラスには装飾やレイアウトなど⼀切のCSS プロパティを付与しません。
まとめ まとめ 以上が私⾃⾝が⼀年FLOCSS を利⽤した際の知⾒や運⽤⽅法になります。 最初は⼾惑うことも多く、CSS を書く量が増えてしまうと感じるでしょう。 しかし、作成したレイヤーはプロジェクトを横断して利⽤可能で、ルール通り 構築していれば、ファイルの移植も⾮常に簡単です。 また、リファクタリングの⼿軽さにも優れており、クラスの影響範囲も把握し やすいです。
HTML,CSS の設計に正解はありません、⼿軽に書けてしまう反⾯、容易に崩壊 しやすく、リファクタリングの難度も上がります。 可能な限り、秩序ある設計を⼼がけていきましょう!