Skip to content

Commit

Permalink
update 2024-02-16-type-scale-does-not-work
Browse files Browse the repository at this point in the history
  • Loading branch information
yuheiy committed Feb 16, 2024
1 parent 7cd4c5e commit 3ae7c89
Showing 1 changed file with 11 additions and 9 deletions.
20 changes: 11 additions & 9 deletions src/content/blog/2024-02-16-type-scale-does-not-work.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -7,26 +7,28 @@ pubDate: 2024-02-16T05:05:00.000+09:00

このサイトは、どんなビューポートのサイズで見ようがほとんどスタイルが変わらない。レイアウトも文字サイズもそのまま。ウェブページって別にそれでいいんだけど、困ることがあるとすれば、見栄えがしない。やはり、大きく表示したときにはそれ相応のスタイルが適用されていないと、手抜きに見える。あとまあ、小さいよりはデカい方が見やすいですね。

そういう意味において合理的に思える手法のひとつとして、[fluid typography](https://www.smashingmagazine.com/2022/01/modern-fluid-typography-css-clamp/ 'Modern Fluid Typography Using CSS Clamp')がある。これをTailwind CSSでも扱いやすいように僕は、[arbitrary valuesを引数として扱うことでon-the-flyでCSSを生成できるプラグインを作り](https://github.com/yuheiy/tailwindcss-fluid-sizing 'yuheiy/tailwindcss-fluid-sizing')、その場かぎりの値——つまりデザイントークンと言われるような秩序立てて整理された値ではないもの——をいくつもソースコードに埋め込みながら、ガシガシと見栄えを整えていった。
そういう意味において合理的に思える手法のひとつとして、[fluid typography](https://www.smashingmagazine.com/2022/01/modern-fluid-typography-css-clamp/ 'Modern Fluid Typography Using CSS Clamp')がある。これをTailwind CSSでも扱いやすいように僕は、[arbitrary valuesを引数として扱うことでon the flyでCSSを生成できるプラグインを作り](https://github.com/yuheiy/tailwindcss-fluid-sizing 'yuheiy/tailwindcss-fluid-sizing')、その場かぎりの値——つまりデザイントークンと言われるような秩序立てて整理された値ではないもの——をいくつもソースコードに埋め込みながら、ガシガシと見栄えを整えていった。

急ぎの話だったので最初は手早く完成させたけど、一度公開してしまってからは、チマチマと余白や文字サイズを細かく調整したりしてしばらく遊んでいた。そのなかで、揃ってないところを揃えようとか思っていろいろ試してみていると、ふと、昔使った[Utopia](https://utopia.fyi/)のことを思い出した。あの時はあまりうまくいかなかったけど、実際のところ何がダメだったんだろう。いちおう[振り返りは書いてみた](/2022-01-24-retrospective-on-utopia 'Utopiaを実際の案件で使ってみて、うまくいったことといかなかったこと')ものの、あまり的を射た分析ができなかった気がする。当時は自分とは別にデザイナーがいたけれど、今は自分自身で作っているのだから、今度こそあの時掴めなかった何かに到達できるかもしれない。
急ぎの話だったので最初は手早く完成させたけど、一度公開してしまってからは、しばらくチマチマと余白や文字サイズを細かく調整したりして遊んでいた。そのなかで、揃ってないところを揃えようと思っていろいろ試してみていると、ふと、昔使った[Utopia](https://utopia.fyi/)のことを思い出した。あの時はあまりうまくいかなかったけど、実際のところ何がダメだったんだろう。いちおう[振り返りは書いてみた](/2022-01-24-retrospective-on-utopia 'Utopiaを実際の案件で使ってみて、うまくいったことといかなかったこと')ものの、あまり的を射た分析ができなかった気がする。当時は自分とは別にデザイナーがいたけれど、今は自分自身で作っているのだから、今度こそあの時掴めなかった何かに到達できるかもしれない。

そんなわけでUtopiaを使い始め、タイプスケールのパラメータをいじりながらソースコードにも適用し、またパラメータをいじるということを繰り返してみて、この辺がよさそうだなと[落ち着くポイント](https://utopia.fyi/type/calculator/?c=640,16,1.125,1440,18,1.175,7,0,&s=0.75%7C0.5%7C0.25,1.5%7C2%7C3%7C4%7C6,s-l&g=s,l,xl,12)が見つかった。ただ、ページを少しスクロールしてみて、そのスケールを別のところにも適用した状態を見てみると、どうにもコレジャナイ感が出る。というのも、さっき見つけたポイントというのは、その時見ていた文字のサイズから逆算して、それに近い計算結果になるようにパラメータを調整しただけのものだったからだ。そこで続けて、ほかの部分がきれいに見えるようにパラメータの再調整をしてみると、次はまた別の部分がイマイチになってしまった。これでは埒が開かない。
そうしてUtopiaを使い始めた。タイプスケールのパラメータをいじりながらソースコードにも適用し、またパラメータをいじるということを繰り返してみると、この辺がよさそうだなと落ち着くポイントが見つかった。ただ、ページを少しスクロールして、そのスケールを別のところにも適用した状態を見てみると、どうにもコレジャナイ感が出る。というのも、さっき見つけたポイントというのは、その時見ていた文字のサイズから逆算してそれに近い計算結果になるようにパラメータを調整しただけのものだったからだ。そこで続けて、ほかの部分がきれいになるように同じくパラメータの再調整をしてみると、次はまた別の部分がイマイチになってしまった。これでは埒が開かない。

イマイチに見えるのは、文字とレイアウトの関係性がいい感じになってないからだろう。しかしこれは、レイアウトを今さら変えられないという、順番の問題なのか? もしタイプスケールの方を先に決めてから作り始めればうまくハマったのか? しかし本当に順番の問題なのであれば、今からレイアウトを作り直せばいいだけの話だ。思うに、これは多分、意識の問題だ。
イマイチに見えるのは、文字とレイアウトの関係性がいい感じになってないからだろう。しかしこれは、一度完成したものの文字サイズだけを後から変えたからだという、制作の順番の問題なのか? もしタイプスケールの方を先に決めてから作り始めればうまくハマったのか? しかし本当に順番の問題なのであれば、今からレイアウトを作り直せばいいだけの話だ。でも、それはできなかった。思うにこれは多分、意識の問題だ。

「先に外枠があってから、そのなかに文字がはめ込まれる」のか、それとも「先に文字があってから、それが主体となって周囲を形作る」のかという、主従関係の問題だ。僕が「見栄えがするように」と考えた結果立ち上がった意識が、文字を従属させたのである。外枠からの要求を成り立たせるために文字があるのだとすれば、タイプスケールという文字主体のルール設定は成り立たない。
「先に外枠があってから、そのなかに文字がはめ込まれる」のか、それとも「先に文字があってから、それが主体となって周囲を形作る」のかという、主従関係の問題だ。僕が「見栄えがするように」と考えた結果立ち上がった意識が、文字を従属させたのである。外枠からの要求を満たすために文字があるのだとすれば、タイプスケールという文字主体のルール設定は成り立たない。

文字が主体という意識さえ確立されていれば、極端なことを言えば、タイプスケールのそれぞれの文字サイズなんてなんであっても成り立つはずだ。タイプスケールのそれぞれに明確な役割(セマンティクス)を与えられれば、それに駆動されるようにしてデザインができる。この場合、タイプスケールの数は最小限に収まるだろう。
一方、文字が主体であるという意識さえ確立されていれば、極端なことを言えば、ひとつひとつのスケールのサイズなんてなんであっても成り立つはずだ。各スケールに明確な役割(セマンティクス)を与えられれば、それに駆動されるようにしてデザインができる。この場合、タイプスケールの数は最小限に収まるだろう。

逆に、文字が従属関係にありながらもタイプスケール的な発想が成り立つとすれば、それらのステップの間隔が狭く、かつ多くの数が用意されている場合だろう。この場合の傾向として、タイプスケールの働きとしては、個々の役割を明確化させるというよりは、アウトプットされるもののブレを間引いて丸めるための仕組みになるだろう
逆に、文字が従属関係にありながらもタイプスケール的な発想が成り立つとすれば、アウトプットされるもののブレを間引いて丸めるための仕組みとしての機能になるだろう。ひとつひとつのステップの間隔を狭めたスケールを作って、出力値を刻むための目盛りとしてそれを位置付けることで、誤差が生じる確率を軽減するための機構となる

タイプスケールと言うとき、そのどちらの働きを期待するかによって意図するものや内容物は変わってくる。もし明確な問題意識があれば、そのとき必要なのはどちらか、自ずと判断できる。
これらはそれぞれ逆方向からのアプローチと言える。インプット側に働きかけるか、アウトプット側に働きかけるかという違いである。

タイプスケールと言うとき、そのどちらの働きを期待するかによって、意図するものや内容物は変わってくる。もし明確な問題意識があれば、そのとき必要なのはどちらか、自ずと判断できるだろう。

---

本質的には、Utopia自体の問題ではなかったように思う。しかし、モジュラースケールという、ステップ間隔の広いタイプスケールを生成する仕組みがあることで、問題を顕在化させる結果に繋がったようだ。

こうして言葉にしてしまえば凡庸な話に思える。ただおそらく、これはけっこうクリティカルなところである気もするのである
こうして言葉にしてしまえば凡庸な話に思える。ただおそらく、これはけっこうクリティカルである気もするのである

「内から外へ」の発想は、[以前のタケルさんのブログ](https://terkel.jp/archives/2021/11/every-layout/ '描写から構成へ 『Every Layout』とコンポジション指向CSS')から着想を得た。

0 comments on commit 3ae7c89

Please sign in to comment.