SCSSの良くない実装について


#1

SCSSテーマをアイマストドンで開発しているやきゅと申します。
テーマをこるもJSさんと作っていたときにテーマ作成が非常にしづらかった点、本家で改善ができそうな点が多々ありましたので、議論し、最終的にGithubでissue・PR化したいと考えております。

  • components.scssの肥大化
  • conponents.scssから依存関係がある(variables, boost)せいで、別ファイルで上書きができない
  • variables.scssの変数が少なすぎるせいで、テーマが作りづらい(1色で全部が変わる)

次以降の投稿で詳しいつまづきポイントを記載します。

皆様のお知恵を拝借して、よりテーマの作りやすいコード・より保守性を高めたコードにしたいと考えています。
よろしくお願いします。


#2
  1. アイマストドンでは、独自機能がいくつかあり、styles/imastodon ディレクトリに幾つかカスタムSCSSコードがある。
  2. 2.0化した際、アイマスっぽいテーマ機能を作る話になった。(現在βとして稼働中)
  3. 第1段階として色を置き換える「カラースキーム化」をthemeディレクトリを作成し行うことにした
  4. 「明らかにカラー上書きしても色が残る」部分があり、調査するとconponents.scssの1行目が以下のようになっていた
@import 'variables';

>>別ファイル読み込ませた意味がない<<


#3

MastodonのWeb UIには数多くの要素がある一方で、variables.scss上で変更できるカラーはわずか7色に過ぎません。デフォルトと異なる色の置き方をする場合、あるいは7色以上の色を使う場合には現行では以下のアプローチが必要となります。

  1. 元のスタイルシートを読み込みつつ新たにスタイルシートを書く方法
  2. 元のスタイルシートは読み込まないですべてのスタイルシートを書き直す方法

2の方法で保守のコストが高いのはどうしようもないとしても、1の方法での保守コストはデフォルトのスタイルシート設計次第でコード量を抑えられると考えています。

具体的には;

  • 要素ごとに異なる変数をvariables.scssに導入する
  • それぞれの変数はデフォルトでは$ui-base-color等の値から初期化される
  • それぞれの変数には!defaultを後置する

と考えています。


#4

大きく分けて問題が2つあるようですね。

  1. variables.scss が再度読み込まれた際に変数をすべて上書きする。
  2. variables.scss でカスタマイズできる範囲が狭い。

1のほうの問題の解決策としては

が一番手っ取り早い上に、特に面倒な議論もなくマージされそうな気がします。

2の方(含む大規模リファクタリング)は少し大規模な改修になると思うのでPull Requestを送ってもなかなかマージされない可能性があると思います。

まず、先に変数が上書きされないようにする対策をするのが良いかと…。


#5

components.scss の一行目ですが、blameしてみたところ、storybook(コンポーネントのサンプル集を作れるやつ)関連の修正と一緒にコミットされていました。当時のstorybook構成では components.scss を単体で読みこんでいたために、当該行が必要になったものと思われますが、現在ではstorybookは削除されているため不要と思われます。

それはそれとして variables.scss は「デフォルトテーマで使う色の定義」と「それらの色を使った配色」に分かれていて、後者には既に !default がついているので、そちらを変更すべきものと思っていたんですが、今確認してみたら、 !default 使っていない変数も直接使われていたりしますね…これは…はい。


#6

不要なcomponents.scssの一行目を消しました。


#7

実装という点から少々外れるが、本体の保守の観点からのSassファイル群の問題点

  • components.scssが肥大化(4500行)しすぎて、スタイル修正時に探すだけでも大変
  • 新しい機能が追加される度にセレクタが雑に追加される事が多く、階層構造が滅茶苦茶

よって、求めるもの

  1. components.scssの細分化
  2. 文書構造に基づいた階層構造に整理

1.については、テーマ作成の点での問題と共通のため、細分化方法について議論の上実行したい。
2.については、階層構造を整理するだけでコミットするのもなあと放置しているので、細分化の詳細が分かればやりたい。components.scss以外については下記variablesを追加することがあればおそらく大幅な書き換えが発生すると思うのでできればその時にと考えています。(なお about.scss だけは3ヶ月前に階層整理済み #4682

スタイル(テーマ作成・アクセシビリティ)の観点から、

凝ったテーマは作らないのであまりコメントできませんが、 $ui-base-lighter-color が背景色だけでなく文字色にも使われている所が結構存在してこれだけはどうにかならないのかと感じています。このために簡単なテーマ作成が難しくなっていることは勿論、コントラスト比をWCAGの規定に到達させられない箇所が多く(例:通知カラムの投稿本文部)、容易なテーマ作成及びアクセシビリティの観点から背景用色と文字用色は分離した方が良いと考えます。 ただ、おそらくdeflisさんの仰る通りvariablesを増やすリクエストを通すのは容易ではないと思われるため、アクセシビリティ向上のため背景と文字色を分離する必要があるという理由で既存の色を分離するという形で1色か2色増やすのが現実的であると考えています。


#8

もちろん、ここにいる人たちだけで議論、というのは狭い範囲なので、できるだけissue化したいのですが、論点整理をしますね。

  1. components の依存関係→variablesに関しては解消に成功
    • boost.scss に関してはまだ問題になっていない?要調査。
  2. 変数少ない問題 →色数は増やせて1-3種程度
    • 文字色と背景色は完全に分離させたい。変数名変更は変更コストが高い?要議論。
  3. components 肥大化問題→分割したいのは多分誰もが思ってそう
    • 出力されるマークアップ階層に基いて、階層化もついでにやっておきたい。どのような形で分割していけばいいかは要議論か。

以下、私の個人の感想とか意見です。

  1. boostもついでに消しておきたいけどどういう挙動かよくわかんないしこれから実験していかなきゃ…
  2. 本当ならボタンやhover以外のlighten・darken要素はcomponentsから廃したいくらい。ひとつずつ議論を重ねていきたい。
  3. 第一段階として「web上のfaなどのアイコン要素」「videoプレーヤー」「レスポンシブ・ブレークポイント」などが分割での候補かと。

#9

Too few color variables in style sheet theme · Issue #6192 · tootsuite/mastodon


建てました


#10

こるもさんありがとうございます!


#11

ありがとうございます。文字色と背景色の分離はかなり大変そうな気がしますが、とりあえず楽にできそうな1ステップとしてまずは変数を増やしてあちこちのlightenとdarkenをやめてもらいたい(variables.scssに集約してほしい)です。下記のような直感的にわかる変数名にすれば現状と大きな変更にならないので通りやすいのではないでしょうか?

↓これら(実際はもっとたくさんある)をvariables.scssに追記

$ui-base-lighten04-color: lighten($ui-base-color, 4%) ;
$ui-base-lighten08-color: lighten($ui-base-color, 8%) ;
$ui-base-lighten12-color: lighten($ui-base-color, 12%) ;
$ui-base-lighten16-color: lighten($ui-base-color, 16%) ;