Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
CSS Application Architecture
Search
Nicolas Gallagher
September 10, 2013
Programming
15
580
CSS Application Architecture
An introduction to the aims and design of the SUIT framework
Nicolas Gallagher
September 10, 2013
Tweet
Share
More Decks by Nicolas Gallagher
See All by Nicolas Gallagher
React Native for web and beyond
necolas
5
990
Thinking beyond "Scalable CSS"
necolas
14
7k
Making Twitter UI Infrastructure
necolas
14
4.2k
Adaptation and Components
necolas
6
1.3k
HTML5 Boilerplate: past, present, and future
necolas
4
260
The purification of web development
necolas
5
530
Other Decks in Programming
See All in Programming
0から始めるモジュラーモノリス-クリーンなモノリスを目指して
sushi0120
0
250
Reactの歴史を振り返る
tutinoko
1
170
新しいモバイルアプリ勉強会(仮)について
uetyo
1
250
AIのメモリー
watany
13
1.3k
階層化自動テストで開発に機動力を
ickx
1
480
CEDEC2025 長期運営ゲームをあと10年続けるための0から始める自動テスト ~4000項目を50%自動化し、月1→毎日実行にした3年間~
akatsukigames_tech
0
110
『リコリス・リコイル』に学ぶ!! 〜キャリア戦略における計画的偶発性理論と変わる勇気の重要性〜
wanko_it
1
300
Scale out your Claude Code ~自社専用Agentで10xする開発プロセス~
yukukotani
8
1.6k
decksh - a little language for decks
ajstarks
4
21k
Terraform やるなら公式スタイルガイドを読もう 〜重要項目 10選〜
hiyanger
12
2.9k
PHPUnitの限界をPlaywrightで補完するテストアプローチ
yuzneri
0
390
Amazon Q CLI開発で学んだAIコーディングツールの使い方
licux
3
180
Featured
See All Featured
RailsConf 2023
tenderlove
30
1.2k
Reflections from 52 weeks, 52 projects
jeffersonlam
351
21k
How to train your dragon (web standard)
notwaldorf
96
6.2k
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
357
30k
How to Ace a Technical Interview
jacobian
278
23k
Building Applications with DynamoDB
mza
95
6.5k
Faster Mobile Websites
deanohume
308
31k
Done Done
chrislema
185
16k
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
Docker and Python
trallard
45
3.5k
Building Better People: How to give real-time feedback that sticks.
wjessup
367
19k
Transcript
CSS Application Architecture @necolas
What’s the difference between “Architecture”, “Framework”, and “Toolkit”?
Architecture… a plan about how to structure an application.
None
Framework… an implementation of an architecture that someone can use
as the basis for a working application.
None
Toolkit / Library… a collection of pre-built patterns that can
be assembled to create an application.
None
Making architectural decisions
Client / Agency work
None
I don’t need an architecture!
None
None
Long-lived product work
No clients to blame :(
Find the right problems
Clean code! …no
“Does he ever think of anything rbut himself?”
Dealing with change
Reducing helplessness
Communicate ways of thinking
The freest human is the one who never has to
choose
1. Single responsibility 2. Extension over modification 3. Composition over
inheritance 4. Low coupling 5. Encapsulation 6. Documentation
Home Sidebar Tweetbox .home .sidebar .tweetbox { ... } .home
.footer .listbox { ... } Footer Listbox
Home Sidebar Tweetbox .tweetbox { ... } .listbox { ...
} Footer Listbox
SUIT framework github.com/suitcss/suit
Web Component-y .tweet { /* make it look good */
} .avatar { ... } .text { ... } <article class="tweet"> ... <img class="avatar" ...> ... <p class="text">...</p> </article>
# utilities u-utilityName # components ComponentName ComponentName--modifierName ComponentName-descendantName # js
utilities js-hookName
None
HTML example <article class="Tweet is-favorited"> ... <img class="Avatar Avatar--large" ...>
... <p class="Tweet-text">...</p> </article>
.Tweet { ... } /* Component */ .Tweet.is-favorited { ...
} /* State */ <article class="Tweet is-favorited"> ... <img class="Avatar Avatar--large" ...> ... <p class="Tweet-text">...</p> </article>
.Tweet { ... } /* Component */ .Tweet-text { ...
} /* Descendant */ <article class="Tweet is-favorited"> ... <img class="Avatar Avatar--large" ...> ... <p class="Tweet-text">...</p> </article>
.Avatar { ... } /* Component */ .Avatar--large { ...
} /* Modifier */ <article class="Tweet is-favorited"> ... <img class="Avatar Avatar--large" ...> ... <p class="Tweet-text">...</p> </article>
<article class="Tweet"> <a class="u-linkComplex" ...> ... <b class="u-linkComplex-target"> {user.name} </b>
<span class="u-textMute"> {user.screenname} </span> </a> <p class="Tweet-text u-textBreak">...</p> ... </article>
<article class="Tweet"> <a class="u-linkComplex" ...> ... <b class="u-linkComplex-target"> {user.name} </b>
<span class="u-textMute"> {user.screenname} </span> </a> <p class="Tweet-text u-textBreak">...</p> ... </article>
<article class="Tweet"> {{>partials/tweet_useridentity}} <div class="u-sizeFit"> {{>partials/tweet_text}} {{>partials/tweet_media}} {{>partials/tweet_actions}} </div> </article>
<x-tweet user-fullname="{{user.fullname}}" user-screenname="{{user.screenname}}" user-avatar="{{user.avatar}}" show-actions show-media> {{text}} </x-tweet>
What about RWD?
bostonglobe.com
92 separate @media directives 27 different width values 380 480
481 600 620 639 640 700 750 768 788 799 800 809 810 900 930 931 960 980 1024 1050 1100 1200 1210 1220 1400
Restraint required
@import “component/grid-v1.css”; @import “component/grid-v2.css” (min-width: 20em); @import “component/grid-v3.css” (min-width: 50em);
.v1-u-size1of2 { ... } .v2-u-size1of4 { ... } .v3-u-size1of6 {
... }
Tooling
bower.io
# bower.json { "name": "my-app", "dependencies": { "normalize-css": "~2.1.0", "suit-utils":
"~0.6.0", "suit-button": "~2.0.0”, "suit-grid": "~0.2.0", ... } }
None
CSS preprocessing
Automatic vendor prefixes
.Button { background: linear-gradient(…); }
.Button { background: -webkit-linear-gradient(…); background: linear-gradient(…); }
CSS variables
:root { var-button-bg: linear-gradient(…); } .Button { background: var(button-bg); }
.Button { background: linear-gradient(…); }
Conformance checking
Nothing is perfect Nothing lasts Nothing is finished
Accept transience and imperfection
End