先日、コーポレートサイトで利用しているCSSアーキテクチャをBEM + Scssから Tailwind CSS に変更しました。
これまで Tailwind CSS に対してはどちらかというと否定的なイメージを持っていたのですが、いざ色々と試してみると思っていたより悪くないなという感想をいだきました。
とはいえこれまで利用してきたBEMなどのCSS設計を、Tailwind CSS に全面的に差し替えるほどの強い魅力を感じたわけではなく、ケースバイケースで使い分けるのが良いかなというのが現状の感想です。
今回はリニューアル時に感じたTailwind CSSの良さそうなところ、辛そうなところをまとめてみたいと思います。
なぜTailwind CSSを採用したのか
ReactなどのJavaScriptフレームワークを利用した開発においては、JSで制御したいコンポーネントのスコープとCSSで制御したいコンポーネントのスコープ(BEMでいうところのBlock)が異なると思いがあり、その解決策を以前から模索していました。
CSS in JS といったJavaScriptフレームワーク由来のCSS設計手法もありますが、CSSを綺麗に書く手法ではなくJavaScriptフレームワークのコンポーネントの粒度にCSSのスコープ粒度に合わせるものと考えており、私が思うCSSのあるべき姿とは少し違うアプローチだと考えています。
Tailwind CSSに関してはCSSからスコープの概念(BEMによるclass名設計など)を排除してHTML要素に直接スタイルをマッピングするものと理解しており面白いアプローチだなと感じて、弊社のコーポレートサイトぐらい手を抜いたシンプルなデザインだとカジュアルに試せるかなと思い採用してみました。
流行っているから食わず嫌いで否定的な印象を持つよりもとりあえず触ってみたかったというのが本音であったりします。
導入は簡単
コーポレートサイトはGatsby.js を利用しているので、導入方法を参考にすれば簡単に導入できました。別件でNext.jsに導入する際もスムーズに導入できたので、普段からnpmを利用する開発を行っている人にとっては導入の障壁は少ないでしょう。
学習コストは思ったより低かった
様々なCSSプロパティに対応したclass名を覚えなくてはいけないので学習コストが高そうと思っていたのですが、いざ触ってみると普段利用するCSSプロパティは限られているので30分ほど触っていたら基本のCSSは難なく書けるようになりました。
利用頻度が低いプロパティなどは覚えるのに時間がかかりそうですが、都度公式ドキュメントで調べていけば問題ないでしょう。
text-shadow など特殊な指定方法が必要なものは少し手間取りますので頑張って対応する必要があります。
リニューアル途中で、Tailwind CSSのベースで利用されてるmodern-normalizeが個人的に性に合わなかったのでOFFにして作業を進めようと思ったのですが、OFFにしたところ記述量がかなり増えてしまったので復活させた経緯もあり、学習コストは低いもののある程度の慣れは必要になるかなと感じました。
ところどころ調べて対応する必要がありましたが、概念がシンプルなので悩むことはそれほどありません。
デフォルトのUtility Classだけでは細かいデザイン再現はできない
デフォルトのUtility Classだけでは細かいデザインの調整ができませんので、tailwind.config.js に独自のUtility Classを追加していく必要があります。
以下が最終的に定義した独自のUtility Classの設定です。
module.exports = {
purge: ['./src/**/*.{js,jsx,ts,tsx}'],
darkMode: false, // or 'media' or 'class'
corePlugins: {
preflight: false,
},
theme: {
extend: {
screens: {
'lg': '960px',
},
colors: {
'main': '#297a89',
'main_hover': '#4eb7ca',
},
borderWidth: {
'3':'3px',
},
borderRadius:{
'2px':'2px',
},
padding: {
'2px':'2px',
'3px':'3px',
'5px':'5px',
'7px':'7px',
'10px':'10px',
'14px':'14px',
'20px':'20px',
'28px':'28px',
'30px':'30px',
},
margin: {
'2px':'2px',
'5px':'5px',
'7px':'7px',
'10px':'10px',
'14px':'14px',
'15px':'15px',
'20px':'20px',
'28px':'28px',
'30px':'30px',
'50px':'50px',
'110px':'110px',
'3%':'3%',
'5%':'5%'
},
width:{
'80px':'80px',
'100px':'100px',
'25%':'25%',
'30%':'30%',
'32%':'32%',
'48%':'48%',
'90%':'90%',
'100%':'100%',
},
height:{
"23px":"23px",
"28px":"28px",
"29px":"29px",
},
maxWidth:{
'930px':'930px',
'600px':'600px'
},
fontSize: {
'11px':'11px',
'12px':'12px',
'14px':'14px',
'16px':'16px',
'17px':'17px',
'18px':'18px',
'21px':'21px',
'28px':'28px',
'130%':'130%'
},
transitionProperty: {
'background': 'background',
}
},
},
variants: {
extend: {},
},
plugins: [
function({ addUtilities }) {
const newUtilities = {
".text-shadowA": {
textShadow: "2px 2px 1px #297a89"
}
};
addUtilities(newUtilities);
}
],
}いくつかのスタイルは調整してマージすることができたのですが、今回は「BEM + Scss」で作成したサイトをTailwind CSSで完全に再現することを目的にしていましたので少し助長な指定になっています。これはのちのち調整しようと思います。
プロジェクトの初期フェーズなどで複数人で同時に作業していると tailwind.config.jsのコンフリクトをが多発しそうだなとは思いました。
CSSの書き味、可読性、認識性は気になるところ
CSSとしての書きやすさや可読性、認識性は通常の通常のCSSに比べると劣ると思います。
VS Codeの拡張機能「Tailwind CSS IntelliSense」などを使えばユーティリティclassのサジェスト表示やCSSでの値表示をしてくれるので楽になりますが、一度ユーティリティクラスのレイヤを経由しているのでCSSを書くような感覚で書けるようにはだいぶ慣れる必要がいると思います。
子孫セレクタによる制御が難しい
普段よく利用する「is-open」のクラス名をつけられたら子孫セレクタで開いた状態のスタイルを当てるなどを制御は難しそうです。
Extracting Componentsを利用するとできると思うのですが、どの部分を抽出するかなどの設計が複雑になりそうで今回は採用せず、JavaScriptを利用して必要な箇所のユーティリティclassを切り替えて対応しました。
after疑似要素やbefore疑似要素が使えない
ちょっとした装飾ならafter疑似要素やbefre疑似要素でスタイリングする人も多いと思いますが、after疑似要素やbefre疑似要素が利用できないのが気がかりです。
結局、Tailwind CSS は使えるのか
キャンペーンサイトといったデザイン再現の要求が高いWebサイトでは無理に導入するメリットは少ないかなと思いました。
Webアプリケーション、それも管理画面といったデザイン再現の要求が少ない場合での利用はありだなと思いました。
初期の開発フェーズである程度CSSに詳しいメンバーがベースのパーツ集を作って、各メンバーがベースのパーツを組み合わせて担当箇所の機能開発を作っていくようなケースで力を発揮できるのではと感じました。(運用フェーズに強そう)
もう少しTailwind CSSに慣れてきたら考えが変わるかもしれませんがファーストインプレッションではこのように感じました。
