utilityファースト
長年感じていた不満を具現化してくれて驚いた
htmlとcssの関心分離か良いとされているが、実在はほぼ同じタイミングで修正するケースがほとんどである。
クラス名がうまく思いつかなかったり、中間クラスを生成しないといけなくて悩んだりする時間はほんとに多い
それはBEMでも解決しなかった
CSS in JSは多少解消してくれたが、命名規則の被りは依然として存在する
自由度の制限としてはlintでの拒否リストより、許可リストのほうが良いというのはまさにそう。
クラス名を書かなくて良い、CSSを書かなくて良いの恩恵は、想像以上だ。
tailwindの使い方のコツ
コンポーネントはuiを抽象化するために使う
すべてのページがあらかじめ用意されたコンポーネントの組み合わせだけで構築できるケースは少ない
main-page-wrapper-innerクラス→クラスが冗長になる問題
繰り返し処理は動的に書くことを意識すれば、それほど問題ではない。
コピペで展開はできるだけ避けるべき
tailwind prettierは入れる
tailwondFunctionsを設定すればclassnamesやclsxでもソートできる
line-heightは行間は正しくない。行間はフォトショ式。文字のサイズも含むのは行送りとよんでいる
leading-snug：こじんまりした
relaxed, looseとかの表現は面白い
クラス名は正規表現で判別している
文中に出たワードが引っかかることもあるが、許容するのが良い
truncate 切り詰める
要素をgrid使わずに等間隔に並べるのはspaceを使う
仕切り棒はdivide
arbitary valuesはtailwindの規則から外れた記載
ESlintのdisableみたいなもので、これが頻発するプロジェクトには何かしらの問題がある（デザインシステムが機能していない・コーディングルールが議論されていない等）
arbitary valuserが出た部分にはコメントを残すなど、プロジェクト内でルールを議論することとセットにしておくとよい。（なぜその部分はtailwindクラスを使うことができないかの説明）
外部から注入するHTMLにスタイルを当てたい場合はtypographyプラグインのproseを使用する
form系のスタイル定義は、Preflightをあてている場合多くなってしまう。これを解決するのがformsプラグイン。これはデザインフレームワークではない。一種のreset.css
AOTは全てのクラスの中から必要なクラス以外を削除する方法
JITは使っているクラスのみを判定してスタイルを作成する方法
JITのおかげでモディファイヤの使用に制限がなくなり、arbitary variantsの作成が可能となった
tailwind.config.jsはどんどんカスタマイズで設定するのが良いが、
arbitary variantsを使った方がいいケースも多くある。（背景画像など）
@applyは複数のクラス名をワンセットにするもの。これはユーティリティファーストを諦める選択肢であり、基本使わない方が良い。使う場合は、外部のHTMLに上書きしたいときなど。
Preflightはtailwind cssのreset.cssやnormalize.cssに似ているがより思想をもったもの。
余白はすべてtailwindクラスで定義されるべきなので全部マージン削除してたり、見出しのスタイル剥奪したり、img/videoなどのinline置換要素をblockにしたり、border-widthはnoneではなく0で設定したり、全ての要素がbox-sizing:border-boxになったりしている。
そのため既存のプロジェクトにtailwindを付与する場合、preflightが悪影響をもたらすケースは意外と多い
コンポーネントを分けるという行為
クラス単位で分ける必要性がなくなった。
機能単位で分けるべき（逆にいうと、素のHTMLで書き連ねるケースはtailwind向いてない？）
基底コンポーネントという誘惑は断ち切った方がいい。
atomic designの思想で完璧にデザインを作るのは難しいという事実がある。
ユーティリティファーストは個別のスタイル指定を要素に受け渡ししており、それで良いのである。
スタイルの上書きに関して
propsに想定の上書き要素を指定する
最終手段としてはclassNameの引数に
arbitary valuesの存在意義は「抜け道がないと普及しない」
ユーザーに使用してもらいたいなら、抜け道は用意してあげるべき
tailwindのcssスタイルはコンポーネントに閉じない
css in jsやweb componentsなど、「クリティカルCSS」との相性は良くない
再配布はどうするのかというと、コピペw
便利なコンポーネントは一応ある
tailwind公式のHeadlessUIとか
メニューやダイアログ、transitionなどのコンポーネントを提供
pugは:を使うとエラー出てしまうのでセパレーター記号を変換しないといけない（まじかーまあpugでtailwind使うとエグくなりそうだからそもそもむいてなさそうだな）
デザインシステムとの連携
デザイナーはシステムについて知っておくといい
figmaでカラーコンポーネントの共有や、スペーシングの共有ができておくとよい。
フィボナッチでスペーシングを作るプロジェクトとかも世にはあるらしい・
tailwind.configファイルをデザイナーと開発者の間でシェアすることもできる。
定期的に更新すべきかどうかは、規模感による。複数のデザイナー・エンジニアが増えてきたらするべき。
勉強したほうがいいなと思ったこと
ITCSS
CSSの@layerについての概念を知る
感想
単なる機能解説書ではなく、なぜこの仕様となっているかの根底部分をしっかりと解説していて面白い。
tailwindは設計思想部分が色濃く出ており、ユーティリティファーストという考え方に全てが帰結する。
これはひとつの「契約」であり、ユーザーはtailwindを使うならばその契約に遵守しなければならない。（そうでなければ、tailwindは逆に足枷になってしまうだろう）
tailwindを使う上でどうしても実装しにくいパターンは存在する。例えば、クラス名が長くなるのでまとめたいとか、コンポーネント化したクラスを複数propsとしてあたえたいとか。しかし、tailwindを使う上ではそれらの考え方自体に問題があるケースが多い。
tailwindで書くのが難しいケースは、tailwindの思想と異なっている部分が多いのだ。
その時は、そもそもの書き方自体を修正する必要がある。
その部分についてもしっかり書いてくれているのでありがたい。
思想を真に理解して賛同した人たちの中で使えば、圧倒的な効果をもたらすことができる。
今までの開発体験で一番良かったのってChakraUIに出会った時の開発体験の良さ。