CSSリント警告の解消：`text-wrap`・`resize`・`user-select`を`@supports`でラップ

2026年05月25日 19:13 JST basecamp/lexxy

https://github.com/basecamp/lexxy/pull/1061

Baseline 2023未満のCSS機能が引き起こすESLintのcss/use-baseline警告を解消するため、text-wrap・resize・user-selectの各プロパティを@supportsクエリでラップする変更が行われました。これにより、コアCSSファイルのリント品質が改善されます。

背景

lexxyのCSSコードベースでは、ESLintの css/use-baseline ルールによってBaselineの互換性が検査されています。このルールは、指定された基準（このリポジトリではBaseline 2023）を下回るブラウザ互換性のCSSプロパティを使用した場合に警告を発します。

対象となったプロパティは複数ありました。text-wrap: balance・text-wrap: pretty・text-wrap: nowrap・text-wrap: wrap・resize: none・user-select: noneが警告の原因として検出されています。これらはいずれもBaseline 2023の基準では広くサポート済みとは見なされていない、あるいはベンダープレフィックスが必要な機能です。

対処方針は2通りに分かれており、@supportsでラップするアプローチと、ESLintコメントによる個別抑制を使い分ける判断がなされています。

技術的な変更

主な対処方針は、問題のあるプロパティを @supports クエリ内に移動することで、ブラウザがそのプロパティをサポートしている場合のみ適用されるプログレッシブエンハンスメント構造に変換することです。

text-wrapの各値に対する変更はlexxy-content.cssとlexxy-editor.cssの両ファイルにまたがっています。以下はtext-wrap: balanceの変更例です：

変更前:

h1, h2, h3, h4, h5, h6 {
  text-wrap: balance;
}

変更後:

h1, h2, h3, h4, h5, h6 {
  @supports (text-wrap: balance) {
    text-wrap: balance;
  }
}

user-select: noneについては、ベンダープレフィックス付きの -webkit-user-select: none を@supportsの外側に残しつつ、標準プロパティを@supports内に配置する構造が採用されました。

変更後:

-webkit-user-select: none;

@supports (user-select: none) {
  user-select: none;
}

一方、::selection { background: transparent; }については@supportsではなく /* eslint-disable-next-line css/use-baseline */ コメントによる抑制が選ばれています。これはプロパティのサポート有無で動作を切り替えることが適切でなく、リント警告を個別に無視する方が実態に即すると判断されたためと読み取れます。

あわせてlexxy-content.cssのコードブロックスタイル（pre要素）では、word-break: break-wordが削除され、代わりにoverflow-wrap: break-wordが追加されています。これはより標準的な長語折り返しの指定への置き換えです。

設計判断

@supportsによる機能検出 と ESLintコメントによる個別抑制 を使い分ける方針が採用されました。

@supportsでラップする方式は、ブラウザがプロパティをサポートしていない場合にそもそも適用しないというプログレッシブエンハンスメントの原則に沿っています。text-wrapやresize・user-selectのような「あれば望ましい」装飾的・操作的なプロパティに対して適切な対処といえます。フォールバックを別途定義するのではなく、未サポート時には単純に無効化されるため、コードの複雑度を最小に抑えています。

一方、::selectionへのeslint-disableコメントは、@supportsが適用できないケース、もしくは挙動の切り替えが不要なケースへの対処として機能しています。2つのアプローチを意識的に使い分けることで、リント警告への対応が機械的な一括処理ではなく、プロパティごとの意図を反映した形になっています。

まとめ

この変更は、ESLintのリント警告をゼロにしながら、CSSの適用ロジックをブラウザの機能サポートに応じて分岐させるプログレッシブエンハンスメント構造へと整理した点に意義があります。@supportsの活用とコメントによる個別抑制の使い分けは、リント対応の実装において参考になる設計パターンです。