実装視点で CSS の変数や mixin の定義をする時に考えていること


こんにちは、Gaji-Labo 横田です。

弊社で手掛けるフロントエンド開発では既存のコード改善や新規Webサイト / アプリケーションの開発など様々なプロジェクトがありますが、使用するフレームワークや開発環境に関わらず、HTML+CSS の実装時に CSS の変数や mixin をプロジェクトに合わせて定義する機会が多いです。
今回は、実装視点で CSS の変数や mixin の定義をする時に考えていることを2点書いてみます。

運用の中で使われ続けるには

CSS の変数や mixin は、開発時に定義するだけでなく長期的な運用の中で使われ続けることに存在意義があると思います。

仮に想定されるパターンが全て出揃っていたとしても、フェーズが変われば全く新しいデザインパターンが作成される可能性があり、どこまで変数にしておくと運用の中で便利なのか、逆に忘れ去られて使われなくなってしまうのか、さじ加減が地味に難しいポイントです。可能な限り形骸化しないよう、変数や mixin として定義する要素は、デザイナーと認識をすり合わせつつ、プロジェクトに合わせて吟味したいところです。

様々なプロジェクトに関わった中で、変数や mixin にしておくと開発上便利で運用の中でも活用しやすいと感じた例をいくつか挙げてみます。

変数

  • フォントファミリー
  • アイコン
  • border-radius

mixin

  • ブレイクポイント
  • リンクインタラクション

CSSの変数や mixin で定義する値として鉄板と言えるかもしれません。

逆に、既存コードの改善の場合では、コード調査の結果、変数や mixin 化されているが使用頻度が低く、使い勝手も悪いために、変数や mixin をやめて直接スタイル指定し直すといった選択をすることもあります。

変数化を積極的に選ばない一例としては line-height を挙げてみます。フォントサイズとセットで指定することが多いプロパティで、運用の中で新しいコンポーネントが作られたりと様々な場面で細かく値を指定することも多く、変数として値を定義してあってもなかなか使える頻度が少ないのです。
どうしても運用上の理由で定義しておきたい場合は、フォントサイズとセットで mixin にし、引数で自由な値を設定できるようにしておくと、使い勝手がよくなったことがあります。

後から拡張しやすくするには

CSS の変数や mixin を定義する時の命名ルールにも、可能な限り、後から拡張しやすいルールを採用したいところです。

色の命名については昔からよくトピックにあがりますが、最近は、例えば $blue のような基準となる色をまず定義し、その色より濃ければ $blue-D1 薄ければ $blue-L1 のように色+濃度+連番を含めた命名ルールが、後から中間色が増えても拡張しやすいと感じています。役割や使いどころを定義したい時は、色名を定義した後に $primary: $blue; のように再定義しています。

また、S / M / Lのような命名は毎回悩みます。後から中間の値を複数変数化したくなった時やS以下L以上の値が増えた時に命名に限界がくるからです。定義した値以外は変数として定義しないといったルールを作っても形骸化してしまうこともあるので、変数名としては安易に選べないところです。

まとめ

CSS の変数や mixin の定義次第で、チームの中で開発スピードも、その後の長期的な運用のしやすさも地味に変わってきます。持続性と拡張性を軸に、その時々のプロジェクトにとってベターな定義を今後も探っていきたいです。

Gaji-Laboでは、HTML/CSSコンポーネント設計経験が豊富なパートナーさんを募集しています

現在、Gaji-Laboの開発チームの一員としてプロジェクトに一緒に取り組んでくれる業務委託のパートナーさんを募集しています。現在は特に正しいHTMLマークアップやCSS設計の業務経験が豊富なWebフロントエンドエンジニアを必要としています。

パートナー契約へのお問い合わせもお仕事へのお問い合わせも、どちらもいつでも大歓迎です。まずはオンラインでのリモート面談からはじめましょう。ぜひお気軽にお問い合わせください!

お問い合わせしてみる!

投稿者 Yokota Tomoko

運用やアクセシビリティに配慮したHTML/CSSの設計やコンポーネント作成、スタイルガイドの構築、コードレビュー、組み込み、要件の整理、社内進行管理、顧客とのコミュニケーションまで、ジョインしたチームを前に進めるためにあれこれ担当しています。子育てと仕事のバランスを楽しめるよう、日々模索しています。