-
reset
- Tailwindの preflight styles を
tailwind.css から最初の約200行コピーして使っている
- Tailwindのresetには長く慣れていて、すべての要素に
box-sizing: border-box を適用するルールは、要素の幅に padding を含めるようにしてくれる
* { box-sizing: border-box; }
html {line-height: 1.5;} のようなほかのresetルールにも無意識に依存している可能性があり、こうしたルールなしでCSSを書くには大きな適応が必要そうだ
-
components
- CSSの大半は、VueやReactのコンポーネントに近い形で コンポーネントごとのファイル に整理している
- 各コンポーネントは固有クラスを持ち、あるコンポーネントのCSSが別のコンポーネントのCSSを上書きしないようにしている
- 実際に変更したいCSSの約80%はコンポーネントファイル内にあるので、100行のコンポーネントを編集するときはその100行だけを考えればよい
- たとえば
.zine コンポーネントは次のようなHTMLを持てる
<figure class="zine horizontal">
<img src="whatever.jpg">
</figure>
- CSSではネストされたセレクタで
.horizontal、.vertical、:hover のような状態をコンポーネント内部にまとめている
.zine {
...
&.horizontal {
...
}
&.vertical {
...
}
&:hover {
...
}
}
- Web Components や
@scope のように、コンポーネント間の干渉をプログラム的に防いではいないが、慣習を定めて守るだけでもかなり改善した感覚がある
-
colours
colours.css には、必要なときに使えるCSS変数をまとめている- 色は難しく、今回のリファクタリングで色の使い方を見直したくはなかったため、既存のやり方を維持している
- 唯一のルールは、サイトで使うすべての色をこのファイルに列挙することだ
:root {
--pink: #fea0c2;
--pink-light: #F9B9B9;
--red: #f91a55;
--orange: rgb(222, 117, 31);
...
}
-
font sizes
- Tailwindでは
text-lg、xl、2xl のようにサイズ段階を選ぶだけでよかったので、em、px、rem のどれを使うか覚えておく必要がなかった
- これをバニラCSSでも維持するため、Tailwindから持ってきたサイズ変数を定義している
--size-xs: 0.75rem;
--line-height-xs: 1rem;
--size-sm: 0.875rem;
--line-height-sm: 1.25rem;
- フォントサイズは変数で指定しており、Tailwindより少し冗長ではあるが、今のところ満足しているやり方だ
h3 {
font-size: var(--size-lg);
line-weight: var(--line-weight-lg);
}
-
utilities
- 複数のコンポーネントで繰り返し使うボタンのような要素は utilities に分類している
- スクリーンリーダー利用者にだけ見せるべき要素のための
.sr-only のような一部のユーティリティクラスはTailwindからコピーした
- この領域は小さく保ち、変更時には慎重に扱いたい
-
base
- “base” スタイルはサイト全体に直接適用するスタイルだ
- サイト全体に多くのスタイルを強制するほどの確信はないため、この領域はごく小さく保っている
- 現時点でよいと感じているルールは
<section> と a の2つだけで、<section> のルールは後で変わるかもしれない
/* put a 950px column in the middle of each <section> */
section {
--inner-width: 950px;
padding: 3rem max(1rem, (100% - var(--inner-width))/2);
}
a {
color: var(--orange);
}
- baseスタイルは最初はほぼ空のままにしておき、共通してほしいものが見つかったときにコンポーネントからbaseへ移す ボトムアップ方式 が最も簡単そうだ
-
spacing
- padding と margin をどう管理するかは、まだ完全には決まっていない
- Tailwindを使っていたときは、望む見た目になるまで padding と margin をあちこちに即興で入れていて、今はそれより原則的なやり方を探している
- 現在は、できるだけ外側のレイアウトコンポーネントが余白を担当するようにしたいと考えている
- 複数の子を持つ
<section> で、子要素同士の間隔を均等に空けたいときは次のルールが使える
section > *+* {
margin-top: 1rem;
}
-
responsive design
- Tailwindでは
md:text-xl のように、特定サイズ以上で text-xl スタイルを適用する メディアクエリベースの構文 を多用していた
- 今は breakpoint をあまり使わなくても済む、より柔軟な CSS grid レイアウトを作ろうとしている
auto-fit を使えば、大きな画面では2カラム、小さな画面では1カラムを自動で使える
display: grid;
grid-template-columns: repeat(auto-fit, minmax(min(100%, 400px), max-content));
justify-content: center;
-
build system
- 開発中は別途ビルドシステムは必要ない
- CSSには組み込みの
@import 文があり、ファイルを分けて読み込める
@import "reset.css";
@import "typography.css";
@import "colors.css";
.page {
h2 { ...}
}
- 本番用にCSSファイルをまとめたければ
esbuild を使える
esbuild style.css --bundle --loader:.svg=dataurl --loader:.woff2=file --outfile=/tmp/out.css
- ふだんはCSSやJSのビルドシステムを使うのを避けているが、
esbuild はWeb標準ベースで静的なGoバイナリなので問題ないと考えている
esbuild については2021年に esbuildとVueに関する記事 を書いたことがある
3件のコメント
zero-configに変わって、もう少し良くなったのではないですか？
Hacker Newsの意見
セマンティックなHTMLとアクセシブルなマークアップを長年教えてきて、スクリーンリーダー向けのサイトやアプリも数多く扱ってきたが、Tailwindの最大の問題はHTMLとCSSを考える順序を逆転させてしまうことにある
HTMLは文書の意味を示すものなので、そこから始めて、その次にCSSでスタイリングすべきだ。スタイルのために追加要素が必要ならdivやspanを使ってもよいが、まずはより適した要素がないか考えるべきだ
Tailwindは開発者をCSS優先のアプローチへ押しやり、欲しいTailwindクラスを先に考え、そのクラスを付けるためにDOMへ別のdivを追加するようにさせる
Web開発者の力量には、将来も読みやすく、すべての利用者が使え、HTML/CSS仕様ともおおむね整合するHTMLとCSSを作る能力が含まれるべきだが、Tailwindはその面で技能を落としてしまう。TailwindのWebサイトの最初の例もdivとspanばかりで、新しい開発者への悪い教育になっており、LLMが別途指示なしではdivスープを吐き出す流れにも寄与したと思う
どんな道具でも誤用はあり得るし、Tailwindも例外ではない。CSSを約20年使い、Less、SASS/SCSS、Stylus、PostCSSも使ってきたが、ここ数年Tailwindに落ち着いたのは、むしろより堅牢なアプリケーションのスタイリングを可能にしてくれるからだ
スタイル／クラスの抽象化を過剰に作らずに済み、影響を受けるマークアップにスタイルをそのまま置くことで認知負荷が減り、緩いセレクタが意図せずスタイルを変えることも減ってデバッグもしやすくなる。独自CSSフレームワークのあるコードベースより、Tailwindのコードベースのほうが、単純なサイトやアプリを除けば、複雑さも脆さも少ない場合が多い
一貫したフォント・色・サイズのスケール、より小さなバンドル、Tailwindを知る開発者同士の一貫性、強固なエコシステムやLLMとの相性まで考えれば、多くのチームにとって素晴らしい選択肢だ。結局のところ多くのツールと同じで、使う人次第で良くも悪くもなる
HTML/CSS/JSの混沌はブラウザを相手にするときに必要な悪だと見ていて、私にとっては単なる表現レイヤーにすぎない。仕事ではデータベーススキーマやバックエンドのビジネスロジックの正確性のほうにずっと重きを置いている
表現レイヤーはできるだけ少ない手間で、それなりに保守可能なコードになれば十分で、その目的にはTailwindがよく合う。LLMがうまく書けて、新しい開発者もすぐ理解でき、後から読んで直すのもかなり容易だ
Tailwindプロジェクトが新しい開発者にHTML/CSSを学ばせる最善の方法ではないという点には全面的に同意するが、新しい開発者には良いデータベーススキーマ、直感的なAPI、テスト可能なビジネスロジックなどに集中してほしい
Tailwind自体に、適切なHTMLタグの代わりにdivやspanを使わせる要素はない
文書とインターフェースは別物であり、Tailwindはインターフェースではるかに理にかなっている。インターフェースにはTailwindを使い、それ以外のコンテンツにはスコープを絞ったHTMLセレクタを使えばよい
複雑なCSSコードベースを書くよりTailwindのほうが約4倍速く、実質的にオーバーヘッドがないという点は、どう評価しても利点として残る
要するにCSSを詳細度ではなく順序で書く方法だ:
/scss/
├── 1-settings. <- グローバル設定
├── 2-design-tokens <- フォント、色、間隔など
├── 3-tools <- Sassミックスイン、CSS関数など
├── 4-generic <- リセット、ボックスサイズ、正規化など
├── 5-elements <- 見出し、ボタン、リンクの基本スタイル
├── 6-skeleton <- レイアウトグリッドなど
├── 7-components <- カード、カルーセルなど
├── 8-utilities <- ユーティリティとヘルパークラス
├── _shame.scss <- 後で直すハック
└── main.scss
ITCSSはCSSコードベースにおける詳細度の争いを事実上なくしてくれる。たいてい
!importantが入る唯一の場所はユーティリティ層だ[1]: https://matthiasott.com/notes/how-i-structure-my-css
コンポーネントライブラリを見れば、
aria属性も含まれている: https://tailwindcss.com/plus/ui-blocks/marketing/sections/pr...ランディングページのようなデジタルパンフレットに近いものでない限り、常にマークアップから始めて、その上にCSSクラスを追加している
Tailwindの良い点は2つあり、AIの学習データにクラス情報がすでに大量にあることと、スタイル衝突がないことだ
そのためAIが新しいスタイルを作るとき、既存のスタイルシートを参照する必要がなく、コンテキスト管理に向いている
独自CSSでは、AIは衝突や重複記述を減らすために既存のスタイルシートを読む必要があるが、大きなスタイルシートはAIのメモリ空間を多く消費するため問題になり得る
Julia Evans の文章が本当に好きだ
弱さと率直さの立場から書いている。多くの人は賢く見せようとして書くが、Juliaは「私も全部知っているわけではないけれど、見つけた中で共有したいものがある」という姿勢で書いている。直接知り合いではなくても、大切な人たちに何かを分かち合うように感じられるほどだ
最後のStrange LoopでRandall Munroeと一緒に発表していて、発表後に彼と話そうと待っていた人たちもいたが、私はJuliaと話すために待っていた。bashスクリプトをPerlで書き直せという私の冗談を理解してもらえなかった気がして、心から申し訳なく思う
私はJuliaではないが、公開講演やプレゼンテーションについてほぼ同じ哲学を持っていて、発表を苦手とする同僚にもそれを根付かせようとしてきた。自分が少しだけなじみのある知識や、相手の役に立つかもしれないことを同僚や愛する人たちに伝えられるのは大きな特権だ
CSS Modules はカスケーディングの問題に対するより単純な解決策だ。ユニークなクラス名を作ってクラス衝突を防いでくれる [1]
Tailwindの大きな欠点である可読性 [2] とツールサポートの問題もない。特にChromeとFireFox DevToolsでデバッグしたり対話的に試したりする際のツールサポートがより良いと思う
[1] https://x.com/efortis/status/1888304658080256099
[2] https://github.com/ericfortis/tailwind-eye
Tailwindでいつも印象的だったのは、支持者のほぼすべての議論が結局「CSSをジュニアレベル以上に学んだことがない」に帰着する点だ
「Tailwindがなければ巨大で整理されていないCSSファイルが1つ膨れ上がって手に負えなくなり、古いコードと
!importantだらけになる」といった話をよく聞くが、CSSも他の技術スキルと同じく1つのスキルだ見た目を合わせられる程度だけ学んで場当たり的に継ぎ足していけば、野心がコードを整理する能力をすぐに追い越してしまう
TailwindとCSSについて話していて、相手が「カスケーディング」の意味を知らないだけでなく、スタイルシートの文脈でその概念が有用であり得ると考えたことすらないと気づく瞬間は本当にうんざりする
90年代からCSSを多用してきてTailwindも見てきたが、理解してからは生のCSSをほとんど避けるようになった。ある意味では1つの混沌を別の混沌に置き換えるだけだが、個人的には複数ファイルにまたがる重なり合って矛盾するカスケードより、局所化されたクラススープを扱うほうがましだと思う
どちらもきれいに実装することはできるが、Tailwindの混沌を整理するほうがCSSの混沌よりはるかにましで、開発全体の体験もより楽しい
私も20年以上プログラミングし、Web開発もほぼ15年やってきたが、CSSをきちんと学ぶ動機を見つけにくい。追いかけるべき技術スキルが多すぎて、CSSは私の優先順位ではかなり低い
専門家に任せたいが、会社は専任のフロントエンド開発者を採ろうとしない
スケールするHTMLとCSSを書くことに焦点を当てたクリーンなWeb開発ガイドを書いている: https://webdev.bryanhogan.com/
ここにいる人たちにも役立つかもしれない。スタイリングにはTailwindのようなものを使わず、AstroやSvelteのようなモダンフレームワークとCSSだけを使っている
すべてのプロジェクトに
reset.css、var.css、global.css、util.cssを置き、残りのスタイルは該当するコンポーネントやレイアウトにスコープを限定している良い記事だ
外部ライブラリ依存を取り除いて最初から自分で解決策を作るのは好きだが、Tailwindではそうしないとはっきり決めている理由がある。プロダクション最適化を提供し、実際に必要な最小限のCSSだけが配信されることを保証してくれるからだ
globals.cssや他の場所に色や余白などの選択肢を全部列挙していても、本番でそのバリエーションを全部使うか心配する必要がない。Next.jsのようなフレームワーク内で作業すれば、ビルド時にこの最小化ステップが自動で起こることさえあり、それだけでもTailwindから移行しない十分な理由になるTailwindでインラインCSSを書くときに耐えがたい制約を感じたこともなく、Tailwindのグリッドツールで画面幅に応じてうまく反応するグリッドを実装するのにも大きな問題はなかった。記事で挙げられていたシナリオはどれもTailwind、あるいはTailwindとCSSの組み合わせで解決してきたし、
grid-column-areasが標準でないのは事実だが、レスポンシブなグリッドレイアウトで大きな制約だと感じたことはまだないTailwindの最大の問題は、読むことに慣れるまで時間がかかる点だ。私たちはインラインCSSは悪く、グローバルスコープのCSSは良いといった形で教えられ、きれいなHTMLに慣れているので、実際のTailwindコード、特に長い行を見ると最初は本当に読みにくく見える。長く使ううちにその見た目に完全に慣れ、最終的にはTailwindのほうが効率的で保守しやすく、さらには読みやすいとすら感じるようになったが、そこに至るまでにはかなり時間がかかった
最近本当に気に入っているアプローチは、Tailwindとスコープ付きスタイルを一緒に使うことだ（SvelteとVueで）
こうするとTailwindの利便性を保ちながら、テンプレートの汚染を最小限にできる:
+
{{ count }}
私にとってはSvelteとLLMがTailwindの必要性を完全になくしてくれた
振り返ると、Tailwindを主に使っていた理由は、自分に課した制約ではなく、CSS衝突の回避と、自分にはより論理的に感じられる文法だったからだ
Tailwindで一番良い点は、その場しのぎのクラス名を作る必要がないことだ。もうBEMを使わなくてよい
Lobste.rsのコメント
個人プロジェクトでは、もう CSS/JavaScriptフレームワーク をほとんど使っていない
依存関係がなければ、サプライチェーン脆弱性も発生しようがないから。もちろん脆弱性はそれだけではないが、助けにはなる
フレームワーク疲れ、
npm auditの負荷、そしてLLMのおかげで実装方法について他人の評価をあまり気にしなくてよくなったことが合わさった結果だ。たとえば「なぜReactやTailwindを使わないのか」といった質問などこれは単に CSSが動く仕組み というだけの話だ
これを知らずにTailwindを盲目的に使っているのを見ると、外に出て雲に向かって叫びたくなる。私にはTailwindの90%は文法が違うだけのインラインスタイルに見え、
<FONT>タグより一段ましな程度だとも思えるこのブログ記事は、私が実際に知る必要があった内容を説明している
Tailwindはインラインスタイルとはかなり異なる動きをし、むしろCSSにはるかに近い。記事でも指摘されているように、Tailwindをうまく使うための良い習慣の多くは、効果的なCSSを書くためにも必要な習慣だ。Tailwindは、すべての要素に暗黙の スコープ付きCSSブロック を付与しつつ、独自のDSLを使うものに近い
CSSの動作原理はよく分かっているが、素のCSSは負担が大きく、グラフィックデザインも得意ではないので、今でもTailwindを使っている。この記事は、Tailwindを足がかりにCSSを構造化するためのアイデアを与えてくれる
最近の流れをあまり追えていない立場からすると、この記事は モダンなCSSの実践 をかなりうまく示しているように思う
インスピレーション元の記事へつながるリンクが多いのも気に入った。読み物として良さそうで、今のところは "no outer margin" だけ読んでみた
ただ、基本スタイルを「下から上へ」組み立てるアプローチには少し懐疑的だ。代わりに何をすべきかは分からないし、試してみる価値はありそうだが、基本スタイルは本質的に扱いが難しい
この記事は本当に良かった
私も小さなサイトをあれこれ作りながら少しずつCSSを学んできたので、最初からこういう システム的な考え方 をもっとしていれば助けになっただろうと思う。フレームワークにはかなり抵抗感があるが、使わないでいると、やりたいものを実装できても構造のない宙空に浮いているような感覚になることがよくあった
「Tailwindはよくないから単にCSSを使え」ではなく、「Tailwindは素晴らしいが、もう必要ないかもしれない」という言い方なのが良い
CSSを手で構造化することにいつも苦労していたが、この記事のおかげでずいぶん違う観点で考えられるようになった
CSSを整理するとき、この 構造化手法 はかなり役に立った: https://rstacruz.github.io/rscss/
全体として、元記事でjvnsが説明していた内容とよく合っていて、その上に構造と整理を少し追加してくれる