-
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に関する記事 を書いたことがある
1件のコメント
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が説明していた内容とよく合っていて、その上に構造と整理を少し追加してくれる