- インストール
- https://tailwindcss.com/docs/installation
create-next-app
なら最初の対話形式で選択肢がある
@tailwind
は何をしているか- https://tailwindcss.com/docs/functions-and-directives
- tailwindlabs/discuss#397
- https://qiita.com/oedkty/items/68461080515ec1012980#tailwind
base
- https://tailwindcss.com/docs/preflight
- modern-normalize? reset スタイル
components
- デフォルトのコンポーネントのクラス。
container
だけしかない?
- デフォルトのコンポーネントのクラス。
utilities
- デフォルトのユーティリティクラス
- デフォルトで生成されるのが
tw-default.css
の内容- 例えば
font-bold
など、最初から利用できるクラスは上述の directive に含まれているものになるはず
- 例えば
- DevEx
- https://github.com/tailwindlabs/tailwindcss-intellisense
- 補完、Lint, hover で CSS を表示、シンタックスハイライト
-
{ "editor.quickSuggestions": { "strings": "on" }, }
- これを settings.json に入れておくとクラス名の記述に対しサジェストがすぐに出て良い
- https://github.com/tailwindlabs/prettier-plugin-tailwindcss
- 推奨される class の順番で並べる
- https://tailwindcss.com/blog/automatic-class-sorting-with-prettier
- base, components, utilitiesの順番
- utilitiesの他のクラスのスタイルを上書きするクラスは後方へいくように
- modifiersはutilitiesの後方へ
- responsive modifiersはthemeの設定の順のまま、最後へ
-
there is no way to change the sort order.
- tailwindlabs/prettier-plugin-tailwindcss#113
- vscodeで動かない場合がある?
- エディター上のunknown at ruleにどう対処するのが良い?
- tailwindlabs/tailwindcss#5258
- tailwindのIntelliSense plugin入れていれば↓で解決するはず
-
"files.associations": { "*.css": "tailwindcss" }
- https://github.com/tailwindlabs/tailwindcss-intellisense
- tailwind は postcss plugin にできるので、当然他の postcss プラグインと一緒に使える
create-next-app
だとデフォルトで autoprefixer 入っている- cssnano 入れて minify もできる(next.js だと minify は自動で行われる)
- JIT
- おそらく v3 からは
デフォルト?唯一のモード - オンデマンドで必要なスタイルだけ動的生成
- https://tailwindcss.com/blog/just-in-time-the-next-generation-of-tailwind-css
- https://patrickkarsh.medium.com/understanding-just-in-time-jit-mode-for-tailwind-css-c4aee27c5ab8
safelist
で必ず生成するクラスを指定できる
- おそらく v3 からは
- コアコンセプト
- 基本
- https://tailwindcss.com/docs/utility-first
-
Building complex components from a constrained set of primitive utilities.
- クラス名が羅列された HTML は戸惑うけど、
- プリミティブなユーティリティの組み合わせによって複雑なコンポーネントを構築する
- クラス命名から解放される
- CSS ファイル肥大化しない
- 対象箇所の HTML のスコープに閉じて変更できる
- HTML に閉じれる利点がすぐに理解できるはず
- ただのインラインスタイル?
- 違う
- クラスによる一定の制約がもたらされる
- インラインスタイルだとメディアクエリーが使えないけど、 https://tailwindcss.com/docs/responsive-design が使える
- hover, focus などに対応できる
- 違う
- メンテできるのか
- state
- https://tailwindcss.com/docs/hover-focus-and-other-states
- 親要素の state に基づいてスタイルあてる場合、
group``group-*
を使う - 兄弟要素の state に基づいてスタイルあてる場合、
peer``peer-*
- スタイルの再利用
- https://tailwindcss.com/docs/reusing-styles
- エディタのマルチカーソルで解決できる類もある?
- あんまりない気がする。。あるのか?
- 同じものを繰り返しているなら、
Array.prototype.map
で良いのでは?- それが次に書いてある
- ループ
- Component に切り出す
@apply
- 最終手段というよりおそらく利用しないようにするべき。tailwind のクラスがずらっと並ぶことより、カスタムの CSS を変更することのほうがずっと困難
- ユーティリティファーストで得られる良いところを消してしまう
- https://twitter.com/adamwathan/status/1226511611592085504
- 最終手段というよりおそらく利用しないようにするべき。tailwind のクラスがずらっと並ぶことより、カスタムの CSS を変更することのほうがずっと困難
- カスタムのスタイル
- https://tailwindcss.com/docs/adding-custom-styles
- tailwind はカスタマイズ前提のもの
tailwind.config.js
- config の全セクションがオプショナル
content
→ tw の対象のパスtheme
→ visual design に関わるすべての値- `screens, colors, fontFamily, spacing
plugins
→ プラグインpresets
→ shared config 的な感じ? config まるごと他所から importprefix
→ class 名のプレフィックスimportant
→ !important つけたスタイルにするかどうかseparator
→ class 名の単語つなぐ文字corePlugins
→ tw デフォルトのクラス毎に生成を止めるかどうか指定できる- デフォルト theme の上書き
- https://tailwindcss.com/docs/theme#overriding-the-default-theme
theme
直下でキーごと記述したら上書きできる- 上書きしたキーだけで、それ以外はデフォルトのまま
- 基本
- class 指定が長すぎる問題
- https://dev.to/wheelmaker24/a-simple-strategy-for-structuring-tailwindcss-classnames-1ba9
className
に直接書かずに変数にして配列で条件を見て生成- オブジェクトにするとさらに整理される
- 別ファイルに分けてコンポーネントのファイルからは見えない状態に
classnames
のようなライブラリーで対応- 命名コストが高くなる可能性 + コロケーションの利点が得られなくなる可能性
- クラスの merge のライブラリー
- https://github.com/JedWatson/classnames
- https://github.com/lukeed/clsx
- https://github.com/michal-wrzosek/cntl
- https://github.com/dcastil/tailwind-merge
- https://github.com/robit-dev/tailwindcss-class-combiner
- https://github.com/GriffinSauce/tailshake
- https://github.com/seandinan/tailwind-classlist
- https://github.com/richardgill/tailwind-override
- variants のライブラリー
- https://github.com/nextui-org/tailwind-variants
- https://www.tailwind-variants.org/docs/comparison
- cvaではなぜだめだったか
- NextUIで必要とする機能が全てcvaにあるわけじゃない + 将来実装される予定もないことを確認したから
- cvaではなぜだめだったか
- tailwind-mergeを内部で使っている
- https://www.tailwind-variants.org/docs/comparison
- https://github.com/nextui-org/tailwind-variants
- vscode ext
- https://github.com/stivoat/tailwind-fold
- 隠せる(そうしたいかどうか。。)
- https://github.com/stivoat/tailwind-fold
- 複数行の折り返しについて
- https://dev.to/wheelmaker24/a-simple-strategy-for-structuring-tailwindcss-classnames-1ba9
- tailwind のクラス名覚えられない問題
- https://github.com/dtinth/tailwind-search
- https://github.com/rogden/tailwind-config-viewer
- config から利用可能な class 名全部分かるようになる?
- rogden/tailwind-config-viewer#72
- ts の config サポートしていなそう
- あんまり活発にメンテされていない感じかも
- tailwindlabs/tailwindcss#10379
- 全部のクラス取れるのか
safelist
で全部を出力するようにはできる
- ベストプラクティス
- https://gist.github.com/sandren/0f22e116f01611beab2b1195ab731b63
- ユーティリティクラス
- 一貫した並び順であるべき
- 短い名前のクラスが使えるなら常にそうするべき
- モバイルファーストのブレークポイントであることを理解するべき
- margin の意図しない相殺をさけるために padding を利用する
- 大抵 gap で良い気がする
@apply
を安易に使用しない- stylelint で
@apply
禁止にするようなルール入れるのが良いのかも- https://stylelint.io/user-guide/rules/at-rule-no-unknown/
- これだけのためにstylelintを入れるかどうか
- stylelint で
- 動的にクラス名を連結しない
- 静的解析できなくなる?
- ユーティリティクラス
- https://theodorusclarence.com/blog/tailwindcss-best-practice
- https://github.com/lukeed/clsx でクラス群を merge
-
Don't get too comfortable with frameworks that you can't make a website without Tailwind CSS or other frameworks like Bootstrap.
- CSSフレームワークがないとUI作れないとはならないように
- https://www.enji.dev/blog/tailwindcss-best-practices
- sort
- clsx
- clsx で分割して、意味のあるまとまりでグループにする
!
をクラス名の先頭につけると!important
になるけど、これは避ける
- https://gist.github.com/sandren/0f22e116f01611beab2b1195ab731b63
- arbitrary properties
- https://tailwindcss.com/docs/adding-custom-styles#arbitrary-properties
- 任意のスタイルのクラスを JIT で生成できる
Arbitrary variants
というのもある
- https://tailwindcss.com/docs/adding-custom-styles#arbitrary-properties
- 嫌われる理由
- https://www.aleksandrhovhannisyan.com/blog/why-i-dont-like-tailwind-css/
-
- 読みにくい
- tailwind 特有の記述の学習コスト
- クラス名に一貫性がない
- コードレビューしづらい
-
- className prop と調和しない
- ?具体的に何が問題なのかイマイチよくわからない。。
-
- ユーティリティ CSS のパラダイムから抜け出せなくなる
-
- ファイルの肥大化
- 書いた人自身が誤りだったと言っている?
- tailwind が JIT で必要なクラスだけ生成するはず
-
- 不必要な抽象
@apply
を利用する前提ならそうかもしれない?
-
- セマンティックじゃないこと
-
- DevEx が良くない
-
- https://jaketrent.com/post/dont-like-tailwind/
- 抽象化している価値が低い
- CSS 自体を学んだほうが良い
- そもそもライブラリー不要論な感じ
- https://thoughtbot.com/blog/tailwind-and-the-femininity-of-css
- CSS を理解せずにライブラリーで CSS を書けている気になる危険性
- CSS を軽視する開発者が安直に tailwind のようなライブラリーで済ませようということに対する批判ぽい
- https://johanronsse.be/2020/07/08/why-youll-probably-regret-using-tailwind/
- 巨大なファイル
- JIT以前の話のはず
- 未使用CSSを削除できると主張するのは不要な問題の解決をしている?マッチポンプ?
- JITに対してはどういうスタンスだろう。。?
- ツールチェーンで苦労なら、という話だろうか
- ユーティリティークラスだけで全部やることが無理?
- UIが複雑であるほどHTMLだけで解決しようとすることに無理があるという考え
- 巨大なファイル
- https://dev.to/kerryboyko/tailwindcss-adds-complexity-does-nothing-3hpn
- https://dev.to/benface/tailwind-css-might-not-be-for-you-jk0
- これも反論かな
- https://joaquinmarti.com/posts/tailwind-utility-classes-as-an-antipattern/
- mobile での hover の問題
- セマンティックではないことの可読性の低さ
- 詳細度が一定であることによる予期しづらさ
- CSS の最新のプロパティをサポートしていない
- 複雑さを減らすことなく抽象レイヤーを足すので、学習コストが増す
- HTML が肥大化しがちなので、キャッシュ面で望ましくない
- 自動テストが遅くなる
- 壊れやすいテスト
- など
- 決めつけだったり、主観の強すぎる意見のように見える
- 特にテストの部分で
- 決めつけだったり、主観の強すぎる意見のように見える
- https://www.aleksandrhovhannisyan.com/blog/why-i-dont-like-tailwind-css/
- class名の一貫性が欠如している件
- tailwindlabs/tailwindcss#575
- tailwindlabs/tailwindcss#575 (comment)
-
Every naming decision was basically a battle between brevity and opportunity for ambiguity.
- 命名において常に争点は、簡潔であることと曖昧さを排除できるかどうか
- 一貫性を優先させようと思えば、コアプラグインを無効化して一貫した命名の独自プラグインを追加することで可能ではある
-
- tailwindlabs/tailwindcss#575 (comment)
- tailwindlabs/tailwindcss#575
- lint
- https://github.com/francoismassart/eslint-plugin-tailwindcss
classnames-order
の順番はprettier pluginと同じ- https://github.com/francoismassart/eslint-plugin-tailwindcss/releases/tag/v3.6.0
-
The official sorting from prettier-plugin-tailwindcss is always used by classnames-order.
-
- https://github.com/francoismassart/eslint-plugin-tailwindcss/releases/tag/v3.6.0
- https://github.com/zhilidali/stylelint-config-tailwindcss
- https://github.com/francoismassart/eslint-plugin-tailwindcss
- pros/cons
- vs unocss
- https://dev.to/danwalsh/tailwindcss-is-great-why-so-much-hate-ink
- https://www.viget.com/articles/what-i-love-hate-about-tailwind-css/
- https://www.jitbit.com/alexblog/tailwind/
- https://dev.to/lixeletto/the-limits-of-tailwind-css-2pg0
- https://www.swyx.io/why-tailwind
-
The Goldilocks solution.
- ちょうど良い
-
- https://frontendmastery.com/posts/the-evolution-of-scalable-css/
-
Not having to continually name things is one reason Tailwind feels so productive. This workflow is backed by the idea of composing single-purpose atoms bottom-up.
-
It’s not about never creating abstractions, but not creating them prematurely.
-
Because classes are localized to the markup they are on, we can confidently refactor these without worrying about affecting other elements or components elsewhere.
-
A key part of scaling CSS is bridging this design gap by having a solid bedrock of sharable primitives that define values for spacing, font-sizing, colors, break-points, etc.
-
- https://jakelazaroff.com/words/tailwind-is-a-leaky-abstraction/
- https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/
- tailwindは
rotateX
やrotateY
を公式にサポートしてない -
But even after working with it for months, there’s still a mental translation layer between “Tailwind CSS” and “real CSS”.
-
It’s so leaky that I have to constantly think about the thing it’s supposed to abstract away.
- logical property
- tailwindlabs/tailwindcss#1483
- tailwindlabs/tailwindcss#1483 (comment)
- 適切な命名ができるならtailwindがサポートするかも
- tailwindlabs/tailwindcss#1483 (comment)
- tailwindlabs/tailwindcss#1483
- 長いクラス名を複数行へprettierでできないか
- dprint
- https://ishadeed.com/article/on-tailwindcss/
-
From what I’ve seen, it’s a utility-only framework. Maybe naming it utility-only will affect how newcomers understand it?
- ユーティリティーファーストじゃなくてユーティリティーオンリー
-
At the end of the day, you will need to set and think about a unique and meaningful name for every single component of the project you’re trying to build. That applies, of course, when you want to scale and maintain the project for a long time.
- 結局コンポーネント名は考える必要がある
-
- hide scrollbar
- cheatsheet
- https://nerdcave.com/tailwind-cheat-sheet
- v2 で更新止まってそう
- https://nerdcave.com/tailwind-cheat-sheet
- best practice
- tips
- 使わない
- https://www.aleksandrhovhannisyan.com/blog/why-i-dont-like-tailwind-css/
- ドキュメントを頻繁に参照しないと当てたいスタイルにはならない
- ラピッドプロトタイピングとはならない
- 命名に一貫性がない
- 例えば、
align-*
がalign-items
に対応すると考える人がいるのが自然だけど、実際にはより利用頻度が少ないであろうalign-content
の方になる- (これは古いバージョンの話だろうか。今は
align-
で始まるクラス無いように見える)
- (これは古いバージョンの話だろうか。今は
- 例えば、
- 横に並び続けるクラス名は読みづらい
- ドキュメントを頻繁に参照しないと当てたいスタイルにはならない
- https://sancho.dev/blog/tailwind-and-design-systems
- https://blog.shimin.io/why-i-dont-use-tailwind-in-production/
- https://ismail9k.com/blog/tailwind-css-why-it-s-not-my-cup-of-tea
- https://www.aleksandrhovhannisyan.com/blog/why-i-dont-like-tailwind-css/
- https://www.builder.io/blog/the-tailwind-css-drama-your-users-don't-care-about
- https://mxstbr.com/thoughts/tailwind/
- chrome ext
- vscode ext
- ts
https://github.com/crswll/clb
valiants