Tailwind css の　特徴と問題点について少し理解した

動的に要素を生成する際に、他のコンポーネントとの干渉を避けたい場合に、使用する。

干渉しない設計とCSSやクラス名を汚染しない実装をしたい場合はtailwind が最適

特にエコシステムのように不特定多数の人に共有されるコンポーネントの場合、クラス名の衝突は避けられないので、tailwind を使った方がいい。

よくない点は、保守がしにくいところだろう。

クラス名によってある意味意味づけされたタグによって構造化されていた(労力を支払って整備された)様式から、ある意味で煩雑で、境界線の曖昧なルーズな実装によって構造の認識に多大な労力を必要とする。

そうは言ってもクラス名の衝突が発生するので、どこまでそれを許容するか、

難しいなと感じる。

外部コンポーネントを使うまでもないようなサイトに関しては、tailwindは絶対にお勧めしない。

色とかはtailwindなどでつけてもいいかもしれないが、色は増えると見た目が悪くなるので、

やはりtailwindは出禁。

共通のライブラリを作成する場合はtailwindを使いたい。

頻繁にメンテする場合は、もはやbox1 box2... のような連番でもいいかもしれない。

大規模になるにつれて破綻するが。

影響を与えないという点において、それを実装するわけだから、tailwind に戻ったのか。

んー

実際tailwindのプロジェクトをいじっていたが、

構造がわかりにくいので、最適ではない気がする

よく変更するところは、CSSで露出させておいて欲しい。

user_setting_style.css などの命名で

自分自身が作成したマークダウンソフトは、編集部と表示部を物理的な二つのブラウザとして実装し、プレーンなcssによってそのスタイルを定義できるようにした。

各プロジェクトにおけるコンテキストを理解することが、スタイルを変更できる手軽さを殺してしまいかねないという理由で分けていた。

変更がそもそもできないようにはしないのは前提としてあるが、

そのプロジェクトの内容を理解していなくとも、ある程度の変更に耐えうる見せ方があるのではないかということを考えていた。