yuheiy

段落間の余白の大きさを正しく均等に見えるようにする

Thu, 26 Feb 2026 00:00:00 GMT

Space Toggleハックを使ってcolor-schemeに応じた値の切り替えを実現する

Sat, 21 Feb 2026 11:30:00 GMT

ライトモードとダークモードに対応したCSSを作成するとき、最初に考えられるのはprefers-color-schemeを使って宣言を上書きする方法だろう。

:root {
  color-scheme: light dark;
}

button {
  background-color: black;
  color: white;

  @media (prefers-color-scheme: dark) {
    background-color: white;
    color: black;
  }
}

しかしプロパティの値だけを切り替えたいのであれば、宣言を重複して記述するのは冗長だ。このような場合はlight-dark()を使うと簡潔になる。

button {
  background-color: light-dark(black, white);
  color: light-dark(white, black);
}

これによって、値を変数化して使い回すこともできるようになる。

:root {
  --fg-color-inverted: light-dark(white, black);
  --bg-color-inverted: light-dark(black, white);
}

button {
  background-color: var(--bg-color-inverted);
  color: var(--fg-color-inverted);
}

ただし、light-dark()で切り替えられるのは色だけだ。たとえばfont-weightの値を切り替えたいとしても対応していない。そこで最近、新たなCSS仕様としてcolor-scheme()が追加された。次のようにif()と組み合わせて使う。

#element {
  font-weight: if(color-scheme(dark): 500; else: 300);
}

とはいえ、color-scheme()はまだ実装が存在せず、if()は実装状況が十分ではない。

代替案として、現状ではSpace Toggleハックを使うと同様のことが実現できる。Space Toggleハックとは、--foo: ;のようにカスタムプロパティの値として空白文字が有効であるという仕様を用いて、条件に応じた値の切り替えをする手法だ。たとえば次のようになる。

--toggler: ;
--red-if-toggler: var(--toggler) red;
background: var(--red-if-toggler, green); /* will be red! */

--toggler: initial;
--red-if-toggler: var(--toggler) red;
background: var(--red-if-toggler, green); /* will be green! */

--togglerを--red-if-togglerに含めることで、--toggler: ;の場合はredが空白文字とともに出力され、initialの場合は無効なプロパティとして評価されてフォールバック値が優先される仕組みになっている（コード例はpropjockey/css-sweeperより）。値の前後に空白文字があっても実際の動作には影響せず無視されるというCSSの仕様によって成り立つものだ。

これを応用して、次のようにprefers-color-schemeによって--togglerに相当する値を切り替えると、light-dark()と同様の仕組みを実現できる。

:root {
  --light: initial;
  --dark: ;
  color-scheme: light dark;

  @media (prefers-color-scheme: dark) {
    --light: ;
    --dark: initial;
  }
}

#element {
  background-color: var(--color-bg-inverted);
  color: light-dark(white, black);
  font-weight: var(--light, 500) var(--dark, 300);
}

デフォルトでは--lightが無効なので500が採用され、--darkは有効なので単なる空白文字になる。color-scheme: light darkを併用することでlight-dark()も機能させられる。

そして、prefers-color-schemeを使わずに値を固定することで、常にライトモードもしくはダークモードに相当する状態も表現できる。

:root {
  --light: initial;
  --dark: ;
  color-scheme: light dark;

  @media (prefers-color-scheme: dark) {
    --light: ;
    --dark: initial;
  }
}

:root[data-theme='light'] {
  --light: initial;
  --dark: ;
  color-scheme: light;
}

:root[data-theme='dark'] {
  --light: ;
  --dark: initial;
  color-scheme: dark;
}

button {
  background: var(--light, #aaa) var(--dark, #444);
}

これらの実装はLightning CSSから着想を得た。

カラースキーム以外のテーマを切り替える使い方もできる。たとえば、設定に応じて余白の大きさが変化する設計を考える。

Name	Base	Compact	Comfortable
050	2	1	4
100	4	2	8
150	6	4	10

data-*属性を使って切り替えるとすれば、次のように実装できる。

:root {
  --is-size-base: initial;
  --is-size-compact: ;
  --is-size-comfortable: ;

  &[data-size='compact'] {
    --is-size-base: ;
    --is-size-compact: initial;
    --is-size-comfortable: ;
  }

  &[data-size='comfortable'] {
    --is-size-base: ;
    --is-size-compact: ;
    --is-size-comfortable: initial;
  }
}

:root {
  --space-050: var(--is-size-base, 2px) var(--is-size-compact, 1px) var(--is-size-comfortable, 4px);
  --space-100: var(--is-size-base, 4px) var(--is-size-compact, 2px) var(--is-size-comfortable, 8px);
  --space-150: var(--is-size-base, 6px) var(--is-size-compact, 4px) var(--is-size-comfortable, 10px);
}

<html data-size="comfortable">
  <!-- ... -->
</div>

参考資料

画像を囲うボーダーの色を半透明にしてコンテンツに馴染みやすくする

Sat, 14 Feb 2026 04:45:00 GMT

CSSのborderプロパティに半透明の色を指定すると、ボーダーが透過してその背景と合成される。

button {
  border: 2px solid oklch(0 0 0 / 0.25);
  background-color: rebeccapurple;
}

ボーダーの色はその背景に応じたものになり、単なる不透明なグレーを使うよりも馴染んで見えるようになる。背景が単色であれば、必ずしも半透明でなくても個別に調整した色を使うことができるが、特に画像やグラデーションが用いられている場合はこの手法が効果的である。

しかしimg要素を使う場合、borderプロパティでは同様の効果を実現できない。img要素のボーダーは画像の外側に描画されるが、前述の効果を実現するには、画像の上に覆い被さるように位置していなければならないからだ。box-shadowプロパティとinsetキーワードを使ってボーダーを描画する手法もあるが、画像の後ろ側に隠れてしまう。

そこで、代わりにoutlineプロパティを使う。通常は要素の外側に描画されるが、outline-offsetプロパティで内側に移動させれば、画像の上にボーダーを重ねることができる。ラッパー要素などは不要だ。

img {
  outline: 1px solid oklch(0 0 0 / 0.1);
  outline-offset: -1px;
}

このようにして画像を半透明なボーダーで囲うと、ただ画像に馴染んで見えるだけではなく、不要なときには目立たなくなることも大きなメリットだ。

というのも画像の周囲のボーダーは、画像と背景を同化させずに際立たせるためのものであり、たとえば白背景のページに白い画像を配置するときに境界線として機能させることを目的としている。一方黒い画像を使う場合、その画像があるだけで境界は明らかなので、ボーダーは必要ない。ところがCSSで一律ボーダーを適用していると、そのような区別がなく、不要なものにもボーダーが付与されて不恰好に見えることがよくある。

不透明なボーダーを適用した例

だが半透明なボーダーであれば、黒い画像には同化して目立たなくなる。より正確に言えば、そのボーダーに近い色の画像と重なり合うと、ということだ。だからもし逆に、黒い背景に白い半透明なボーダーが使われていれば、白い画像に同化する。

半透明なボーダーを適用した例

こうした仕組みによって、冗長にならない場合にのみボーダーが「見える」ことになる。

Astro Meetup Japan v0: パネルディスカッション

Wed, 04 Feb 2026 00:00:00 GMT

Tailwind CSSにおけるデフォルトのspacingとサジェストを無効化する方法

Sun, 01 Feb 2026 09:00:00 GMT

Tailwind CSSでは、テーマ変数の--spacingに応じてmarginユーティリティなどのスペースに関するCSSが生成される。--spacingではほかのテーマ変数と違って、値を一つひとつ指定するのではなく、乗数となる値を一つ指定することで、その計算式が値として用いられる仕組みだ。

.m-8 {
  margin: calc(var(--spacing) * 8);
}

これによって、ユーティリティのキーには自由な数値を指定できるようになっている。

一方エディタでの編集時には、事前設定された値がサジェストされるようになっている。これによって、デフォルトの選択肢を提案しつつもそこから外れた値も使用できるという緩い制約として機能する。

これらのサジェスト内容はTailwindのソースコード内に直接定義されているもので、ユーザーがカスタマイズすることはできない。したがって、もしデザインの制約として独自のスペーシングセットを定義したいという場合でも、これを直接変更することはできない。

しかし別の方法で設定することはできる。まず--spacingを無効化したうえで、有効なスペーシングセットを明示的に指定する。これによって、デフォルトのサジェスト内容の代わりに独自のものが表示されるようになる。

@theme {
  --spacing: initial;

  --spacing-0: 0px;
  --spacing-050: calc(2 / 16 * 1rem);
  --spacing-100: calc(4 / 16 * 1rem);
  --spacing-150: calc(6 / 16 * 1rem);
  /* ... */
}

ただしこの場合、クラス名として自由な値を直接記述することはできなくなる。代わりにarbitrary valuesとして記述する必要がある。

<div class="m-150"><!-- ... --></div>

<div class="m-[calc(3/16*1rem)]"><!-- ... --></div>

また、デフォルトの--spacingでは常にrem単位が使用されるが、アクセシビリティの観点では好ましくない。具体的には、ブラウザやOSの文字サイズ拡大機能を使用した際、すべてにrem単位を使っていると文字サイズだけでなくすべてが同時に拡大してしまう（Tailwind作者のAdam Wathanもこの設計は失敗だったと認めている）。本来は、用途に応じてrem単位とpx単位を使い分けるべきだ。

--spacingを無効にすると、使用する単位をプロパティ別に設定できる。--spacing-*はあらゆるユーティリティに影響するが、個別のユーティリティにだけ有効なテーマ変数も定義されている。これらのテーマ変数はドキュメント化されていないが、utilities.tsに実装されているthemeKeysの値を参考にすれば、次のようにしてプロパティ別のスペーシングを設定できる。

@theme {
  --spacing: initial;

  --margin-0: 0px;
  --margin-050: calc(2 / 16 * 1rem);
  --margin-100: calc(4 / 16 * 1rem);
  --margin-150: calc(8 / 16 * 1rem);
  /* ... */

  --padding-0: 0px;
  --padding-050: 2px;
  --padding-100: 4px;
  --padding-150: 8px;
  /* ... */
}

<!-- margin: var(--margin-150); -->
<div class="m-150"><!-- ... --></div>

<!-- padding: var(--padding-150); -->
<div class="p-150"><!-- ... --></div>

コンテンツに自律的に適応するレイアウトとコンポジション、アップデートされたレイアウトプリミティブ

Mon, 29 Dec 2025 23:10:00 GMT

「ウェブはデフォルトでレスポンシブ」とかねてより言われている。それを妨げるようなスタイリングをしないかぎり、ウェブページのレイアウトはブラウザの表示幅に合わせて自動的に調整される。

レスポンシブデザインが普及する前、ウェブページは960pxの固定幅で作成することが一般的だった。当時のディスプレイ解像度は多くが1024pxの幅だったため、それに決め打ちした設計であった。

body {
  width: 960px;
}

固定幅のレイアウトは、余計なことをしなければ得られたはずのレスポンシブな性質を損なうものである。こうした固定的な設定を避けて、より柔軟なレイアウト手法で置き換えるのがレスポンシブデザインという戦略だ。

たとえば固定幅のレイアウトは、代わりに最大幅を指定することで、表示幅が狭くてもそれに適応して収縮するようなレイアウトになる。

body {
  max-width: 960px;
}

このとき、960pxという値は絶対のものではなくなる。幅は常に960pxではなく、広い範囲の中でのいずれかの値を取ることになる。960pxは境界値でしかない。あくまで妥当なレイアウトを実現するためのルールを提示しているのであって、唯一の解を強制するわけではないということ。

そして、特定の表示幅だけを前提とするのではなく、いかなる表示幅にも適応させると考えると、最大幅が960pxであることの必然性も薄れていく。決まった画面サイズに当てはめるよりも、コンテンツをどのように見せたいか——つまり、コンテンツにとってどの最大幅が適切かに基づいて値を設定すべきである。

レイアウトプリミティブ

Every Layout（日本語訳版）では、レスポンシブなレイアウトの最小要素を独自に定義し、それらをレイアウトプリミティブと呼んでいる。レイアウトプリミティブの特徴は、メディアクエリ無しでレイアウトの自動調整ができることと、それらを組み合わせて複合的なレイアウトを作成できることだ。

メディアクエリの問題は、特定の要素自身の大きさに基づいたルールを記述できないことにある。コンポーネントは300pxの幅のコンテナの中に配置されることもあれば、より広い500pxの幅のコンテナの中に配置されることもある。コンテナの大きさが異なれば、それに応じたレイアウトの調整が必要になることもあるが、メディアクエリではビューポートの幅に基づいたルールしか記述できない。

— The Sidebar: Every Layout

こうした問題を克服すべく、レイアウトプリミティブでは、要素自身の大きさに基づいたレイアウト調整ができるCSSの手法が組み込まれている。これによって要素の配置や折り返し位置が自動で処理されることになるため、個別にメディアクエリを記述して制御する必要がなくなる。

さらにEvery Layoutでは、ウェブにおけるレイアウトの多くはレイアウトプリミティブの組み合わせだけで実現できると述べられている。メディアクエリに依存する従来のレイアウト手法では、個々の要素に応じた制御が難しく、その結果として汎用性や再利用性が制約されがちだった。しかしこれを打開することで、再利用の可能性が一気に開ける。

— Composition: Every Layout

言い換えれば、コンテンツに自律的に適応するレイアウト要素を組み合わせることで、より複雑なレイアウトを自己組織化によって成立させられるということ。スクリーンサイズごとのレイアウトをトップダウンに規定するのではなく、局所的なルールから全体がボトムアップに立ち上がる。内からの構成と言ってもよいだろう。

このようなレイアウトプリミティブを駆使してレイアウトを構成することで、従来よりも効率的かつ堅牢なレスポンシブデザインが実現できるはずだ。

パターンの紹介

レイアウトプリミティブの妙は、パターンとしての完成度の高さにある。ウェブでよくあるレイアウト表現が、自律的に機能するプリミティブとしてうまく再定義されている。モジュラーな設計を実現するうえでは、こうした抽象化の精度こそが肝になる。

Every Layoutの共著者であるAndy Bellは、後にCUBE CSSというCSS方法論を発表する。CUBE CSSには、レイアウトプリミティブにも似たCompositionの概念があり、リファレンス実装としてそれらのソースコードが公開されている。

僕が思うに、これらはEvery Layoutの例と比べて、より実用的なパターン集になっている。多くはEvery Layoutと変わらないが、中でもあまり使われないものを取り除いたり、不足していたものを追加したりすることで、よく使うものが取り揃った使いやすいライブラリになった。これをアップデート版のレイアウトプリミティブと考えてもよいだろう。

そこで、以降はCUBE CSSの例をもとに各レイアウトを簡単に紹介する。デモがついているので、ウインドウをリサイズしながら確認してほしい。これらのパターンを学ぶことで、開発者がより良い実装ができるだけでなく、デザイナーにとっても堅牢な設計パターンを理解するための助けになるだろう。

Flow (Stack)

垂直方向に積み重ねられた要素の間に一律したマージンを設定する。特定の要素の余白だけ調整することもできる。

<div class="flow">
  <p>Nullam id dolor id nibh ultricies vehicula ut id elit. Nulla vitae elit libero, a pharetra augue.</p>
  <p>Nulla vitae elit libero, a pharetra augue. Cras justo odio, dapibus ac facilisis in, egestas eget quam.</p>
  <p style="--flow-space: 3em"><code>--flow-space</code> set with an inline style to 3em: <code>style="--flow-space: 3em"</code></p>
</div>

/*
FLOW COMPOSITION
Like the Every Layout stack: https://every-layout.dev/layouts/stack/
Info about this implementation: https://piccalil.li/quick-tip/flow-utility/
*/
.flow > * + * {
  margin-top: var(--flow-space, 1em);
}

— cube-boilerplate/src/css/compositions/flow.css at main · Set-Creative-Studio/cube-boilerplate

参考資料

Wrapper (Center)

コンテンツを水平方向に中央配置して、最大幅を制限する。左右の余白を確保することで、狭い画面でもコンテンツが端に張り付かないようになっている。

<div class="wrapper">
  <p>I am centered and have a nice, consistent gutter.</p>
</div>

/*
WRAPPER COMPOSITION
A common wrapper/container
*/
.wrapper {
  margin-inline: auto;
  max-width: clamp(16rem, var(--wrapper-max-width, 100vw), 80rem);
  padding-left: var(--gutter);
  padding-right: var(--gutter);
  position: relative;
}

— cube-boilerplate/src/css/compositions/wrapper.css at main · Set-Creative-Studio/cube-boilerplate

参考資料

Cluster

要素を水平方向に並べて、スペースが足りなくなったら自動的に折り返す。ラベルの長さに応じたレイアウトができる。

<div class="cluster">
  <div>Item 1</div>
  <div>Item 2</div>
  <div>Item 3</div>
  <div>Item 4</div>
  <div>Item 5</div>
  <div>Item 6</div>
  <div>Item 7</div>
  <div>Item 8</div>
</div>

/*
CLUSTER
More info: https://every-layout.dev/layouts/cluster/
A layout that lets you distribute items with consitent
spacing, regardless of their size

CUSTOM PROPERTIES AND CONFIGURATION
--gutter (var(--space-s-m)): This defines the space
between each item.

--cluster-horizontal-alignment (flex-start) How items should align
horizontally. Can be any acceptable flexbox aligmnent value.

--cluster-vertical-alignment How items should align vertically.
Can be any acceptable flexbox alignment value.
*/

.cluster {
  display: flex;
  flex-wrap: wrap;
  gap: var(--gutter, var(--space-s-m));
  justify-content: var(--cluster-horizontal-alignment, flex-start);
  align-items: var(--cluster-vertical-alignment, center);
}

— cube-boilerplate/src/css/compositions/cluster.css at main · Set-Creative-Studio/cube-boilerplate

参考資料

The Cluster: Every Layout

Repel

2つの要素を両端に配置し、スペースがあるときは引き離し、スペースが足りなくなったら積み重ねる。Every Layoutには存在しないパターン。

<div class="repel">
  <div>Item 1 repels item 2</div>
  <div>Item 2 repels item 1</div>
</div>

/*
REPEL
A little layout that pushes items away from each other where
there is space in the viewport and stacks on small viewports

CUSTOM PROPERTIES AND CONFIGURATION
--gutter (var(--space-s-m)): This defines the space
between each item.

--repel-vertical-alignment How items should align vertically.
Can be any acceptable flexbox alignment value.
*/
.repel {
  display: flex;
  flex-wrap: wrap;
  justify-content: space-between;
  align-items: var(--repel-vertical-alignment, center);
  gap: var(--gutter, var(--space-s-m));
}

.repel[data-nowrap] {
  flex-wrap: nowrap;
}

— cube-boilerplate/src/css/compositions/repel.css at main · Set-Creative-Studio/cube-boilerplate

Sidebar

サイドバーとメインコンテンツを横に並べるパターン。サイドバーは指定した幅になり、メインコンテンツは残りのスペースを埋める。ビューポートの幅が狭くなり、両方を横に並べるスペースがなくなると、自動的に縦に積み重なる。

<div class="sidebar">
  <div>I am the sidebar</div>
  <div class="flow">
    <h1>I am the content</h1>
    <p>Etiam porta sem malesuada magna mollis euismod. Cras mattis consectetur purus sit amet fermentum.</p>
    <p>Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Vestibulum id ligula porta felis euismod semper.</p>
  </div>
</div>

/*
SIDEBAR
More info: https://every-layout.dev/layouts/sidebar/
A layout that allows you to have a flexible main content area
and a "fixed" width sidebar that sits on the left or right.
If there is not enough viewport space to fit both the sidebar
width *and* the main content minimum width, they will stack
on top of each other

CUSTOM PROPERTIES AND CONFIGURATION
--gutter (var(--space-size-1)): This defines the space
between the sidebar and main content.

--sidebar-target-width (20rem): How large the sidebar should be

--sidebar-content-min-width(50%): The minimum size of the main content area

EXCEPTIONS
.sidebar[data-direction='rtl']: flips the sidebar to be on the right
*/
.sidebar {
  display: flex;
  flex-wrap: wrap;
  gap: var(--gutter, var(--space-s-l));
}

.sidebar > :first-child {
  flex-basis: var(--sidebar-target-width, 20rem);
  flex-grow: 1;
}

.sidebar > :last-child {
  flex-basis: 0;
  flex-grow: 999;
  min-width: var(--sidebar-content-min-width, 50%);
}

— cube-boilerplate/src/css/compositions/sidebar.css at main · Set-Creative-Studio/cube-boilerplate

参考資料

Switcher

2つの要素を横に並べ、コンテナの幅が指定した閾値を下回ると縦に積み重なる。

<div class="switcher">
  <div>Item 1</div>
  <div>Item 2</div>
</div>

/*
SWITCHER
More info: https://every-layout.dev/layouts/switcher/
A layout that allows you to lay **2** items next to each other
until there is not enough horizontal space to allow that.

CUSTOM PROPERTIES AND CONFIGURATION
--gutter (var(--space-size-1)): This defines the space
between each item

--switcher-target-container-width (40rem): How large the container
needs to be to allow items to sit inline with each other

--switcher-vertical-alignment How items should align vertically.
Can be any acceptable flexbox alignment value.
*/
.switcher {
  display: flex;
  flex-wrap: wrap;
  gap: var(--gutter, var(--space-s-l));
  align-items: var(--switcher-vertical-alignment, flex-start);
}

.switcher > * {
  flex-grow: 1;
  flex-basis: calc((var(--switcher-target-container-width, 40rem) - 100%) * 999);
}

/* Max 2 items,
so anything greater than 2 is full width */
.switcher > :nth-child(n + 3) {
  flex-basis: 100%;
}

— cube-boilerplate/src/css/compositions/switcher.css at main · Set-Creative-Studio/cube-boilerplate

参考資料

Grid

グリッドレイアウトを自動的に生成する。指定した最小幅を保ちながら、利用可能なスペースに応じて列数を自動調整する。

<div class="grid">
  <div>Item 1</div>
  <div>Item 2</div>
  <div>Item 3</div>
  <div>Item 4</div>
  <div>Item 5</div>
  <div>Item 6</div>
  <div>Item 7</div>
  <div>Item 8</div>
</div>

/* AUTO GRID
Related Every Layout: https://every-layout.dev/layouts/grid/
More info on the flexible nature: https://piccalil.li/tutorial/create-a-responsive-grid-layout-with-no-media-queries-using-css-grid/
A flexible layout that will create an auto-fill grid with
configurable grid item sizes

CUSTOM PROPERTIES AND CONFIGURATION
--gutter (var(--space-s-m)): This defines the space
between each item.

--grid-min-item-size (14rem): How large each item should be
ideally, as a minimum.

--grid-placement (auto-fill): Set either auto-fit or auto-fill
to change how empty grid tracks are handled */

.grid {
  display: grid;
  grid-template-columns: repeat(
    var(--grid-placement, auto-fill),
    minmax(var(--grid-min-item-size, 16rem), 1fr)
  );
  gap: var(--gutter, var(--space-s-l));
}

/* A split 50/50 layout */
.grid[data-layout='halves'] {
  --grid-placement: auto-fit;
  --grid-min-item-size: clamp(16rem, 50vw, 33rem);
}

/* Three column grid layout */
.grid[data-layout='thirds'] {
  --grid-placement: auto-fit;
  --grid-min-item-size: clamp(16rem, 33%, 20rem);
}

— cube-boilerplate/src/css/compositions/grid.css at main · Set-Creative-Studio/cube-boilerplate

参考資料

レスポンシブデザインの「間」を適切に設計するためのフルイドタイポグラフィとグリッドシステムの考え方——キャンバスインからコンテンツアウトへ

Mon, 01 Dec 2025 00:00:00 GMT

「PLAID Designer’s Advent Calendar 2025」の1日目の記事です。

レスポンシブデザインでウェブサイトの制作をする場合、デザイナーがモバイル幅とデスクトップ幅のデザインカンプを作成し、開発者がそれをもとに実装するというワークフローが一般的である。このとき決まって問題になるのが、デザインカンプとして定義されていない、モバイル幅とデスクトップ幅の「間」（もしくはその区間の外の幅）をどのように実装するかということだ。

デザインカンプを作成する際は、標準的なビューポートとして決まったモバイル幅やデスクトップ幅に向けてデザインするだろう。しかし実際のユーザー環境は極めて多様で、Set Studioの調査によれば12万件のデータから2300種類以上のビューポートのサイズが観測されたと言う。筆者がそのデータをもとに、典型的なデザインカンプの幅と一致するものを調べてみたところ、375pxは11.9%、1440pxはわずか1.15%だった。さらに、ユーザーは必ずしもブラウザを画面いっぱいに表示しているわけではなく、多くは好みの大きさにリサイズされているはずであり、昨今ではiPadでさえ複数ウインドウの表示が可能だ。

この状況において、標準的なビューポートを定義することには無理がある。だからこそ、デザインカンプとして仮定された幅での見え方ばかりを重視するよりも、モバイル幅からデスクトップ幅までの幅広い範囲全体を分け隔てなく設計すると考えるべきだ。

基本的に多くのデザインでは、モバイル幅では狭い描画領域に応じたシンプルなレイアウトで要素のサイズは小さく、デスクトップ幅では広い描画領域に応じた複雑なレイアウトで要素のサイズは大きくなる傾向がある。したがって、間の幅ではそれらの中間くらいになるようにデザインするのが適当と考えられる。

しかし、その中間くらいのデザインをするには思いのほか手間がかかる。デスクトップ幅のデザインとモバイル幅のデザインを見比べながら、レイアウトや文字サイズ、余白などがちょうどよいところに落ち着くよう、周囲の要素とのバランスも鑑みながら一つひとつ調整していく作業はそれなりに大変なものだ。また、細かくブレークポイントを設けて個別にスタイルを上書きしていくことで、CSSの保守性も悪化してしまう。さらに複数の開発者が携わると、中間のデザインのバランス感覚や実装方式にブレが生じて問題が複雑化する。

こうした諸問題は、個別のスタイル調整のたびに人の手を介在させなければならないことに由来して生じる。だがCSSの機能をうまく利用すれば、ブレークポイントの個別の調整なしに自ずとレスポンシブなレイアウトを構築できる。そして前述のような問題もかなり軽減されるのだ。今回は、そのために効果的なCSSの手法や考え方について紹介する。

フルイドタイポグラフィ

ビューポートの幅に応じて文字サイズを調整したいとき、まず思いつく手法は、メディアクエリを使ってブレークポイントごとに上書きしていくことだろう。このように実装すると、ブラウザをリサイズしてブレークポイントに達するたびに、レイアウトがガクンと切り替わるような見え方になる。

h1 {
  font-size: 2rem;
}

@media (min-width: 768px) {
  h1 {
    font-size: 3rem;
  }
}

@media (min-width: 1280px) {
  h1 {
    font-size: 4rem;
  }
}

@media (min-width: 1600px) {
  h1 {
    font-size: 5rem;
  }
}

— Modern Fluid Typography Using CSS Clamp — Smashing Magazine

この手法には大きく2つの問題がある。

一つは、ブレークポイントごとにCSSを上書きする作業が必要なこと。一つの要素だけ調整するのなら簡単だが、実際はサイト全体に渡るあらゆる要素においてこの作業をすることになる。保守性の観点でも好ましくない。

もう一つは、ブレークポイントに近づくにつれて見栄えが悪くなってしまうこと。モバイル幅からデスクトップ幅にかけてCSSを記述する場合、ビューポートの幅が広がることにともなって文字サイズの調整が必要になるたび、ブレークポイントを設けてCSSを上書きすることになる。しかし現実的な問題として、ブレークポイントを無数に設けるわけにはいかないので、見た目の理想状態から離れて許容できる限界に達するまでタイミングを間引いてから上書きするという判断になるがちだ。その結果、ブレークポイントの付近ではよい見た目にならない傾向がある。

こうした問題の解決策として、文字サイズなどの値を自動調整する手法がある。CSSのvw単位などを駆使して、指定した最小値から最大値までをビューポートの幅に応じて線形に変化させる計算式を使った仕組みだ。これはフルイドタイポグラフィ（fluid typography）、もしくは単に文字を指してフルイドタイプ（fluid type）と呼ばれる（参考: Fluid Typography | CSS-Tricks）。

— Modern Fluid Typography Using CSS Clamp — Smashing Magazine

実装例はいくつかあるが、よりネイティブなアプローチとして、CSSの@functionを使ったものを紹介しておこう。

/**
Creates fluid typography that scales with viewport.

NOTE: This function is mathematically equivalent to `--responsive-value()` but optimized for typography. Use this for `font-size`, `--responsive-value()` for other properties.

@param {Length} --min - Minimum font size.
@param {Length} --max - Maximum font size.
@param {Length} --min-viewport - Minimum viewport width.
@param {Length} --max-viewport - Maximum viewport width.
@returns {Length} Fluid font size.
@example font-size: --fluid-type(16px, 24px, 320px, 1280px);
*/
@function --fluid-type(--min, --max, --min-viewport: 320px, --max-viewport: 1280px) {
	--slope: calc((var(--max) - var(--min)) / (var(--max-viewport) - var(--min-viewport)));
	--intercept: calc(var(--min) - var(--slope) * var(--min-viewport));
	result: clamp(var(--min), calc(var(--intercept) + var(--slope) * 100vw), var(--max));
}

— css-extras/index.css at v0.4.0 · sindresorhus/css-extras

これによって、前述のブレークポイントを使った例は次のように置き換えられる。

h1 {
  font-size: --fluid-type(2rem, 5rem);
}

このフルイドタイポグラフィの良いところは、今まで通りのワークフローをほとんど変えることなく取り入れられることだ。モバイル幅の値を最小値に、デスクトップ幅の値を最大値にそのまま指定することで、ブレークポイントベースの実装をほぼ機械的に置き換えられる。

そしてフルイドタイポグラフィは、文字サイズだけではなく、余白や要素の幅・高さなどにも併せて適用することでより効力を発揮する。ブレークポイントベースでの実装と同じく、全体のバランスが問題であり、そのためにはさまざまな要素を同時に調整することが肝心だからだ。

注意点として、モバイル幅とデスクトップ幅で異なったあしらいが施されている場合、見たままの通りに最小値と最大値を指定して実装できないことがある。もしくは、間の幅に合わせてどちらでもないレイアウトをせざるを得ない場合もそうだ。そうした場合は、単に静的な値を指定するか、いい塩梅の変化になるように値を検証して指定する必要がある。

前述の実装例は、好みのツールに合わせて書き換えるとよい。@functionの実装状況はまだ不十分なことに加え、Firefoxでは異なる単位同士の乗算や除算に対応しておらず、そのままでは使用できないからだ。僕の場合はTailwind CSSを使うことが多いので、独自のPostCSSプラグイン作成したうえで独自関数を導入している。これはTailwind CSSで次のように使用できる。

<h1 class="text-[length:--fluid(2rem,5rem)]"><!-- ... --></h1>

もしくは次のようにしてもよい。

@theme {
  --text-h1: --fluid(2rem, 5rem);
}

<h1 class="text-h1"><!-- ... --></h1>

Utopia

フルイドタイポグラフィ自体は有用であるものの、しかしデザインのためのシステムとしてはこれだけでは不完全とも言える。レスポンシブデザインにおける値の指定は、単一の要素のみではなく、複数要素の組み合わせからなる問題だと考えると、その組み合わせをどのように生成すべきかが次の問いになるからである。

具体的に言えば、レスポンシブデザインを前提としたタイプスケールや余白のバリエーションをどう設計するか。もしこれらを無秩序に設定すると、全体の統一感がなくなったり、ヒエラルキーを適切に表現できなくなったりしてしまう。だから、パターンをどこかのタイミングで決めて、その全体ルールに則って個別デザインを進めるのが定石だ。

— The type system - Material Design

一方、レスポンシブデザインを前提とした方法論はあまり普及していないように思う。モバイル幅とデスクトップ幅でバリエーションは別々に定義するのか、それとも共通のセットが先にあってから幅によって値だけが変化するのか。モバイル幅での値とデスクトップ幅での値の比率はどのようになるのか。

そこで、レスポンシブデザインのための体系的な方法論として生まれたのがUtopiaである。Utopiaが提供するのは、タイプスケールと余白のバリエーションを生成するための2つのジェネレーターだ。

Utopiaの狙いの一つは、デザイナーと開発者が同じ意図に基づいて制作すること。デザイナーはこれによって生成されたタイプスケールと余白を使ってデザインし、開発者はそうして指定された値をそのままコードに適用する。

これらはフルイドタイポグラフィと同様の仕組みに基づいている。モバイル幅とデスクトップ幅を指定したうえで、それぞれのジェネレーターに固有の設定をすることで、そこからなるスケールとCSSが出力される。

タイプスケールにはモジュラースケールが採用されており、基準値と比率をそれぞれ幅ごとに指定する。

— Fluid type scale calculator | Utopia

ステップごとの値を視覚化すると次のようになる。

— Designing with fluid type scales | Utopia

余白はもっと単純で、単なる基準値の乗算になっている。

— Fluid space calculator | Utopia

こうして生成されたタイプスケールと余白を使って、まずデザイナーがデザインカンプを作成する。「タイトルはステップ2」「その周囲の余白はS」というように、パレットから値を選ぶようにしてデザインする。開発者がそれを実装すると、間の幅も含めた全体が自ずと出来上がる。

— Utopian project kickstarter with modes | Figma

— Designing with fluid type scales | Utopia

実際にUtopiaを使うとどのようなウェブページができるかについては、公式のデモやShowcaseの事例を開いてリサイズしてみるとわかりやすい。

Utopiaは、デザイナーの設計の一部を自動化すると同時に制約するアプローチでもある。これが良い方向に働くこともあれば、そうならないこともあるだろう。特にモジュラースケールは思うように機能しないことも多いので、そのまま採用すると不便かもしれない。これについて、モジュラースケールの等比数列の代わりに調和数列を使うことを提案するものもある。また現在開発中のBootstrap 6では、小さいサイズは固定値で大きいサイズはフルイドタイポグラフィという使い分けがなされている。

いずれにしても、レスポンシブを前提とした値のセットをデザイナーと開発者で共有するアイデアは有用に感じる。というのも、モバイル幅とデスクトップ幅で別々にデザインカンプを作成していると、それぞれで別物のデザインをしているような意識になることがしばしばある。そうしたとき、文字サイズや余白に対して、モバイル幅とデスクトップ幅で共通のスケールを適用するという意識が生まれることで、良き制約として機能することを期待できるからだ。

キャンバスインからコンテンツアウトへ

これまでの僕の経験として、デザインカンプにおけるグリッドシステムの扱いには非常に苦心してきた。この指定をもとにCSSを作成しても、レスポンシブデザインとしてうまくいったと思えることはほとんどない。多くのデザイナーはそれを静的なアートボード上のガイドとしか捉えておらず、ビューポートが伸縮したときに機能するかどうかまでは基本的に考えていないからだ。

そもそもグリッドシステムは、歴史的には紙媒体のデザインのなかで確立されてきた。紙媒体のデザインでは、レイアウトの出発点は紙面である。特定の紙面の寸法と比率に基づいて列と行のグリッドシステムに分割し、そのモジュール上にコンテンツを配置する。これはキャンバスインとも呼ばれる。紙面という固定された明確な制約に基づいたプロセスであり、ビューポートのサイズが不定なウェブとは一線を画す。

多くのレスポンシブデザインはいまだキャンバスインの発想で作成されている。デバイスのサイズごとに別々のアートボードを作成し、アートボードごとにグリッドを設定し、そのグリッドに合わせて要素を複製してサイズ調整する。これによって生じるのは、どのようなデバイスにもなめらかに適応するレスポンシブデザインではなく、ブレークポイントごとに分離された別々のデザインの出し分けだ。これについて『Every Layout』では次のように述べられている。

Every Layoutでは、幅を基準としたメディアクエリの使用を避けています。メディアクエリでは、レイアウトの再構成をハードコーディングで表現することになります。さらに、要素やコンポーネントが実際に置かれている状況と結びついていないのです。先ほどの例のように、インターフェイスのスケーリングを個別の「ブレイクポイント」に基づいて行うのは恣意的な設定です。960pxは何か特別な幅なのでしょうか？　959pxで小さいサイズになることが本当に適切だといえるのでしょうか？

ブレイクポイントを使用すると、1pxの違いが大きな「ジャンプ」になります。

— ヘイドン・ピカリング、アンディ・ベル著、安田祐平、横内宏樹監訳『Every Layout』、株式会社ボーンデジタル、2021年

ウェブは流動的なメディアであり、ユーザーのビューポートのサイズを事前に知ることはできない。つまり、紙媒体のような固定的なグリッドシステムは成り立たない。だから発想を転換しなければいけない。

グリッドには頼れない代わりに、ウェブではコンテンツからレイアウトを作成すると考える。ブレークポイントごとにページ全体を別物のレイアウトに書き換えてしまうのではなく、ビューポートの拡大にともなう個々のコンテンツの変化に着目し、必要に応じて個別に調整していくというアプローチだ。これをコンテンツアウトと呼ぶ。

具体的な解説がweb.devにあったので引用しよう。特に動画の例を見るとわかりやすい。

画面が広くなると、ウィジェットの形状がそれに応じて変化します。

（中略）

小さく始め、徐々に大きくして主要なブレークポイントを選択する

まず小さい画面サイズに収まるようにコンテンツを設計し、ブレークポイントが必要になるまで画面を拡大します。これにより、ページのブレークポイントの数を最小限に抑え、コンテンツに基づいて最適化できます。

次の例では、このページの冒頭にある天気予報ウィジェットの例について説明します。最初のステップは、予報を小さい画面に適切に表示することです。

幅が狭いアプリ。

次に、要素間の空白が広すぎてウィジェットが見づらくなるまでブラウザのサイズを変更します。判断は主観的ですが、600pxを超えると明らかに広すぎます。

このサイズでは、アプリのレイアウトを変更する必要があります。

— レスポンシブウェブデザインの基本 | Articles | web.dev

また「CSS Container Queries For Designers」や「An Interactive Guide to CSS Container Queries」では、ほかにもいくつかのレイアウトパターンをContainer Queriesを使って作成する方法が紹介されている。

しかし、このような設計をするにはコードを書きながらでないと難しい。デザイナーにとってはそこが障壁だろう。このやり方だけでページ全体のデザインを考えることも現実的ではないかもしれない。そこでデザインカンプでの作業を前提としたうえで、もう少し別の観点も紹介しよう。

グリッドシステムとの向き合い方

デザインカンプのグリッドシステムとしてもっとも典型的な設定は、ページを横に12分割するカラムだろう。一方、このようなグリッドに忠実なCSSを実装しても、あまり良い結果にならないことが多い。特定の幅のデザインカンプで良い見栄えになるとしても、レイアウトをそのカラムに沿わせたままウィンドウをリサイズするとたいてい不恰好だったり意図に反する結果になる。

いくつか例を出そう。12カラムのうち左の3カラムがサイドバーになっているレイアウトがあるとする。そのサイドバーの幅がページ全体の3/12になるように実装すると、ページ全体の幅が少し狭まるだけでサイドバーの領域も狭まりすぎてしまうことが推測できる。

もしくは、12カラムの左右から2カラムずつずらして、8カラム分のコンテンツ領域を中央に配置するとする。この場合も同じく、そのコンテンツ領域をページ全体の8/12になるように実装すると、ページ全体の幅が少し狭まるだけでコンテンツ領域の幅も狭まりすぎてしまう。

これについてのシンプルな解決策は、12カラムグリッドのようなガイドを拠り所にするのをやめることだ。コンテンツアウトの発想でデザインするなら、そのようなガイドがなくとも必要に応じたレイアウト調整がなされるだろう。

では、前述の例をコンテンツアウトの発想で実装するならどうするか。サイドバーの幅には相対値の代わりに絶対値を指定した方が、より幅広い範囲のビューポートにおいて妥当に表示できそうだ。中央に配置された8カラムのコンテンツ領域は、相対値を指定する代わりにmax-widthで絶対値を指定した方が、狭すぎる状態になることがなく、空間を無駄にせずに済む。

もっとも、これは周囲のコンテンツとの関係や別ページとの整合性にも関わる問題なので、一概にこの方が良いとは言い切れない。しかし、グリッドに沿わせるようにレイアウトすることは根本的にキャンバスインの発想で、ビューポートの変化に耐えられない傾向にある。

一方で現実的には、レイアウトの当たりをつけるのにグリッドがなければ難しいこともある。だから落とし所として、「グリッドを使うのは良いがあくまで静的なレイアウトの目安として使う。実装の際には必ずしも採用しない」。デザイナーと開発者の間でそのように認識を合わせるのが良いのかもしれない。

また、コンテンツアウトの発想での解釈ができるのは、必ずしもグリッドに沿わせなくてもレイアウトが成立する余地があるときだけだ。特にこのような調整が難しくなるのは、デザイナーがあらゆる要素をグリッドに沿わせようと固執しているときである。

たとえばSpectrumでは、グリッドにおける「レイアウト領域（layout regions）」の概念が文書化されている。これはグリッド上に配置される、任意のコンテンツを囲うコンテナのようなものを指す。

— Responsive grid - Spectrum

このレイアウト領域のルールでは、レイアウト領域の縁はグリッドに沿わせるが、領域の内側のレイアウトは沿わせてはならない。そこまでもがグリッドに沿っていると、ボタンのラベルの長さなどの応じたレイアウトの調整が効かなくなってしまうからだ。

— Responsive grid - Spectrum

これは言い換えれば、レイアウト領域はキャンバスイン、レイアウト領域の内側はコンテンツアウトでレイアウトすることだとも言える。マクロなレイアウトはグリッドを拠り所にしてレイアウトしつつ、外側から規定しづらいミクロなレイアウトはコンテンツに応じて調整可能にするという使い分けである。その意味でキャンバスインとコンテンツアウトは、トップダウンとボトムアップの関係にあると言ってもよい。これは些細なことのようで、レスポンシブデザインを成立させるうえで重要な視点だ。

レイアウト領域の内側では、グリッドに由来しない、何かしらの絶対的な値に基づいてレイアウトをする。そこで前述したUtopiaの例のように、利用する余白サイズのパターンを決めて用いることで、グリッドシステムにも似たシステム的なアプローチが実現される。

— gridless.design

また別の例を出そう。あるレイアウト領域のなかにまた別のレイアウトが入れ子になることがある。サイドバーと隣り合ったメインカラムのなかに、グリッド状のカードビューを表示するような場合だ。もしその内側のレイアウトも全体のグリッドに沿わせなければならないと解釈すれば、いろいろと窮屈なことになるだろう。しかしFigmaでは、外側のアートボードだけではなく、あらゆるフレームに対してグリッドを設定することができる。

— Everything you need to know about layout grids in Figma

これによってレイアウト領域の内側では、個々のコンテンツに応じたガイドの設定をすることもできる。アートボードレベルのグリッドに沿わせることだけが正しいやり方なのではない。

「PLAID Designer’s Advent Calendar 2025」の2日目は、tomaさんによる「プロダクトデザイナーが実践するtoB SaaSのNPS調査」です。

参考資料

iframe要素の中身のコンテンツに応じて属性を自動設定できるAstroコンポーネントを作る

Fri, 12 Sep 2025 20:50:00 GMT

前回のブログを作成するにあたって、デモページをいくつも用意する必要があった。これまではCodePenで作成したものを埋め込んで表示していたが、ソースコードがブログと別の場所で管理されていることが煩わしかったので、代わりにデモページを同サイトに配置してiframe要素から読み込んで表示することにした。

これをシンプルに実装すると次のようになる。

<iframe
  src="/2025-09-12-click-friendly-target-areas/navbar-bad.html"
  title="ナビゲーションバーのデモ（悪い例）"
  height="128"
  style="width: 100%"
></iframe>

このうち、title属性にはそのドキュメントのタイトルを設定する。そして、iframe要素をそのドキュメントとピッタリ同じ高さにするために、ドキュメントの高さをheight属性に設定する。これらを手動で設定するのはやや手間なので、次のようにして自動化した。

src/content/blog/2025-09-12-click-friendly-target-areas.mdx:

import SmartIframe from '../../components/SmartIframe.astro';

<SmartIframe src="/2025-09-12-click-friendly-target-areas/navbar-bad.html" />

src/components/SmartIframe.astro:

---
import type { HTMLAttributes } from 'astro/types';
import { chromium } from 'playwright';
import invariant from 'tiny-invariant';

interface Props extends HTMLAttributes<'iframe'> {
  src: string;
}

const { src, ...attrs } = Astro.props;

invariant(typeof src === 'string', 'SmartIframe requires a src prop');

const url = new URL(src, Astro.url).href;

const browser = await chromium.launch();
const page = await browser.newPage();

await page.setViewportSize({ width: 756, height: 720 }); // iframeを表示するページのコンテンツ幅を指定
await page.goto(url);
await page.waitForLoadState('load');

const [title, height] = await page.evaluate(() => [
  document.title,
  document.documentElement.offsetHeight,
]);

await browser.close();
---

<iframe src={src} title={title} height={height} style={{ width: '100%' }} {...attrs}></iframe>;

Playwrightを使ってドキュメントを実際に描画し、そのタイトルと高さを取得してiframe要素に割り当てている。これによって、src属性さえ指定すれば、それ以外の属性の手動指定は不要になる。

また、iframe要素のなかのドキュメントの高さは、iframe要素が描画される際の幅によって変化することがある。iframe要素の高さをこれに応じたものにするために、クライアントサイドでの動的な処理を追加する。ResizeObserverを使ってドキュメントの高さの変化を監視し、それをiframe要素に反映する。

<iframe
  src={src}
  title={title}
  height={height}
  style={{ width: '100%' }}
  {...attrs}
  data-smart-iframe></iframe>

<script>
  for (const iframe of document.querySelectorAll<HTMLIFrameElement>('[data-smart-iframe]')) {
    iframe.addEventListener('load', () => {
      const resizeObserver = new ResizeObserver((entries) => {
        const { blockSize } = entries[0].contentBoxSize[0];
        iframe.height = blockSize.toString();
      });

      if (iframe.contentDocument) {
        resizeObserver.observe(iframe.contentDocument.documentElement);
      }
    });
  }
</script>

これによって、ドキュメントの実際の高さに応じて動的に変化するレスポンシブなiframe要素を実現できた。

クリックしやすいターゲットエリアを実装する #web_ui_devs

Thu, 11 Sep 2025 16:20:00 GMT

この記事は、「Web UI 実装勉強会 #1」での同タイトルの発表をもとにしたものです。

ターゲットエリアを広げる工夫

リンクやボタンなどのUI要素を押したときに反応する領域のことをターゲットエリアと呼びます。素朴に実装すれば、その要素の視覚的なサイズがそのままターゲットエリアになります。

しかし場合によっては、これではあまり使い勝手が良くならないことがあります。要素自体のサイズが小さいと押すことができる領域も狭くなるので、その分正確性が求められて押しづらくなります。

そういうときには、視覚的なサイズよりも余分にターゲットエリアを広げるテクニックを使います。paddingプロパティを使って要素自体のサイズを広げつつ、レイアウトが崩れないように同じ大きさのネガティブマージンを適用します。

a {
  margin: -4px;
  padding: 4px;
}

一方、プレーンなテキストリンクと違って、背景色などがついたボタンなどの場合、paddingプロパティのテクニックは少し使いづらいです。

そのような場合は、擬似要素を使って相対的な位置指定をするのが簡単です。

button {
  position: relative;

  &::before {
    position: absolute;
    inset: -6px;
    content: '';
  }
}

iOSにおけるターゲットエリア

このような工夫は僕が独自に考えたものではなくて、昔からさまざまな実装に採用されています。たとえばiOSにおいては、ナビゲーションバーのボタンではボタン自体の大きさよりも大きなターゲットエリアが確保されているそうです（参考: iPhone の当たり判定を検証した）。

— ソシオメディア | iPhone の当たり判定を検証した

興味深いのは、キーボードのターゲットエリアはタイピングの途中で動的に変化するようになっていることです。ユーザーが一文字タイプするたびに、次にくる文字を予測して、キーごとに重み付けがされているのです。

QWERTYキーボードのキーの幅はかなり狭く、通常時のターゲットエリアのサイズは32ptです。

— ソシオメディア | iPhone の当たり判定を検証した

しかし、「WORLD」という単語を打つつもりで「WORL」までをタイプすると、次に来る可能性が高いDキーのターゲットエリアが広がって44ptになるそうです。

— ソシオメディア | iPhone の当たり判定を検証した

このような高度な実装をしてまでも、ターゲットエリアの大きさを確保することが重要なのだと思います。

ターゲットサイズの基準

とはいえ、現実的にどこまで大きくすればいいかについては、基準がなければ判断が難しいものです。

一つの目安として、WCAGにはターゲットサイズに関する達成基準が二つあります。そのなかで、最低限の基準としては24px × 24px、より高度な基準としては44px × 44pxを満たすことが定められています。また、Human Interface Guidelinesでは44pt × 44ptが基準になっています。

ガイドライン	サイズ
WCAG SC 2.5.8	24px × 24px
WCAG SC 2.5.5	44px × 44px
Human Interface Guidelines	44pt × 44pt

これを踏まえて、24px × 24pxの大きさは最低限確保するようにしつつ、状況に応じて44px × 44pxも達成することを目指すと考えるとよいでしょう。

押せそうな場所は押せるようにする

また別の例として、本来押せそうに見えるのに押せないようになっている実装をたまに見かけることがあります。わかりやすい例としては、チェックボックスです。チェックボタンを押せば反応するけど、そのラベルを押しても反応しないようになっていることがあります。

<input type="checkbox" /> Do you need animations?

慣習的に考えても、チェックボックスはラベルまで含めて押せるようになっているべきです。実装としては、label要素で囲えばそれを実現できます。

<label><input type="checkbox" /> Do you need animations?</label>

もう少し複雑な例として、アイコンとinput要素の組み合わせからなる検索フィールドの実装についても考えてみます。こうしたUI要素は、マークアップとして見れば複数の要素を組み合わせた複合的なコンポーネントですが、ユーザーにとっては単一の入力フィールドです。このことを意識せずに、見た目だけを再現するつもりで実装すると、限られたエリアしか押すことができない次のような実装になってしまいます。

<div class="search-field">
  <svg>...</svg>
  <input type="search" />
</div>

.search-field {
  display: inline-flex;
  gap: 8px;
  border: 1px solid;
  background-color: white;
  padding: 4px 8px;

  input {
    border: 0;
    background-color: transparent;
  }
}

これは実装モデルに引っ張られてしまったがゆえの失敗です。理想的には、複数の要素の組み合わせであることをユーザーに意識させないような実装になっているべきです。つまり、普通の入力フィールドと同じようにどこを押してもフォーカスできるようになっているのが良いでしょう。

<div class="search-field">
  <svg>...</svg>
  <input type="search" />
</div>

.search-field {
  position: relative;

  svg {
    position: absolute;
    margin: 4px 8px;
    pointer-events: none;
  }

  input {
    border: 1px solid;
    background-color: white;
    padding: 8px 8px 8px 40px;
  }
}

無闇に広げすぎない

一方、ターゲットエリアは必ずしも広ければ広いほど良いわけでもありません。

リスト項目が縦にスタックしたようなナビゲーションがあるとします。そのなかのリンクにdisplay: blockを適用すると、コンテナサイズいっぱいまでターゲットエリアが拡張されます。

a {
  display: block;
}

一見、ターゲットエリアが広がって良いことのように思えますが、別の側面から見れば、対象の要素と関係なさそうな場所を押しても反応してしまうことになります。すると、「リンクを押すつもりはないのに、意図せず押したことになってしまった」ということが起こり得ます。

この改善例としては、width: fit-contentなどを適用して必要以上に伸び広がらないように制御するのが良いでしょう。またpaddingのテクニックも併用して、周辺に少しだけ広げる工夫もするとなお良いです。

a {
  display: block;
  margin-inline: -12px;
  padding-inline: 12px;
  width: fit-content;
}

似たような例として、入力フィールドのラベルのターゲットエリアがあります。レイアウトの都合でdisplay: blockを適用することはよくありますが、その場合も同様の問題が起こります。

label {
  display: block;
}

こうしたときにも、width: fit-contentなどを適用して範囲を制御するのがよいと思います。

label {
  display: block;
  width: fit-content;
}

今回の勉強会についての余談

今回のこの勉強会に参加したのは、開催者のKatashinさんが以前投稿していた「UI の実装に関する勉強会をやりたい」という問題意識に共感したからだ。

最近また勉強会に参加するようになって色々と行っているうちに、ふと UI の実装に関する勉強会ってほとんどないなと思った。UI デザインはちらほら見かけるけど、UI 実装は見かけない。

たいてい TypeScript、Vue、Biome みたいに言語、ライブラリ、ツールをテーマにしたものが多くて、UI を切り口にしているものを見かけない。もちろん、他のテーマの勉強会で UI を絡めた話がある場合もあるけど、UI 実装をテーマに据えた会でいろいろな話を聞いてみたい。

— UI の実装に関する勉強会をやりたい

同日に投稿されていた、橋本麦さんの「Jul 24, 2025: 詰め方の問題」にも感化された部分がある。

結局のところ、ぼくが気になっているのは、ものごとを媒介する関係性や構造ばかりが語られて、肝心のそれ自体——グラフィックであれ、アニメーションであれ、画面に現れる表層的な“何か”そのものが、語られることなくどこかへ押しやられていることだ。もちろん、それをめぐる構造、物語性、組織や経済がどう影響しているかは、無視できるわけじゃない。でも、だからといってそれ「ばかり」に意識を向けるのは、Lev Manovichが言うように、画面の「出力」だけを見てその背後にあるプログラムのアーキテクチャを問わないのと同じくらい片手落ちだ。それは生存戦略として間違っちゃいないにせよ、グラフィックデザイン文化としては貧しいと思う。

— Jul 24, 2025: 詰め方の問題

個人的には、自分の近辺のコミュニティで、UIそのものについて語られる機会が少ないと思っていた。みんなある程度のキャリアを経ると、そういう手前の話は「通過済み」のものとして理解されてしまうのかもしれない。けれど僕にとっては最初と変わらず喫緊の問題だし、いつまで経っても、世の中に新たな出来の悪いUIが生み出され続けていることに辟易としている。

また、開発者のUIに対する無頓着さについても気になっていた。開発者としてコードを書いていると、何かを形にするための方法にばかり視点が向いてしまうことがある。しかしその方法としての妥当性の前に、形にしようとしているそのものに目を向けることが重要だし、それに付き従って構造ができるのだ。ダメなものの構造を強化しても仕方がない。これは分業体制下において抜け落ちがちな意識かもしれない。

だからこそ、UIのデザイン意図と実装が交差するような話をしたいと思った。本来デザインと実装の垣根はないが、何かしらの肩書きのもとで植え付けられた意識が、そこに壁を作っている。そうしたナンセンスな区分けにとらわれずに、それそのものについてフラットな視点で考えられるようにしたい。

こういう考え方がもっと広められると良いし、そのような機会があれば連帯したい。次回も開催されるようなので参加したいと思う。

あと、久しぶりに会ったterkelさんに「相変わらずfundamentalな話してる」と評されたのがうれしかった。

UIとフロントエンド技術が好きなエンジニア→デザインエンジニアを募集しています

Sat, 06 Sep 2025 00:00:00 GMT

package.jsonのdependenciesをアップデートする技術

Wed, 13 Aug 2025 00:00:00 GMT

Figmaのstylesをもとにして「Tailwind CSSのテーマ」「tailwind-mergeの設定」「Storybookのドキュメント」などの各種ファイルを自動生成する

Tue, 12 Aug 2025 00:00:00 GMT

Tailwind CSS 4をShadow DOM内で動作させる方法

Sun, 10 Aug 2025 08:50:00 GMT

ページ内のスタイルの競合を避けるため、Shadow DOMのなかでTailwind CSSを読み込みたいという場面があった。これはTailwind 3では問題なく実現できたが、Tailwind 4では一部のスタイルが適用されなくなる問題が発生した。

具体的な実装は次のようなものである。

import root from 'react-shadow';

// ViteのExplicit URL Importsを使用する
// https://vite.dev/guide/assets.html#explicit-url-imports
import styleSheetURL from './index.css?url';

function Button() {
  return (
    <button className="rounded-lg bg-gradient-to-r from-blue-500 to-purple-600 px-4 py-2 font-semibold text-white shadow-lg transition duration-300 hover:scale-105 hover:from-blue-600 hover:to-purple-700">
      Save changes
    </button>
  );
}

function App() {
  return (
    <>
      <p>Inside a shadow root:</p>
      <root.div>
        <link rel="stylesheet" href={styleSheetURL} />
        <Button />
      </root.div>

      <p>Outside a shadow root:</p>
      <Button />
    </>
  );
}

期待される描画結果は次の通り。

しかし実際には背景のグラデーションが適用されず、不完全な状態で表示されてしまった。

原因を調べてみると、どうやらTailwind 4で使用されている@propertyルールがShadow DOMのなかで動作しないせいであるようだ。Shadow DOMのなかでは@propertyルールが無視されて、カスタムプロパティが未定義扱いになってしまう。

Tailwind 4では、@propertyルールを使ってカスタムプロパティを定義している。一部のユーティリティはこれによって定義されたカスタムプロパティに依存しているため、Shadow DOMのなかでは正しく機能しない。

@layer utilities {
  .bg-gradient-to-r {
    --tw-gradient-position: to right in oklab;
    background-image: linear-gradient(var(--tw-gradient-stops));
  }
  .from-blue-500 {
    --tw-gradient-from: var(--color-blue-500);
    --tw-gradient-stops: var(--tw-gradient-via-stops, var(--tw-gradient-position), var(--tw-gradient-from) var(--tw-gradient-from-position), var(--tw-gradient-to) var(--tw-gradient-to-position));
  }
  .to-purple-600 {
    --tw-gradient-to: var(--color-purple-600);
    --tw-gradient-stops: var(--tw-gradient-via-stops, var(--tw-gradient-position), var(--tw-gradient-from) var(--tw-gradient-from-position), var(--tw-gradient-to) var(--tw-gradient-to-position));
  }
}

/* ... */

@property --tw-gradient-position {
  syntax: "*";
  inherits: false;
}
@property --tw-gradient-from {
  syntax: "<color>";
  inherits: false;
  initial-value: #0000;
}
@property --tw-gradient-via {
  syntax: "<color>";
  inherits: false;
  initial-value: #0000;
}
@property --tw-gradient-to {
  syntax: "<color>";
  inherits: false;
  initial-value: #0000;
}
@property --tw-gradient-stops {
  syntax: "*";
  inherits: false;
}
@property --tw-gradient-via-stops {
  syntax: "*";
  inherits: false;
}
@property --tw-gradient-from-position {
  syntax: "<length-percentage>";
  inherits: false;
  initial-value: 0%;
}
@property --tw-gradient-via-position {
  syntax: "<length-percentage>";
  inherits: false;
  initial-value: 50%;
}
@property --tw-gradient-to-position {
  syntax: "<length-percentage>";
  inherits: false;
  initial-value: 100%;
}

/* ... */

@layer properties {
  @supports ((-webkit-hyphens: none) and (not (margin-trim: inline))) or ((-moz-orient: inline) and (not (color:rgb(from red r g b)))) {
    *, ::before, ::after, ::backdrop {
      --tw-gradient-position: initial;
      --tw-gradient-from: #0000;
      --tw-gradient-via: #0000;
      --tw-gradient-to: #0000;
      --tw-gradient-stops: initial;
      --tw-gradient-via-stops: initial;
      --tw-gradient-from-position: 0%;
      --tw-gradient-via-position: 50%;
      --tw-gradient-to-position: 100%;
    }
  }
}

しかし、@propertyルールが使用できない環境のためのフォールバックも実装されている。@layer propertiesの内側にあるフィーチャークエリがそれである。MozillaとSafariのためとコメントされているが、ブラウザを問わずこれが有効になるように書き換えられればうまく動作するはずだ。

やり方はいくつか考えられるが、PostCSSプラグインとしてASTを経由して書き換えることにした。要件としては次の2つだ。

@propertyルールを削除する（削除しなくても動作するが、不要なものはない方がよいため）
@layer propertiesのなかにある宣言ブロックを有効にするために、その間にあるフィーチャークエリだけを取り除く

これに準じて次のように実装した。

postcss.config.ts:

import type { Plugin } from 'postcss';
import type { Config } from 'postcss-load-config';

// @propertyルールはShadow DOM内で動作しないため削除する
const removeAtProperty: Plugin = {
  postcssPlugin: 'remove-at-property',
  AtRule: {
    property(atRule) {
      atRule.remove();
    },
  },
};

// `@layer properties`の内側にあるフィーチャークエリを取り除いて、@propertyルールのフォールバックをすべてのブラウザで有効化する
// https://github.com/tailwindlabs/tailwindcss/blob/v4.1.11/packages/tailwindcss/src/ast.ts#L697-L705
const transformPropertiesLayer: Plugin = {
  postcssPlugin: 'transform-properties-layer',
  AtRule: {
    layer(atRule) {
      if (atRule.params !== 'properties') {
        return;
      }

      atRule.walkAtRules('supports', (supportsRule) => {
        const supportedRules = supportsRule.nodes;

        supportsRule.remove();

        if (supportedRules) {
          atRule.append(supportedRules);
        }
      });
    },
  },
};

const config: Config = {
  plugins: [removeAtProperty, transformPropertiesLayer],
};

export default config;

Tailwind CSS 4において意図せずoutline-colorがtransitionしてしまう問題の対処法

Mon, 21 Jul 2025 09:55:00 GMT

Tailwind CSS 4では、transitionユーティリティおよびtransition-colorsユーティリティのtransition-propertyプロパティにoutline-colorプロパティが含まれるように変更された（参考: Upgrade guide - Getting started - Tailwind CSS）。

変更前（Tailwind CSS 3）:

.transition {
  transition-property: color, background-color, border-color, text-decoration-color, fill, stroke, opacity, box-shadow, transform, filter, -webkit-backdrop-filter;
  transition-property: color, background-color, border-color, text-decoration-color, fill, stroke, opacity, box-shadow, transform, filter, backdrop-filter;
  transition-property: color, background-color, border-color, text-decoration-color, fill, stroke, opacity, box-shadow, transform, filter, backdrop-filter, -webkit-backdrop-filter;
  transition-timing-function: cubic-bezier(0.4, 0, 0.2, 1);
  transition-duration: 150ms;
}

.transition-colors {
  transition-property: color, background-color, border-color, text-decoration-color, fill, stroke;
  transition-timing-function: cubic-bezier(0.4, 0, 0.2, 1);
  transition-duration: 150ms;
}

変更後（Tailwind CSS 4）:

.transition {
  transition-property: color, background-color, border-color, outline-color, text-decoration-color, fill, stroke, --tw-gradient-from, --tw-gradient-via, --tw-gradient-to, opacity, box-shadow, transform, translate, scale, rotate, filter, -webkit-backdrop-filter, backdrop-filter, display, visibility, content-visibility, overlay, pointer-events;
  transition-timing-function: var(--tw-ease, var(--default-transition-timing-function));
  transition-duration: var(--tw-duration, var(--default-transition-duration));
}

.transition-colors {
  transition-property: color, background-color, border-color, outline-color, text-decoration-color, fill, stroke, --tw-gradient-from, --tw-gradient-via, --tw-gradient-to;
  transition-timing-function: var(--tw-ease, var(--default-transition-timing-function));
  transition-duration: var(--tw-duration, var(--default-transition-duration));
}

これにともなって、要素をフォーカスしたときのインジケータの色が一瞬currentcolorになってしまう問題が生じることがある。

Chromeのユーザーエージェントスタイルシートでは、フォーカス時のoutline-colorプロパティの値として-webkit-focus-ring-colorが指定されている。

:focus-visible {
  outline: auto 1px -webkit-focus-ring-color
}

— third_party/blink/renderer/core/html/resources/html.css - chromium/src.git - Git at Google

通常は即座にこの色に変化するが、transitionの対象になっていると、currentcolorを開始点として-webkit-focus-ring-colorに遷移するという挙動になる。これによって、一瞬黒く見えてしまう。

このような挙動になるのはChromeのみで、SafariやFirefoxではtransitionが有効にならない。とはいえ、このような挙動は好ましくないため、何かしらの方法で修正する必要がある。

Tailwind CSSのUpgrade Guideでは、そのための回避策として、条件にかかわらずoutline-colorの値が変化しないように指定することが提案されている。

-<button class="transition hover:outline-2 hover:outline-cyan-500"></button>
+<button class="outline-cyan-500 transition hover:outline-2"></button>

— Upgrade guide - Getting started - Tailwind CSS

しかし、フォーカス可能なすべての要素に対してこのような指定をすることは現実的ではない。このような個別の指定が必要になると、必然的に間違いが起こるだろう。そのため、代わりとなる別のアプローチをいくつか挙げて検討してみる。

1. `transition-property`のデフォルト値を上書きする

最初に考えられる方法としては、transition-propertyプロパティの値からoutline-colorプロパティを取り除くことだ。そのために、それぞれのユーティリティの実装を調べてみる。

まず、transitionユーティリティは次のように実装されている。

functionalUtility('transition', {
  defaultValue:
    'color, background-color, border-color, outline-color, text-decoration-color, fill, stroke, --tw-gradient-from, --tw-gradient-via, --tw-gradient-to, opacity, box-shadow, transform, translate, scale, rotate, filter, -webkit-backdrop-filter, backdrop-filter, display, visibility, content-visibility, overlay, pointer-events',
  themeKeys: ['--transition-property'],
  handle: (value) => [
    decl('transition-property', value),
    decl('transition-timing-function', defaultTimingFunction),
    decl('transition-duration', defaultDuration),
  ],
});

— tailwindcss/packages/tailwindcss/src/utilities.ts at v4.1.11 · tailwindlabs/tailwindcss

もう一方の、transition-colorsユーティリティは次のように実装されている。

staticUtility('transition-colors', [
  [
    'transition-property',
    'color, background-color, border-color, outline-color, text-decoration-color, fill, stroke, --tw-gradient-from, --tw-gradient-via, --tw-gradient-to',
  ],
  ['transition-timing-function', defaultTimingFunction],
  ['transition-duration', defaultDuration],
]);

— tailwindcss/packages/tailwindcss/src/utilities.ts at v4.1.11 · tailwindlabs/tailwindcss

これらを上書きするには、@utilityディレクティブを使ってCSSを記述する。ここで指定されている値からoutline-colorプロパティを取り除いて指定する。

@utility transition {
  transition-property:
    color, background-color, border-color, text-decoration-color, fill, stroke, --tw-gradient-from, --tw-gradient-via, --tw-gradient-to, opacity, box-shadow, transform, translate, scale, rotate, filter, -webkit-backdrop-filter, backdrop-filter, display, visibility, content-visibility, overlay, pointer-events;
}

@utility transition-colors {
  transition-property:
    color, background-color, border-color, text-decoration-color, fill, stroke, --tw-gradient-from, --tw-gradient-via, --tw-gradient-to;
}

ただし、これらユーティリティのプロパティ値は予期せず変更される可能性があるため、Tailwind CSSのアップデートにともなう変更を監視して追従できるようにしておく必要がある。

2. `transition`ユーティリティの対象プロパティを個別に指定する

transitionユーティリティ自体の実装に手を入れずとも、arbitrary valuesとしてユーティリティの値を調整することはできる。次のようにして対象のプロパティだけを個別に指定すれば、意図しないプロパティのtransitionが有効になってしまうことを回避できる。

<button class="bg-blue-500 transition-[background-color] hover:bg-indigo-500"><!-- ... --></button>

3. フォーカス可能な要素すべての`outline-color`プロパティにデフォルト値を指定する

先ほどの説明の繰り返しになるが、outline-colorプロパティの値が変化しないように指定すれば意図しないtransitionを回避できる。

-<button class="transition hover:outline-2 hover:outline-cyan-500"></button>
+<button class="outline-cyan-500 transition hover:outline-2"></button>

— Upgrade guide - Getting started - Tailwind CSS

この例はカスタムのoutline-colorプロパティを適用するものだが、ブラウザデフォルトのフォーカスリングを適用したい場合には次のようにする。

<button class="outline-[-webkit-focus-ring-color] transition"><!-- ... --></button>

これによって、要素がフォーカスされてフォーカスリングが表示される際のtransitionを無効化できる。

Firefoxではフォーカス時のoutline-colorプロパティの値はcurrentcolorになっているが、このように-webkit-focus-ring-colorを指定した場合はパースエラーとして扱われて無視される。

4. すべての要素の`outline-color`プロパティのデフォルト値を上書きする

outline-colorプロパティを個別に設定するアプローチでは、やはり作業の抜け漏れが生じる可能性がある。それよりも、あらかじめすべての要素のプロパティ値を指定してしまうのが良いだろう。次のようにして実装する。

@layer base {
  *,
  ::after,
  ::before,
  ::backdrop,
  ::file-selector-button {
    outline-color: -webkit-focus-ring-color;
  }
}

サードパーティウィジェットのアクセシビリティ

Fri, 27 Jun 2025 00:00:00 GMT

VSCodeのGenerate alt textを使って代替テキストを自動生成する

Sun, 25 May 2025 07:10:00 GMT

VSCodeエクステンションのGitHub Copilot Chat 0.27にて、画像の代替テキストを自動生成できる機能が追加された。

この機能を使用するには、HTMLファイルまたはMarkdownファイル内の画像がある行までカーソルを移したうえで、キーボードショートカットの⌘.を使うか、行の上部に表示される電球アイコンを選択する。alt属性の値が空であれば「Generate alt text」、すでに存在すれば「Refine alt text」がコードアクションとして表示される。

アクションを実行するとインラインチャットが立ち上がり、「Generate alt text」の場合は次のプロンプトが実行される。

Create an alt text description that is helpful for screen readers and people who are blind or have visual impairment. Never start alt text with "Image of..." or "Picture of...". Please clearly identify the primary subject or subjects of the image. Describe what the subject is doing, if applicable. Please add a short description of the wider environment. If there is text in the image please transcribe and include it. Please describe the emotional tone of the image, if applicable. Do not use single or double quotes in the alt text.

「Refine alt text」であれば次のようになる。

Refine the existing alt text for clarity and usefulness for screen readers. Create an alt text description that is helpful for screen readers and people who are blind or have visual impairment. Never start alt text with "Image of..." or "Picture of...". Please clearly identify the primary subject or subjects of the image. Describe what the subject is doing, if applicable. Please add a short description of the wider environment. If there is text in the image please transcribe and include it. Please describe the emotional tone of the image, if applicable. Do not use single or double quotes in the alt text.

チャットからのレスポンスが返ってきたタイミングで、その結果が値として挿入される。

自動生成の使いどころと注意点

いくつかの記事や画像に対してこの機能を試してみたが、内容にかかわらずそこそこの精度の出力ができた。たとえば複雑な図表でも、プロンプトが優秀なのかかなり正確に内容を出力できる。少なくとも、ほとんどの人にとっては自力で記述するよりも良い結果になる可能性が高い。注意点もあるので順を追って説明する。

まず、この自動生成機能は、ブログなどの記事中で登場する画像のために使うのが適切だと思われる。代替テキストの書き方にはいくつかパターンがあるが、altディシジョンツリーに則れば、「意味のある画像」もしくは「複雑な画像」に当てはまる例に適用するのに向いている。

それ以外のパターンについては、この自動生成を用いると冗長になりがちであり、人が自ら記述したほうがうまくいく。たとえば単なる「文字画像」や、ボタンのなかで使用するアイコンなど（「機能を持つ画像」）については、制作者自身にとっては記述内容は自明なのでわざわざAIに頼る必要もないだろう。言い換えれば、自動生成ができるとしても、altディシジョンツリーくらいは最低限理解しておく必要がある。

この自動生成では、対象の画像に含まれる情報だけでなく、同ファイルの記述内容も考慮した結果になる。このおかげで、単なる画像単体の説明ではなく、ある程度前後の文脈も踏まえた出力ができているようだ。したがって、同一ファイルに本文もいっしょに記述された形式であることが望ましい。つまり、マークダウンファイルで記事データが管理されているブログなどに向いている。先に本文を書き切ってから、最後に代替テキストを生成すると精度が上がるだろう。

あとは、代替テキストがたまに英語で出力されてしまうことがある。プロンプトが英語であるせいでそれに引っ張られてしまうようだ。インラインチャットで続けて「as japanese」などと要求すれば日本語にしてくれる。もしくは、.github/copilot-instructions.mdに「代替テキストを作成する際は、日本語として出力すること。」のように書いておけばだいたい日本語になる。

運が悪いと、マークアップの代替テキスト部分だけでなく、タグ全体を丸ごと出力結果で置き換えてしまうことがある。プロンプトが改善されればこのような現象は回避できるかもしれないが、とりあえず今の時点ではそのたび手動で直していくのが早い。

そして、一般的に良いモデルを使うほど良い結果になる。Claude 3.7 SonnetとClaude Sonnet 4で結果を比較してみたが、後者のほうが明らかに的確な内容が出力された。

Generate alt textの実装を調べる

この機能はコードアクションとして提供されているものだが、たとえばVSCode以外のエディタやその他のAIエージェントなど、別の経路からも実行できると便利だ。そこで、これがどのように実装されているかを理解するため、エクステンションのソースコードを調べてみる。

GitHub Copilotのリポジトリは公開されていないので、ローカルにある~/.vscode/extensions/を対象に「Generate alt text」の文字列を検索すると、~/.vscode/extensions/github.copilot-chat-0.27.0/dist/extension.jsのなかにその記述が見つかった。

extension.jsはminifyされているため、Prettierでフォーマットする。検索で見つかった該当箇所は次のようになっていた。

async provideAltTextQuickFix(e, t) {
  let n = e.lineAt(t.start.line).text,
    o = kbe(n),
    s = kbe(n, !0);
  if (!(!o && !s)) {
    if (o) {
      let a = this.isValidUrl(o),
        c = a ? o : s$.default.resolve(s$.default.dirname(e.uri.fsPath), o);
      return {
        title: Ao.l10n.t("Generate alt text"),
        kind: Ao.CodeActionKind.QuickFix,
        resolvedImagePath: c,
        type: "generate",
        isUrl: a,
        isAI: !0,
      };
    } else if (s) {
      let a = this.isValidUrl(s),
        c = a ? s : s$.default.resolve(s$.default.dirname(e.uri.fsPath), s);
      return {
        title: Ao.l10n.t("Refine alt text"),
        kind: Ao.CodeActionKind.QuickFix,
        resolvedImagePath: c,
        type: "refine",
        isUrl: a,
        isAI: !0,
      };
    }
  }
}

このprovideAltTextQuickFixが呼び出されている場所を調べると、次のソースコードが出てくる。

async provideCodeActions(e, t, n) {
  if (
    !this.configurationService.getConfig(ee.EnableCodeActions) ||
    (await this.ignoreService.isCopilotIgnored(e.uri))
  )
    return;
  let s = [],
    a = Ao.window.activeTextEditor;
  if (!a) return s;
  let c = await this.provideAltTextQuickFix(e, t);
  if (
    (c &&
      ((c.command = {
        title: c.title,
        command: "github.copilot.chat.generateAltText",
        arguments: [
          {
            type: c.type,
            resolvedImagePath: c.resolvedImagePath,
            isUrl: c.isUrl,
          },
        ],
      }),
      s.push(c)),
    this.reviewService.isCodeFeedbackEnabled() && !a.selection.isEmpty)
  ) {

github.copilot.chat.generateAltTextというコマンドに目をつけて調べると、次のような定義が見つかった。

p.add(
  Ot.commands.registerCommand("github.copilot.chat.generateAltText", N),
),

N = async (M) => {
  if (
    M &&
    typeof M == "object" &&
    "isUrl" in M &&
    "resolvedImagePath" in M &&
    typeof M.resolvedImagePath == "string" &&
    "type" in M
  ) {
    let Y =
        'Create an alt text description that is helpful for screen readers and people who are blind or have visual impairment. Never start alt text with "Image of..." or "Picture of...". Please clearly identify the primary subject or subjects of the image. Describe what the subject is doing, if applicable. Please add a short description of the wider environment. If there is text in the image please transcribe and include it. Please describe the emotional tone of the image, if applicable. Do not use single or double quotes in the alt text.',
      k =
        M.type === "generate"
          ? Y
          : `Refine the existing alt text for clarity and usefulness for screen readers. ${Y}`,
      D = M.isUrl
        ? me.parse(M.resolvedImagePath)
        : me.file(M.resolvedImagePath);
    return Ot.commands.executeCommand("vscode.editorChat.start", {
      message: k,
      attachments: [D],
      autoSend: !0,
      initialRange: Ot.window.activeTextEditor?.selection,
    });
  }
},

どうやらこの実装では、インラインチャットに対して、先ほどのプロンプトといっしょに画像もコンテキストとして渡しているようだ。

試しにこのプロンプトだけを別のところにコピペして実行してみたらあまり良い結果にならなかったのだが、それは画像のコンテキストもいっしょに渡していないことが原因だったと分かった。当然と言えば当然だが。

これらを踏まえて、良い代替テキストを出力するために重要なポイントをまとめよう。

代替テキストの要件をプロンプトとして明快に記述する
画像へのリファレンスを渡す
同ファイルの記述内容から当該画像のコンテキストを読み取れるようにする

aria-label属性は何にでもつけられるわけじゃない

Mon, 19 May 2025 07:15:00 GMT

ARIA in HTMLでは、要素の名前付けの可否について次のようにある。

著者は、名前付けできない暗黙のWAI-ARIAロールをもつ要素で、aria-labelまたはaria-labelledbyを指定してはならない。著者由来の名前付けを禁止する暗黙のWAI-ARIAロールは、4. HTMLでARIA属性を使用するための文書適合性要件で特定されたHTML要素で特定される。

次のマークアップの例は、著者由来の名前付けを禁止する暗黙のARIAロールをもつHTML要素の選択を示す。

例14：著者由来の名前付けを禁止する暗黙のARIAロールをもつ要素

<p aria-label="...">...</p>

<span aria-label="...">...<span>

<code aria-label="...">...<code>

<div aria-labelledby="...">...</div>

— ARIA in HTML 日本語訳 § 4.1 要素に名前を付けるためのARIA属性の使用に関する要件

つまり、aria-label属性やaria-labelledby属性を適用できる要素の種類は決まっていて、何にでもつけられるわけじゃない。名前付けができないロールは次のように定義されている。

5.2.8.6 名前を付けることができないロール（名前は禁止されている）

caption

code

deletion

emphasis

generic

insertion

paragraph

presentation

strong

subscript

superscript

— Accessible Rich Internet Applications (WAI-ARIA) 1.2 日本語訳 § 5.2.8.6 名前を付けることができないロール（名前は禁止されている）

HTML要素にはそれぞれデフォルトのロール（暗黙のWAI-ARIAロール）が定義されているが、例として挙げられているp要素、span要素、code要素、div要素のロールはこの名前をつけることができないロールに該当する。

逆に、これらに該当しないロールであれば、名前付けをすることは妥当とみなされる。

次のマークアップの例は、著者由来の名前付けを可能にする明示的なWAI-ARIAロールを持つ要素を示す。これらの要素で指定される明示的なロールのために、aria-labelおよびaria-labelledby属性は許可される。

例15：著者由来の名前付けを可能にする明示的なARIAロールをもつ要素
<p role="link" tabindex="0" aria-label="...">...</p>

<span role="button" tabindex="0" aria-label="...">...<span>

<div role="article" aria-labelledby="...">...</div>

— ARIA in HTML 日本語訳 § 4.1 要素に名前を付けるためのARIA属性の使用に関する要件

では、名前付けができないロールに対してaria-label属性を使用することは何が問題か。それは、ブラウザや支援技術において安定して動作しないことである。仕様では要素は著者由来の名前をサポートしないと明言されており、基本的にブラウザや支援技術はこれに則って実装される。一部の実装ではこの限りではないが、あくまでそれは例外であり、サポート状況の幅広さや前方互換性の観点で堅牢さに欠ける。

しかし、そのように使用したい場面が存在することもまた事実である。たとえば、スタイリングの都合により、文字を一文字ずつ分割してspan要素で囲うような場合。このように分割されたノードは、利用環境によっては連続した文字列として正しく読み上げられないことがある。そのための対処としてaria-label属性がよく使用される。

<!-- 次のようにしてはならない！ -->
<p aria-label="Lorem ipsum">
  <span aria-hidden="true">L</span><span aria-hidden="true">o</span><span aria-hidden="true">r</span><span aria-hidden="true">e</span><span aria-hidden="true">m</span>
  <span aria-hidden="true">i</span><span aria-hidden="true">p</span><span aria-hidden="true">s</span><span aria-hidden="true">u</span><span aria-hidden="true">m</span>
</p>

この場合の妥当な代替策は、visually hiddenを使うことだ。次のようにすれば、aria-label属性を使うことなく代替コンテンツを設定できる。

<style>
  .visually-hidden {
    position: absolute;
    clip-path: inset(50%);
    width: 1px;
    height: 1px;
    overflow: hidden;
    white-space: nowrap;
  }
</style>

<p>
  <span class="visually-hidden">Lorem ipsum</span>
  <span aria-hidden="true">L</span><span aria-hidden="true">o</span><span aria-hidden="true">r</span><span aria-hidden="true">e</span><span aria-hidden="true">m</span>
  <span aria-hidden="true">i</span><span aria-hidden="true">p</span><span aria-hidden="true">s</span><span aria-hidden="true">u</span><span aria-hidden="true">m</span>
</p>

当エンジニアブログで実施したアクセシビリティ改善の方法についての解説

Fri, 09 May 2025 00:00:00 GMT

アクセシビリティ学習の手引きとしての入門講座

Thu, 08 May 2025 00:00:00 GMT

ブロックリンク（もしくはカードUI）のアクセシビリティ上の問題と解決策

Thu, 17 Apr 2025 02:05:00 GMT

複数のテキスト要素や画像がグループ化されて、そのグループ全体が一つのリンクになっているというUI表現がある。ブロックリンクやカードUIなどと呼ばれるものだ。たとえば次のような実装になる。

<article>
  <a href="news.html">
    <h3>Budget Debate Continues in Parliament</h3>
    <p class="subhead">
      <img class="alertimg" src="alerticon.png" alt="Breaking News" height="30" width="30" />
      Members of Parliament continued vigorous debate on three challenging issues surrounding the
      upcoming year's budget.
    </p>
    <p>Read more</p>
  </a>
</article>

これはWCAGのTechnique H30にかつて存在した例だが、良い例でないとして現在は削除されている。

ブロックリンクの問題としては、リンク選択時の読み上げが冗長になることが指摘されている。リンクのタイトルだけでなく、説明文などの副次的な情報も合わせて一気に読み上げられてしまうので、最後まで読み終わるのに余計な時間が掛かる。かつスクリーンリーダーによっては、名前の読み上げが終わるまでそれがリンクであることがわからない。

また、リンクの入れ子の問題もある。もしこのブロックリンクの内側に、別のリンクも含めたいという要件があった場合、このようにa要素で全体を囲うマークアップでは実現が難しい。JavaScriptを使って無理やり実現することもできなくはないが、やはりアクセシビリティ上の問題を孕んでしまうだろう。

こうした事情を踏まえて、a要素の疑似要素を使ってターゲット領域を広げる手法が用いられることがある。

<article style="position: relative">
  <h3><a href="news.html" class="stretched-link">Budget Debate Continues in Parliament</a></h3>
  <p class="subhead">
    <img class="alertimg" src="alerticon.png" alt="Breaking News" height="30" width="30" />
    Members of Parliament continued vigorous debate on three challenging issues surrounding the
    upcoming year's budget.
  </p>
  <p class="colophon">By <a href="author.html" style="isolation: isolate">John Smith</a></p>
</article>

.stretched-link::after {
  position: absolute;
  inset: 0;
  content: '';
}

stretched linkはBootstrapで採用されているものだ。

これによって、前述の問題は回避できる。しかしこの場合でも、リンクのテキスト選択ができなくなってしまうというまた別の問題が生じる。

通常、リンクのテキストを選択しようとしても、リンク自体を掴むようなインタラクションが生じてテキスト選択ができないが、Altを押しながらだとテキスト選択ができる機能がある。ところが、この例のように疑似要素で覆い被されているとそれが機能しなくなる。

そこで、代わりにJavaScriptを使って、リンクの外側がクリックされたときにもリンクが反応するように実装する。

<article class="card">
  <h3><a href="news.html">Budget Debate Continues in Parliament</a></h3>
  <p class="subhead">
    <img class="alertimg" src="alerticon.png" alt="Breaking News" height="30" width="30" />
    Members of Parliament continued vigorous debate on three challenging issues surrounding the
    upcoming year's budget.
  </p>
  <p class="colophon">By <a href="author.html">John Smith</a></p>
</article>

for (const card of document.querySelectorAll('.card')) {
  const link = card.querySelector('h3 a');

  card.addEventListener('pointerup', (event) => {
    if (event.target.closest('a:any-link')) {
      return;
    }

    if (document.getSelection().isCollapsed) {
      link.click();
    }
  });
}

加えて、JavaScriptが利用可能な環境においてのみ要素全体にcursor: pointerを適用するため、メディアクエリのscriptingを使用する。

.card {
  @media (scripting: enabled) {
    cursor: pointer;
  }
}

これによって、ブロックリンクのどこをクリックされても、リンクがクリックされたときと同等の振る舞いがエミュレーションされる。本物のリンクがクリックされたときには、処理が二重に実行されることを防ぐべく、event.targetがリンクであれば早期リターンする。

そして、ユーザーがテキスト選択しようとしているときにはリンクを反応させず、テキスト選択ができるようにするために、現在の選択状態をもとに処理を分岐する。pointerupイベントの段階でもしテキストが選択されていれば、何もしない。

しかしながらこれでは、修飾キーの入力を無視した振る舞いになってしまう。たとえば通常の場合、Commandを押しながらリンクをクリックすると、リンク先が新しいタブで開く。一方この実装では、その類の機能が無効化されてしまい、常に普通のページ遷移になってしまう。

修飾キーに紐づく機能を無効化させないためには、修飾キーの入力に応じた処理の分岐を行う必要があるが、ブラウザやOSごとの仕様の違いを網羅するのは容易ではない。したがって、既存のライブラリで解決できると好ましい。@react-aria/utilsにあるopenLink関数がまさにそれだ。これを使ってlink.click()を置き換える。

import { openLink } from '@react-aria/utils';

for (const card of document.querySelectorAll('.card')) {
  const link = card.querySelector('h3 a');

  card.addEventListener('pointerup', (event) => {
    if (event.target.closest('a:any-link')) {
      return;
    }

    if (document.getSelection().isCollapsed) {
      openLink(link, event);
    }
  });
}

おそらくこれが、僕が考え得るかぎりで最もマシな実装だと思う。

このような要件に対応するためのLink Area Delegationという提案もある。将来的には、これを採用することでより適切な実装ができるようになるかもしれない。

参考文献

リンクの下線の視覚的ノイズを軽減する

Mon, 17 Mar 2025 19:30:00 GMT

“Designing dyslexia-friendly navigational components”によれば、text-decoration: underlineによるデフォルトの下線はアクセシブルではないと言う。理由としては大きく二つ。

下線がディセンダーと重なることで文字の判読性や可読性が損なわれる
コンテンツの邪魔になって読み手の気を散らす

これは特にディスレクシアなど、認知機能に困難があるユーザーへの影響が大きい。

加えて、デフォルトの下線は美観としても好ましくないという評価を受けることが多い。視覚的に煩雑な印象を与えるからという、上記と類似する理由によるものだろう。

件の記事では、そうした問題を踏まえた改善案が紹介されている。これを参考に、このサイトでは次のような実装を採用した。

html {
  /* 下線と文字の距離を離す */
  text-underline-offset: 0.3em;
}

a:any-link {
  /* UAスタイルシートに含まれているが、説明のために記述 */
  text-decoration: underline;
  /* リンクの文字色よりも薄い下線の色。背景と3:1以上のコントラスト比を確保する */
  text-decoration-color: oklch(0.67 0 0);
  /* 下線を細くする */
  text-decoration-thickness: 1px;
}

また、文字と下線の距離が離れることに合わせて、line-heightプロパティを少し広めに設定している。

これにより視覚的なノイズや判読性の問題を軽減できるほか、美観としても好ましくなったように思う。

参考情報

特定の要素の外側すべてをinertにする

Sun, 23 Feb 2025 19:50:00 GMT

モーダルダイアログを実装する場合は、その外側を不活性化する必要がある。ここで言う不活性とは、

要素にクリックやタッチなどで作用（interact）しても反応しない
フォーカスできない
支援技術での読み上げ対象からも除外されている

という状態を指している。

この要件を満たすには、dialog要素を.showModal()で呼び出して使うとよい。それだけで外側の要素は自動的に不活性化される。しかし実装上の制約などにより、dialog要素を使えないこともあるだろう。そうした場合は、不活性化の処理を独自に実装することになる。

要素を不活性化するにはinert属性を使う。要素にinert属性が適用されると、その子孫まで不活性状態が継承される。

<div>
  <label for="button1">Button 1</label>
  <button id="button1">I am not inert</button>
</div>

<div inert>
  <label for="button2">Button 2</label>
  <button id="button2">I am inert</button>
</div>

— HTMLElement: inert property - Web APIs | MDN

そのため、モーダルダイアログ以外のすべての要素が一つの要素の中に囲われていれば、inert属性を一箇所に適用するだけで済む。

<div inert>
  <h1>Outside the dialog</h1>

  <label for="button">Button</label>
  <button id="button">I am inert</button>
</div>

<div role="dialog" aria-labelledby="dialog_label" aria-modal="true">
  <!-- ... -->
</div>

とはいえ、いつもこのような構造を実現できるとはかぎらない。場合によっては、モーダルダイアログが別の要素の中に入れ子になった、もっと複雑な文書構造になることもあるだろう。

<h1><!-- ... --></h1>

<label for="button">Button</label>
<button id="button">I am not inert</button>

<section>
  <h2><!-- ... --></h2>

  <p>... <a href="https://example.com/">awesome link</a> ...</p>

  <div role="dialog" aria-labelledby="dialog_label" aria-modal="true">
    <!-- ... -->
  </div>
</section>

このような場合、モーダルダイアログを除いた上端にあたる要素すべてにinert属性を適用しなければならない。

<h1 inert><!-- ... --></h1>

<label inert for="button">Button</label>
<button inert id="button">I am not inert</button>

<section>
  <h2 inert><!-- ... --></h2>

  <p inert>... <a href="https://example.com/">awesome link</a> ...</p>

  <div role="dialog" aria-labelledby="dialog_label" aria-modal="true">
    <!-- ... -->
  </div>
</section>

これを実現するには、次のような処理を実装する。

function setInert(el) {
  const undos = [];

  crawlSiblingsUp(el, (sibling) => {
    if (!sibling.inert) {
      sibling.inert = true;

      undos.push(() => {
        sibling.inert = false;
      });
    }
  });

  return () => {
    while (undos.length > 0) undos.pop()();
  };
}

function crawlSiblingsUp(el, callback) {
  if (el.isSameNode(document.body) || !el.parentNode) return;

  for (const sibling of el.parentNode.children) {
    if (sibling.isSameNode(el)) {
      crawlSiblingsUp(el.parentNode, callback);
    } else {
      callback(sibling);
    }
  }
}

これを次のように使用する。

const dialogEl = document.querySelector('[role="dialog"]');
let undoInert = null;

function openDialog() {
  undoInert = setInert(dialogEl);
}

function closeDialog() {
  undoInert();
  undoInert = null;
}

モーダルダイアログを開くタイミングでsetInert関数を実行する。これにより、モーダルダイアログを除くすべての要素の上端にinert属性が適用される。閉じるタイミングでその戻り値を実行することで、開くときに適用したinert属性はすべて取り除かれる。なおこの実装は、Alpine.jsのFocusプラグインを参考にしたものである。

モーダルダイアログを実装する際にはそれ以外にも考慮すべき点がある。ここでは取り上げないので、詳しくはARIA Authoring Practices Guideを参照のこと。

inert属性を使う以外のやり方としては、特定の要素の中だけにフォーカスを閉じ込めるフォーカス・トラップというテクニックがある。しかし、フォーカス・トラップではドキュメントの外側にフォーカスを移せなくなるので、通常のタブ・ナビゲーションのようにブラウザのアドレスバーなどにフォーカスする操作ができなくなってしまうことが問題である。これについては次の資料でも言及されている。

また、フォーカス・トラップを採用するにしても、モーダルダイアログの外側の要素にaria-hidden属性を適用する処理は依然必要になることがある。WAI-ARIA 1.1で導入されたaria-modal属性をサポートする支援技術では、aria-modal="true"が指定された要素より外側は、不活性状態として読み上げ対象から除外される。しかしaria-modal属性をサポートしない支援技術では、そのままでは外側の要素も通常通り操作できてしまうため、明示的にaria-hidden="true"を適用しなければならない。これについては、ARIA Authoring Practices Guideの“Notes on aria-modal and aria-hidden”で解説されている。aria-modal属性のサポート状況はまだ十分ではないため、このようなフォールバック処理は重要だ。

「段落と段落の間」と「段落と画像の間」の余白を均一にする

Fri, 03 Jan 2025 14:40:00 GMT

垂直方向に複数の段落と画像が並ぶとき、間隔を均一にしたければ、それぞれ同じ大きさのmarginプロパティを適用するだろう。

<p><!-- ... --></p>
<p><!-- ... --></p>
<figure><!-- ... --></figure>
<p><!-- ... --></p>

:root {
  --space-default: 1rlh;
}

p {
  margin-block-start: var(--space-default);
  margin-block-end: 0;
}

figure {
  margin-block-start: var(--space-default);
  margin-block-end: 0;
}

しかし実際には、このようにすると段落と画像の間隔がやや詰まって見える。段落同士の間隔に比べて、段落と画像の間隔が少し狭く感じる。

これはハーフレディングが原因の現象だ。line-heightプロパティの仕様上、テキストの行の上端と下端には余白が設けられる。たとえばfont-sizeプロパティが16pxで、line-heightプロパティが24pxであれば、上下に4pxの余白ができる。

(24px - 16px) / 2 = 4px

段落が連続する場合、marginプロパティの値に加えてこのハーフレディングを加えた分の大きさの余白ができる。前の段落の下端のハーフレディングと、後の段落の上端のハーフレディングが組み合わされるため、ハーフレディングの2倍分の余白が含まれることになる。marginプロパティが24pxで、ハーフレディングが4pxであれば、大きさは合計で32pxになる。

4px + 24px + 4px = 32px

一方、段落の直後に画像が続く場合、片方のハーフレディングしか含まれない。したがって、余白の大きさはその分小さい28pxになる。

4px + 24px = 28px

段落と画像の間隔が詰まって見えるのはこのような理由である。

この問題を解決するには、画像の周囲にハーフレディングの分を余分に含めた余白を設定するとよい。ハーフレディングの値は(1rlh - 1rem) / 2で算出できるので、これを通常のmarginプロパティの値と足し合わせる。

:root {
  --space-rect: calc(var(--space-default) + (1rlh - 1rem) / 2);
}

figure {
  margin-block-start: var(--space-rect);
  margin-block-end: var(--space-rect);
}

これによって、画像の前後にも段落の間と同じ間隔が適用されるようになる。

便宜上、ここまでは画像を例に解説したが、そのほかの要素においても同様の問題が生じることがある。たとえば、背景色がついていたりボーダーで囲われていたりして、周囲との境界がはっきりしている要素。このサイトで言えば、hr要素、pre要素、table要素などだ。これらについても同様にmarginプロパティを設定する。

hr {
  margin-block-start: var(--space-rect);
  margin-block-end: var(--space-rect);
}

pre {
  margin-block-start: var(--space-rect);
  margin-block-end: var(--space-rect);
}

table {
  margin-block-start: var(--space-rect);
  margin-block-end: var(--space-rect);
}

ただし、これらの要素が連続して配置されると、やはりほかより狭い間隔になってしまう。--space-rectには片方のハーフレディングの分の余白しか含まれていないが、これらの要素が連続した際にはハーフレディングの余白は存在しないため、ほかと均一にするには両方のハーフレディングの分の余白を含める必要がある。そこで、要素が連続した際にはmarginプロパティを上書きすることで余白を均一にすることができる。

:root {
  --space-rect2: calc(var(--space-default) + 1rlh - 1rem);
}

:is(hr, pre, figure, table) {
  & + & {
    margin-block-start: var(--space-rect2);
  }
}

この記事での解説は、Hail2uのCSSで採用されている手法を参考にしたものである。

僕のホームページ遍歴

Wed, 25 Dec 2024 01:05:00 GMT

「個人ホームページ訪問 Advent Calendar 2024」の23日目の記事です。遅刻しました。

ハムスター島

初めてのホームページは、ハムスター島というサービスを使って作った。2006年ごろだったと思う。ホームページを作ることがブームになってから、少しピークを過ぎたくらいの時期だ。当時は、ウェブ技術についての知識がなくても簡単に自分のホームページを立ち上げられるサービスがいくつもあり、ハムスター島もその一つだった。サーバーの概念もHTMLの書き方も何も知らなかったけど、数クリックするだけで自分のホームページを作ることができた。

僕はまだ小学生だった。幼少期に父親からパソコンの使い方を教わって以来、ずっとパソコンの前に張り付いているような子供だった。最初の頃は、インターネットに公開されているフリーゲームで遊ぶのがおもな使い方だったが、そのうち自分でも何か作ってみたいと思うようになった。まずはよく遊んでいたFlashゲームを自分でも作れないかと考えたが、子供がいきなり独学するにはあまりにハードルが高く、頓挫した。だから、とにかく何でもいいので自分にも作れるものがないかと探して、そうして見つけたハムスター島が僕にとってのウェブ制作への入り口になった。

ハムスター島のホームページでできるのは、決まったテンプレートにテキストコンテンツを入力して掲載したり、アクセスカウンターや掲示板を設置することくらいだった。それでも最初は、自分で入力したものがウェブに公開されているというだけで嬉しかった。

一方、実際に作ってみて気づいたのが、ホームページはそこに掲載するコンテンツがないと成り立たないということだった。というのも、普通は何かを発表したいと思った人がホームページを作るのだろうが、僕の場合は作ること自体が目的だったので載せるものがなかった。絵を描いたり音楽を作ったりできる人はそれを載せていたけど、僕には何もない。もっとも、ホームページブームだったのでそういう人は少なくなかっただろう。だからみんな無益な自己紹介を書いたり100の質問に回答したりしていた。もう思い出したくもないけど、僕は魔法のiらんどで小説を書いていたこともある。今となっては味わい深い気もするが。

リヴリーアイランド

それから少し経って、リヴリーアイランドというオンラインゲームに夢中になった。ユーザー同士のコミュニケーションに重点を置いたゲームで、ギルドのような制度があり、それが当時かなりの盛り上がりを見せていた。人気のあるギルドには例外なく専用のホームページがあり、ギルドの制度や交流イベント、主要メンバーのプロフィールなどが、なかなかの熱量をもって紹介されていた。また、リヴリーアイランドは可愛らしいキャラクターや装飾のデザインがコンテンツとしての目玉であり、ユーザーがそれを二次創作的に素材集サイトにまとめて配布することも一般的になっていた。そのほかにもファンサイトは無数に存在し、充実した攻略コンテンツがあったり、非常に凝ったよくできたデザインになっていたりするものも多かった。

そうしたコミュニティの影響もあり、ここぞとばかりに僕も自分のギルドのホームページを作った。そのとき使ったのは、WYSIWYGで独自デザインのページを作成できるサービスだった。相変わらず技術的なことはよくわからなかったが、リンクの概念やタグの仕組み、スタイリングのやり方などは、手を動かしているうちに感覚として覚えた。

（なお、リヴリーアイランドは一度サービス終了した後にリニューアルして再開しているが、当時とはまったく別物になっている。）

ネパワ界

また少し時間が経って、僕はパワフルプロ野球シリーズ（以下、パワプロ）にハマった。やはりこれもファンサイトを通したコミュニティが非常に活発だったゲームである。ある収集家によると、今までに4300以上のファンサイトの存在が確認されていると言う。これらの界隈は「ネパワ界」（ネットパワプロ界の略）と呼ばれていた。

僕はゲームの攻略情報を調べるために、自分がプレイしていたシリーズを扱うあるホームページによくアクセスするようになり、いつからかその掲示板でほかの訪問者たちと交流するのが日課になった。掲示板では攻略情報を交換したり、強い選手のパスワードを共有したり、パワプロの好きなところを語り合ったりした。さらには、各人が運用するファンサイトや、その作り方について話す人もいて、それに影響された僕はまた新たなホームページを作ることになった。

かれこれするうちに僕はもう自分でHTMLをコーディングするようになっていた。ez-HTMLを使ってテーブルコーディングで制作したことを覚えている。2008年ごろなのでトレンド的には時代遅れではあるが。

コンテンツはいくつか作ったけど、特によく覚えているのは、ホームページに設置したCGIゲームを改造して遊んでいたこと。そう、当時は自分のホームページにCGIゲームを設置するという文化があったのだ。箱庭諸島なんかが有名どころだけど、ネパワ界では劇空間ぱわふるリーグ（以下、劇ぱわ）というCGIゲームが人気だった。劇ぱわでは、選手ごとに「パワー」「ミート」「走塁」「守備」のようなパタメータに数値を割り振って自分のチームを作る。そして、別のチームとの対戦を実行すると、試合の様子が実況チックなテキストとして1回から最終回まで一度に表示される。試合の中での盛り上がりどころは赤くて大きな文字で表示されたりするけど、それ以外にグラフィカルな要素はなく、見た目としてはちょっと騒がしいテキストサイトくらいの感じだった。それでも昔はそれに熱中する人がたくさんいた。僕はこれを改造して、自分のホームページのトンマナに合った見た目になるようにしたり、パラメータをいじって場外ホームランが出やすいようにしたりと、ちょっとしたアレンジを重ねてオリジナリティを加えていった。技術的に難しいことではなかったが、そうした細かい工夫が楽しかった。結果、数十人くらいの人に登録して遊んでもらうことができた。

ところでCGIゲームを設置するには、それに対応したサーバーを用意する必要があった。無料のレンタルサーバーの中にもCGI/Perlに対応したものはいくつかあったが、無料の代わりにバナー広告が挿入されたりするのがうっとうしくて、あるとき思い切って有料のレンタルサーバーを契約した。当時中学生なのでほとんどお金がなく、両親の理解を得られそうもないので、溜め込んだお年玉を持ってこっそりコンビニに行って支払いをしたことを覚えている。さくらのレンタルサーバだった。後日、自宅にその郵便が届いたせいで母親に怒られた。

ライブドアブログ

前述のホームページ作りと並行して、いくつかのブログも運用していた。初めて立ち上げたブログは、使っていたサービスはもう名前も思い出せないが、ハムスター島と同じく素人でも簡単に扱えるようなものだった。いま思えばあのような、技術への入り口となるようなサービスは偉大だったと思う。周囲の誰かに教えてもらえるわけでもなく、かといって自分で調べる技術もそれほど身についていなかった時期に、偶然自分のレベルに合ったサービスに巡り会えたことは運がよかった。

そんなブログの内容は、たいしたことのない、ただの子供の痛々しい雑記でしかなかった。インターネットを使って何か生産的なことをしてみたいという気持ちだけはあったけど、何の技術もない僕にかろうじてできたのは、テキストを書いて公開することくらいだった。幸い、書くことは好きだった。好きになった。

ブログを書く傍らで、テーマをカスタマイズすることも楽しくてのめり込んでいった。ブログのサービスによってこの辺りの作りに違いがあることが気になって、主要なレンタルブログサービスに片っ端から登録して、いろんなブログを作ってカスタマイズして遊ぶようになった。そして、それぞれのブログサービスを比較するために、個別にいろんなネタを決めて運用していた。普段の生活の日記、当時作っていたホームページの運用日誌、2ちゃんねるのまとめブログ、気になったニュース記事をピックアップしてコメントとともに紹介するニュースまとめブログ、などなど。ちなみにその頃の日課は、RSSリーダーに登録した大量のニュースやブログにひと通り目を通して消化することだった。そういう経緯もあって、普段から注意深くブログにできるネタがないかを探す癖がついた。

やがていくつかのレンタルブログサービスを経て、最終的にはライブドアブログに行き着いた。ライブドアブログがほかと一線を画すのは、テーマのカスタマイズ性の高さだった。多くのレンタルブログサービスでは、HTMLテンプレートは決まった構造から変更ができず、できるのは独自のCSSを適用するくらいのことだったが、ライブドアブログでは独自のHTMLテンプレートを作成することができた。XMLのようなライブドアブログ独自の記法でイテレーションやパーシャルの出力が表現できるようになっていて、それがわかりやすいドキュメントで解説されていた。当時の僕にはプログラミングの技術はなかったが、おかげでHTMLコーディングの延長としてすんなりテーマ作成の考え方を理解できた。これを機に僕はブログテーマ制作に夢中になって、以来いくつもの独自テーマを作ることになった。パソコンの前を離れてもずっとそのことを考えていて、学校でも紙のノートにワイヤーフレームを書いたりCSSを書いたりしていた。

（いま調べたら、ライブドアブログのデザインのカスタマイズについてのドキュメントがなくなっていて、「サポート対応の範囲外」ということになっていた。悲しい。）

テーマ作りに力を入れるにつれて、デザインとコンテンツの関係、つまり側（がわ）と中身の卵鶏問題について強く意識せざるを得なくなってきた。ブログを書くのはそれなりに好きだったが、それだけでなく、テーマのデザインを成り立たせるために書かなければならない、言うなれば鞄のあんこ（詰め物）のようなものとしても捉えていた。思えばこの頃から、ブログを書くこと自体は目的ではなく、ブログテーマを作るための手段としてブログを書いているという感覚がずっとある。

しかし、そうして病的な熱量でパソコンに張り付いている日々が続いて、ある日、遂に母親にパソコンを取り上げられてしまった。学校の成績が著しく悪化したせいだ。中二の頃だった。僕のホームページ道はそのとき一度終わった。

ポートフォリオサイト

高校を卒業してから、僕はウェブデザインの専門学校に進学した。専門学校に行けば一日中パソコンを触っていられると聞いたからだ。

専門学校では、基本的なコーディングやソフトウェアの操作方法についての授業のほか、ポートフォリオの制作が主なウェイトを占めていた。支給されたコンテンツに応じてデザインとコーディングをしたり、何かしらの企画を立ててそれに基づいたウェブサイトを作ったりして、作品の数を増やしていた。

しかし、残念ながらその頃の僕はウェブサイトの企画を立てるのが苦手で、あまり気が乗らなかった。それよりも当時は、ウェブデザインのギャラリーサイトを眺めてスクラップしたり真似したりすることのほうが好きだった。こういうかっこいいデザインや面白いモーションを使って、それありきで好きなようにウェブサイトを作るにはどうすればいいだろうと考えた結果、やがて自分のポートフォリオサイトを作ることに力を入れ始めた。まあ言ってみれば、クリエイターにとってポートフォリオサイトというのは、好きなようにやっていい場所なのである。そんなわけで、ポートフォリオサイトに載せられる作品はほとんどないのに、ポートフォリオサイトばかりを作るようになった。在学中に作ったポートフォリオサイトは10個くらいあって、新しいポートフォリオサイトには作品集として古いポートフォリオサイトをいくつも並べていた。

そう言えば、この時期に出会ったHail2uにはかなりの影響を受けたと思う。技術的な側面よりも、ウェブデザインのスタイルとしてミニマリズムを体現しているのが新鮮に感じて、以来ずっと頭の片隅にあった。在学中に作ったポートフォリオサイトでも、最初は派手な装いを好んでいたけど、バージョンを重ねるにつれてシンプルになっていった。それがきっかけだったのかはわからないけど、デザインだけにかぎらず、技術的にもオーバーエンジニアリングを避ける方向に進んだ。当時作った、WordPressのREST APIを使ったシングルページアプリケーションや、発表されたばかりのReactのサーバーサイドレンダリング機能を取り入れたウェブサイトは、トレンドを取り入れるタイミングとしてはかなり早くて、技術的にはけっこうおもしろかったと思う。けど、それを使って作るもののしょぼさを思うと、オーバースペックなものはイケてないと考えるようになっていった。結局、最後のバージョンのポートフォリオサイトは手書きのHTMLで作った。そのこだわりをプレゼンする技術はなかったので、就活の戦略としては失敗した。

モダンフロントエンド

専門学校の卒業後には、ウェブサイト制作の仕事を始めた。いわゆるモダンフロントエンドの概念が勢力を増してきた時代だった。

どの技術を使ってウェブサイトを開発するかという判断が非常に難しかった。タスクランナーにgulp.jsを使って、SassとBabelでコンパイルする、くらいの共通認識はあったけど、ちょうどいいサイトジェネレーターが見つからなかったので、自分で作ったものを案件ごとに調整したりして使っていた。開発環境構築をする担当者によってビルドの仕組みやディレクトリ構成がまるで違うのでいろいろ苦労していた。

そうこうしているうちに、Next.jsやNuxtが台頭してきた。最初はそれらはウェブアプリケーションのための技術だと考えられていたが、ウェブサイト制作にも使えるという論調が強まってきた。僕としては、一時はその流れに賛同していたが、やはりこれは何か間違っていると違和感を抱くようになった。この手のフレームワークは、ウェブサイト制作に流用することもできるというだけであって、そのために作られたものではない。ウェブサイト制作に必要なのは、JavaScriptフレームワークではない。ウェブサイト制作の開発環境の問題は、細かなツール群を寄せ集めて組み合わせるという責務をユーザーが担わされれていることであって、必要なのはウェブサイト制作のためにチューニングされたワンストップソリューションなのだ。

しかしその夢のようなワンストップソリューションは長らく登場せず、その間、僕はさまざまなツールを組み合わせたボイラープレートを、一番マシな開発環境として同僚たちに共有することで開発の一貫性を維持していた。でもこのやり方は、技術的にはあまり美しくない。スケールしづらいし、開発手法として広いコミュニティの中で一般化させることは難しい。それが不満だった。

そんなとき、突如としてAstroが登場した。初めてAstroが世に出たタイミングでのCSS-Tricksの紹介記事を見たとき、ずっと求めていたものがついにと電撃が走ったようだった。Astroの前は僕はEleventyを使っていて、これもサイトジェネレーターとしては悪くないのだが、あくまでプレーンなHTMLを生成することだけを責務としていて、その周辺ツールとの接続方法はユーザーに委ねられている。そして誤解を恐れずに言えば、古臭い。モダンなフロントエンド技術との相互運用性を考慮した作りになっていない。一方、Astroは従来的なサイトジェネレーターではなく、必要なもの全部入りのワンストップソリューションであることが画期的なのである。そして世界に平穏が訪れた。

ベースライン

仕事を始めてからも、僕はずっとこの自分のウェブサイト、いや、ホームページを更新して維持し続けている。専門学生時代と同じく、たまに全部作り直したりしてきていて、それなりのバージョン数になっている。

けど今のバージョンになってからは、しばらく大きな作り直しをしていない。今のバージョンを作るときに、ずっと古くならないように作ろうと考えたからだ。これまでは「気分で作り直せばいいや」くらいのノリだったが、今回はもう最終版だと思って作った。後ろ向きな理由としては、もう頻繁に作り直すのも疲れるからやりたくないというのがあるけど、前向きな理由としては、これからのブログのベースラインになるような模範的なものを作りたいという想いがある。

僕は単にテキストを書くことも好きで、うまく書けるようになるための努力もしてきたが、それ以上に、そのテキストのレイアウトの仕方を考えることが好きだ。僕は、テキストのデザインについてはそれなりの関心がある。昨今、これだけテキストばかりのホームページというのも珍しいが、だからこそ、テキストを中心に据えた環境における理想を追求したいと思う。

ブログは「テーマのデザインを成り立たせるために書かなければならない」ものだと前述したが、翻って、今だと別の解釈ができるかもしれない。ブログを書くことで、そのテーマにコンテンツが適用されている様を見て楽しむことができる。テーマを楽しむためにブログを書く。それが楽しいから書く。僕は依然として、より良いブログテーマを作るためにブログを書いている感覚でいる。けれど。よいレイアウトで文字を並べられるようになっているかどうか、血の通ったテキストを書くことでそれを確かめられる。逆に、テキストを書くことで、心地よく文字が並んでいることが感じられる。書き手が自らレイアウトを調整できると、そういう嬉しさに通ずることができる。

僕は自分のホームページを持つことにささやかな誇りがあるが、同業者の中ではそういうことに興味を持つ人が減ってきているようだ。時代の流れだろうか。もしかすると、自分のホームページを所持することに憧れを持つことができるのは、僕くらいの世代が最後なのかもしれない。そう思うと寂しいが、それでも僕は、自分自身の喜びのためにこれを続けていくだろう。

line-clampとhanging-punctuationを併用するときはoverflow:hiddenの代わりにclipを使う

Thu, 05 Dec 2024 15:40:00 GMT

CSSの-webkit-line-clampプロパティを使うとき、通常はoverflow: hiddenを併用することが多い。

p {
  display: -webkit-box;
  -webkit-box-orient: vertical;
  -webkit-line-clamp: 3;
  overflow: hidden;
}

しかし、hanging-punctuationプロパティを併用する場合、overflow: hiddenが指定されているとはみ出した役物が見切れてしまう。

p {
  display: -webkit-box;
  -webkit-box-orient: vertical;
  -webkit-line-clamp: 3;
  overflow: hidden;
  hanging-punctuation: allow-end;
}

-webkit-line-clampプロパティを機能させるには、本来はoverflow-yプロパティを使うだけで十分だ。ただしoverflow-y: hiddenを指定すると、その副作用として横方向にスクロール可能な状態になってしまう。

p {
  display: -webkit-box;
  -webkit-box-orient: vertical;
  -webkit-line-clamp: 3;
  overflow-y: hidden;
  hanging-punctuation: allow-end;
}

この問題を解決するのが、clipである。clipを使うと、単方向の切り取りを実現しつつ、もう一方はスクロール不能な状態のままにできる。

p {
  display: -webkit-box;
  -webkit-box-orient: vertical;
  -webkit-line-clamp: 3;
  overflow-y: clip;
  hanging-punctuation: allow-end;
}

hanging-punctuationプロパティにかぎらず、横方向にコンテンツのはみ出しが発生する場面においては有効だろう。

なぜ僕はデザイナーの作ったデザインを「見づらい」と感じてしまうのか

Sun, 01 Dec 2024 00:00:00 GMT

「PLAID Design Advent Calendar 2024」の1日目の記事です。

僕はこれまでフロントエンドの開発者として働いてきた傍ら、自身をウェブデザイナーとしても自認して、自分なりのやり方でデザインに携わってきました。この記事は、特定の組織での経験をテーマにしたものではなく、そうした自分の成り立ちを省みるためのものです。

また記事は、書籍『ビジュアル・シンカーの脳』の内容をもとにした自分の感想や思索についてまとめたものです。特定の属性の人物やその主義主張に優劣をつける意図はありません。

デザイナーが作ったデザインを見たとき、「見づらい」や「わかりにくい」といった印象を抱くことが僕にはそれなりにある。おおまかに言って、そう感じるのには大きく2通りの原因がある。

一つは、視覚的にボヤッとして見づらいとき。主要な文字のサイズが小さすぎたり色が薄すぎたり、周辺空間が騒々しくて目的の情報をすんなり読み取れなかったり、何かしらの機能を示す装飾がさりげなすぎて気づけないようなとき。あるいは、情報のヒエラルキーやグループ関係を読み取れないとき。

もう一つは、UI表現として自分が認識しているパターンを裏切られたとき。「こういうUI要素はこのようなコンテキストの中でこのような挙動をするだろう」という自分の脳内にあるモデルを逸脱するような設計が想定されているとき。

そうした自分の見解について話すと、まれに「いや、わかるでしょ」とでも言わんばかりの反応が返ってくることがある。つまりデザイナー本人からしてみれば、十分見やすくわかりやすく作っているつもりなので、それに難癖をつけられる道理が理解できないというわけだ。僕としては本当に「わからない」のだが、さも何かの意地悪で極論を言っているかのように捉えられるのである。

僕はこれまで、それは自分の作ったものを見慣れすぎているという作り手のバイアスが原因の問題だと考えていた。もっとも、それも問題の一因ではあるだろう。しかし、僕が明らかに見づらくわかりづらいと思うものに対して、初見の人が真逆の感想を述べる光景も数多く目にしてきた。

この感覚の違いの正体はいったい何なのか。誰かが嘘をついているのか。自分の心を正しく解釈できていないだけなのか。それとも彼らは、自分とはまったく違うレンズで世界を見ているのか。

最近、『ビジュアル・シンカーの脳』という本を読んだ。そこには、まさに先のような問いに対する答えがあった。

なお以降の項での記述は、最後を除いてすべて本書の要約と抜粋から構成されていることを断っておく。僕自身の見解ではなく、本書の内容をもとにして編集されたものである。

いわく、ある種の人々は、言葉の代わりに「絵」を使って思考する。一般に、言語は思考の土台であると考えられている。しかし一部の人々は、情報処理のプロセスとして脳の視覚の回路を使って思考する。つまり、通常の言語思考とは異なる考え方をするのである。本書ではそれを視覚思考者（ビジュアル・シンカー）と呼ぶ。

視覚思考者は、頭の中で言語を経由せずに直接イメージを思い浮かべる。Googleで画像検索をするように、視覚的なイメージを高速で連想する。地図や絵画、迷路が好きで、道には迷わない。一方で、子供のころに言葉を話し始めるのが遅く、学校での教え方についていくには苦労する傾向がある。視覚化できない抽象概念を理解することも苦手である。

その対である言語思考者は、物事を順序立てて理解するので、学校での体系化された勉強は得意な傾向にある。一般的な概念を理解するのが得意で、時間感覚に優れているが、方向感覚は良いとは言えない。書類やファイルはきちんと整理整頓する性分である。何かしらの問題に向き合う際には、講じる対策を明確にして、解決や決定にたどり着く。声に出さずに自分の心に語りかける。口が達者で、言葉を巧みに使いこなす能力が必要な職業に就くことが多い。

この二者の違いを端的に理解できる一つの研究がある。ある心理学者が、書類をファイルに閉じてキャビネットにきちんと並べる人と、書類の山に囲まれている人との比較を行った。すると、書類をファイルしない人にきちんと整理させたら、何も見つけられなくなってしまったと言う。なぜか。彼らは、整理しなくても、散らかった状態のままでそれらを組織化し、頭の中で見ているからだ。無理に整理すると、構築したイメージが損なわれてしまう。これが視覚思考である。

本書の著者テンプル・グランディンは動物学博士だ。彼女は自閉スペクトラム症であるとともに、視覚思考者である。本書は、その視覚思考者の考え方というものが存在することを解明して世に知らしめるものなのだ。

人が視覚思考タイプかどうかを判定するテストはいくつかある。著者が考案した「イケア・テスト」では、家具を買ってきて組み立てると仮定する。そのとき自分なら、説明書の文を読むかイラストを見るかを想像する。視覚思考者の著者にとっては、言葉で書かれた説明文を読んでも連続した手順についていけずちんぷんかんぷんだが、イラストを見れば一目瞭然だと言う。イケアでは説明書はすべてイラストで示されているが、これは創業者がディスレクシアであり言葉より絵を優先するタイプだからだそうだ。

また別の「視覚空間型思考判定テスト」では、18の質問に「はい」か「いいえ」で答える。「はい」が10個以上なら視覚思考タイプの可能性がかなり高いと言う。著述家や編集者、弁護士はたいてい「はい」が10よりずっと少なく、想像力が極めて高い人や数学が好きな人には「はい」が多い。たいていの人はその間のどこかに当てはまり、2種類の思考の混合タイプになるだろう。

考えるときには、言葉ではなく、おもに絵を使う。

物事がわかるが、その方法や理由は説明できない。

ふつうと違う方法で問題を解決する。

物事をありありと想像する。

目で見たことはおぼえているけれど、耳で聞いたことは忘れる。

単語をつづるのが苦手。

物体をいろいろな視点から思い浮かべることができる。

整理整頓が苦手。

時間の経過がわからなくなることがよくある。

行く先は言葉で説明してもらうより、地図を見るほうがわかる。

一度しか行ったことのない場所でも道順をおぼえている。

字を書くのが遅く、字はほかの人に読みづらい。

ほかの人の気持ちがわかる。

音楽か美術か機械が得意。

周囲が思っている以上に物知り。

人前で話すのは苦手。

歳を重ねるごとに賢くなっていると思う。

コンピューターに熱中する。

視覚思考者の割合については、まだ十分なデータがない。小学生を対象に行った調査によれば、ほぼ3分の1が明確な視覚思考タイプで、およそ4分の1が明確な言語思考タイプ、残りの半分弱が混合タイプだった。

視覚思考者には、2種類のタイプがいる。物体視覚思考者と空間視覚思考者だ。それぞれ次のような特徴がある。

物体視覚思考者: 写真のように正確なイメージで周りの世界を見る
- グラフィックデザイナーや画家、目端の効く商人、建築家、発明家、機械工学士、設計士などに多い
空間視覚思考者: パターンと抽象的な概念で周りの世界を見ている
- 音楽や数学が得意
- 統計学者、科学者、電気技師、物理学者、コンピュータープログラマーなどに多い

プログラマーに空間視覚思考者が多いのは、コードにパターンが見えるからだそう。この二者の思考を区別すれば、「物体視覚思考者はコンピューターを組み立て、空間視覚思考者はプログラムを作成する」という風になる。

はたまた、極端な言語思考者の中には、写真や略図を見てもどう解釈すればいいのかがさっぱりわからない人がいる。物体視覚思考者や空間視覚思考者にとっては自明のテストをしたとき、言語思考者はまるででたらめのような回答をしたと言う。ほかにも、次のような事例が紹介されている。

ある研究では、視覚思考者と言語思考者に説明文と写真を見せて、新しいことを学ぶテストをした。視線を追跡すると、当然ながら、視覚思考者は写真に、言語思考者は説明文に注目した。言語思考者が写真を見たときには、写真の縁など新しい情報を得るのに何の役にも立たないところを見ることが多かった。

また別の研究では、美術、理科、語学のどれか一つが得意な学生をグループにして、それぞれに未知の惑星の絵を描かせた。研究の目的を知らされていない専門家が作品を評価したところ、結果は次のようになった。

美術の得意な生徒（物体視覚思考タイプ）
- 色鮮やかでファンタスティックな3つの惑星を描いた
理科の得意な生徒（空間視覚思考タイプ）
- 自分たちの描く惑星に明確なコンセプトを持っていた
- 惑星は球体で色がなく、どちらかというとよくあるタイプだった
語学の得意な生徒（言語思考タイプ）
- 描いた惑星は想像力に欠け、点描の抽象画のように見えた

そして研究をさらに進めて、生徒たちが惑星を描くときにどのようにアイデアを展開したかを調べた。

美術と理科の生徒はどちらも最初に「中心になる独創的なアイデア」を展開した。美術の生徒は、惑星の外観を話し合い、理科の生徒は、惑星の重力や化学的性質、生物の種類など構成要素を話し合った。語学の生徒は描いた惑星に名前をつけたが、制作にあたって練った構想を説明できなかった。

この3種類の考え方は、本書にある3つの思考スタイル（物体視覚思考、空間視覚思考、言語思考）と一致する。

我々の業界におけるデザイナーとエンジニアの関係を理解するうえで、本書の「建築家と建築エンジニア」の話は興味深かった。

通常、建築家は注目され、大胆な設計だとか、美しく調和が取れているなどと称賛される。設計に命を吹き込み、その結果できあがった建物を安全に使えるようにするのは、建築エンジニアの領分だ。私の経験と観察からすると、建築家はたいてい物体視覚思考タイプで、建物の姿を頭の中で見るが、建築エンジニアはたいてい空間視覚思考タイプで、数学の得意な脳で電気系統を操作し、建物にかかる風圧や雪の重さを計算する。

近代高層ビルの生みの親ウィリアム・ル・バロン・ジェニーは、建築家と建築エンジニアの二刀流だった。1884年に完成させたホーム・インシュアランス・ビルは、当時の米国内でもっとも高く、内部フレームにレンガと石ではなく鉄と鉄鋼が初めて使われた。「12世紀にゴシック様式が大聖堂に取り入られれて以来のもっとも大きな革新だ」と語られている。

しかし物体視覚思考者の著者にとっては、このビルはいかにも建築エンジニアが設計したように見えると言う。

機能一点張りの背の高い長方形で、ちっとも美しくない。察するに、ジェニーは建築家ではあったが、おもに数学に強い空間視覚思考タイプで、最大の関心は、崩れ落ちない鋼鉄製のフレームで建築することだったのだろう。

この建築家と建築エンジニアの考え方の相違は、学校での建築とエンジニアリングの教え方の違いに象徴されている。

教室という物理的な空間を見ても、エンジニアリングの教室では、無味乾燥な部屋に机が整然と並べられている。建築の教室では、学生が大きな作業台のあちこちでそれぞれに作業し、壁には絵画や下絵が貼られ、教室というより画家のアトリエに見える。エンジニアリングのカリキュラムは「がんじがらめ」で、一度に一つずつ技術的なスキルの問題に取り組む。一方、建築のカリキュラムは制約が少なく、創造性を重視する。

工業デザインの分野でも似たような話がある。

工業デザインの企画では、美術と作図に重点が置かれ、数学はそれほど重視されない。工業デザイナーは、製品が作動する仕組みや外観の構想を練る。一方、機械エンジニアは、負荷テストや物理的な力という数字に関わる面に目を向けて製品の機能を計算する。工業デザイナーは設計し、機械エンジニアはそれを機能させる。

機械エンジニアと工業デザイナーが周りの世界をどのように見ているのかを調査した研究がある。被験者はいろいろな種類の椅子の写真を見て、機能性、創造性、美しさを5段階で評価する。

調査の結果、機械エンジニアにとっては、外観と性能は密接に関係しているようだった。それぞれの椅子の機能性を美しさと一緒くたに評価する傾向があった。ところが工業デザイナーは、美しさと機能性を分けて考えた。つまり、エンジニアにとって形と機能を切り離すことは難しいが、デザイナーは美しさと機能性を上手に区別した。

この研究から、美しさと機能性は見る人によって大きく評価が異なることが明らかになった。さらに言えば、機械エンジニアは空間視覚思考タイプで、工業デザイナーは物体視覚思考タイプだと推測できる。

本書からのこれらの情報を踏まえたとき、僕の経験の中には思い当たることがいくつもある。一つひとつ紐解いていこう。

まず、僕は言語思考者としての傾向が強い。日頃ずっと言葉が頭の中を渦巻いていて、無意識に心でしゃべっている。学生時代の得意教科は国語と英語だった。プログラマーとしてコードにパターンが見えるという感覚はわかるので、空間視覚思考者でもあるのかもしれないが、言語思考ほど強い傾向は見られない。

視覚的な情報を読み取ることが苦手だという心当たりはある。子供のころから母には「物をよく見ていないでぼうっとしている」と言われてきた。酷い方向音痴でもあり、道を覚えるのはめっぽう苦手だ。地図を見ても位置関係を理解するまでしばらくかかる。ついでに言えば、人が良いと言う絵や写真を見てもいまいちピンとこない。

両親の思考タイプはどうだったか。母はたぶん言語思考と物体視覚思考の混合タイプで、よくしゃべるが言葉に厳しく、僕がおかしな日本語を使ったり要領を得ない話をしたりするたびに目ざとく非難した。絵を描くのが得意で製図の仕事をしていた。父は空間視覚思考者で、経理の仕事をしていた。家ではいつもパソコンの前にいて、父とはまともな会話をした記憶がない。母が僕に施した美術的教育は実を結ばなかったが、シビアな言語感覚は受け継がれた。

これまで僕が仕事をしてきたデザイナーの中に物体視覚思考者が多かったことは想像に難くない。その物体視覚思考者が作り出すものが、言語思考者にとって易しくないものであることは、ごく自然な帰結に思える。要するに、受け取りやすい情報の形式が大きく違うのだろう。その感覚に相手との齟齬があるという意識がないから、話がすれ違う。

では、UI表現のパターンについて、僕が人一倍厳密に考えてしまうのはなぜだろう。これは空間視覚思考者としての傾向が働いているせいだと解釈できないか。普段から物事を抽象的に捉える癖があり、目に見えるものもパターンで認識しようとする強い意識がある。だからこそ、細微な違いにつまづいて意味を取り違えてしまうことも多い。それがある意味、僕の融通の効かなさを形成している。

そして僕の感覚とは裏腹に、ある種のデザイナーは、デザインの問題を指摘するときによく「文字文字しい」という表現を用いる。文字の量が多すぎたりその存在感が強すぎたりするという意味だ。だから、そのテキスト部分を無くしたり減らしたり隠したりしたいという話につながる。これは程度問題なのでどちらが正しいと言い切ることはできないが、そのバランス感覚の違いに言語思考者と視覚思考者の隔たりが表れていると思う。

僕が業界を志したころ、ウェブデザインの心得として強く影響を受けたのが「Words」である（もしくは、「Motherfucking Website」）。人によってはまるで理解されないだろう。海外のギャラリーサイトで紹介されるようなきらびやかなウェブページにも憧れはあったが、結局そこにのめり込むことはなく、やがて言葉やタイポグラフィに惹かれるようになっていった。「Web Design is 95% Typography」を胸に刻み、マテリアル・オネスティ（参考: 「Material Honesty on the Web」）を信条として、テキストをデザインのための拠り所として理解し、実践してきた。

自分の過去を否定するつもりはない。しかし、それらの選択が一つの「逃げ」だったこともまた事実である。視覚的な美しさを追求することが僕にはできないと悟ったとき、デザインの答えを自分の中でなく客観性の中に求めた。さまざまな素材や理論と一体化した合理性の中に美しさを見い出すようになっていった。そうだったと思う。本当のところ、何が卵で何が鶏だったかはもはやわからない。ほかにもいろいろ書いたけど消した。

視覚思考者であるかどうかで人を理解することはできないが、少なくとも、他者にとっての世界の見え方を想像するための助けにはできる。そして、彼が見たくてやまない世界を、僕は見ることができているのかもしれないと想い浮かべることもできる。それでよしとしよう。

「PLAID Design Advent Calendar 2024」の2日目は、tomaさんによる「ユーザーインタビューのときに考えている5つのこと」です。

npmパッケージの代わりに独自の仕組みを構築して定数ファイルを配布する運用に切り替えた経緯と移行プロセス

Thu, 14 Nov 2024 00:00:00 GMT

npmパッケージじゃない仕組みで共有ライブラリを管理する

Wed, 06 Nov 2024 00:00:00 GMT

Feature-Sliced Designのディレクトリ規約をAstroのプロジェクトに適用する

Sat, 17 Aug 2024 05:50:00 GMT

昨今、特にフロントエンドのアプリケーションにおいて、技術的な役割よりもフィーチャー（feature）を起点としてディレクトリを構成する（package by feature）というする考えが一般化しつつある。たとえば、技術的な役割を起点としたディレクトリ構成（package by layer）は次のようなものだ。

my-system
├─ controllers
│  ├─ user-controller.js
│  ├─ order-controller.js
│  ├─ payment-controller.js
├─ services
│  ├─ user-service.js
│  ├─ order-service.js
│  ├─ payment-service.js
├─ models
│  ├─ user-model.js
│  ├─ order-model.js
│  ├─ payment-model.js

— Structure your solution by components

この代わりに、次のように構成すべきという考えである。

my-system
├─ apps (components)
│  ├─ orders
│  │ ├─ package.json
│  │ ├─ api
│  │ ├─ domain
│  │ ├─ data-access
│  ├─ users
│  ├─ payments
├─ libraries (generic cross-component functionality)
│  ├─ logger
│  ├─ authenticator

— Structure your solution by components

同様の議論はこれまでにいくつもあって、方向性としては僕も賛同するが、それだけでは体系として不十分であるとも感じていた。フィーチャーの観点だけでアプリケーションが構成できるわけではないので、もっと踏み込んだ整理が必要だと思っていた。

そんなわけで、コミュニティにも同様のモチベーションがあってか、より包括的な議論も目にするようになってきた。しかしその中で僕が一際目を引かれたのが、Feature-Sliced Designという方法論だ。

Feature-Sliced Designにおいてもっとも特徴的なのが、「Layers」「Slices」「Segments」という階層構造になったスキームである。

— Feature-Sliced Design

各Layersには決まった役割があり、その中にSlicesとSegmentsがそれぞれ入れ子になる。ただし、appとsharedにはSlicesを含めずにSegmentsが直接配置される。またSegmentsの名前としては、「ui」「api」「model」「lib」「config」が基本的な例として提案されている。

このスキームが秀逸な点は、大体のソースコードはこのLayersの中にすっきり分類できてしまうこと。加えて、SlicesとSegmentsがあることで、ディレクトリを跨いでも階層構造が同様になるよう統一できることだ。

そして、Feature-Sliced Designはフロントエンドのアプリケーション全般に適用できる方法論として紹介されている。その典型的な例としては、ReactやVue.jsなどを使ったSPAが当てはまるのだろうが、今回は、同様の問題を抱えがちなAstroを使ったプロジェクトに適用する例について考えてみたい。

というのも、AstroのProject Structureとして紹介されている構成は、まさに技術的な役割が起点になっている例である。これに従ってウェブサイトを構築していくと、たとえば次のような形になり得る。

src/
├── assets/
│   ├── about/
│   │   └── profile.jpg
│   ├── blog/
│   │   └── ad.jpg
│   ├── home/
│   │   └── hero.jpg
│   └── shared/
│       ├── favicon.ico
│       └── logo.svg
├── components/
│   ├── about/
│   │   └── Carousel.astro
│   ├── blog/
│   │   └── Sidebar.astro
│   ├── home/
│   │   └── Hero.astro
│   └── shared/
│       ├── Button.astro
│       └── Header.astro
├── content/
│   ├── blog/
│   │   └── hello.md
│   └── config.ts
├── layouts/
│   └── Layout.astro
├── pages/
│   ├── blog/
│   │   ├── [slug].astro
│   │   └── index.astro
│   ├── about.astro
│   └── index.astro
├── scripts/
│   └── main.ts
├── styles/
│   └── main.css
└── consts.ts

この構成はフレームワークによって強制されているわけではなく、多くは好みに応じて自由に変更できる。

この例では、「about」「blog」「home」などの共通する関心事に基づいたファイルがそれぞれのレイヤーに分散してしまって扱いづらいため、Feature-Sliced Designに基づいて再整理してみる。次のようになる。

src/
├── pages/
│   ├── blog/
│   │   ├── [slug].astro
│   │   └── index.astro
│   ├── about.astro
│   └── index.astro
├── content/
│   ├── blog/
│   │   └── hello.md
│   └── config.ts
├── app/
│   ├── layouts/
│   │   └── Layout.astro
│   ├── scripts/
│   │   └── main.ts
│   └── styles/
│       └── main.css
├── views/
│   ├── about/
│   │   ├── assets/
│   │   │   └── profile.jpg
│   │   └── ui/
│   │       └── Carousel.astro
│   └── home/
│       ├── assets/
│       │   └── hero.jpg
│       └── ui/
│           └── Hero.astro
├── widgets/
│   └── blog-sidebar/
│       ├── assets/
│       │   └── ad.jpg
│       └── ui/
│           └── index.astro
└── shared/
    ├── assets/
    │   ├── favicon.ico
    │   └── logo.svg
    ├── config/
    │   └── index.ts
    └── ui/
        ├── Button.astro
        └── Header.astro

このようにすると、おおむね関心事に基づいた構成にできたように思う。

前提として、Astro固有の制約によってpagesのディレクトリ名は変更できないので、妥協してFeature-Sliced Designのレイヤー名の方を「views」に変更した。また可能であれば、pagesとcontentはappレイヤーに含めたいが、これもAstroの制約により断念。

appレイヤーには、アプリケーションを動作させるための構成要素を含める。この例では、ページ全体のレイアウトを決めるlayoutsや、グローバルスタイルやクライアントサイドで実行されるスクリプトを含めている。

続いて、特定のページでだけ使うAstroコンポーネントや画像ファイルなどが存在することはよくあるが、Astroの通常のディレクトリ構造ではそのためにちょうどいい置き場がない。そこで、viewsレイヤーがあることでコロケーションができるようになる。逆に、プロジェクト全体で共通して参照されているファイルについては、sharedレイヤーに配置することでその用途を明示することができる。

ページを跨いで共有されるAstroコンポーネントは一部widgetsレイヤーに含めている。汎用コンポーネントならsharedレイヤーに配置できるが、これは特定の機能に紐づいたものなのでここに配置した。

また、Astroを使うプロジェクトでは、SPAなどと違って、UIのソースコードが大部分を占めることになるだろう。そのため、レイヤーによってはセグメントの存在がやや冗長に感じられる。たとえば、viewsレイヤーにおいてはセグメントを省略する運用にしてもいいかもしれない。

加えて、Feature-Sliced Designでは画像ファイルの置き場は考慮されていないが、Astroの運用スタイルを踏まえて、assetsというセグメントを新たに作成した。

ここまでいろいろ述べてきたものの、Feature-Sliced Designを使った後者の例の方が必ずしも優れているとは限らない。特に小規模でシンプルなプロジェクトであればあるほど、前者の一般的な例の方が簡単で迷いづらいという見方もできる。しかし、特に規模が大きく複雑なプロジェクトにおいては、Feature-Sliced Designは検討に値するだろう。

yuheiy

Fri, 16 Aug 2024 21:40:00 GMT

このサイトの名前を「Yuhei Yasuda」から「yuheiy」に変更した。「Yuhei Yasuda」だと人名そのままだからサイト名っぽくなくて微妙だったけど、「yuheiy」ならそれっぽいかなと思ったので。

最初にこのサイトを作ったとき、「yuheiy.com」のようにドメイン名をそのまま使うという手もあった。けどそれもなんだかメタ的な感じがするので、もっと普通のサイト名っぽくしたいと思っていた。それから時を経てふと先日、ドメイン名からトップレベルドメインの「.com」を取り除いたらどうだろうと考えてみて、そこそこしっくり来たのでこれに決めた。ついでに、文字の造形としてもアイコニックな感じがしてそれっぽい。

そもそも「yuheiy.com」というドメインに決めた理由は、「yuhei.com」が取れなかったからだ。大昔に「yuhei.info」を取ったこともあるけど、そこで運用していたウェブサイトをしばらく放置しっぱなしにしてしまって、ドメインごと破棄した。その後、改めて自分のドメインを取ることになり、今度は「.com」がいいなと思ったので「yuhei」の末尾に苗字の「y」を付与してなんとか取った。以来、SNSなどのIDにも「yuheiy」を使うようになっていった。

ただそうすると、ハンドルネームをそのままサイト名に採用しているような感じにもなってしまって、けっきょく「Yuhei Yasuda」と変わらないような気がする。でも、これはインターネット人格用の名前だし、そのためのウェブサイトなのだと考えると、まあいいやという気にもなってきた。少なくとも、「Yuhei Yasuda」よりはマシだ。

そういうわけで、これからはyuheiyというサイト名でやっていく。また別のアイデアが出たら変えるかもしれない。

ソースコードを解析して社内向けUIライブラリの使用状況を自動で集計する

Mon, 05 Aug 2024 00:00:00 GMT

Astroのアセットをdynamic importで読み込んで間接的な変数をなくす

Sun, 04 Aug 2024 23:20:00 GMT

Astroにおいて、コンポーネントから画像などのアセットを読み込む場合、import文を使うことが一般的だ。

---
import { Image } from 'astro:assets';
import logoImage from '../assets/logo.svg';
---

<Image src={logoImage} alt="Yuhei Yasuda" />

しかし、このような書き方をするとやや不便なことがある。それはimport文を使うと、実際にアセットを使用する箇所から離れた部分に記述が分散するため、一見して対応関係がわかりづらくなること。かつ、編集が面倒になる。例のように行数の少ないファイルではそれほどではないが、行数の多いファイルでは、離れた箇所に記述すると非常に煩わしいことになる。

そこで、代わりにdynamic importを使うことで、アセットの読み込みをインライン化することができる。<Image />コンポーネントのsrc propはPromiseに対応しているため、ここで直接dynamic importを使用できる。

---
import { Image } from 'astro:assets';
---

<Image src={import('../assets/logo.svg')} alt="Yuhei Yasuda" />

普通JavaScriptのアプリケーションでは、code splittingを有効にするためにdynamic importを使うが、この場合ではビルドへの影響はない。

ただし、Promiseの解決のためにawaitが必要な場合は都合が悪い。Astroコンポーネントにおいては、コードフェンスの外側ではawaitを使用できず、awaitはコードフェンスの内側に記述しなければならないからだ。したがって、直接パスを参照したければ、けっきょくは変数化せざるを得ない。

---
import { Image } from 'astro:assets';

const logoImage = (await import('../assets/logo.svg')).default;
---

<img src={logoImage.src} alt="Yuhei Yasuda" />

このような場合では、あえてdynamic importを使う理由はない。

一方、Astroコンポーネントではなく、MDXファイルの中ではawaitを使うことができる。そのため、dynamic importを活用した記述が可能である。

<video controls>
  <source src={(await import('./assets/video.webm')).default} type="video/webm" />
</video>

日本語におけるtext-wrapプロパティの運用

Sun, 21 Jul 2024 19:20:00 GMT

CSSのtext-wrapプロパティを使うと、テキストの行の折り返し方法を変更できる。text-wrap: balanceを適用すると、適用しない場合と比べて次のように変化する。

— CSS text-wrap: balance | CSS and UI | Chrome for Developers

text-wrap: balanceが適用された下の例では、すべての行の長さが均等になるように制御されている。

しかし正確に言えば、すべての行の長さが必ずしもまったく同じになるわけではない。文字の適切な折り返し位置を考慮した上で、おおよそ同じくらいの長さになるように分配される、というのが正しい。その際、一つの英単語の途中で行が分割されるようなことは通常起こらない。これは、英語では単語の区切りに空白文字を挟んで記述されるが（わかち書き）、それが改行位置を決めるためのヒントとなるからである。

だが日本語の場合は都合が違う。改行できる位置に空白文字が挟まることがないため、文節や単語の途中でも関係なく改行される仕様になっている。したがって、日本語にそのままtext-wrapプロパティを適用しても、英語の例と同じように好ましい結果にはならない。

文節区切りでの改行の実現

日本語においても適切な位置で改行がなされるようにするための手法はいくつかあるが、最も有望なのはword-break: auto-phraseを使うことであろう。これによって文節区切りの改行が実現できる。

<html lang="ja">
  <style>
    h1 {
      word-break: auto-phrase;
    }
  </style>

  <h1>窓ぎわのトットちゃん</h1>
</html>

— Introducing four new international features in CSS | Blog | Chrome for Developers

改行位置を手動で調整するやり方もあるが、この手法ではそれが自動的に行えるという点画期的だ。現状、このプロパティのサポート状況は十分ではないため、必要に応じてBudouXの使用なども検討すると良いだろう。

`balance`と`pretty`の使い分け

text-wrapプロパティの値としてはbalanceが取り立てて紹介されがちだが、それ以上に有用なprettyという値もある。balanceではすべての行が同じくらいの長さになるように調整されるのに対して、prettyは最後の行が一つの単語だけで終わることを防ぐ。

— Widows & orphans – Fonts Knowledge - Google Fonts

欧文組版においては、最後の行に一つだけ配置された単語をwidows and orphansと呼び、これがあるとテキストが読みにくくなるとして避けられている。prettyはこの問題を解決するためのものである。

また、prettyは欧文の本文に適用するためのものであるようにしばしば紹介されるが、見出しなどでも有効に活用できる。見出しのレイアウトにおいては、中央揃えならbalanceだが、行頭揃えならprettyの方が見栄えがよくなるという個人的な経験則がある。なぜなら行頭揃えの見出しにbalanceを適用してしまうと、行の幅がその周辺のコンテンツよりもやけに狭く見えたり、行末方向にできた余白が不自然に大きく見えてしまったりしがちだ。これは日本語や英語に特有の問題ではなく、一般的な現象である。

— CSS text-wrap: balance | CSS and UI | Chrome for Developers

代わりにprettyを適用することで、行の幅は自然なままにしつつ、折り返しが不自然になることは回避できる。

ただし、prettyのサポート状況も十分ではないため、プログレッシブエンハンスメントとして採用するのがよいだろう。

日本語における適用方法

widows and orphansは欧文固有の問題であり、日本語では事情が異なる。日本語の本文はベタ組みにすることが原則であり、単語や文節に応じた折り返し位置の調整は行わないからである。したがって同じ理由で、本文にbalanceを適用することもないはずだ。

そのためtext-wrapプロパティの使いどころは、本文を除く見出し部分などが主となる。方針によっては、リードやキャプションなどを含むこともあるだろう。

ここまでの説明を経てルールがやや複雑になってきたので、フローチャートを用いて整理してみる。英語の場合、行揃えの方向によって使い方が異なる。

行頭揃えの見出しにはtext-wrap: pretty、中央揃えの見出しにはtext-wrap: balance。本文は常にtext-wrap: pretty。

日本語の場合、見出しか本文かによってテキストの組み方が異なる。

行頭揃えの見出しにはtext-wrap: pretty、中央揃えの見出しにはtext-wrap: balance。本文にはtext-wrapプロパティは使用しない。これに当てはまらないリードやキャプションなどについては、方針に応じていずれかの組み方に合わせる。

また、見出しは文節改行かつプロポーショナル詰め、本文はベタ組みにするのが一般的であるため、フローチャートでは次のように整理できる。

欧文は常にプロポーショナル詰めになる。和文の場合は、見出しの場合は文節改行かつプロポーショナル詰めだが、本文ではベタ組みになる。

ここまで述べてきた方針は、次のようなCSSとして表現できる。

見出し（行頭揃え）:

:lang(en) {
  text-wrap: pretty;
}

:lang(ja) {
  font-feature-settings: 'palt';
  text-wrap: pretty;
  word-break: auto-phrase;
}

見出し（中央揃え）:

:lang(en) {
  text-wrap: balance;
}

:lang(ja) {
  font-feature-settings: 'palt';
  text-wrap: balance;
  word-break: auto-phrase;
}

本文:

:lang(en) {
  text-wrap: pretty;
}

:lang(ja) {
  /* デフォルト値を使用 */
}

参考資料

Storybookでcontrolledなコンポーネントを操作可能にしつつ引数をモックする

Tue, 09 Jul 2024 05:10:00 GMT

Storybookにおいて、Reactコンポーネントを使ったstoryを作成する際、単なるボタンのようなシンプルなコンポーネントであればcomponentプロパティに指定するだけで良い。

なおこの記事での解説は、Storybookのバージョン8.1.1に基づいたものである。

Button.tsx:

import { MouseEvent, ReactNode } from 'react';

export interface ButtonProps {
  children?: ReactNode | undefined;
  onClick?: ((event: MouseEvent<HTMLButtonElement>) => void) | undefined;
}

export function Button({ children, onClick }: ButtonProps) {
  return (
    <button type="button" className="button" onClick={onClick}>
      {children}
    </button>
  );
}

Button.stories.tsx:

import type { Meta, StoryObj } from '@storybook/react';
import { fn } from '@storybook/test';
import { Button } from './Button';

const meta = {
  title: 'Button',
  component: Button,
  args: {
    onClick: fn(),
  },
} satisfies Meta<typeof Button>;

export default meta;
type Story = StoryObj<typeof meta>;

export const Primary = {
  args: {
    children: 'Click me',
  },
} satisfies Story;

このように記述することで、コンポーネントにargsが渡されたうえで描画される。疑似コードで表現すれば次のようになる。

function Primary() {
  const args = {
    children: 'Click me',
    onClick: fn(),
  };
  return <Button {...args} />;
}

一方、controlledなコンポーネントのstoryを作成する場合、そのコンポーネントの状態を外部から制御するための実装が必要になる。たとえば次のように。

ToggleButton.tsx:

import { ReactNode, useCallback } from 'react';

export interface ToggleButtonProps {
  isSelected: boolean;
  children?: ReactNode | undefined;
  onChange: (isSelected: boolean) => void;
}

export function ToggleButton({ isSelected, children, onChange }: ToggleButtonProps) {
  const handleClick = useCallback(() => {
    onChange(!isSelected);
  }, [isSelected, onChange]);

  return (
    <button type="button" className="toggle-button" aria-pressed={isSelected} onClick={handleClick}>
      {children}
    </button>
  );
}

ToggleButton.stories.tsx:

import { useState } from 'react';
import { ToggleButton } from './ToggleButton';

function Primary() {
  const [isSelected, setSelected] = useState(false);

  return (
    <ToggleButton isSelected={isSelected} onChange={setSelected}>
      Toogle
    </ToggleButton>
  );
}

`render`メソッドの実装

これをstoryとして表現するには、componentプロパティにコンポーネントを指定するだけでは不十分である。そこでこの描画方法をカスタマイズするために、renderメソッドを併せて実装する必要がある。

ToggleButton.stories.tsx:

import type { Meta, StoryObj } from '@storybook/react';
import { fn } from '@storybook/test';
import { useState } from 'react';
import { ToggleButton } from './ToggleButton';

const meta = {
  title: 'ToggleButton',
  component: ToggleButton,
  args: {
    isSelected: false,
    onChange: fn(),
  },
  render: function Render(args) {
    const [isSelected, setSelected] = useState(false);
    return <ToggleButton {...args} isSelected={isSelected} onChange={setSelected} />;
  },
} satisfies Meta<typeof ToggleButton>;

export default meta;
type Story = StoryObj<typeof meta>;

export const Primary = {
  args: {
    children: 'Toggle',
  },
} satisfies Story;

metadata（meta）として指定された値はstoryに継承されるため、自ずとPrimary storyでは同じrenderメソッドが再利用される。ちなみにrenderメソッドにRenderという名前で関数宣言を記述しているのは、eslint-plugin-react-hooksのreact-hooks/rules-of-hooksルールとの競合を回避するためだ。

これによって、controlledなコンポーネントを操作可能なstoryをを作成できる。ただしこの実装では、Storybookのcontrolsからargsの値を制御できなくなってしまう。

`useArgs`フックの使用

そのようなケースに対応すべく、argsの値を操作するuseArgsフックがStorybookによって提供されている。これを利用することで次のような実装ができる。

ToggleButton.stories.tsx:

import { useArgs } from '@storybook/preview-api';
import type { Meta, StoryObj } from '@storybook/react';
import { fn } from '@storybook/test';
import { ToggleButton } from './ToggleButton';

const meta = {
  title: 'ToggleButton',
  component: ToggleButton,
  args: {
    isSelected: false,
    onChange: fn(),
  },
  render: function Render(args) {
    const [{ isSelected }, updateArgs] = useArgs();

    const handleChange = useCallback<ToggleButtonProps['onChange']>(
      (isSelected) => {
        updateArgs({ isSelected });
      },
      [updateArgs],
    );

    return <ToggleButton {...args} isSelected={isSelected} onChange={handleChange} />;
  },
} satisfies Meta<typeof ToggleButton>;

残る問題は、argsに設定されているonChangeが呼び出されていないことである。onChangeに渡されているfn()はメソッドをモックするための機能であり、Jestにあるモック関数に似たものだ。これを用いることで、呼び出しのたびにStorybookのActionsパネルにログを表示したり、interaction testsにて呼び出し回数を調べたりできる。storyをより有用なものにするには、これが機能している方が良いだろう。

そんなわけで、このモックの呼び出しを有効にするには、次のように実装する。

ToggleButton.stories.tsx:

import { useArgs } from '@storybook/preview-api';
import type { Meta, StoryObj } from '@storybook/react';
import { fn } from '@storybook/test';
import { useCallback } from 'react';
import { ToggleButton, ToggleButtonProps } from './ToggleButton';

const meta = {
  title: 'ToggleButton',
  component: ToggleButton,
  args: {
    isSelected: false,
    onChange: fn(),
  },
  render: function Render(args) {
    const [{ isSelected }, updateArgs] = useArgs();

    const handleChange = useCallback<ToggleButtonProps['onChange']>(
      (...a) => {
        args.onChange(...a);
        const [isSelected] = a;
        updateArgs({ isSelected });
      },
      [args, updateArgs],
    );

    return <ToggleButton {...args} isSelected={isSelected} onChange={handleChange} />;
  },
} satisfies Meta<typeof ToggleButton>;

onChange propの呼び出しタイミングでargsのonChangeメソッドとupdateArgsフックが同時に呼び出されるようにする。それにより、argsの値を制御可能にしつつ、メソッドの呼び出しのたびにログが表示されるようにできる。

`useArgs`フックの問題

しかし、useArgsフックには、同一ページ内の複数箇所で呼び出されると正しく機能しないという不具合がある。したがって、Autodocsによって生成されるドキュメントページなどではコンポーネントが操作不能になってしまうため、都合が悪い。

そのため、useArgsフックを使わないパターンの実装も紹介しておく。次のようになる。

ToggleButton.stories.tsx:

import type { Meta, StoryObj } from '@storybook/react';
import { fn } from '@storybook/test';
import { useCallback } from 'react';
import { ToggleButton, ToggleButtonProps } from './ToggleButton';

const meta = {
  title: 'ToggleButton',
  component: ToggleButton,
  tags: ['autodocs'],
  argTypes: {
    isSelected: {
      control: false,
    },
  },
  args: {
    isSelected: false,
    onChange: fn(),
  },
  render: function Render(args) {
    const [isSelected, setSelected] = useState(args.isSelected);

    const handleChange = useCallback<ToggleButtonProps['onChange']>(
      (...a) => {
        args.onChange(...a);
        setSelected(...a);
      },
      [args],
    );

    return <ToggleButton {...args} isSelected={isSelected} onChange={handleChange} />;
  },
} satisfies Meta<typeof ToggleButton>;

まず、useArgsフックの代わりに、前述と同様のuseStateフックを使うようにする。次に、argsに設定したisSelectedをuseStateフックに渡す。これによって、argsから初期値を制御できるようになる。別のstoryを作成する際に次のように活用できる。

export const SelectedByDefault = {
  args: {
    isSelected: true,
  },
} satisfies Story;

最後に、argTypesからisSelectedのcontrolをfalseにする。useArgsフックを使用しないとcontrolからの制御はできないので、control自体を非表示にしてしまう。

controlledとuncontrolledの両方に対応したコンポーネントを作成する

とはいえ、そもそもコンポーネントがuncontrolledな状態にも対応できるように実装されていれば、通常利用する際にも便利だし、Storybookでの扱いも簡単になる。controlledとuncontrolledの両方に対応するコンポーネントを作成するには少しコツがいるが、既存のライブラリなどを利用すれば容易に実現できる。

React Spectrumで利用されている@react-stately/utilsでは、そのためのuseControlledStateフックが提供されており、次のような実装ができる。

ToggleButton.tsx:

import { useControlledState } from '@react-stately/utils';
import { ReactNode, useCallback } from 'react';

export interface ToggleButtonProps {
  isSelected?: boolean | undefined;
  defaultSelected?: boolean | undefined;
  children?: ReactNode | undefined;
  onChange?: ((isSelected: boolean) => void) | undefined;
}

export function ToggleButton({ children, ...props }: ToggleButtonProps) {
  const [isSelected, setSelected] = useControlledState(
    props.isSelected,
    props.defaultSelected || false,
    props.onChange,
  );

  const handleClick = useCallback(() => {
    setSelected(!isSelected);
  }, [isSelected, setSelected]);

  return (
    <button type="button" className="toggle-button" aria-pressed={isSelected} onClick={handleClick}>
      {children}
    </button>
  );
}

[その他の使用例は同リポジトリから参照できる](https://github.com/search?q=repo%3Aadobe%2Freact-spectrum%20useControlledState(&type=code)。

不可視状態からフェードインする要素を即座にフォーカスする方法

Sat, 06 Jul 2024 10:30:00 GMT

CSSのdisplay: noneやvisibility: hiddenによって不可視状態になっている要素を、表示して即座にフォーカスしたいということがある。たとえば、初期状態では非表示になっている検索ボックスを、ユーザーのインタラクションに応じて表示するような場合。そうしたとき、通常では、スタイルを切り替えてすぐにfocusメソッドを呼び出すだけで良い。

<input type="search" />

input[type='search'] {
  display: none;

  &.open {
    display: revert;
  }
}

const searchBoxElement = document.querySelector('input[type="search"]');

function open() {
  searchBoxElement.classList.add('open');
  searchBoxElement.focus();
}

function close() {
  searchBoxElement.classList.remove('open');
}

しかし場合によっては、表示する際にフェードインなどのアニメーションを伴わせたいこともある。これを簡単に実現するには、CSSのtransitionプロパティを使いつつ、opacityプロパティとvisibilityプロパティを操作するとよい。visibilityプロパティはアニメーション可能（discrete）であるため、transitionプロパティで制御することができる。

input[type='search'] {
  visibility: hidden;
  opacity: 0;
  transition:
    visibility 300ms,
    opacity 300ms;

  &.open {
    visibility: revert;
    opacity: revert;
  }
}

const searchBoxElement = document.querySelector('input[type="search"]');

function open() {
  searchBoxElement.classList.add('open');
  searchBoxElement.focus();
}

function close() {
  searchBoxElement.classList.remove('open');
}

ただし、このような実装ではフォーカスができずに失敗してしまう。なぜなら、スタイルを書き換えた直後にはまだ不可視状態（visibility: hidden）のままだからだ。フォーカスさせるには、アニメーションが開始してvisibility: visibleの状態になるまで待機しなければならない。そのために対処として、requestAnimationFrameメソッドが使用されがちである。

function open() {
  searchBoxElement.classList.remove('open');

  requestAnimationFrame(() => {
    searchBoxElement.focus();
  });
}

残念ながら、これは必ずしもうまくいくわけではない。requestAnimationFrameメソッドが呼び出される時点ですでにアニメーションが開始しているかどうかは保証されていないからだ。そこで苦肉の策として、requestAnimationFrameメソッドを二重に入れ子にすることで成功率を上げるというやり方もあるが、やはり確実ではない。

requestAnimationFrame(() => {
  requestAnimationFrame(() => {
    searchBoxElement.focus();
  });
});

ここで重要なのは、アニメーションの開始タイミングに合わせて処理をすることである。そのためには、transitionstartイベントを使用するのが適切だ。

function open() {
  searchBoxElement.classList.remove('open');

  searchBoxElement.addEventListener(
    'transitionstart',
    () => {
      searchBoxElement.focus();
    },
    { once: true },
  );
}

visibilityプロパティをvisibleに書き換えると、アニメーションの開始タイミングですぐにvisibleに切り替わる（Animation of visibility）。そのため、トランジションの開始をフックにすればうまくいく。

さらには、transition-behaviorプロパティと@starting-styleを活用すればより簡単に実現できそうだ。visibilityプロパティをアニメーションさせるのと違って、displayプロパティにallow-discreteを適用すると、表示の際にはトランジションの開始を待たずに切り替わるらしい。この性質を利用すれば、focusメソッドは単に同期的に呼び出すだけでよい。

input[type='search'] {
  display: none;
  opacity: 0;
  transition:
    opacity 300ms,
    display 300ms allow-discrete;

  &.open {
    @starting-style {
      opacity: 0;
    }
    display: revert;
    opacity: revert;
  }
}

const searchBoxElement = document.querySelector('input[type="search"]');

function open() {
  searchBoxElement.classList.add('open');
  searchBoxElement.focus();
}

function close() {
  searchBoxElement.classList.remove('open');
}

参考資料

Tailwind CSSにおけるHTMLのコンポーネント化とCSSのコンポーネント化

Mon, 18 Mar 2024 01:35:00 GMT

Tailwind CSSにおいて、スタイルの組み合わせを抽象化したいと考えたとき、対処としてはいくつかの方法が考えられる。

もっとも一般的なのは、コンポーネントやパーシャルとして、クラス属性値とHTMLをセットで抽出する方法。

<template>
  <div>
    <img class="rounded" :src="img" :alt="imgAlt" />
    <div class="mt-2">
      <div>
        <div class="text-xs font-bold uppercase tracking-wider text-slate-600">{{ eyebrow }}</div>
        <div class="leading-snug font-bold text-slate-700">
          <a :href="url" class="hover:underline">{{ title }}</a>
        </div>
        <div class="mt-2 text-sm text-slate-600">{{ pricing }}</div>
      </div>
    </div>
  </div>
</template>

<script>
export default {
  props: ['img', 'imgAlt', 'eyebrow', 'title', 'pricing', 'url'],
};
</script>

— Reusing Styles - Tailwind CSS

これによってスタイルに関するコードが一元化されるため、新たにCSSを記述せずとも共通化の役割を果たせる。

次に、クラスの文字列だけを変数化することで再利用可能にする方法。shadcn/uiでは、コンポーネントに適用するクラスの文字列をexportして提供することで、ユーザーがスタイルだけを独立して利用できるようにしている。コンポーネント固有のマークアップやロジックに縛られないことが特徴である。

shadcn-ui/ui/templates/next-template/components/ui/button.tsx:

const buttonVariants = cva(
  'inline-flex items-center justify-center rounded-md text-sm font-medium transition-colors focus-visible:outline-none focus-visible:ring-2 focus-visible:ring-ring focus-visible:ring-offset-2 disabled:opacity-50 disabled:pointer-events-none ring-offset-background',
  {
    variants: {
      variant: {
        default: 'bg-primary text-primary-foreground hover:bg-primary/90',
        destructive: 'bg-destructive text-destructive-foreground hover:bg-destructive/90',
        outline: 'border border-input hover:bg-accent hover:text-accent-foreground',
        secondary: 'bg-secondary text-secondary-foreground hover:bg-secondary/80',
        ghost: 'hover:bg-accent hover:text-accent-foreground',
        link: 'underline-offset-4 hover:underline text-primary',
      },
      size: {
        default: 'h-10 py-2 px-4',
        sm: 'h-9 px-3 rounded-md',
        lg: 'h-11 px-8 rounded-md',
        icon: 'h-10 w-10',
      },
    },
    defaultVariants: {
      variant: 'default',
      size: 'default',
    },
  },
);

// （中略）

export { Button, buttonVariants };

この方法では、クラスを構成するためのライブラリとしてclsxやClass Variance Authority、Tailwind Variantsが用いられる。また、それらに応じた専用の正規表現をエディタに設定することで、Tailwindのインテリセンスを機能させることができる。

もう一つが、自分でCSSを書くという方法。

<!-- Before extracting a custom class -->
<button
  class="rounded-full bg-violet-500 px-5 py-2 font-semibold text-white shadow-md hover:bg-violet-700 focus:outline-none focus:ring focus:ring-violet-400 focus:ring-opacity-75"
>
  Save changes
</button>

<!-- After extracting a custom class -->

<button class="btn-primary">Save changes</button>

@tailwind base;
@tailwind components;
@tailwind utilities;

@layer components {
  .btn-primary {
    @apply focus:ring-opacity-75 rounded-full bg-violet-500 px-5 py-2 font-semibold text-white shadow-md hover:bg-violet-700 focus:ring focus:ring-violet-400 focus:outline-none;
  }
}

— Reusing Styles - Tailwind CSS

ある意味、これがもっともTailwindらしくないやり方ではあるが、有効になる場面もある。

また似たアプローチとしては、普通にCSSを記述するのではなく、CSSを生成するためのプラグインを作成するという方法もある。これについては以前の僕のブログ「Tailwind CSSで引数のあるMixinのような仕組みを作る方法（改）」で紹介した。

HTMLのコンポーネント化とCSSのコンポーネント化

それでは、これらのうちどれを採用すべきか。判断するには、そのスタイルはマークアップから独立して存在し得るか否かという観点が重要になる。Tailwindにおいては、HTMLにおけるコンポーネントとCSSにおけるコンポーネントという概念は区別して考えられるからである。

従来のBEM的なアプローチを思い返せば、CSSのためのクラスとHTMLは一対一の関係になっているのが基本だった。

<!-- Even with custom CSS, you still need to duplicate this HTML structure -->
<div class="chat-notification">
  <div class="chat-notification-logo-wrapper">
    <img class="chat-notification-logo" src="/img/logo.svg" alt="ChitChat Logo" />
  </div>
  <div class="chat-notification-content">
    <h4 class="chat-notification-title">ChitChat</h4>
    <p class="chat-notification-message">You have a new message!</p>
  </div>
</div>

— Reusing Styles - Tailwind CSS

CSSはこうした決まったHTMLのために記述されるものであって、そこからは独立して存在できないように意図されている。その場合は1つ目の方法を採用するのが妥当だ。これはHTMLまでまとめてパターン化するものなので、便宜上「HTMLのコンポーネント化」と呼ぶこととする。一般に、ほとんどの場面ではこの選択になるだろう。

一方「CSSのコンポーネント化」と言えるのが、スタイルの組み合わせを一つのクラスとして束ねてしまう3つ目の方法である。これはTailwindにおいては基本的に推奨されないが、しかしTailwind自身が提供しているクラスの中にはこれに該当するものがある。containerクラスである。

Tailwindには、ITCSSから着想を得て取り入れられたレイヤーの概念がある。現代的な仕様で言うところのCascade Layersに近いものである。

@tailwind base;
@tailwind components;
@tailwind utilities;

Tailwindから提供されるすべてのクラスは、このbase / components / utilitiesのいずれかのレイヤーに分類されている。ほとんどのクラスはutilitiesレイヤーだが、唯一containerクラスだけがcomponentsレイヤーに属している（公式プラグインまで含めれば、proseクラス、form-*クラス、aspect-*クラスなどもcomponentsである）。

このcomponentsレイヤーは、スタイルの組み合わせをクラスとしてパターン化したものであり、後ろのutilitiesレイヤーのクラスから上書きされることが想定されている。このレイヤリングの考え方はITCSSから影響を受けたものであるが、構成をそのまま継承しているわけではなく、微妙なアレンジが施されている。ITCSSの各レイヤーをTailwindのそれと照合してみると、次のようになる。

ITCSS	Tailwind CSS
generic	base
elements	base
objects	components
components	HTMLテンプレート
utilities	utilities

ここで重要なのが、componentsレイヤーとして指し示される対象が変化していることである。

ITCSSにおけるcomponentsレイヤーとは、特定の役割のために構築された、直接それとわかるようなはっきりとした形を持ったパーツ——普通に言われるところの「コンポーネント」——のことを指している。しかしTailwindにおいては、それはCSSのクラスではなく、HTMLのテンプレートとして表現されることがセオリーだ。つまり、「HTMLをコンポーネント化」したものがそれと対応する。

問題は、Tailwindにおけるcomponentsレイヤーと対応する、ITCSSのobjectsレイヤーとは何かということ。これは、OOCSSの原則である「構造と表層の分離（Separate structure and skin）」から影響を受けたものであり、ITCSSにおいてはそれは、装飾のない抽象的なパターンだとされている。具体例としては、OOCSSで言うところのmediaオブジェクトや、グリッドシステムのカラム、そしてTailwindのcontainerクラスのようなもの。実装としては、inuitcssのobjectsディレクトリや、Every Layoutのレイアウトプリミティブなども参考にできるだろう。

この両者の重要な差異は、前者はHTMLの構造を規定するが、後者は必ずしもそうではないという点である。たとえば、ボタンというUI要素は前者に含まれる。それはbutton要素やa要素として描画されることが意図されており、何にでもあてがえるわけではない。しかし後者は、自身がどのようなHTMLに対して適用されるかという関心を持たない。理論上、どのような場面で適用されても問題がないように構築されるものだ（もっとも、「objectsレイヤーに含まれるコンポーネント」が入れ子構造に依存する可能性はあるが、それはレイアウト上の理由でしかない）。

後者のように、特定の用途やHTMLの構造に縛られないような、汎用的かつ意味のある繰り返しのパターンがあるのであれば、CSSとしてコンポーネント化する方が扱いやすくなることもある。僕がよく作るのは、コンテンツの最大幅を制御するwrapperクラスや、グリッドレイアウトのためのauto-gridクラス、heading-2クラスのような標準的なテキストスタイル（例: Material Design、Human Interface Guidelines）のためのものなど。いずれも、utilitiesのように単機能ではなく、複合的な一つのセットになることで意味のあるものだ。

componentsレイヤーがutilitiesレイヤーと異なるのは、後ろのレイヤー、つまりutilitiesレイヤーからの上書きができるという点である。これによって、あくまでcomponentsレイヤーのスタイルは「デフォルト」として扱いつつ、utilitiesレイヤーを用いることで用途に応じた調整ができるようになっている。逆に、utilitiesであるsr-onlyクラスは、一見複数の機能の組み合わせのようにも見えるが、調整は想定されておらず常にこのまま適用されるべきであるためこのレイヤーに位置している。

ただし実は、表に示したように、ITCSSとTailwind CSSのレイヤーが明確に一対一の関係にマッピングできるわけではない。ITCSSのcomponentsレイヤーとTailwind CSSのcomponentsレイヤーは、一部役割が被るところがある。たとえば、公式プラグインにあるproseクラスやform-*クラスはITCSSで言えばcomponentsに近いが、HTMLテンプレートではなくTailwindのcomponentsレイヤーで実装されている。前述の表をより正確に表すとすれば次のようになるだろう。

ITCSS

Tailwind CSS

generic

base

elements

base

objects

components

HTMLテンプレート

utilities

最後に、前半で紹介した2つ目の方法は、HTMLのコンポーネント化とCSSのコンポーネント化のどちらでもないような、間に位置するアプローチである。しかし実際にそれを用いるのは、大抵の場合、特定の用途のためのスタイルを抽出するとき、つまりITCSSで言うcomponentsのようなものを作る場面だろう。実装の柔軟性のために、それをHTMLから独立した状態で扱えるようにしつつも、やはり実際のところどのような要素に適用されるかが決まっている。そのような場合に採用するのが適切である。

Tailwind CSSで引数のあるMixinのような仕組みを作る方法（改）

Sat, 16 Mar 2024 10:10:00 GMT

以前、「Tailwind CSSで引数のあるMixinのような仕組みを作る方法」というブログを書いた。しかしその後、調査を重ねていくうちに、以前書いたのとは別のアプローチの方が望ましいと考えるようになったため、改めて書き直すことにした。

またこのブログの内容は、「『Tailwind CSS実践入門』出版記念イベント」で行った僕のLTを基にしたものでもある。

ちなみにここで紹介する手法はさておき、そもそもどういうときにこれをやるべきかという話については、「Tailwind CSSにおけるHTMLのコンポーネント化とCSSのコンポーネント化」に書いた。

Tailwind CSSを使っていると、Sassで言うところのmixinのような仕組みが欲しくなることがたまにある。たとえば次のように、三角形を描画するための定型表現を形式化したいとき。

// https://qiita.com/degudegu2510/items/09f34d4b218c9df6bb57
@mixin triangle($size) {
  clip-path: polygon(50% 0, 100% 100%, 0 100%);
  width: $size;
  height: calc(#{$size} / 2 * tan(60deg));
}

.triangle {
  @include triangle(100px);
  background-color: rebeccapurple;
}

似たようなことを実現するためのやり方はいくつかあるが、今回はこれをTailwind CSSプラグインとして実装してみる。

1値の引数を取る仕組み

まず引数を取る仕組みを作るには、プラグインのmatchUtilities関数を使う。ほかにもmatchComponents関数やmatchVariant関数というのもあるが、今回はユーティリティなのでこれが順当である。次のようにして使う。

const plugin = require('tailwindcss/plugin');

module.exports = {
  theme: {
    tabSize: {
      1: '1',
      2: '2',
      4: '4',
      8: '8',
    },
  },
  plugins: [
    plugin(function ({ matchUtilities, theme }) {
      matchUtilities(
        {
          tab: (value) => ({
            tabSize: value,
          }),
        },
        { values: theme('tabSize') },
      );
    }),
  ],
};

例のように実装すると、次のようなクラスが使えるようになる。

<!-- テーマを参照する例: -->
<div class="tab-4">
  <!-- ... -->
</div>

<!-- arbitrary valuesを使う例: -->
<div class="tab-[13]">
  <!-- ... -->
</div>

.tab-4 {
  tab-size: 4;
}

.tab-\[13\] {
  tab-size: 13;
}

これを見ればわかる通り、matchUtilities関数のコールバック関数が返すオブジェクトがそのままCSSとして出力されるという仕組みになっている。なのでたとえば、valueを元にして動的に宣言を組み立てることもできる。

matchComponents({
  'auto-grid': (value) => ({
    display: 'grid',
    'grid-template-columns': `repeat(auto-fill, minmax(min(${value}, 100%), 1fr))`,
  }),
});

ただし、このやり方では引数を一つしか受け取ることができない。そのため、複数の引数に応じた処理をしたい場合には使いづらい。

2値の引数を取る仕組み

そこで参考として、Tailwindのコアプラグインの実装を調べてみる。fontSizeプラグインでは、次のようにして2値を引数として指定できる。

<p class="text-base/6 ...">So I started to walk into the water...</p>
<p class="text-base/7 ...">So I started to walk into the water...</p>
<p class="text-base/loose ...">So I started to walk into the water...</p>

baseがfont-size、6/7/looseがline-heightである。この実装は次のようになっている。

tailwindcss/src/corePlugins.js#L2100-L2120:

text: (value, { modifier }) => {
  let [fontSize, options] = Array.isArray(value) ? value : [value]

  if (modifier) {
    return {
      'font-size': fontSize,
      'line-height': modifier,
    }
  }

  let { lineHeight, letterSpacing, fontWeight } = isPlainObject(options)
    ? options
    : { lineHeight: options }

  return {
    'font-size': fontSize,
    ...(lineHeight === undefined ? {} : { 'line-height': lineHeight }),
    ...(letterSpacing === undefined ? {} : { 'letter-spacing': letterSpacing }),
    ...(fontWeight === undefined ? {} : { 'font-weight': fontWeight }),
  }
},

注目すべきは、関数の第二引数からmodifierという値を受け取っていること。クラス名のなかのスラッシュの後ろ側の値がこれに対応している。2値を取るプラグインはこれと同じ要領で実現できる。ただそれでも、3値以上の引数が必要になる場合に対応できない。

0値以上の引数を取る仕組み

そうした場合、カスタムプロパティを活用すると、3値以上（正確に言えば0値以上）の引数を取ることができる。たとえば、Tailwindではtransformプロパティに関するクラスを次のように併せて記述できる。

<div class="translate-x-4 scale-75 skew-y-3">
  <!-- ... -->
</div>

この場合、対応するCSSは次のように生成される。

.translate-x-4, .skew-y-3, .scale-75 {
  --tw-translate-x: 0;
  --tw-translate-y: 0;
  --tw-rotate: 0;
  --tw-skew-x: 0;
  --tw-skew-y: 0;
  --tw-scale-x: 1;
  --tw-scale-y: 1;
  transform: translate(var(--tw-translate-x), var(--tw-translate-y))
    rotate(var(--tw-rotate))
    skewX(var(--tw-skew-x)) skewY(var(--tw-skew-y))
    scaleX(var(--tw-scale-x)) scaleY(var(--tw-scale-y));
}

.translate-x-4 {
  --tw-translate-y: 1rem;
}

.skew-y-3 {
  --tw-skew-y: 0.75rem;
}

.scale-75 {
  --tw-scale-x: 0.75;
  --tw-scale-y: 0.75;
}

通常、transformプロパティに複数の座標変換関数を適用するには、マルチクラスの設計では実現しづらい（もっとも昨今では、それぞれに独立したプロパティが利用できるため、必ずしもtransformプロパティを使用する必要はないが、それは別の話）。しかしTailwindでは、このように値を部分的に挿入できるようにすることで、マルチクラスによって引数のような仕組みを実現している。

同じような仕組みを実装するには、transformプロパティに関するプラグインや、同様の手法を採用しているgradientColorStopsプラグインのソースコードを参考にしていただければできるはずだ。

しかし前述の2つの例と異なるのが、この手法では、複数の引数をJavaScript側で同時に受け取って加工するような処理ができないということ。「2値の引数を取る仕組み」では、valueとmodifierをJavaScript側で同時に受け取って処理することができたが、この手法では、JavaScript側で値を一つずつ受け取った上で、CSSの中で値の合成が行われることになる。そのため、複数の値の組み合わせに基づいた計算などを行うには、CSS組み込みの機能として表現できる範囲のことしかできない。

たとえば、コミュニティによるプラグインのtailwindcss-text-scaleでは、カスタムプロパティとして2つの数値を受け取った上で、それをCSSのcalc関数を用いて計算するという実装方法が採用されている。

tailwindcss-text-scale/src/index.ts#L58-L87:

addBase({
  ':root': {
    [`--${varsPrefix}-screen-max`]: maxScreen.toString(),
    [`--${varsPrefix}-screen-min`]: minScreen.toString(),
  },
  [screenMatcher]: {
    [`--${varsPrefix}-offset`]: `calc(100vw - var(--${varsPrefix}-screen-min) * 1px)`,
    [`--${varsPrefix}-screen-difference`]: `calc(
      var(--${varsPrefix}-screen-max) - var(--${varsPrefix}-screen-min)
    )`,
    /* *16 because clamp-percentage is in px and fontSize is in rem */
    [`--${varsPrefix}-percentage`]: `calc(
      var(--${varsPrefix}-offset) / var(--${varsPrefix}-screen-difference) * 16
    )`,
  },
  [fontScaleMatcher]: {
    [`--${varsPrefix}-min-rem`]: `calc(var(--${varsPrefix}-min) * 1rem)`,
    [`--${varsPrefix}-max-rem`]: `calc(var(--${varsPrefix}-max) * 1rem)`,
    [`--${varsPrefix}-current-rem`]: `calc(
      var(--${varsPrefix}-percentage) * (var(--${varsPrefix}-max) -
      var(--${varsPrefix}-min)) +
      var(--${varsPrefix}-min-rem)
    )`,
    'font-size': clamp
      ? `clamp(
      var(--${varsPrefix}-min-rem),
      var(--${varsPrefix}-current-rem),
      var(--${varsPrefix}-max-rem)
    )`
      : `var(--${varsPrefix}-current-rem)`,
  },
});

tailwindcss-text-scale/src/index.ts#L92-L122:

matchUtilities(
  {
    [`${textScalePrefix}`]: (value, { modifier }) => {
      if (modifier === null) return {};
      const clampedUnitMin = unitToRem(value);
      const clampedUnitMax = unitToRem(modifier);

      return {
        [`--${varsPrefix}-min`]: clampedUnitMin,
        [`--${varsPrefix}-max`]: clampedUnitMax,
      };
    },
  },
  {
    values: fontSizes,
    modifiers: fontSizes,
  },
);

matchUtilities(
  {
    [`${screenScalePrefix}`]: (value, { modifier }) => {
      if (modifier === null) return {};
      const clampedUnitMin = parseScreenSize(value);
      const clampedUnitMax = parseScreenSize(modifier);

      return {
        [`--${varsPrefix}-screen-min`]: clampedUnitMin,
        [`--${varsPrefix}-screen-max`]: clampedUnitMax,
      };
    },
  },
  {
    values: screens,
    modifiers: screens,
  },
);

Object.fromEntriesを活用してArray#reduceを代替する

Tue, 05 Mar 2024 21:05:00 GMT

JavaScriptにおいて、ある配列をもとにして別のオブジェクトを作成する場合、Array#reduceを使用することが多い。

const input = ['foo', 'bar', 'baz'];

const result = input.reduce((accumulator, currentValue) => {
  accumulator[currentValue] = capitalize(currentValue);
  return accumulator;
}, {});

assert.deepStrictEqual(result, { foo: 'Foo', bar: 'Bar', baz: 'Baz' });

しかし例のように、単にキーと値の組み合わせにマッピングするだけなら、あえてArray#reduceを使うまでもない。代わりにObject.fromEntriesを使えば、記述するコードをもっとシンプルにできる。

const input = ['foo', 'bar', 'baz'];

const result = Object.fromEntries(input.map((element) => [element, capitalize(element)]));

assert.deepStrictEqual(result, { foo: 'Foo', bar: 'Bar', baz: 'Baz' });

まず配列を「キーと値のペアからなる配列」（[key, value][]）に変換してから、それをObject.fromEntriesに渡すことでオブジェクト化できる。

Object.fromEntriesはObject.entriesの対になるメソッドである。Object.entriesは、オブジェクトを「キーと値のペアからなる配列」に変換するものであるのに対して、Object.fromEntriesはその逆に、「キーと値のペアからなる配列」をオブジェクトに変換する。

ついでに、TypeScriptではArray#reduceを使うと型の取り扱いがやや煩雑になるが、Object.fromEntriesを使うとそのような問題が起こらない。

タイプスケールがハマらないとはどういうことか

Thu, 15 Feb 2024 20:05:00 GMT

先日、頼まれて知人のサイトを作った。載せられるコンテンツはほとんどないものの、会社っぽい体裁にはしたいとのことだ。そんなわけで、要素はほとんどないなりに、多少なりとも見栄えがするようにデザインしてみた。要するに、このサイトみたいな極端な作りにはしなかったってこと。

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

そういう意味において合理的な手法のひとつとして、fluid typographyがある。これをTailwind CSSでも扱いやすいように僕は、arbitrary valuesを引数として扱うことでon the flyでCSSを生成できるプラグインを作り、その場かぎりの値——つまりデザイントークンと言われるような秩序立てて整理された値ではないもの——をいくつもソースコードに埋め込みながら、ガシガシと見栄えを整えていった。

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

そうしてUtopiaを使い始めた。タイプスケールのパラメータをいじりながらソースコードにも適用し、またパラメータをいじるということを繰り返してみると、この辺がよさそうだなと落ち着くポイントが見つかった。ただ、ページを少しスクロールして、そのスケールを別のところにも適用した状態を見てみると、どうにもコレジャナイ感が出る。というのも、さっき見つけたポイントというのは、その時見ていた文字のサイズから逆算してそれに近い計算結果になるようにパラメータを調整しただけのものだったからだ。そこで続けて、ほかの部分がきれいになるように同じくパラメータの再調整をしてみると、次はまた別の部分がイマイチになってしまった。これでは埒が開かない。

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

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

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

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

これらはそれぞれ逆方向からのアプローチと言える。インプット側に働きかけるか、アウトプット側に働きかけるかという違いである。

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

本質的には、Utopia自体の問題ではなかったように思う。しかし、モジュラースケールという、ステップ間隔の広いタイプスケールを生成する仕組みがあることと、始点と終点という決まった2値の掛け合わせにデザインを委ねることのマインド的な難しさによって、問題を顕在化させる結果に繋がったようだ。

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

「内から外へ」の発想は、以前のタケルさんのブログから着想を得た。

任意の要素に対してブラウザデフォルトのフォーカスリングを適用する方法

Sun, 31 Dec 2023 02:00:00 GMT

任意の要素に対して、ブラウザデフォルトのフォーカスリングが描画されるように明示的に設定したいことがある。たとえば、スタイリングの都合により一度取り除いたフォーカスリングを、ふたたび適用したいとき。

フォーカスリングのスタイルは、ブラウザの種別や状況によってまちまちであるため、CSSでそれらしいものをエミュレートするのが難しい。そのため、同じものを呼び出せるような特別なやり方を採用できると望ましい。

一つの方法として、outline: revertを適用すればデフォルトの挙動を復元できる。

* {
  outline: 0;
}

button {
  outline: revert;
}

しかし場合によっては、通常はフォーカスリングが描画されない要素に対して、ブラウザのデフォルトと同じフォーカスリングが描画されるようにしたい、ということもあるだろう。この場合、outline: revertではフォーカスリングを適用できない。

代わりに、次のように指定することでフォーカスリングを描画させられる。

.card:focus-within {
  outline: auto;
  outline: auto -webkit-focus-ring-color; /* for Chrome */
}

デフォルトのフォーカスリングを適用するための方法はブラウザによって異なるため、この方法では、それぞれに対応するためにoutlineプロパティを二重に宣言する。

まずFirefox/Safariでは、次の条件に一致するときにデフォルトのフォーカスリングが描画される。

outline-styleとしてautoが指定されている
outline-widthとして0より大きい<length>が指定されている

outline-styleの値がautoの場合、outline-colorの値は無視される。

Firefoxにおいては、accent-colorが指定されている場合、その値がフォーカスリングの色として適用される。

一方Chromeでは、次の条件に一致するときにデフォルトのフォーカスリングが描画される。

outline-styleとしてautoが指定されている
outline-widthとして0より大きい<length>が指定されている
outline-colorとして-webkit-focus-ring-colorが指定されている

-webkit-focus-ring-colorはブラウザの独自実装であり、標準化されていない。outline-colorの値を指定しなければ、currentcolorがフォーカスリングの色として適用されることになる。

.card:focus-within {
  outline: auto; /* `outline-color`は暗黙的にgreenになる */
  color: green;
}

これらの二重の宣言はブラウザで次のように動作する。

	`outline: auto`	`outline: auto -webkit-focus-ring-color`
Chrome	❌（`currentcolor`で描画される）	✅（カスケードによって優先される）
Firefox	✅	❌（パースエラーとなり無視される）
Safari	✅（カスケードによって打ち消される）	✅（カスケードによって優先される）

デフォルトのスタイルを適用するためには、Chromeではoutline: auto -webkit-focus-ring-colorを使用する必要がある。このやり方の場合、カスケードによって前者のoutline: autoは打ち消されて、後者の宣言が優先される。

Firefoxではoutline: autoを使用する必要がある。後者のoutline: auto -webkit-focus-ring-colorはパースエラーとなり無視されて、前者の宣言が適用される。

Safariではそのどちらの宣言を使用してもデフォルトのスタイルが適用される。標準仕様を採用するという意味では、前者のoutline: autoを使用するのが好ましいが、このやり方では、カスケードによって後者のoutline: auto -webkit-focus-ring-colorが優先されることになる。

参考資料

次世代Webカンファレンス 2023: CSS Session

Sat, 16 Dec 2023 00:00:00 GMT

「リンクの中にあるリンク」「ボタンの中にあるボタン」を正しく実装する

Thu, 02 Nov 2023 00:00:00 GMT

CSSファイルに記述されたクラスをTailwind CSS IntelliSenseで検出できるようにする

Sat, 12 Aug 2023 10:55:00 GMT

VS Codeの拡張機能であるTailwind CSS IntelliSenseを使用する際には、通常、CSSファイルに記述されたクラスは補完されない。というのも、Tailwind CSS IntelliSenseでは、Tailwind CSSの設定ファイル（tailwind.config.js）を基にしてCSSを算出しており、設定ファイルを介さずに実装されたCSSは無視されるからだ。

そのため、公式ドキュメントのAdding Custom StylesにあるようにCSSを記述するだけでは、IntelliSenseが有効にならない。

これに対する解決策は、TailwindプラグインとしてCSSを実装することだ。たとえば次のようにすることで、IntelliSenseからcardクラスを検出できるようになる。

const plugin = require('tailwindcss/plugin');

module.exports = {
  // ...
  plugins: [
    plugin(({ addBase, addComponents, addUtilities, theme }) => {
      addComponents({
        '.card': {
          backgroundColor: theme('colors.white'),
          borderRadius: theme('borderRadius.lg'),
          padding: theme('spacing.6'),
          boxShadow: theme('boxShadow.xl'),
        },
      });
    }),
  ],
};

ただしこの場合、JavaScriptとしてCSSを記述しなければならないという制約がある。普通のCSSと異なる書き方をしなければならないという点では、やや不便だろう。

そこで、代わりに次のような実装をすることで、普通のCSSとして記述されたファイルをプラグインとして読み込むことができる。

const fs = require('fs');
const postcss = require('postcss');
const plugin = require('tailwindcss/plugin');

module.exports = {
  // ...
  plugins: [
    plugin(({ addComponents }) => {
      const content = fs.readFileSync('src/styles/card.css', 'utf8');
      const styles = postcss.parse(content);
      addComponents(styles.nodes);
    }),
  ],
};

card.cssは次のようになる。

.card {
  box-shadow: theme(boxShadow.xl);
  border-radius: theme(borderRadius.lg);
  background-color: theme(colors.white);
  padding: theme(spacing.6);
}

styles.nodesには、CSSをパースしてオブジェクト化された結果が格納されており、これをそのまま読み込むことでスタイルを登録できる。これは、Core pluginsのpreflightの実装方法を参考にしたものだ。

これによってCSSファイルを読み込めるようにはなったが、ただ、さらに言うならば、CSSファイルが増えたり名前が変わったりした際には、その都度プラグインの実装に手を入れる必要があり、余計な手間は生じる。それを省力化すべく、CSSのファイル名に応じて自動的にスタイルが読み込まれる仕組み（convention over configuration）を作ってみよう。

一つ前提として、Tailwindにはレイヤーという概念がある。Tailwindのすべてのスタイルは、base、components、utilitiesのいずれかに分類される必要がある。詳しくは「Why does Tailwind group styles into “layers”?」を参照のこと。

プラグインの引数であるaddBase、addComponents、addUtilitiesは、それらのレイヤーに基づいており、ユーザーは、適切なレイヤーに対応する関数を選択して使用することになる。CSSファイルがどのレイヤーに属するかの区分をするために、ファイル名のプレフィックスとしてレイヤー名を含めるという規約を設けるのがよいだろう。

これを踏まえると、次のような実装になった。

/**
 * Loads CSS files through Tailwind’s plugin system to enable IntelliSense support.
 *
 * This plugin scans CSS files located in the `src/styles` directory and appends
 * them to their respective layers based on the file naming convention:
 *
 * - Files named `src/styles/base.{name}.css` are added to the base layer.
 * - Files named `src/styles/components.{name}.css` are added to the components layer.
 * - Files named `src/styles/utilities.{name}.css` are added to the utilities layer.
 */
const cssFiles = plugin(({ addBase, addComponents, addUtilities }) => {
  const dirname = path.join(__dirname, 'src/styles');
  const files = fs.readdirSync(dirname);

  for (const file of files) {
    const matched = /^(base|components|utilities)\..+\.css$/.exec(file);

    if (matched) {
      const layer = matched[1];
      const addStyles = {
        base: addBase,
        components: addComponents,
        utilities: addUtilities,
      }[layer];
      const content = fs.readFileSync(path.join(dirname, file), 'utf8');
      const styles = postcss.parse(content);

      addStyles(styles.nodes);
    }
  }
});

module.exports = {
  // ...
  plugins: [cssFiles],
};

しかし、まだ一つ問題が残る。それは、開発時にビルドツールなどを使ってソースコードの変更を監視する場合、CSSファイルを変更してもそれが検知されないため、再ビルドが自動的に実行されないということだ。

これについての解決策としては、ビルドツールとは別に監視プロセスを設けるという手がある。CSSファイルが変更されるたびにtailwind.config.jsのタイムスタンプを更新することで、ビルドツールが再ビルドを実行するように促すことができる。npm scriptsとして、Chokidar CLIやconcurrentlyを使用することで、次のように実現できる。

{
  "scripts": {
    "dev": "concurrently --raw \"npm:dev:*\"",
    "dev:astro": "astro dev",
    "dev:css": "chokidar \"src/styles/{base,components,utilities}.*.css\" -c \"touch tailwind.config.cjs\" -d 0 --silent"
  }
  // ...
}

ReactのuseStateをrender propとして抽象化して、コンポーネントを分割せずにコードのまとまりをよくする

Fri, 11 Aug 2023 16:30:00 GMT

ReactのuseStateを使用する際、stateのスコープが必要以上に大きくなってしまうことがある。たとえば次の例のように、コンポーネントの中のごく限られた部分でしか使わないstateが、コンポーネントのどこからでも参照できてしまう。

function App() {
  const [isFirstOpen, setFirstOpen] = useState(false);
  const [isSecondOpen, setSecondOpen] = useState(false);
  const [isThirdOpen, setThirdOpen] = useState(false);

  return (
    <>
      <Button onClick={() => setFirstOpen(true)}>First</Button>
      <Popover isOpen={isFirstOpen} onOpenChange={setFirstOpen}>
        ...
      </Popover>

      <Button onClick={() => setSecondOpen(true)}>Second</Button>
      <Popover isOpen={isSecondOpen} onOpenChange={setSecondOpen}>
        ...
      </Popover>

      <Button onClick={() => setThirdOpen(true)}>Third</Button>
      <Popover isOpen={isThirdOpen} onOpenChange={setThirdOpen}>
        ...
      </Popover>
    </>
  );
}

こうした場合の一般的な解決策としては、それぞれのstateに応じた粒度でコンポーネントを分割することだ。次のようにすると、stateのスコープが必要最小限になるように制限できる。

function App() {
  return (
    <>
      <First />
      <Second />
      <Third />
    </>
  );
}

function First() {
  const [isOpen, setOpen] = useState(false);

  return (
    <>
      <Button onClick={() => setOpen(true)}>First</Button>
      <Popover isOpen={isOpen} onOpenChange={setOpen}>
        ...
      </Popover>
    </>
  );
}

function Second() {
  const [isOpen, setOpen] = useState(false);

  return (
    <>
      <Button onClick={() => setOpen(true)}>Second</Button>
      <Popover isOpen={isOpen} onOpenChange={setOpen}>
        ...
      </Popover>
    </>
  );
}

function Third() {
  const [isOpen, setOpen] = useState(false);

  return (
    <>
      <Button onClick={() => setOpen(true)}>Third</Button>
      <Popover isOpen={isOpen} onOpenChange={setOpen}>
        ...
      </Popover>
    </>
  );
}

しかし場合によっては、stateの粒度に基づいてコンポーネントを分割していくと、却ってソースコードの見通しが悪くなることがある。

そこで一つの代替案として、IIFEの中でuseStateを使用するというやり方がある。次のようにすることで、useStateのスコープを制限できる。

function App() {
  return (
    <>
      {(() => {
        const [isOpen, setOpen] = useState(false);
        return (
          <>
            <Button onClick={() => setOpen(true)}>First</Button>
            <Popover isOpen={isOpen} onOpenChange={setOpen}>
              ...
            </Popover>
          </>
        );
      })()}

      {(() => {
        const [isOpen, setOpen] = useState(false);
        return (
          <>
            <Button onClick={() => setOpen(true)}>Second</Button>
            <Popover isOpen={isOpen} onOpenChange={setOpen}>
              ...
            </Popover>
          </>
        );
      })()}

      {(() => {
        const [isOpen, setOpen] = useState(false);
        return (
          <>
            <Button onClick={() => setOpen(true)}>Third</Button>
            <Popover isOpen={isOpen} onOpenChange={setOpen}>
              ...
            </Popover>
          </>
        );
      })()}
    </>
  );
}

しかしこれでは、条件に応じてそのIIFEの表示を切り替えるようなケースに対応できなくなってしまう。たとえば次のような実装をすると、isThirdVisibleの値が切り替わった時にフックの整合性が保てなくなってしまう。

function App({ isThirdVisible }: { isThirdVisible: boolean }) {
  return (
    <>
      {(() => {
        const [isOpen, setOpen] = useState(false);
        return (
          <>
            <Button onClick={() => setOpen(true)}>First</Button>
            <Popover isOpen={isOpen} onOpenChange={setOpen}>
              ...
            </Popover>
          </>
        );
      })()}

      {(() => {
        const [isOpen, setOpen] = useState(false);
        return (
          <>
            <Button onClick={() => setOpen(true)}>Second</Button>
            <Popover isOpen={isOpen} onOpenChange={setOpen}>
              ...
            </Popover>
          </>
        );
      })()}

      {isThirdVisible &&
        (() => {
          const [isOpen, setOpen] = useState(false);
          return (
            <>
              <Button onClick={() => setOpen(true)}>Third</Button>
              <Popover isOpen={isOpen} onOpenChange={setOpen}>
                ...
              </Popover>
            </>
          );
        })()}
    </>
  );
}

加えて、最上位レベルのフックのみを呼び出すというルールに反しているため、ESLintプラグインのeslint-plugin-react-hooksを使用すると警告が発生してしまう。あくまでコードスタイルに限っての問題ではあるが。

したがって、IIFEの使用は得策ではなさそうだ。そのためやはり、useStateのスコープを制限するためにはコンポーネントを分割しなければならないという制約は免れない。

そこで、useStateの使用を抽象化する汎用的なコンポーネントを作成するとする。これを用いることで、stateのスコープを制限しつつも、ノードの記述はインライン化できるようになる。

import { State } from './State';

function App() {
  return (
    <>
      <State initial={false}>
        {({ state: isOpen, setState: setOpen }) => (
          <>
            <Button onClick={() => setOpen(true)}>First</Button>
            <Popover isOpen={isOpen} onOpenChange={setOpen}>
              ...
            </Popover>
          </>
        )}
      </State>

      <State initial={false}>
        {({ state: isOpen, setState: setOpen }) => (
          <>
            <Button onClick={() => setOpen(true)}>Second</Button>
            <Popover isOpen={isOpen} onOpenChange={setOpen}>
              ...
            </Popover>
          </>
        )}
      </State>

      <State initial={false}>
        {({ state: isOpen, setState: setOpen }) => (
          <>
            <Button onClick={() => setOpen(true)}>Third</Button>
            <Popover isOpen={isOpen} onOpenChange={setOpen}>
              ...
            </Popover>
          </>
        )}
      </State>
    </>
  );
}

<State>の実装は次の通り。

import type { Dispatch, DispatchWithoutAction, ReactNode, SetStateAction } from 'react';
import { useCallback, useState } from 'react';

/**
 * The implement a hooks version of React PowerPlug’s `<State>`.
 * https://renatorib.github.io/react-powerplug/#/docs-components-state
 *
 * @example
 * <State initial={false}>
 *   {({ state: isOpen, setState: setOpen }) => (
 *     <>
 *       <button type="button" onClick={() => setOpen(true)}>Open</button>
 *       <Popover isOpen={isOpen} onOpenChange={setOpen}>...</Popover>
 *     </>
 *   )}
 * </State>
 */
export function State<S>({
  initial: initialState,
  children,
}: {
  initial: S | (() => S);
  children: (props: {
    state: S;
    setState: Dispatch<SetStateAction<S>>;
    resetState: DispatchWithoutAction;
  }) => ReactNode;
}) {
  const [state, setState] = useState(initialState);
  const resetState = useCallback(() => setState(initialState), [initialState]);

  return children({
    state,
    setState,
    resetState,
  });
}

<State>はその内部でuseStateを保持しつつ、render propを介してその値や操作方法を提供する。これによって、スコープは<State>のchildrenだけに制限できるようになる。最初の例と比較して、コードのまとまりはよくなったように思う。

この<State>は僕が考案したものではなく、React PowerPlugというライブラリからアイデアを借用したものだ。残念ながら、React PowerPlugは長らくメンテナンスされておらず、フックスやTypeScriptにも対応していないので、僕は前述のように自分で実装し直して使っている。

もっとも、昨今の気の利いたUIライブラリであれば、こうした冗長なコードを省略できる仕組みもある。たとえば、Headless UIの系譜にあるReact Aria Componentsでは、次のようにコンポーネントを構成するだけで、状態管理やイベントの登録が暗黙的に行われるようになっている。

<DialogTrigger>
  <Button>Open popover</Button>
  <Popover>
    <OverlayArrow>
      <svg width={12} height={12}>
        <path d="M0 0,L6 6,L12 0" />
      </svg>
    </OverlayArrow>
    <Dialog>This is a popover.</Dialog>
  </Popover>
</DialogTrigger>

— Popover – React Aria

こうした仕組みによって、多くの場面には対応できるが、これでは解決できないようなケースではStateコンポーネントを採用するとよいだろう。

ついでに言えば、<Suspense>を使う場合にも同じ問題がある。これに対して、React Routerでは、<State>と同じくrender propインターフェースが実装された<Await>という独自コンポーネントを提供することで、やはりコンポーネントを分割せずに記述できる仕組みを実現している。

Deferred Data v6.15.0 | React Router

Tailwind CSS実践入門——まず作ってから、あとで共通化する

Mon, 24 Jul 2023 00:00:00 GMT

ReactコンポーネントでレンダリングされるHTML要素の種類を変更可能にするためのパターン

Sun, 04 Jun 2023 03:35:00 GMT

ReactのUIコンポーネントライブラリを使っていると、あるコンポーネントによってレンダリングされるHTML要素の種類を変更したくなる場面がある。たとえば、通常はbutton要素としてレンダリングされるButtonコンポーネントを使うときに、代わりにa要素を使ってレンダリングしたいというケース。

`as` prop

そのような場合、一般的には、Buttonコンポーネントにas propを実装して対処することが多い。

function Button({ as: Component = 'button', ...props }) {
  return <Component {...props} />;
}

render(
  <>
    <Button type="button">
      I’m a <code>button</code> element
    </Button>
    <Button as="a" href="/">
      I’m an <code>a</code> element
    </Button>
  </>,
);

このパターンは、Polymorphicとも呼ばれる。styled-componentsやMaterial UI、Chakra UIなど、数多くのライブラリで同等の手法が採用されている。

このコードだけを見ればごくごく簡単に実現できる機能のように思えるが、TypeScriptとして正しく型付けをしようしたり、forwardRefを適用したりしていると、そこそこ複雑な実装になってしまう。

具体的な実装方法については、詳しく解説している記事があったのでそちらに譲る。

ただ、単にその仕組みの実装が複雑になるだけであれば、パッケージ化しておいたものを参照して使えばよい。実際にそれに当たるnpmモジュールもいくつかある。

しかし、それ以外にもいくつかの問題がある。かつてas propを採用していたRadix UIでは、これらの問題を解決するために、as propが廃止されて新たにasChild propが採用されている。これらの機能を実装したJenna Smith氏によると、いくつかの観点から見て、as propは過度な複雑性をもたらすと言う。

I've been thinking a lot about the `as` prop for polymorphism lately and wondering why we all went down the road of runtime TypeScript polymorphism. It introduces so many unnecessary complexities, bloats error messages and kills TS perf... 🧵
— jenna (@jjenzz) August 6, 2021

一つは、TypeScriptのエラーメッセージが複雑になってしまうこと。たとえば、Reactの要素に間違ったpropが渡されたとき、通常のa要素と、as propとしてa要素が指定されたコンポーネントを比較すると、明らかに後者の方がユーザーにとって理解しづらい。

次に、TypeScriptのパフォーマンスを悪化させること。as propの型定義においては、高度な型推論や条件型、ジェネリクスを多用することになり、コンパイルするための負荷が高まってしまう。

そして、as propを使うと、元のコンポーネントとasに当たるコンポーネントの双方に対するpropを同時に記述することになり、どのpropがどのコンポーネントのためのものかが理解しづらくなる。さらに、元のコンポーネントとasに当たるコンポーネントに同じ名前のpropがあるとコンフリクトしてしまう。

const ComponentOwnProps = {
	onChange(thing: boolean): void;
};

const Component = () => {/* ... */};

// thing would be `event` type from `input`
return <Component as="input" onChange={thing => console.log(thing)} />;

— [Polymorphic] Allow ComponentType props to override by jjenzz · Pull Request #779 · radix-ui/primitives

`asChild` prop

これらの問題を解決するために、新たにasChild propが考案された。次のようにして使用する。

import * as Tooltip from '@radix-ui/react-tooltip';
import * as React from 'react';

export default () => (
  <Tooltip.Root>
    <Tooltip.Trigger asChild>
      <a href="https://www.radix-ui.com/">Radix UI</a>
    </Tooltip.Trigger>
    <Tooltip.Portal>…</Tooltip.Portal>
  </Tooltip.Root>
);

— Composition – Radix UI

レンダリングする要素を変更する対象のコンポーネントに対して、as propの代わりにasChild propを付与する。そのchildren propとして任意のノードを指定する。

このasChild propによって、前述の問題は一通り解決されることになる。

おまけに、asChild propの特性としてもたらされるのが、asChild propを指定されたコンポーネントを複数に入れ子にできる機能である。次のように記述することで、親に当たるコンポーネントの機能を継承していくことができる。

import * as Dialog from '@radix-ui/react-dialog';
import * as Tooltip from '@radix-ui/react-tooltip';
import * as React from 'react';

const MyButton = React.forwardRef((props, forwardedRef) => (
  <button {...props} ref={forwardedRef} />
));

export default () => {
  return (
    <Dialog.Root>
      <Tooltip.Root>
        <Tooltip.Trigger asChild>
          <Dialog.Trigger asChild>
            <MyButton>Open dialog</MyButton>
          </Dialog.Trigger>
        </Tooltip.Trigger>
        <Tooltip.Portal>…</Tooltip.Portal>
      </Tooltip.Root>

      <Dialog.Portal>...</Dialog.Portal>
    </Dialog.Root>
  );
};

— Composition – Radix UI

自前のコンポーネントに`asChild` propを組み込む

asChild propはRadix UIのコンポーネントで提供されている機能だが、自前のコンポーネントにも容易に実装できる。@radix-ui/react-slotパッケージを使用するのがよい。

import { Slot } from '@radix-ui/react-slot';
import React from 'react';

function Button({ asChild, ...props }) {
  const Comp = asChild ? Slot : 'button';
  return <Comp {...props} />;
}

— Slot – Radix UI

TypeScriptを使用しつつ、forwardRefを適用する場合は、次のように記述する。

import { forwardRef, type ComponentPropsWithRef } from 'react';

const Button = forwardRef<unknown, ComponentPropsWithRef<'button'> & { asChild?: boolean }>(
  ({ asChild, ...props }, forwardedRef) => {
    const Comp: any = asChild ? Slot : 'button';
    return <Comp {...props} ref={forwardedRef} />;
  },
);

Button.displayName = 'Button';

ただし、こうなってくると定型コードとしてはやや煩雑である。そこで代わりに、Radix UIの内部で使用されている@radix-ui/react-primitiveパッケージを使うことで多少マシになる。

import { Primitive } from '@radix-ui/react-primitive';
import type * as Radix from '@radix-ui/react-primitive';
import { forwardRef } from 'react';

type ButtonElement = React.ElementRef<typeof Primitive.button>;
type PrimitiveButtonProps = Radix.ComponentPropsWithoutRef<typeof Primitive.button>;
interface ButtonProps extends PrimitiveButtonProps {}

const Button = forwardRef<ButtonElement, ButtonProps>((props, forwardedRef) => (
  <Primitive.button {...props} ref={forwardedRef} />
));

Button.displayName = 'Button';

このパッケージの使用方法はドキュメント化されていないので、Radix UIのソースコードの中で実際に使用されている様子を参考にして実装する必要がある。

コンポーネント同士のpropsのマージ

Slotコンポーネント（およびPrimitive.*コンポーネント）のpropsは、その子のpropsとマージされる仕組みになっている。たとえば、次のようにコンポーネントを使用するとする。

import { Primitive } from '@radix-ui/react-primitive';
import type * as Radix from '@radix-ui/react-primitive';
import { forwardRef } from 'react';

type ButtonElement = React.ElementRef<typeof Primitive.button>;
type PrimitiveButtonProps = Radix.ComponentPropsWithoutRef<typeof Primitive.button>;
interface ButtonProps extends PrimitiveButtonProps {}

const Button = forwardRef<ButtonElement, ButtonProps>((props, forwardedRef) => (
  <Primitive.button
    {...props}
    ref={forwardedRef}
    className="Button"
    style={{ backgroundColor: 'gray' }}
    data-test="original"
    onClick={(_event) => console.log('original event')}
  />
));

Button.displayName = 'Button';

render(
  <Button asChild>
    <a
      href="/"
      className="child"
      style={{ border: '1px solid' }}
      data-test="child"
      onClick={(_event) => console.log('child event')}
    >
      Hello
    </a>
  </Button>,
);

このButtonコンポーネントのpropsは、擬似的に表現すれば、次のようにマージされることになる。

<a
  href="/"
  data-test="child"
  class="Button child"
  style={{
    backgroundColor: 'gray',
    border: '1px solid',
  }}
  onClick={(...args) => {
    childProps.onClick(...args);
    slotProps.onClick(...args);
  }}
>
  Hello
</a>

このpropsのマージには次のルールがある。

onから始まる同名のpropが指定されていれば、それらをcomposeする関数が作成される
style propの値はマージされる。同じプロパティが指定されていれば子が優先される
className propの値はマージされる
それ以外のpropは子の値で上書きされる

詳しくは、mergePropsの実装を参照のこと。

以上のように、Slotコンポーネントのpropsはその子のpropsと自動的にマージされる仕組みになっていることは把握しておきたい。

注意すべきは、Buttonコンポーネントのpropsについては、ユーザー側でマージする実装を行わなければならないということ。もし次のように、Buttonコンポーネントのpropsのマージを考慮しない実装になっていると、Buttonコンポーネントにpropsを指定した際に期待に反する挙動をする。

import { Primitive } from '@radix-ui/react-primitive';
import type * as Radix from '@radix-ui/react-primitive';
import { forwardRef } from 'react';

type ButtonElement = React.ElementRef<typeof Primitive.button>;
type PrimitiveButtonProps = Radix.ComponentPropsWithoutRef<typeof Primitive.button>;
interface ButtonProps extends PrimitiveButtonProps {}

const Button = forwardRef<ButtonElement, ButtonProps>((props, forwardedRef) => (
  <Primitive.button
    {...props}
    ref={forwardedRef}
    className="Button"
    style={{ backgroundColor: 'gray' }}
    data-test="original"
    onClick={(_event) => console.log('original event')}
  />
));

Button.displayName = 'Button';

render(
  <Button
    className="child"
    style={{ border: '1px solid' }}
    data-test="child"
    onClick={(_event) => console.log('child event')}
  >
    Hello
  </Button>,
);

このButtonコンポーネントは、次のようにレンダリングされる。

<button
	className="Button"
	data-test="original"
	style={{ backgroundColor: 'gray' }}
	onClick={_event => console.log('original event')}
>
	Hello
</Button>

これでは、期待通り上書きできるものと、期待に反して上書きできないものが、propの種類によってまちまちになってしまう。期待通りのインターフェースを実現するには、Slotコンポーネントにpropsが渡される前に、それらの値をマージしておかなければならない。たとえば、次のような実装になる。

import { Primitive } from '@radix-ui/react-primitive';
import type * as Radix from '@radix-ui/react-primitive';
import { forwardRef } from 'react';
import { mergeRefs } from 'react-merge-refs';

type ButtonElement = React.ElementRef<typeof Primitive.button>;
type PrimitiveButtonProps = Radix.ComponentPropsWithoutRef<typeof Primitive.button>;
interface ButtonProps extends PrimitiveButtonProps {}

const Button = forwardRef<ButtonElement, ButtonProps>((props, forwardedRef) => {
  const internalRef = useRef(null);
  return (
    <Primitive.button
      {...props}
      ref={mergeRefs([internalRef, forwardedRef])}
      className={['Button', props.classname].filter(Boolean).join(' ')}
      style={{
        backgroundColor: 'gray',
        ...props.style,
      }}
      data-test={(props as any)['data-test'] || 'original'}
      onClick={() => {
        props.onClick?.(event);
        console.log('original event');
      }}
    />
  );
});

Button.displayName = 'Button';

コンポーネントの中の子を規定する場合

場合によっては、Buttonコンポーネントの実装として、ルートのコンポーネントの内側に別のコンポーネントを入れ子にしたいこともあるだろう。as propを使えば、次のように実装することができる。

function Button({ as: Component = 'button', children, ...props }) {
  return (
    <Component {...props} className={['Button', props.className].filter(Boolean).join(' ')}>
      <span className="ButtonLabel">{children}</span>
    </Component>
  );
}

しかし、asChild propで同等のことを実現しようとすると、かなり複雑な実装が必要になる。たとえば次のようになる。

import { Primitive } from '@radix-ui/react-primitive';
import type * as Radix from '@radix-ui/react-primitive';
import {
  Children,
  cloneElement,
  ElementRef,
  forwardRef,
  isValidElement,
  ReactElement,
  ReactNode,
} from 'react';

type ButtonElement = ElementRef<typeof Primitive.button>;
type PrimitiveButtonProps = Radix.ComponentPropsWithoutRef<typeof Primitive.button>;
interface ButtonProps extends PrimitiveButtonProps {}

export const Button = forwardRef<ButtonElement, ButtonProps>(
  ({ children, ...props }, forwardedRef) => {
    const wrapChildren = (children: ReactNode) => <span className="ButtonLabel">{children}</span>;

    return (
      <Primitive.button
        {...props}
        ref={forwardedRef}
        className={['Button', props.className].filter(Boolean).join(' ')}
      >
        {props.asChild
          ? isValidElement(children)
            ? cloneElement(Children.only(children as ReactElement), {
                ref: forwardedRef,
                children: wrapChildren(children.props.children),
              })
            : children
          : wrapChildren(children)}
      </Primitive.button>
    );
  },
);

Buttonコンポーネントのテストケース

import renderer from 'react-test-renderer';
import { describe, expect, it } from 'vitest';
import { Button } from './button';

describe('empty', () => {
  it('default', async () => {
    const tree = renderer.create(<Button></Button>).toJSON();
    expect(tree).toMatchInlineSnapshot(`
      <button
        className="Button"
      >
        <span
          className="ButtonLabel"
        />
      </button>
    `);
  });
  it('asChild', async () => {
    const tree = renderer.create(<Button asChild></Button>).toJSON();
    expect(tree).toMatchInlineSnapshot('null');
  });
});

describe('string', () => {
  it('default', async () => {
    const tree = renderer.create(<Button>string</Button>).toJSON();
    expect(tree).toMatchInlineSnapshot(`
      <button
        className="Button"
      >
        <span
          className="ButtonLabel"
        >
          string
        </span>
      </button>
    `);
  });
  it('asChild', async () => {
    const tree = renderer.create(<Button asChild>string</Button>).toJSON();
    expect(tree).toMatchInlineSnapshot('null');
  });
});

describe('single element', () => {
  it('default', async () => {
    const tree = renderer
      .create(
        <Button>
          <a href="/">single</a>
        </Button>,
      )
      .toJSON();
    expect(tree).toMatchInlineSnapshot(`
      <button
        className="Button"
      >
        <span
          className="ButtonLabel"
        >
          <a
            href="/"
          >
            single
          </a>
        </span>
      </button>
    `);
  });
  it('asChild', async () => {
    const tree = renderer
      .create(
        <Button asChild>
          <a href="/">single</a>
        </Button>,
      )
      .toJSON();
    expect(tree).toMatchInlineSnapshot(`
      <a
        className="Button"
        href="/"
      >
        <span
          className="ButtonLabel"
        >
          single
        </span>
      </a>
    `);
  });
});

describe('mixed', () => {
  it('default', async () => {
    const tree = renderer
      .create(
        <Button>
          <span>multi</span>-<a href="/">ple</a>
        </Button>,
      )
      .toJSON();
    expect(tree).toMatchInlineSnapshot(`
      <button
        className="Button"
      >
        <span
          className="ButtonLabel"
        >
          <span>
            multi
          </span>
          -
          <a
            href="/"
          >
            ple
          </a>
        </span>
      </button>
    `);
  });
  it('asChild', async () => {
    expect(() =>
      renderer.create(
        <Button asChild>
          <span>multi</span>-<a href="/">ple</a>
        </Button>,
      ),
    ).toThrowError();
  });
});

これはあまり現実的な実装方針ではないし、そもそもインターフェースとしてあまり直感的ではないと思う。

もっともシンプルな解決策としては、内側に入れ子になったコンポーネントを別コンポーネントとして切り出してしまうことだろう。そして、利用時にはそれら二つのコンポーネントを組み合わせて使うという規約を設けておく。

<Button>
	<ButtonLabel>Hello</ButtonLabel>
</Button>

<Button asChild>
	<a href="/">
		<ButtonLabel>Hello</ButtonLabel>
	</a>
</Button>

実際のところ、Radix UIにおいてはこのような設計方針が採用されている。しかし、Radix UIのようなプリミティブなコンポーネントライブラリと違って、一般的なコンポーネントライブラリとしては、これでは使い勝手が悪い場合があるだろう。

Ariakitにおける`render` prop

Ariakitでは、レンダリングする要素をrender propを介して変更できるように設計されている。

<Combobox render={<textarea rows={5} />} />

— Composition - Ariakit

興味深いのは、そのrender propに渡された要素に対して、内部的に管理されたpropsなどが暗黙的に渡される仕組みになっていること。たとえばあるコンポーネントに対して、render propとchildren propを同時に指定すると、render propに指定した要素に対してそのchildren propが渡される仕組みになっている。

<Tab render={<Link href="/new" />}>New</Tab>

— Composition - Ariakit

これは次のような結果になる。

<Link href="/new">New</Link>

先ほどのasChild propにおいては、コンポーネントの内側に別の要素が入れ子になっている場合の表現の難しさが問題になった。しかし、このAriakitのrender propのアイデアを借用すれば、比較的直感的なインターフェースとシンプルな実装を実現することもできる。

import { cloneElement, ComponentProps, forwardRef, ReactElement, ReactNode } from 'react';

type ButtonProps = { render?: ReactElement } & ComponentProps<'button'>;

const Button = forwardRef<HTMLElement, ButtonProps>(
  ({ render, children, ...props }, forwardedRef) => {
    const createElement = (props: any, children: ReactNode) => {
      return render ? (
        cloneElement(render, props, children)
      ) : (
        <button {...props}>{children}</button>
      );
    };

    return createElement(
      {
        ...props,
        ref: forwardedRef,
        className: ['Button', props.className].filter(Boolean).join(' '),
      },
      <span className="ButtonLabel">{render?.props.children || children}</span>,
    );
  },
);

render(
  <>
    <Button>Hello</Button>
    <Button render={<a href="/" />}>Hello</Button>
    <Button render={<a href="/">Hello</a>} />
  </>,
);

必要に応じて、AriakitのcreateElementの実装も参照のこと。

Base UIにおける`slots` propと`slotProps` prop

Base UIでは、コンポーネントの内部の構造まで上書きすることができるslots propおよびslotProps propが提供されている。

<Select slots={{ listbox: 'ol' }} defaultValue="First option">
  <Option value="First option">First option</Option>
  <Option value="Second option">Second option</Option>
</Select>

— Overriding component structure - Base UI

<Badge slotProps={{ badge: { className: 'my-badge' } }} />

— Overriding component structure - Base UI

as propではルートのコンポーネントしか変更できなかったのに対して、Base UIのslots propでは、そのコンポーネントの内部のサブコンポーネントまで変更することができる。slotProps propを使えば、ルートおよびサブコンポーネントのpropsを変更できる。

asChild propやAriakitのrender propをベースとした設計では、提供するコンポーネントは細かく分割する必要があり、それらを組み合わせて使うことがユーザー側の責務になる。一方、Base UIのslots propおよびslotProps propを前提とすると、提供するコンポーネント自体を細分化する必要はなくなるため、ユーザーが組み合わせて使う負荷は軽減される。

強いて言うならば、前者の方が柔軟性があってシンプル、後者の方が簡潔に使えてイージー、という違いだろうか。まだBase UIについての考察が十分にできていないので、総括としては物足りないけれど、ひとまず今回はこんなところで。

Tailwind CSS実践入門——まず作ってから、あとで共通化する

Fri, 24 Feb 2023 00:00:00 GMT

肩の力を抜いてラフに書く、思いつくままに書く

Sat, 11 Feb 2023 08:20:00 GMT

根を詰めて取り組んでいた原稿がやっと手離れして、肩の荷が下りた。僕がこれまで経験して来た中で、最も重い執筆だった。

僕が文章を書くスピードにはかなりのムラがある。1日で1万文字書けることもあれば、100文字とか200文字くらいしか書けないこともある。前者の場合はあまり悩まずにスラスラ書けている時で、後者の場合は悩みに悩んで絞り出すように書いている時だ。今回はかなり後者寄りだった。

今回がいつもと違ったのは、かなりガチガチに構成を考えて書いたこと。規定のページ数ぴったりに収まるように、書くべきこととそうでないことを細かく選り分けて、それらが自然に理解できるように話の順序を何度も再検討して、重複したり無駄があるところ、抜け漏れが出ないようにも意識しながら、また説明の程度の濃淡も偏らないように調整しつつ書いていた。

ブログと大きく違うのは、紙には強い「清書感」があることだと思う。ブログのように、あとから気軽に修正したり、別の記事として書き直したり、といったことが実質的にできない。やり直しが効かない中で、この一発にすべてを賭けるような意識で、完成されたものを作り上げなければならない。もっとも、経験を重ねればまた別の感覚を覚えるようになるかもしれないけれど。

ここで書くときにはそのような緊張感はない。思いつくままに気楽に書けばいい。そういう思いでずっとやってきた。

僕がブログを始めたのは、今から15年以上前の小学生のころだった。当初はなにか書きたいことがあったわけではないが、すでに下火になりつつあったブログブームに影響されて、とにかくなんでもいいのでブログを書くことをやってみたかった。また、簡単なホームページ的なものも作っていたけど、なにかコンテンツになるものがないとどうしようもないと悩みあぐねているときでもあった。

ブログを立ち上げて以来、僕は書けるネタをずっと探し続けることになった。そして捻り出すようにしてなにかしらのブログを投稿した。日々の些細な出来事について書いたり、当時作っていたホームページの話をしたり、ある時は2ちゃんねるのまとめブログを作ったり、ニュース記事まとめサイトみたいなものを運営したりもしていた。

そうこうしているうちに、僕は高校を卒業してウェブデザインの学校に進学した。そこでいろいろと専門的らしいことを勉強して、少しおもしろみのあることを書けるようになってきた。いろいろな人から読んでもらえるようにもなってきた。それくらいの時期から、文章を書くことが自分にとってのアイデンティティであるとも自覚し始めた。

スタンダードデザインユニットのサイトを始めたことをきっかけに、これまでよりもきちんとした文章を書かなければならないと考え始めた。個人ではなく会社として発信するためには、それなりの責任が伴う。文章の書き方について真面目に勉強し始めたのがそのころだった。

そうした経験を経て、よい文章を書くための技量は上がったように思う。その分、あえて書かないことも増えてきた。なにか書くにしても、筆の進みがどんどん慎重になってきた。そういう傾向を感じる。切り捨てられるものが増えて来たということ。

硬直化している気がする。もっと気軽に書きたいし、そうすべきだとも思う。昔のように、あるいはそれよりもっと、軽やかに。僕はその楽しさに惹かれていたはずだ。

WEB+DB PRESS Vol.133に特集「Tailwind CSS実践入門——まず作ってから、あとで共通化する」を寄稿しました #wdpress

Mon, 06 Feb 2023 04:30:00 GMT

後日追記: 寄稿した特集がgihyo.jpにて全章無料公開されました。

Tailwind CSS実践入門～まず作ってから、あとで共通化する記事一覧 | gihyo.jp

2023年2月24日発売の「WEB+DB PRESS Vol.133」に特集「Tailwind CSS実践入門——まず作ってから、あとで共通化する」を寄稿しました。

WEB+DB PRESS Vol.133、どこよりも早い表紙画像です！
TypeScript最新活用、速習Ruby 3.2、Tailwind CSS実践入門を大特集！2月24日発売です！#wdpress pic.twitter.com/TaHmqI7eyq
— WEB+DB PRESS編集部 (@wdpress) February 6, 2023

この特集では、すでにCSSの基本的な使い方は身につけているけどTailwind CSSについては知らない人、これから使ってみたい人、あるいはCSSの設計について改めて考えてみたいという人に向けて、その意義や使い方を解説しています。なぜTailwind CSSなのか、なぜTailwind CSSでなければならないかを解き明かすべく、ユーティリティファーストというTailwind CSSのコンセプトを中心に据えて、「まず作ってから、あとで共通化する」という考え方を掘り下げて書いています。

構成は次のようになっています。

第1章: ユーティリティファーストとは何か——従来のやり方の問題点を解決するためのアプローチ
第2章: Tailwind CSSの導入——開発環境へのインストール、設定ファイルの記述、エディタの設定
第3章: Tailwind CSSの使い方——ユーティリティクラス、修飾子、カスタムスタイル
第4章: Tailwind CSSとデザイン——より良いデザインのためにCSSはどうあるべきか

まず第1章では基礎編として、Tailwind CSSを使うことのメリットや、ユーティリティファーストという基本的なコンセプト、従来のやり方の問題を解説します。第2章ではより具体的に、開発環境へのインストール方法、設定ファイルの記述方法、エディタの設定を紹介します。続いて第3章では、ユーティリティクラスやその修飾子の使い方、カスタムスタイルの実装方法を紹介します。最後に第4章では発展編として、デザインとCSSの関係性や、CSS設計の新しいあり方を考察します。

少し前に、ブログ「CSS設計における、すべてがコンポーネントであるという誤謬」を書きましたが、それはこの特集のプロトタイピングのためでした。CSS設計について僕が抱いている問題意識をまとめたつもりでしたが、ブログに対するさまざまな反応を見るに、言いたいことはあまりよく伝わっていないようでした。

そこでこの特集においては、その問題意識をもとにしつつ、必要となる前提知識からしっかりとていねいに説明したり、議論の幅を広げたりしながら、要点やその伝え方を徹底的に整理し直しました。

その結果、Tailwind CSSを使う意味について、ほかにどこにもないような見方で解説する記事ができあがったと思います。

企画の発端は、CSSの特集を書かないかという誘いをいただいたことです。ユーティリティファーストCSSについて書いてほしいという提案もあったので、当時いろいろと考えていたことを整理してまとめることにしました。しかしそれは、僕にとってはけっこうな挑戦でした。問題は、文章の量と、取り扱うテーマの複雑さです。

この特集は全30ページで、最終原稿の文字数はおよそ4万文字です。長らくブログを書いてきてはいるものの、一本のブログがこれだけの分量になることは多くありません。

文章の量や質が変わると、同じような書き方は通用しなくなります。短くて簡単な記事であれば、とりあえず本文を書き進めながら内容を考えていくということができます。書き終わってから気になるところがあっても、また頭に戻って書き直すことを繰り返していればなんとかなります。ところが、量が増えたり、話が複雑になってくると、それだけでは収拾がつかなくなってきます。要するに、本文を書きながら考えているだけでは、頭の中で話が整理しきれないのです。

僕は基本的に、1テーマ思いつくごとに一本ブログを書くというやり方を取っています。単純に、それが簡単で書きやすいからです。しかしこの特集では、これまで蓄積してきたさまざまな考えを一挙に語る必要がありました。できるだけ網羅的で、抜け目のない議論にすることが重要だと考えたからです。加えて、入門者にも向けた特集である以上、基本的な使い方についてもカバーしなければいけません。そのため、それらをいかにして一つのつながりのある文章として成立させるかが難しいところでした。

Tailwind CSSについて語るには、いくつもの論点があります。普段であれば、そういったものは箇条書きにしたりアウトライナーに書き出したりして、自分の頭の中を整理しています。執筆当初もそのように試みましたが、今回はそれがうまくいきませんでした。なぜなら、それぞれの論点がかなり複雑にリンクし合っていて、いきなりリニアな構造として形にするには無理があったからです。とりあえず書き出してみることはできても、それはあまり理解の助けになりませんでした。

そこで、今回はHeptabaseというツールを使いました。Heptabaseでは、トピックごとにカードを作って内容を記述し、それらを二次元の座標系に並べることができます。MiroやFigJamにも似ていますが、テキストベースの情報を整理するにはHeptabaseが向いています。

これを使って、頭の中にある考えを一つ一つアウトプットしました。

思考の断片をこのように可視化することで、自分の考えの全貌が少しずつ見えてきました。頭の中から一度に取り出せる情報はごく限られていますが、少しずつ外部化していくことによって、全体のつながりが明らかになってきました。

そして、これらをもとにして記事の構成案を作成します。目次のようなものです。ここで初めてリニアな構造を意識し始めるわけですが、Heptabaseのおかげで話の種はできており、あとはその並べ方を考えるだけだったので、大きくは苦労せずに済みました。

これは例えるならば、食材を用意することと料理を作ることに似ています。まずはHeptabaseで食材を用意して、用意が終わったあとから構成案という料理を作っているのです。もし食材の用意なしにいきなり料理を作り始めていれば、料理をする片手間で食材の用意もしなければならなくなるため、どちらの仕事も疎かになってしまうでしょう。

とはいえ、実際の作業が手戻りなく進んだかというと、もちろんそういうわけでもありません。実際に本文を書き進めてみてから、当初の構成案ではうまくいかないということがわかり、引き返して手を入れることは何度か行いました。またそれに加えて、Heptabaseにだいたいのことは書き切ったと思っていても、文章の流れに促されて、想定していなかったことを新たに書く必要に迫られる場面も度々ありました。そもそも文章を書くという行為は、事前に予測不可能な発想を創発させるプロセスなのだと思います。それでも、下準備をするのとしないのでは大きな差がありました。

全体としては非常に苦労しました。最初に想定していたよりもずっと長い時間がかかってしまいました。ほかにもこのような仕事をされている方々に対しては頭の下がる思いです。

けれど最終的には、なんとかそれなりのものになりました。CSSについて考える人にとって、この特集がなにかしらのヒントなればうれしく思います。

ウルトラブースト日記

Fri, 02 Dec 2022 15:30:00 GMT

僕は右利きだが、スマホはいつも左手で使う。だから、スマホに入ったPASMOを改札機にタッチするときは毎回フラストレーションを覚える。

少し仕事の余裕ができたので、久しぶりに外に出かける。渋谷に向かうため電車に乗ると、気分が少し鬱々としてきた。そういえば僕は、電車に乗っている時間があまり好きではなかった。そんなことも忘れていた。

adidasのスニーカーを買いに来た。ウルトラブーストというランニングシューズが狙い。ランニングを始めるわけではなく、普段履きとして使うためだ。

僕は以前、ひどくスニーカーにハマっていて、今となってはちょっとどうかしていると思うほどの数を買っていた。しかしその大半はもう手放してしまった。気持ちの赴くままに手をつけていたけど、いつまでも履き続けたいと思えるものはほとんどなかったのだ。その時の気分に任せて靴を買っても、僕の気分の方はすぐに変わってしまう。でもその一方で、履き心地が好きだと思える靴は変わらなかった。当然と言えば当然かもしれない。

最近になって、ウルトラブーストというやつはすこぶる履き心地がよいという評判を目にした。そのせいで、ふたたび気持ちが昂ってしまった。見た目としても割と好きな形だった。どうやら僕はランニング用っぽい形が好きらしく、これまでもそういうものばかり買ってきた。よくあるバッシュ系は一つも買ったことがない。

店にいるスタッフは全員サッカーのユニフォームを着ていた。それがなぜなのかがしばらくわからなかった。

ウルトラブーストを見つけたので、いざ履いてみる。たしかにいい感じがする。普通の靴と大きく違うのが、アッパー全体がニット生地になっていて、大袈裟に言えば靴下みたいに足にフィットするところ。ニット生地の靴はたまに見かけるけど、総じて独特のフィット感がある。快適なものも多いけど、このモデルはちょっと着圧が強すぎる。ランニング用だからだろうけど、一日ずっと履くにはつらいだろう。

残念ながら今回は断念かと思いかけたところ、近くにあった、ウルトラブースト DNAという別シリーズが目に入った。ライフスタイル向けのウルトラブーストということらしい。手に取って調べてみると、アッパーが普通の靴とニット系の合いの子のような作りになっていた。このおかげで、強い着圧に頼らずに足をホールドできる。というのも、純粋なニットとして足をホールドしようとすると、立体的な構造として足型を包み込むことができなくて、着圧に頼らざるを得なくなるからだ。かれこれ一時間近く悩んでから、意を決してこれに決めた。

ウルトラブースト以外のスニーカーも眺めてみて、「ああ、これ欲しいな」と思うこともあったけど、もちろん買わなかった。それは自分が買うべきものではないとわかっているので。今になって考えてみると、気になったスニーカーがあっても別に買わなくてもいい。店に飾られているものを眺めているだけで十分楽しめるから。というか、むしろその時間が気持ちの一番のピークなのだと思う。それに、自分の狭い家に飾って満足するよりも、暇があるときにいろんな店を巡ってたくさんのスニーカーを見た方が多幸感がある。

その後、帰路にある「いきなり！ステーキ」に入った。この数年で、出かけた帰りには立ち寄るのが当たり前になった。普通に出社する生活になればこの習慣もなくなるかもしれない。

家に着いてから、改めて履いて外を歩いてみた。家に帰ってから冷静になると、「なんか違う」となることがたまにあるけど、幸い今回はそうならなかった。足と一体化して、肌の一部になったと錯覚するほどよくフィットするし、足の運びが本当に軽くなった。これからも長く履いていけそうなので満足している。

ブロックエディタ用のCSSを参考にした、よりよいコンテナの実装

Sun, 27 Nov 2022 07:05:00 GMT

以前、「本文エリア内の要素をpaddingのないコンテナとして実装する」という記事を書いた。本文エリア内の要素をすべて同じ幅でレイアウトするのではなく、ものによっては少し広めにしたりページの最大幅まで広げたりしたいという場合に、どのように実装すべきかという話。

その後、「【WordPress】受託開発におけるハイブリッドテーマ開発」という記事を読んで、ここで紹介されているやり方の方がシンプルでよさげに見えたのでメモしておく。

具体的には、次のような実装になる。前述の記事からの抜粋。

/* 幅広・全幅ブロック以外にデフォルトコンテンツ幅を指定 */
.entry-content > *:not(.alignwide):not(.alignfull) {
  max-width: var(--wp--style--global--content-size);
}

/* 幅広ブロックに幅広コンテンツ幅を指定 */
.entry-content > *.alignwide {
  max-width: var(--wp--style--global--wide-size);
}

/* 全幅ブロックを除いて左右にオートマージンを付与する */
.entry-content > *:not(.alignfull) {
  margin-right: auto;
  margin-left: auto;
}

ここまでは以前の記事で紹介したやり方とあまり変わらない。しかし、コンテナの外側にできる余白の実装が少し違う。

.entry-content {
  padding-right: var(--wp--custom--gutter);
  padding-left: var(--wp--custom--gutter);
}

.entry-content > *.alignfull {
  margin-right: calc(var(--wp--custom--gutter) * -1);
  margin-left: calc(var(--wp--custom--gutter) * -1);
}

最大幅の実装は個々の要素が担いつつ、外側の余白は親要素に持たせておくようになっている。そして、ページいっぱいまでに広がる要素（alignfull）は例外として、ネガティブマージンで処理されている。

参考としてTwenty Twenty-Twoの実装を調べてみると、style.cssに同様の記述があった。

.wp-site-blocks,
body > .is-root-container,
.edit-post-visual-editor__post-title-wrapper,
.wp-block-group.alignfull,
.wp-block-group.has-background,
.wp-block-cover.alignfull,
.is-root-container .wp-block[data-align='full'] > .wp-block-group,
.is-root-container .wp-block[data-align='full'] > .wp-block-cover {
  padding-right: var(--wp--custom--spacing--outer);
  padding-left: var(--wp--custom--spacing--outer);
}

.wp-site-blocks .alignfull,
.wp-site-blocks > .wp-block-group.has-background,
.wp-site-blocks > .wp-block-cover,
.wp-site-blocks > .wp-block-template-part > .wp-block-group.has-background,
.wp-site-blocks > .wp-block-template-part > .wp-block-cover,
body > .is-root-container > .wp-block-cover,
body > .is-root-container > .wp-block-template-part > .wp-block-group.has-background,
body > .is-root-container > .wp-block-template-part > .wp-block-cover,
.is-root-container .wp-block[data-align='full'] {
  margin-right: calc(-1 * var(--wp--custom--spacing--outer)) !important;
  margin-left: calc(-1 * var(--wp--custom--spacing--outer)) !important;
  width: unset;
}

settings.useRootPaddingAwareAlignmentsについての解説も参考になった。

これらの例はWordPress向けの実装になっているので、少し手を加えて、単独で実装パターンとして成立するように整理した。

<div class="entry-content">
  <!-- コンテンツ幅 -->
  <h2>Hello</h2>

  <!-- コンテンツ幅 -->
  <p>Lorem ipsum dolor sit amet.</p>

  <!-- ワイド幅 -->
  <figure class="alignwide">...</figure>

  <!-- フル幅 -->
  <figure class="alignfull">...</figure>
</div>

:root {
  --spacing-outer: max(1.25rem, 5vw);
  --content-size: 40rem;
  --wide-size: 60rem;
}

.entry-content {
  padding-right: var(--spacing-outer);
  padding-left: var(--spacing-outer);
}

.entry-content > :not(.alignwide, .alignfull) {
  margin-right: auto;
  margin-left: auto;
  max-width: var(--content-size);
}

.entry-content > .alignwide {
  margin-right: auto;
  margin-left: auto;
  max-width: var(--wide-size);
}

.entry-content > .alignfull {
  margin-right: calc(var(--spacing-outer) * -1);
  margin-left: calc(var(--spacing-outer) * -1);
}

参考までに、Tailwind CSSっぽい疑似コードも示しておく。

<div class="px-outer">
  <!-- コンテンツ幅 -->
  <h2 class="max-w-content mx-auto">Hello</h2>

  <!-- コンテンツ幅 -->
  <p class="max-w-content mx-auto">Lorem ipsum dolor sit amet.</p>

  <!-- ワイド幅 -->
  <figure class="max-w-wide mx-auto">...</figure>

  <!-- フル幅 -->
  <figure class="-mx-outer">...</figure>
</div>

マークアップのわかり方

Thu, 03 Nov 2022 04:50:00 GMT

この記事は、2022年10月28日に開催されたDIST.37「マークアップな夜」での発表「マークアップのわかり方」をもとにしたものです。当日は話せなかった内容も大幅に追加しています。

現代における「マークアップ」とはどのような行為なのか。いかにそれと向き合っていけばいいのか。そういったことについて考えてみます。

マークアップの議論においては、「マークアップには正解がない」という意見が決まって出ます。正解がないと言うならば、たいていなんであってもそうです。たとえばCSSやJavaScriptの書き方には「正解」があるのかと考えてみると、必ずしもそうではありません。

しかし、ことさらマークアップにおいてこれがよく言われる理由としては、妥当性を判断する基準がわからない、ということでしょう。

というのも、CSSなら望む通りの見た目になればとりあえずOKだし、JavaScriptでも意図した通りの振る舞いをすればまあいいだろう、という判断ができます。けれどHTMLでは、divを使おうがbuttonを使おうが、何が変わるのかがその場でわからなくてどうしようもないのかもしれません。

— Showing results for https://dist.connpass.com/event/261960/ - Nu Html Checker

HTMLにはチェッカーがありますから、もし構文エラーをしていたり、変な属性を使っていたりすれば、チェッカーから発される警告によってそのことに気づけるようになっています。それでも、すべての間違いをチェッカーで指摘できるわけではありません。

あくまでチェッカーでわかるのは、型通りに判断できるような、明確に間違いであると言える部分についてだけです。HTML仕様の定義と照らし合わせたときに、アリかナシかをはっきり言い切れる部分についてだけチェックしている、ということです。

一方でマークアップにおいては、非常に文脈的な解釈が必要になる場面があります。HTMLの性質からして、定義の幅を狭く固定するということがなされていないので、状況に応じてその場その場の個別解を導き出すことが重要になります。したがって、個々人の考えをもって正解を決めるしかないのです。

一つ例を挙げます。私の家の近所にはインドカレー屋がありますが、その周りにはいくつか立て看板のようなものがあります。そこで、店自体をウェブサイトとして、看板はウェブページとして捉えてみると、マークアップにおいてはどのように考えて判断できるでしょうか。

最初にマークアップすべきは、看板右上にあるこの店のロゴです。明らかにこれがサイトのシンボルだと思います。ウェブサイトで言うところのヘッダーなのでheaderとしつつ、その中に入るロゴは画像なのでimgです。

<header>
  <p><img src="logo.svg" alt="インド料理 ハティ" /></p>
</header>

一つポイントになるのが、そのaltの値です。ロゴとしては「HATI INDIAN RESTAURANT」と表記されていますが、altは店名として正式な表記であろう「インド料理ハティ」とします。altの書き方についてはいくつかの考え方がありますが、基本としては、その画像をそのままテキストに置き換えてもおかしくないようにしておくのがセオリーです。

altとは代替を意味しますが、ロゴにあるのと同じ文字列に置き換えることが必ずしも代替なのではありません。そもそもは、店名の正式な表記が先にあってからロゴが後からついてくる、という主従関係になっているはずです。逆説的に言えば、むしろロゴの方が代替です。

続いて看板の左上には、大きな文字で「Take Out Menu」「お弁当メニュー」とあります。ここからはページ固有の要素と言えるでしょう。外側はmainで囲いつつ、「Take Out Menu」はh1にします。

<main>
  <hgroup>
    <h1 lang="en">Take Out Menu</h1>
    <p>お弁当メニュー</p>
  </hgroup>

  ...
</main>

「Take Out Menu」の下には「お弁当メニュー」の文字があります。日本語訳を併記しているようです。これらの二行はまとめてhgroupにするのがよいでしょう。場合によっては、両方のテキストをh1の中に含めてしまうのもアリですが、レイアウトの都合を考えるとこちらがベターです。

それらに続いて「インド料理のお弁当」という見出しがあり、お弁当の種類がカード状に並んでいます。カードが六つあるので、これらをulでまとめてしまうのがよさそうに見えます。

<li>
  <p>A カレーライス弁当</p>
  <p><img src="indian-lunchbox-a.jpg" alt="..." /></p>
  <p><del>¥ 480</del> <ins>¥ 500</ins></p>
  <p>A 弁当 <span lang="en">A Lunch Box</span></p>
  <p>カレー1種・ライス<del>・ナン</del></p>
  <p lang="en">1 Curry, Rice <del>or Nan</del></p>
</li>
<li>...</li>
<li>...</li>
<li>...</li>

ところが最後の六つ目のカードを見ると、これだけ少し違った内容になっています。それ以外のカードは、「カレーライス弁当」「インド弁当」「ナン付きカレーライス弁当」という風になっているのに、六つ目のカードだけ、「ナンお持ち帰り」「ライス・麺の大盛り」とあります。

これらは情報の種類としては別物なので、別の項目に分けて扱いたいところです。同じ項目としてまとめられていると、弁当が六種類あるように勘違いしてしまうからです。

そこでマークアップとしては、六つ目のカードだけ別のリストにできるとよさそうです。しかしそうすると、CSSでレイアウトするのが難しくなってしまうかもしれません。

<ul>
  <li>...</li>
</ul>

<p><img src="indian-other.jpg" alt="..." /></p>

<ul>
  <li>
    <p>ナンお持帰り</p>
    <p lang="en">Nan Take Out</p>
    <p><del>¥ 280</del><ins>¥ 300</ins></p>
  </li>
  <li>...</li>
</ul>

ならば、display: contentsを使うのもアリです。こうすれば、レイアウト的にはulの存在が無視されて、その中のliが直接の子要素と同等に扱われるようになります。これでCSSとしても問題ないでしょう。

<div class="grid">
  <ul style="display: contents" role="list">
    <li>...</li>
  </ul>

  <div>
    <p><img src="indian-other.jpg" alt="..." /></p>
    <ul>
      <li>
        <p>ナンお持帰り</p>
        <p lang="en">Nan Take Out</p>
        <p><del>¥ 280</del><ins>¥ 300</ins></p>
      </li>
      <li>...</li>
    </ul>
  </div>
</div>

注意点としては、ulにはdisplay: contentsと同時にrole=listが指定されていることです。roleというのは、その要素がどのような役割を持つのかをスクリーンリーダーの支援技術などに対して明示するための属性です。これはHTMLとは別に、WAI-ARIAと呼ばれる仕様として定義されているものです。ulの場合、role属性を指定しなければlistの役割を持つことに決まっています。

では、なぜあえてrole=listと指定するのでしょうか。それは、現在の一部の環境においては、display: contentsを指定するとlistとして扱われなくなってしまうという不具合があるからです。ulがlistとして扱われなくなると、スクリーンリーダーのユーザーなどにとって使い勝手が良くありません。そこで、明示的にrole=listと指定することでその問題を回避できるのです。

というわけで、マークアップの際にはどういった風に考えているかという例を簡単に示してみました。それほど複雑なコンテンツではないものの、しかしながら、具体的な判断基準を言葉にしてみると、それなりにこみ入っていることがわかります。

HTMLでは、それぞれの要素などをどう使うのかは一応定義されているものの、基本的には、それによってマークアップが強く規定されるというわけではありません。定義はあるものの、緩い定義になっていて、状況に応じて柔軟な使い方ができるような余白がある。そういうイメージです。

だから、何か0か1かの判断を下せば自動的に答えが決まるわけではありません。考慮すべきさまざまな事情を踏まえて、時にはあちらを立てればこちらが立たずなジレンマを抱えながらも、それぞれの場面において最も理想的なバランスを見つけ出す。そうした姿勢が重要です。

マークアップの際に考慮すべきことは、大きく捉えると次のような種類に分けられます。

コンテンツの性質、制作者の狙い
HTMLのセマンティクス
WAI-ARIAのセマンティクス
ブラウザ・OS・スクリーンリーダーでのサポート状況、ユーザーにとっての使い勝手
CSSやJavaScriptなど周辺技術との兼ね合い、連携のしやすさ
ソースコードの運用性

まず、マークアップの対象である情報構造は人の手から生まれるものですから、そこには何かしらの意図や狙いがあるはずです。それを、HTMLにおいてどのように表現すべきかを考えてマークアップする必要があります。

関連するところとして、以前、HTMLの語彙を使って情報構造を考えるという発表をしたことがあります。そちらもご覧ください。

— 制作者のためのHTML

次に、HTMLのセマンティクスです。つまり、HTML仕様をよく理解した上でマークアップできているか、ということです。非常に基本的ではあるものの、簡単ではありません。仕様を素直に読み解くことは誰にでもできることではありません。

最近では、HTML仕様をわかりやすく正確に解説した書籍『HTML解体新書』がありますので、まずはこちらを読んでいただくのがおすすめです。

— HTML解体新書 | ボーンデジタル

続いて、WAI-ARIAのセマンティクスです。WAI-ARIAはHTMLと連携した仕様であり、スクリーンリーダーなどの支援技術に対して適切な情報伝達ができるようにすることを目的としています。

ブラウザでHTML文書を表示すると、それがDOMツリーに変換された上でページが描画されます。その際同時に、DOMツリーをもとにしてアクセシビリティツリーと呼ばれる構造が生成されています。スクリーンリーダーのユーザーは、OSを経由してアクセシビリティツリーにアクセスすることによってページを利用しています。

— Accessibility Object Model | aom

アクセシビリティツリーは、基本的にはWAI-ARIA仕様に則って生成されます。そのため、WAI-ARIAについてもよく理解しておくことが大切です。『HTML解体新書』では、WAI-ARIAについても解説されています。

WAI-ARIAの基本的なところを理解した後には、WAI-ARIAのデザインパターンに目を通してみるとよいでしょう。W3C Web Accessibility Initiativeというグループによって、WAI-ARIAを使って一般的なUIコンポーネントを実装するためのパターンが公開されています。

— Patterns | APG | WAI | W3C

そして、ブラウザ・OS・スクリーンリーダーでのサポート状況、ユーザーにとっての使い勝手について。環境によって、HTMLの機能が実装されていたりされていなかったりすることがありますが、これはWAI-ARIAにおいても同じです。仕様としては存在していても、ブラウザに実装されていないから実質使えない、ということがあります。そういったことを調べられるツールとして、Can I use…のWAI-ARIA版のようなものがあります。

— Accessibility Support

これによって実装状況を確認した後には、実際にその環境を使って検証するようにしてください。自分でもスクリーンリーダーを使ってみることが大切です。

そして、ある機能が実装されていたとしても、それがユーザーにとって使いやすいものになっているかどうかはまた別の問題です。さらに、個々の機能だけにかぎらず全体として、ユーザーは実際にどのような環境で操作しているのかを知っておくことは重要です。

そこで、実際に支援技術を利用する障害者がどのようにウェブページを利用しているかを紹介する動画が総務省から公開されています。まずはこれを見ていただくのがよいでしょう。

— 総務省｜情報バリアフリー環境の整備｜障害者のウェブページ利用方法の紹介ビデオ

加えて、実際のユーザーの利用状況についての調査結果なども公開されています。こうしたものにも目を通しておくと参考にできることがあります。

— 第2回支援技術利用状況調査報告書 | 日本視覚障害者ICTネットワーク

さて次に、CSSやJavaScriptなど周辺技術との兼ね合い、連携のしやすさです。HTMLの構造によっては、CSSが書きにくくなったり、JavaScriptでの操作が難しくなったりすることがあります。あるいは、CMSの機能やWYSIWYGからの出力、テンプレートエンジンやコンポーネントシステムの性質を踏まえて、それに適した実装方法を検討することもあるはずです。そうした考慮もマークアップの一環です。

— Introducing WordPress 6.0 - YouTube

最後に、ソースコードの運用性です。たとえば、よかれと思って複雑な仕様を実装してしまった結果、メンテナンスできないほど厄介な状態になってしまうことは珍しくありません。また似たようなところでは、無理のある運用ルールを設定して誰にも守られなくなるということもあるでしょう。そうした問題を防ぐためには、ちょうどいい塩梅を探りながら開発を進めていかなければなりません。

マークアップのアプローチとして一つ頭に入れておいてほしいことがあります。それは、たとえば何か複雑に見えるものがあるとき、必ずしもそれを複雑なまま実装する必要はなく、もっとシンプルな形にしてもよいということです。

『インクルーシブHTML+CSS & JavaScript』では、いわゆるボタンリンクの実装方法について紹介されています。いわく、ボタンリンクと本当のbuttonは、同じ見た目にせずにそれぞれ別々にしてしまおう、という話です。

— 電子書籍版インクルーシブHTML+CSS & JavaScript | ボーンデジタル

aとbuttonは、どちらも押せるという意味では同じですが、細かく見ていくと微妙に振る舞いが異なります。にもかかわらず、それらを同じ見た目にして同じコンポーネントであるように扱ってしまうのはやや乱暴です。機能的に異なるものを同じように扱うことで、制作者自身が混乱してしまうこともあります。

その解決策はシンプルです。別物なのだから、見た目としても別物にしてしまう。ただそれだけです。もともとあるHTMLの区分を無視して、無理やり別のことをしているから難しくなってしまうのです。

これまで話してきたのは、マークアップの複雑さについてです。考慮すべき要素がいくつもあるがゆえに、それらをうまく調整する手腕が問われるという話でした。一方、そのような「小難しいこと」を考えずに、ごく素朴な感覚をもってマークアップができるものの例として、利用規約のマークアップが挙げられます。

— 利用規約 - connpass

利用規約は、極めてシンプルなウェブページの代表です。これは言ってしまえば、「誰も読まないページ」でもあります。だからこそ、HTMLという形式に対して素直で作りやすく、ごく普通の形を保ち続けられるのだとも言えます。

利用規約のマークアップでは、ほとんど迷うことがありません。どのようにマークアップするかが明確で、簡単です。なぜならHTMLが、利用規約のような文書を表現するために適した形式になっているからです。

HTMLでは、情報を表現するために使える語彙があらかじめ決められています。そのため、それに合ったものは作りやすく、合わないものは作りづらくなります。どのようなウェブページを作るにしても、そこから逃れることはできません。ではそもそも、どうしてこうなったのでしょうか。

ティム・バーナーズ゠リー『Webの創成』によれば、HTMLの始まりは次のような考えで作られたと言います。

私は、あらゆる種類のデータのフォーマット形式がWeb上に存在することになるだろうと予測していた。一方で、そこには誰でもが使える簡単な共通語が必要であるとも感じていた。（中略）すなわち、メニュー、ヘルプ・ファイルのような簡単な文書、会議録、メール、すなわちたいていの人の日常生活の用事の95%をカバーするような仕事である。これが、HTMLすなわちハイパー・テキスト・マークアップランゲージである。

ウェブで扱われることになるであろうあらゆるタイプのドキュメント、それはたとえば、ビデオ、CAD、音声、アニメ、実行可能なコンピュータプログラムといったものを繋ぐための「糸」として、HTMLが機能することが期待されていました。

1991年当時のHTMLで使われていたタグは次のようなものです。

<TITLE> ... </TITLE>

<NEXTID 27>

<A NAME=xxx HREF=XXX> ... </A>

<ISINDEX>

<PLAINTEXT>

<LISTING>
	...
</LISTING>

<P>

<H1>, <H2>, <H3>, <H4>, <H5>, <H6>

<H2>Second level heading</h2>

<ADDRESS> text ... </ADDRESS>

<HP1>...</HP1>   <HP2>... </HP2> etc.

<DL>
<DT>Term<DD>definition pagagraph
<DT>Term2<DD>Definition of term2
</DL>

<UL>
<LI> list element
<LI> another list element ...
</UL>

いくつか見慣れないタグはあるものの、現在でも当たり前に使われているものがいくつも含まれているのは驚くべきことです。見出しレベルが1から6までなのも最初から決まっていました。

『Webの創成』には、続けて次のようにあります。

世界中の人々に新しい地球規模の情報システムを使わせることが困難であることは知っていたので、私はできる限りすべてのグループを議論の場にひきずり出したかったのだ。マークアップ・ランゲージという分野がすでに存在していて、standard generlized markup language（SGML）がすでに世界の文書作成に関わる人々の間で好んで使われていた。また、当時はハイパーテキスト作成に関わる人々の間でも、これが唯一可能性のある文書作成の標準システムであると考えられていた。私はHTMLを開発するにあたり、SGMLの親戚のように見えるようにつくった。

山型のついたタグという表現も、要素や属性としてデータの種類をマークアップする考え方も、SGMLを参考にしてできたものでした。しかし大きく違うのは、SGMLはその用途があらかじめ決められているわけではない、というところです。HTMLはウェブページの作成を目的とした言語ですが、SGMLはあらゆる情報をマークアップするための言語です。SGMLの作業は、個々の目的に応じた文書を分析するところから始まります。

『SGML入門』では、教科書の前付けページの構成例が紹介されています。教科書の前付けページに含まれるデータを分析して、ツリーダイアグラムとして構造を定義したものです。

— Martin Bryan『SGML入門』（福島誠訳）

教科書
- 前付け
  - 小扉のページ ¹
    - 本の表題
  - 小扉の裏
    - シリーズの表題
    - シリーズの編集者
    - 他の表題
  - 本扉
    - 表題
      - 表題の行
      - 副題 ^※
      - 版番号 ^※
      - 巻番号 ^※
    - 著者
      - 名前 ²
      - 役職 ^※2
    - 編集者
      - 名前
      - 役職
    - 文書番号 ^※
      - ISBN ⁴
      - その他
    - 発行日
    - 出版社／印刷所の情報
      - 名前 ^※
      - 住所 ^※
    - 抄録／その他のテキスト ^※
  - 本扉の裏
    - 出版社／印刷所の詳細 ³
      - 名前
      - 住所
    - 著作権の詳細
      - 発行日
      - 著作権所有者
      - 著作権の宣言
      - 初版（翻訳）の詳細
    - 印刷所のマーク
      - 印刷の詳細
        
        発行日（および前版） ^※
        
        再版日
        
        印刷所名
        
        印刷所の住所
      - 他の製作者のクレジットライン ^※
        
        植字工
        
        デザイナー
        
        イラストレーター
    - 出版目録の詳細 ^※
      - 英国図書館 ⁴
      - 米国国会図書館 ⁴
    - ISBN ⁴
  - 著者の献辞 ^※
  - 目次
  - 図のリスト ^※
  - 略語のリスト ^※
  - 序文 ^※
    - まえがき
    - 序文
    - 謝辞
    - その他

^※ オプション要素
¹ 本扉から自動的に作成可能
² 複数の著者／編集者および共作の場合もある
³ 本扉と裏のページに分けられる
⁴ 複数の箇所に現れる場合もある

もう少し親しみやすい例としては、『SGML実践ガイド』では、料理のレシピをマークアップするための要素の例も紹介されていました。

— B.トラビス, D.ウォルト『SGML実践ガイド』（学研, スリーエーシステムズSGML事業室訳）

『SGML実践ガイド』によれば、SGMLの文書を定義するに当たっては、次の3つの基本的な観点があります。

書式
構造
内容

要素のスタイルまたは体裁にもとづいてタグをつけていくことを書式タグ付けと呼びます。対象となるのは、テキスト内の一部の言葉だけを太字にする強調部分などです。表も書式に大きく依存した要素です。書式タグに頼りすぎると、データを他の目的に転用するのが難しくなります。

<head1 q='left' w='bold'>This is a heading that is quad left and
bold
<p in='1em' type='bold'>This is an indented paragraph
The author wants to <emphasis/emphasize/ this word.

次に、総称的な階層にもとづいてタグをつけていくことを構造タグ付けと呼びます。要素には、階層内の順列を表す名前をつけます。

<head1>This is a First Level Head
<head2>This is a Second Level Head
<para0>This is a high-level paragraph
<list1>This is a first-level indented list item
<list2>This is a second-level indented list item

最後に、体裁や階層構造にとらわれず、要素の内容（目的）にもとづいてタグをつけるのが内容タグ付けです。

<lesson>How to peel an egg
<intro>In this lesson, we will present the best ways to peel
two kinds of eggs.
</intro>
<obj>Successfully peel a hard-boiled egg</obj>
<obj>Successfully peel a raw egg</obj>

内容タグは使いすぎないように注意します。データとして別物であると意識しすぎて違うタグを使いたくなっても、実は、区別しなくても処理には差し支えないということがよくあるからです。

内容タグの例としては次のようなものがあります。

Techinical Manual
- <part>: Part Number
- <mod>: Model
- <chkl>: Checklist
- <cau>: Caution
Computer Manuals
- <command>: Command
- <opt>: Option
- <parm>: Parameter
- <key>: Keystroke
Training Manual
- <les>: Lesson
- <obj>: Objectives
- <ex>: Exercise
- <def>: Definition
General
- <fw>: Foreign Word
- <name>: Name
- <gl>: Glossary Word
- <xref>: Cross Reference
Periodicals
- <au>: Author
- <hl>: Headline
- <en>: End Note
- <blurb>: Blurb
Legal
- <case>: Case Cite
- <reg>: Reg Cite
- <code>: Code Cite
- <squib>: Squib

これら3つの観点をバランスよく組み合わせて定義するのが理想的であるそうです。

現在あるHTML要素と照らし合わせてみると、まさにこの3つの観点が存在することがわかります。HTML5では定義が改められたb要素やi要素なども、もとは明らかに書式タグ付けを意識しています。

先述の通り、HTMLではこうして要素を定義するフェーズは通過済みで、ユーザーが使うときには定義を参照しながらマークアップするだけの状態になっています。これはつまり、「ウェブページとはこういうものだ」という思考の枠組みが決められているとも言えます。だからこそ、それに合わせて発想しさえすれば簡単にマークアップはできるわけですが、それができなければ難儀するかもしれません。

はたまた、HTML仕様は変化し続けています。定義が決まっていると言っても不変ではありません。なぜなら、より多くのユースケースがウェブに求められているためです。時には、ユーザーが想定外の使い方をすることで新しい可能性が見い出されては、それに適応するように仕様が書き変わってきました。価値は変わりゆくものです。かつてはナシだったものが、今はアリになっている。そしてそれは、一時の逸脱によってもたらされます。

HTMLのマークアップは保守的な営みです。問題が起こらないように、意味が損なわれないように、複数の文脈を繋ぎ止める役割をします。これは見方によっては、過去と現在を接続する言語だと捉えられます。

変化は必然ですが、同時に、人は過去に依存して生きています。過去の選択が今を作っています。覆すことはできません。これを理解し、受け入れて、今を成り立たせていくことこそが、マークアップの意義であると思います。

複数の要素を重ね合わせつつ、その中で最も大きい要素に合わせて親要素のサイズを設定するCSS

Thu, 25 Aug 2022 14:00:00 GMT

複数の要素を重ね合わせるためには、従来、position: absoluteを使うことが多かった。親要素にposition: relativeを、その子要素にposition: absoluteを設定するというもの。

<div style="position: relative;">
  <div style="position: absolute;"><!-- ... --></div>
  <div style="position: absolute;"><!-- ... --></div>
</div>

しかしその場合、子要素自身のサイズに基づいて親要素のサイズを設定するということができない。CSSだけでは実現できないので、JavaScriptを使うことになる。

<div style="position: relative; height: 421px;">
  <div style="position: absolute;"><!-- ... --></div>
  <div style="position: absolute;"><!-- ... --></div>
</div>

そんなとき、position: absoluteの代わりにGridを使うと、CSSだけでこれを実現できるようになる。

<div class="wrapper">
  <div><!-- ... --></div>
  <div><!-- ... --></div>
</div>

.wrapper {
  display: grid;
}

.wrapper > * {
  grid-row: 1 / -1;
  grid-column: 1 / -1;
}

このようにすると、自ずと、最も大きい子要素のサイズに基づいて親要素のサイズが設定されるようになる。

これを使うと、たとえば、ボタンのラベルの長さが変わってもボタン自体の幅は変化しないようにすることができる。

あるいは、複数の画像がクロスフェードするギャラリーのようなUIを作成するときに、画像自体に基づいてサイズを設定することもできる。

横並びになったボタンを同じ幅で配置するCSS

Sat, 13 Aug 2022 23:20:00 GMT

複数のボタンを横並びにしつつ、それぞれのボタンが同じ幅になるように合わせたいということがある。ボタンに同じwidthを指定すれば合わせられるが、するとラベルの長さに応じた幅にできなくなる。

縦方向に並んだボタンであれば、いずれか幅の広い方に合わせることは難しくない。次のようにすれば、最も幅の広いボタンに合わせて他のボタンも配置することができる。

<div class="wrapper">
  <button type="button">Hi</button>
  <button type="button">Hello</button>
  <button type="button">Lorem ipsum dolor</button>
</div>

.wrapper {
  display: flex;
  flex-direction: column;
  gap: 1em;
  width: fit-content;
}

この例では、ボタンの幅は親要素いっぱいになりつつ、親要素の幅は最も幅の広いボタンにフィットするようになる。

横方向に並んだボタンの幅を合わせる場合でも、何かしらの方法で、最も幅の広いボタンの大きさを知る必要がある。そこで、Gridのfrが使える。グリッドアイテムの幅は等幅になるように指定しつつ、グリッド自体の幅はコンテンツに応じた幅にすることで、すべてのボタンの幅を最も幅の広いボタンに合わせることができる。

.wrapper {
  display: grid;
  grid-auto-columns: 1fr;
  grid-auto-flow: column;
  gap: 1rem;
  width: fit-content;
}

grid-auto-columnsとgrid-auto-flowを指定することで、どのように暗黙的なグリッドが生成されるかを定義できる。例のような場合、明示的なグリッドを使用すると、要素内に含めるボタンの個数に応じてグリッドの設定を変更する必要があるが、暗黙的なグリッドを使用すれば、ボタンの個数にかかわらず自ずと適切に処理されるようになる。

プロフィール画像を作り直した

Sat, 13 Aug 2022 13:40:00 GMT

僕のプロフィール画像、通称ギザギザを新しく作り直した。SVG化したいなと長らく思っていたけど、そのまま機械的に変換するのもつまらないし、せっかくなのでとマイナーチェンジを施した。

これまでのプロフィール画像

新しいプロフィール画像

線が太くなって、角が丸くなり、パスも少し単純化した。その分、線が強く見えるようになったので、色を薄くした。これによって、縮小されても多少見やすくなった気がする。

これまでのものも、新しいものも、いずれもプログラムによって線がランダムに生成されることでできている。たぶんこの元ネタになるのが、6年くらい前に実験で作っていたデモだった。

僕の今のプロフィールアイコンをSVG化したいと思って元データを探していたら、元になった6年前のデモが出てきた pic.twitter.com/ziVumDyBAp
— 全部入りHTML太郎 (@_yuheiy) August 13, 2022

これはcanvasを使って実装したもので、後にプロフィール画像を作るタイミングになってからSVG版を作った。しかし、そこで生成されたSVGを保存していなかったので、以来、必要になるたびに自分のTwitterアカウントなどからアイコンをダウンロードしてくる羽目になった。

ところで、今回どのようにしてこれを作ったかと言うと、とにかく大量のパターンを生成しては、それらを見比べて良さげなものを選ぶ、という感じ。というか、こんな単純な線に良いとか悪いとかあるのだろうか、わからない。

pic.twitter.com/96qUSzJEd9
— 全部入りHTML太郎 (@_yuheiy) August 13, 2022

そうこうしてアイコンをSVG化できたので、このサイトのヘッダー部分のアイコンとファビコンをSVGに変更した。あと、favicon.icoとapple-touch-icon、OG画像は、PNGのまま新しいものに差し替えた。ファビコンはフォールバック用にfavicon.icoも残しているというわけだ。SNS系のプロフィール画像も一通り更新したはず。

ボタンの最低幅を設定しつつ、かつコンテナが縮小してもはみ出さないようにするCSS

Fri, 12 Aug 2022 06:40:00 GMT

ボタンのラベルが短い場合でも、ボタン自体には最低限ある程度の幅を持たせたいという場合がある。そんなときには、ボタン自体にmin-widthを指定して最低幅を設定する。

button {
  min-width: 10em;
}

しかし、そのボタンを配置するコンテナの幅が、ボタン自体のmin-widthの値よりも狭くなってしまうこともある。すると、ボタンがコンテナをはみ出してしまう。

ボタンの幅をコンテナに収めるためにはmax-width: 100%が使えそうにも思えるが、min-widthの方が優先されてしまうので機能しない。そこで、min-widthの値としてmin()を使うようにする。

button {
  min-width: min(10em, 100%);
}

このようにすると、min-widthの値が100%を超えることを防げる。

後日追記: min()とすべきところを誤ってmax()と表記してしまっていたことをご指摘いただいたため、内容を修正した。

テキストの行の末尾に付随するアイコンをアイコンだけで改行させないようにするCSS

Thu, 11 Aug 2022 11:25:00 GMT

テキストの行の末尾にアイコンを付随させるというレイアウトがある。

これは、インライン整形コンテキストにおいてテキストとアイコンを並べて配置することで実現できる。

<a href="#"
  >テキストの行の末尾に付随するアイコンを…<svg><!-- ... --></svg></a
>

しかし、その空間の大きさやテキストの分量によっては、末尾のアイコンだけが改行してしまって不恰好に見えることがある。

そうした場合には、テキスト要素のパディングとアイコン要素のネガティブマージンを組み合わせることで対処できる。次のようにすると、アイコンだけが単独で改行されることがなく、常にテキストを伴って改行されるようになる。

<a class="card" href="#">
  <span class="card__label">テキストの行の末尾に付随するアイコンを…</span
  ><!--
	--><svg class="card__icon"><!-- ... --></svg>
</a>

.card {
  --icon-size: 1em;
  --icon-margin: 0.25em;
}

.card__label {
  padding-right: calc(var(--icon-margin) + var(--icon-size));
}

.card__icon {
  margin-left: calc(var(--icon-size) * -1);
  width: var(--icon-size);
  height: var(--icon-size);
}

まずテキスト要素のpadding-rightによって、アイコンとその間の余白を加えた分の空間が末尾に確保されるようになる。そしてその空間を埋めるように、アイコン要素の位置をmargin-leftのネガティブ値で移動させる。それによって、アイコンが必ずテキストの末尾に隣り合って配置されるようになる。

注意点としては、テキスト要素とアイコン要素の間にソースコード上でホワイトスペースが入らないようにすることだ。ホワイトスペースの分の幅ができると、アイコンのために確保した空間をはみ出してしまうため、改行方法が正しく制御されなくなる。

後日追記

Firefox でアイコンが .card--improved の padding を突き抜けちゃうのなんでだろう。

テキストの行の末尾に付随するアイコンをアイコンだけで改行させないようにするCSS https://t.co/29Y1SkJSDI pic.twitter.com/CuRtPZLQ9t
— トミー (@SaekiTominaga) August 12, 2022

テキスト要素にmargin-rightを使っていたら、Firefoxでこのような問題が起こってしまった。代わりに、padding-rightに差し替えると直った。理由はよくわからない……。

パディング領域よりアイコンの大きさが小さいと、まれに右下のようにアイコンが飛び出すっぽかった（ラベルの最後の文字に依存しそう） pic.x.com/eT03xm8Eq0
— ながしまきょう (@hail2u_)
August 11, 2022

これは直し方がわからなかった……。

アイコンのためにsvg要素やあるいは擬似要素を使う代わりに、テキスト要素のbackground-imageを使うとより安全だけど、その場合はアイコンの高さを1emより大きくすることができないという制約がある。

2025年1月7日追記

text-wrapプロパティを利用することで、アイコンだけで改行させないテクニックが紹介されていた。

CSS fix to prevent orphan icons dropping to a new line · Muffin Man

宣言的デザインシステム（翻訳）

Mon, 01 Aug 2022 00:00:00 GMT

この記事は、Jeremy Keith氏による「Declarative design systems」の日本語訳です。掲載に当たって著者の許諾を得ています。

「宣言的デザイン」（日本語訳）という考え方について書いたことで、多くの人々から確かな共感が得られました。

一般的な感覚として、デザインや開発において命令的アプローチを取ると、つまり、あらゆることを精緻かつ直接的に指定しようとすると、歯痒い思いをするものなのだと思います。要するに、それはスケールしないのです。Jasonの言葉を借りれば、従来のウェブデザインのプロセスは根本的に破綻しているということです——

これは最悪の事態です。ウォーターフォール型のプロセスによって何十もの成果物が作成されますが、デザインがブラウザでどのように見えて、どのように動作するのかについては、そのうちのどれも正確に捉えることができていないのです。

理論的には、この問題を打開するためにデザインシステムが役立つかもしれません。あらかじめ時間をかけてコンポーネントを正しいものにしておけば、あらゆる状況においてすばやく展開することができます。しかしこの場合、「正しい」という言葉には解釈の余地があります。

命令型の考え方でデザインシステムに取り組むと、「正しい」は「精緻」という意味になります。このアプローチでは、精緻なスペーシングに精緻な数値、精緻なピクセルなど、精緻であることに価値が置かれます。

宣言型の考え方でデザインシステムに取り組むと、「正しい」は「弾力的」であることを意味します。このアプローチでは、柔軟なスペーシングに柔軟なレンジ、柔軟な出力など、柔軟性に価値が置かれます。

これら二つは根本的に異なるデザインアプローチですが、いずれの成果もデザインシステムだと言い表されるでしょう。実際のところ、「デザインシステム」は定義することが難しい用語です。ある人が「デザインシステム」と言うと、非常に精緻に統制されたコンポーネントのコレクションを意味し、別の人が「デザインシステム」と言うと、コンポーネントを生成するためにあらかじめ用意された境界条件の集合を意味するのです。

個人的には、その「システム」という言葉こそがデザインシステムにとって重要な部分だと考えています。しかし多くの場合、デザインシステムはシステムというよりコレクションです。コンポーネントを生成するためのシステムではなく、あらかじめ生成されたコンポーネントのコレクションなのです。

宣言的デザインの核心は、システム的なアプローチです。事前にルールと比率を設定し、最終的な実装の詳細はブラウザの実行時に委ねます。

宣言的アプローチのコンポーネントとして、私が考える例を挙げてみましょう。デザインシステムのコンポーネントにおける「Hello World」とも言える、よくあるボタンを用いてみます。

二年前、Sassの色関数を代替するためのCSSプログラミングについて書きました。カスタムプロパティやcalc()といったCSSの機能を使って、darken()やlighten()のようなmixinを再現する方法について説明しました。

カスタムプロパティとしてエンコードされた色相、彩度、明度を使用して、異なる色のボタンを宣言するCSSをいくつか紹介しました。これが、さまざまなボタンの例を含むCodePenです。

もし、これらのボタンが命令的デザインシステムの中にあるとすれば、出力が重要になるでしょう。そのデザインシステムは、これらのボタンを精緻に作成するためのコードを提供するでしょう。別のボタンを使いたければ、それがバリエーションとしてデザインシステムに追加されなければならないでしょう。

しかし宣言的デザインシステムにおいては、出力は基礎となるルールセットほど重要ではありません。この場合には、次のようなルールがあります。

ボタンのホバー状態では、背景色の明度を5%下げる。

これはCSSで次のようにエンコードされます。

button:hover {
  background-color: hsl(
    var(--button-colour-hue),
    var(--button-colour-saturation),
    calc(var(--button-colour-lightness) - 5%)
  );
}

この種のデザインシステムでは、いくつかの例を見ればルールの実行結果を確認することができます。しかしこれらの出力は、理解を助けるためのものです。これだけで終わりではありません。もし必要なボタンがなかったとしても、それを生成するために必要な情報は提供されていますし、そうすると、たとえばボタンのホバー状態などについても、あらかじめ定義されたルールの範囲内に収まります。

この方がよりスケールするように思えるのです。また、より強力なアプローチだと思います。

デザインシステムを組織に取り入れる上での困難の一つは、人々にそれを採用してもらうことです。私の経験では、上層部から提供される出来合いのコンポーネント群を採用したいと思う人はいません。「この既成のコンポーネントを使えば、車輪の再発明をする時間を節約できるので便利ですよ」ということなのですが、一方、過度に支配的に見えてしまうこともあります。「あなた方が適切な判断を下せるとは思えないので、あらかじめ用意されたコンポーネントを使いなさい」という風に。

宣言的アプローチは、あまり支配的ではありません。「これはコンポーネントの作成に役立つルールとガイドラインです」ということです。しかし代償として、精緻さに欠けます。そしてこのデザインシステムを利用するためには、提供された体系的なルールから必要なコンポーネントを作成するための考え方と技能を習得しなければなりません。

私の直観では、FigmaやSketchのようなグラフィックデザインツールには命令型の考え方がよく合うと思うのです。これらのツールは、レンジやルールではなく、精緻な数値を扱います。

一方で宣言型の考え方は、ますますCSSにぴったりだと感じるようになってきました。この言語は、カスタムプロパティ、calc()、clamp()、minmax()などを通してルールを設定できるように進化してきました。

したがって言うまでもなく、このアプローチに正しいも間違いもないのです。けっきょくのところ、なにがあなたの組織にとって最も適しているかということになります。

もしデザイナーや開発者が命令型の考え方を持っていて、FigmaファイルがSource of Truthと考えられているなら、命令的デザインシステムの方が適しているでしょう。

しかし幸運にも、HTMLとCSSの観点から考えるデザインエンジニアのチームがあるとすれば、宣言的デザインシステムは力を発揮するでしょう。デザインエンジニアリングマインドのための自転車になります。

宣言的デザイン（翻訳）

Mon, 01 Aug 2022 00:00:00 GMT

この記事は、Jeremy Keith氏による「Declarative design」の日本語訳です。掲載に当たって著者の許諾を得ています。

ここ数年で、同じようなマインドセットを共有するウェブデザインのアプローチがいくつか現れたように思います。JenのIntrinsic web design、AndyとHeydonのEvery Layout、TrysとJamesのUtopiaです。

FlexboxやGrid、calcのような、CSSという技術独自の機能を活用していることも特色ではあります。しかしそれ以上に重要なのは、アプローチを共有していることです。これらはすべて、適切な「入力」を生み出すことに焦点を当てています。ありとあらゆる「出力」を制御しようとするのではなく。出力のための最終的な計算はブラウザに任せてしまう。それがコンピュータの得意とするところです。

Andyはこう言います。

ブラウザのマイクロマネジャーではなく、メンターになること。

Jim NielsenはUtopiaのアプローチを振り返って、次のように書いています。

CSSは「宣言的」だとは言いますが、ビューポートの範囲全体に渡って、デザインをさまざまな方法で変更するためにブレイクポイントを追加すればするほど、命令的なコードを書いているように感じます。一連の宣言的なルールが命令的な操作に見えてくるのはいつからでしょうか？

これに対してUtopiaの原則の一つは、宣言的であること、つまり「どのようにするかを指示するのではなく、なにをするかを記述すること」です。Utopiaのアプローチでは、任意のビューポート幅における文字サイズとスペーシングを数式で導き出す、というルールを宣言しています。

宣言的！　これこそ、UtopiaとEvery Layout、Intrinsic web designが共有するものを表現できる言葉なのかもしれません。

宣言的デザインがあるのなら、命令的デザインもあるのでしょうか？　それなら、命令的デザインのためのツールや技術はどのようなものでしょうか？

私が思うに、Tailwindは命令的デザインのうまい例です。これは特定の出力をするためだけのものです。システム的な思考は積極的に排除され、代わりに、画面に最終的に表示されるピクセルをどうしたいかを精緻に示すことになります。

Utopiaのような宣言型ツールが正しく、Tailwindのような命令型ツールが間違いだと言っているわけではありません。言うまでもなく、場合によります。それはあなたの考え方次第です。

もしこの意見に賛同するなら、おそらく命令型デザインツールを使うべきでしょう——

CSSは破綻しているので、CSSの性質をツールによって回避したい。

逆にこの意見に賛同するなら、おそらく宣言型デザインツールを使うべきでしょう——

CSSは素晴らしいので、CSSの性質をツールによって増幅したい。

もしあなたが最初の意見に賛同するなら、UtopiaやEvery Layoutのような宣言型ツールを使おうとしたとき、おそらく嫌な思いをするでしょう。たぶん嫌いになるでしょう。そのツールは「悪いもの」だと断定してしまうかもしれません。

同様に、もしあなたが二つ目の意見に賛同するなら、Tailwindのような命令型ツールを使おうとしたとき、おそらく嫌な思いをするでしょう。たぶん嫌いになるでしょう。そのツールは「悪いもの」だと断定してしまうかもしれません。

そのツールの背後にある哲学が、自分の哲学と一致するかどうかにかかっているのです。哲学が一致すれば、そのツールは生産的になり、知性の自転車として機能するでしょう。しかし、ツールの哲学が自分の哲学と一致しなければ、いちいちツールとけんかすることになり、足手まといになるでしょう。

宣言型ツールと命令型ツールの間にこのようなスペクトルが存在することを知っておくと、技術を評価するときに役立ちます。あるウェブデザインツールが売り込まれているときに、それはCSSが破綻していることを前提としているのか、それともCSSは素晴らしいということを前提としているのか、評価することができるのです。

ウェブデザインや開発についての方針も、このスペクトルのどちらに共感するかに関わってくるのではないでしょうか。たとえば、HTMLやCSSのような宣言型言語を学んできた人なら、Intrisic web designが響くかもしれません。しかし、JavaScriptのような命令型言語が得意な人には、Tailwindの方がより理にかなっているかもしれません。

ここでも、どちらが正しいということはありません。考え方とツールとの適正についての話です。

個人的には、宣言的デザインのアプローチは、グローブのように私にフィットしています。JohnのA Dao Of Web DesignやEthanのResponsive Web Designのような、ウェブの木目に沿って作業するという伝統的な流儀を受け継いでいるような気がするのです。

「宣言的デザインシステム（翻訳）」に続きます。

本文エリア内の要素をpaddingのないコンテナとして実装する

Sat, 30 Jul 2022 16:30:00 GMT

後日追記: このやり方の改良版をブログ「ブロックエディタ用のCSSを参考にした、よりよいコンテナの実装」として書いた。

CSSにおいて、コンテナと呼ばれるパターンがある。たとえば次のような実装を指している。

.container {
  box-sizing: content-box;
  margin-right: auto;
  margin-left: auto;
  padding-right: 1.25rem;
  padding-left: 1.25rem;
  max-width: 60rem;
}

この実装の特徴は、ビューポートの幅が広いときには要素の内容物が中央揃えになり、狭いときには左右に最低限の余白を残しつつ縮むことだ。

よくある使い方としては、このコンテナでページの外側の方を囲いつつ、その中に雑多に要素を配置していくことになる。

<div class="container">
  <h2><!-- ... --></h2>
  <p><!-- ... --></p>
  <p><!-- ... --></p>
</div>

しかし、このコンテナの幅よりも広い幅で何かを配置したいという場合には、コンテナの中に配置すると都合が悪い。そういう場合には、そのコンテンツをコンテナの外側に配置できると望ましい。

<div class="container">
  <h2><!-- ... --></h2>
  <p><!-- ... --></p>
  <p><!-- ... --></p>
</div>

<figure class="wider-than-container"><!-- ... --></figure>

<div class="container">
  <p><!-- ... --></p>
  <p><!-- ... --></p>
</div>

ただし、いつでもこのように自由にHTMLを構成できるとは限らない。

たとえば、CMSによってユーザーに入力された記事の本文部分を表示する場合。出力されるHTMLの形式はある程度決まっていて、カジュアルに変更するのは難しいときがある。

前述の例の場合、HTMLとしては次のような形を取らざるを得ないかもしれない。

<div class="container">
  <h2><!-- ... --></h2>
  <p><!-- ... --></p>
  <p><!-- ... --></p>
  <figure class="wider-than-container"><!-- ... --></figure>
  <p><!-- ... --></p>
  <p><!-- ... --></p>
</div>

CMSから出力されるHTMLを、コンテナの幅ごとに分割することはできないので、このままの構造に従ってスタイルを適用しなければならない。

その場合、こうした本文エリアの全体をコンテナで囲ってしまうと、幅の実装をするのが難しくなる。そこで、その代わりとして、出力されるHTMLに含まれる要素の一つ一つに直接幅を指定する、というやり方がある。

<div class="prose">
  <h2><!-- ... --></h2>
  <p><!-- ... --></p>
  <p><!-- ... --></p>
  <figure class="wider-than-container"><!-- ... --></figure>
  <p><!-- ... --></p>
  <p><!-- ... --></p>
</div>

.prose > * {
  box-sizing: content-box;
  margin-right: auto;
  margin-left: auto;
  padding-right: 1.25rem;
  padding-left: 1.25rem;
  max-width: 60rem;
}

.prose > .wider-than-container {
  max-width: 75rem;
}

こうすると、幅に関する実装が簡単になる。

しかし、要素にpaddingが適用されていると、別のスタイルとの組み合わせに支障をきたすことがある。

たとえば、見出しに下線が引かれているようなあしらいを実現するためにborder-bottomを使うとすれば、下線の描画範囲がpaddingのせいで左右に余計に広がってしまう。また、背景色がついている要素などの内側でpaddingを使いたくても使えなくなってしまう。あるいは、position: absoluteを使って、要素の相対位置に何かを配置したいというときに、X軸の基準位置が外側にずれてしまう。

こうした問題は、何かしらのテクニックによって回避できるかもしれないが、少なくともpaddingがないに越したことはないだろう。

そういったわけで僕は、あえてpaddingを使わずにコンテナを実装することがある。次のような感じだ。

.container {
  --_container-margin: 1.25rem;
  margin-right: auto;
  margin-left: auto;
  width: calc(100% - var(--_container-margin) * 2);
  max-width: 60rem;
}

これを応用すると、本文エリア内でも要素の幅が異なるような実装ができる。

<h1 class="container"><!-- ... --></h1>

<div class="prose">
  <h2><!-- ... --></h2>
  <p><!-- ... --></p>
  <figure><!-- ... --></figure>
  <p><!-- ... --></p>
  <figure class="alignwide"><!-- ... --></figure>
  <p><!-- ... --></p>
  <figure class="alignfull"><!-- ... --></figure>
  <p><!-- ... --></p>
</div>

.container {
  --_container-margin: 1.25rem;
  margin-right: auto;
  margin-left: auto;
  width: calc(100% - var(--_container-margin) * 2);
  max-width: 60rem;
}

.prose > :not(.alignfull) {
  --_container-margin: 1.25rem;
  margin-right: auto;
  margin-left: auto;
  width: calc(100% - var(--_container-margin) * 2);
  max-width: 45rem;
}

.prose > .alignwide {
  max-width: 60rem;
}

具体的なイメージが伝わりやすいように、もう少し複雑な、よくある記事ページの実装例も用意した。

Re: #deisui_html_radio #52

Wed, 15 Jun 2022 04:24:00 GMT

これについて超絶走り書きで簡単に返すのでお許しください。

Play

僕が言いたかったのは、figmaで言うと、figma用のコンポーネント機能があるじゃないですか。デザインしていて普通コンポーネントだと考えるのはそれだと思うんですよ。たとえばあるページに、中央揃えになったボタンがあるとして、コンポーネントと言えるのはそのボタンそのものだけで、どうやって中央配置にするかということは蚊帳の外というか、コンポーネントとはまた別の観点になる。多くの場合、そこにはコンポーネントのように明文化されたルール、制約はなくて、なんでもありになる。遊びがあるという状態。けど、実質的に、セオリーからすると、だいたいこうレイアウトするよねっていう暗黙のルールがある。でもこれは必ずしも確かなものではなくて、ケースバイケースに判断を変えることが許されている。そういう意味で、偶然そうなっているだけでしかない、ということが言えると思います。そこで、css設計ではその遊びをどう解釈するかという問題がある。

テキストコンポーネントの話について言うと、figmaのただのテキストレイヤーをコンポーネントと理解するのはcss脳というか、偏った捉え方だと思う。テキストスタイルとしてルールを定義することはあるにしても、これもまたすべてがそうではなくて、例外もある。そのとき、それがどうしてそうなっているかという意図を求めたとしても、この状況においてはこうなるべきだからという以上の答えが出てこない、というか必要ない。後で本当に必要になったらそのとき考えればいい。そういう場面があるはずなんです。そういうものをcssにおいてもそのまま表現できる手段が欲しいよねと。

CSS設計における、すべてがコンポーネントであるという誤謬

Sat, 11 Jun 2022 10:55:00 GMT

後日追記: WEB+DB PRESS Vol.133でさらに詳しく書いた。

BEMによってもたらされた、コンポーネントベースのアプローチでは、「ページはコンポーネントの集合によって表現されるべきであり、ページに含まれるのはすべてがコンポーネントである」と考える。しかしこれまでCSSを書いてきた経験から、これではデザイン意図をまともに表現することができないと感じ始めた。なぜなら、普通デザイナーはページのすべてがコンポーネントであるとは考えないからだ。

もちろんページの構成要素のなかには、明らかにそれが「コンポーネント」であると意識して作られたものもある。ただしそれは一部であり、全部ではない。「コンポーネントもあれば、コンポーネントではないものもある」という感覚のほうが普通なのだ。

典型的なUIライブラリにある、「ザ・コンポーネント」みたいなものだけではページは完成しない。例として、一貫してBEMに則って実装されている、BEM公式サイトにあるMethodologyのページのコードを見てみれば、「これは本当に僕らが頭のなかに思い描くコンポーネントなのだろうか？」という疑問が浮かぶ。すべてがコンポーネントであるとはこういうことだ。本当に確信をもって、「これこそがコンポーネントである」と認識ができるのは一部分でしかない。

僕は以前までは、あくまでCSS設計の作法に則って、すべてをコンポーネントとして表現しようと努めてきた。デザイナーが作ったデザインカンプからルールを見い出して自分なりに解釈し、ページに境界を引いて、名前をつけてコンポーネントとして分解する。これを隅から隅まで徹底した。その甲斐あってか、この設計はある程度は機能しているかに思えた。

しかしある時、テンプレートの条件分岐が増えて、複雑な仕様になっていくにつれて、なんとなくうまくいかない感じが浮かび上がってきた。たとえばそれは——

ひとつのコンポーネントとして表現していたセクションが分かれて別々の箇所に配置されることになったので、コンポーネントをふたつに分解して作り直すことになったり
だいたい同じような感じだけど、微妙に違う——それも偶然似ているだけなので共通化できないパターンが登場して、個別にコンポーネントを何種類も作ることになったり
部分的に見るとこれまで繰り返し何度も登場しているように思えるスタイルなのに、コンポーネントとしては別物なので、都度新しくコンポーネントを書き足さないといけなかったり
本当にちょっとした要素を追加するために、ちょうどいい既存のコンポーネントが存在しなければ、わざわざそれだけのために新しいコンポーネントを作ることになったり

というようなわけで、見た目にはたいしたことのない変化のために、結果として、割に合わない膨大な数のコンポーネントができあがってしまった。これはきっと、なにかが間違っている。

問題は、すべてがきっちりとコンポーネント化されたデザインができていないこと、ではない。デザインとコードとで、ルール化の観点がズレていることだ。

この場合、CSS設計上のコンポーネントの多くが、デザイナーの頭のなかにあるイメージと非対称的な構造になっている。エンジニアの頭のなかにしかない、元のデザインを独自に解釈した「別物」を作り出してしまっている。つまりこれでは、変更に対応できるかという以前に、現状に対応できていない。今のデザインが正しく表現されていない。

たまたま近くにあっただけのものをひとつのコンポーネントとしてまとめたり、偶然そうなっているだけのものに意図を見い出して抽象化したりして、変更が発生してから、間違った構造化がなされていたことに気づく。あるいは、もっと細かなルールが見落とされてしまう。こうした取り違えが、コンポーネントありきの発想によって誘発される。コンポーネント化するということは、解釈を加えることだ。だから、変更に対応するたびに、間違った解釈を修正するという不必要な痛みが伴う。

CSS設計は、コンポーネントというものに固執しすぎていた。

つまりこれは、実装技術側の方法論的問題だ。すべてをコンポーネントにするアプローチ自体に無理がある。本当にそれがコンポーネントだと言い切ることができなかったとしても、コンポーネントとして表現する以外にやりようがない。これが設計を歪ませるのだ。ではどうするか。

ページはもっと「一緒くた」になっていると考えていいと思う。不可分な要素もあって然るべきであり、必要を超えた構造化は害になる。その方が現実に即している。

コンポーネントとは別に、より即物的な表現方法が必要だ。そういう意味でも、ユーティリティファーストなのだ。今やBootstrapでさえ、ユーティリティファーストとまではいかなくても、大量のユーティリティクラスを取り入れている。

ビジュアル的な観点では、デザインルールはコンポーネントごとに「区切られている」わけではない。サイト全体など特定のコンテキストにおいて一貫した印象を与えるために、意図的に共有している要素がある。それはたとえば、タイポグラフィや余白、色やグラデーション、形状や影といったもの。ページ上のあらゆる要素は、コンポーネントであるかどうかという以前に、基本としてこれらのマナーに則っている。

だとすれば、セレクタという観点においても、これらそのものを直接的に指し示すクラスがあってもいいはずだ。わざわざコンポーネントのクラスを経由する必要はない。必ずしも「セマンティック」なクラス名でなかったとしても、これもまたひとつのルールである。

本文のタイポグラフィとCSS

Fri, 27 May 2022 00:00:00 GMT

yuheiy.com-v6

Tue, 03 May 2022 13:50:00 GMT

このウェブサイトをリニューアルした。これまでも何度かリニューアルを重ねてきており、今回でバージョン6ということになる。サイトとしては今年で7年目。

ブログを組み込んだのはひとつ前のバージョン5からだ。それ以前は、1ページしかないただのリンク集のようななにかでしかなくて、ブログを書くときには外部のブログサービスを使っていた。その方が、考えないといけないことが少なくて済む。でも、ずっとやってるとそれに飽きてきた。やはりブログも自分で作った方が楽しいと思ったので、こうして丸ごとサイトに含めることにした。

そして、それから2年弱くらいこのサイトを運用してきて、そろそろ作り直したい気持ちになってきた。前回リニューアルしたときから少し僕の考え方が変わっているし、技術的にもいろいろ試したいものが出てきたので、ちょうどまとまった時間が取れたこの連休でリニューアルした。

まず、サイト全体としてかなり質素なスタイルにした。かつ、ページの構成要素も最小限に。ブログにとって重要なのは、その内容について参照するために、どこからかリンクされることであって、それに当たって余計な要素はできるだけ排除したかった。サイトとしてのナビゲーションとか、そのサイトらしさみたいな、サイトとしての都合、つまり単一リソースとして見たときに関係のない部分は不要だということだ。

そう考えると、ブログにはサイトのタイトルすら不要に思えるが、これは残すことにした。ブログという情報を解釈する前提として、それを「誰が言っているのか」という点は欠かせないからだ。同じことを言っても、それを誰が言うかによって意味は違ってくる。どういった背景を踏まえた意見なのかが異なるから。このサイトでは筆者の名前がそのままサイト名になっているので、ページの上部にそれを配置した。

次に、前のバージョンでは文字のジャンプ率がやや高めになっていたが、あまり差をつけすぎないように変更した。こういったコントラストは基本的に読み飛ばしを助長する方向に働く。読まずにわかった気にさせる。そもそもウェブはそういうものだと言われるかもしれないが、少なくともこの場所ではそれに抗っていたいと思う。

技術的な部分での変更点はいろいろあるので、箇条書きで簡単に挙げてみる。

EleventyからAstroに移行
NetlifyからVercelに移行
Value DomainからGoogle Domainsに移行
Tailwind CSSを導入
ダークモード対応
- セマンティックな色指定ができるようにTailwind CSSを設定
カラム幅を文字サイズの整数倍にするようにした
:visitedのスタイルを追加
viewport-fit=coverを適用
コードブロック内でのシンタックスハイライトを有効化
マークダウンファイル内に記述した<img>要素にwidth/heightとdecoding=async属性を自動で付与するようにした
<title>要素にサイトタイトルを含めないようにした
ホームに最新記事のリストを追加

詳しくは、GitHubリポジトリを参照してほしい。

また言うまでもなく、至るところでHail2uとterkel.jpの影響を受けている。

Tailwind CSSで引数のあるMixinのような仕組みを作る方法

Mon, 21 Mar 2022 08:35:00 GMT

後日追記: このブログの内容を再考して「Tailwind CSSで引数のあるMixinのような仕組みを作る方法（改）」として書き直した。

Sassでは、引数の値に応じて宣言をクラスに注入できるMixinの機能がある。たとえば次のようにすれば、フォントサイズがビューポートの幅に応じて流動的に変化するように実装できる。

@function rem($px) {
  @return ($px / 16 * 1rem);
}

// https://www.smashingmagazine.com/2022/01/modern-fluid-typography-css-clamp/
@function fluid-size($min-size, $max-size, $min-width: 640, $max-width: 1280) {
  $v: (100 * ($max-size - $min-size)) / ($max-width - $min-width);
  $r: ($min-width * $max-size - $max-width * $min-size) / ($min-width - $max-width);

  @return clamp(#{rem($min-size)}, #{$v * 1vw} + #{rem($r)}, #{rem($max-size)});
}

@mixin fluid-text($min-size, $max-size, $min-width, $max-width) {
  font-size: fluid-size($min-size, $max-size, $min-width, $max-width);
}

h1 {
  @include fluid-text(32, 64);
}

Tailwind CSSを使う場合でも、独自のプラグインを実装することで似たような仕組みが実現できる。

Tailwind CSSによってデフォルトで提供されているクラス群は、内部的には、すべてプラグイン機構を使って実装されている。プラグインの設定によって、クラス名のプリフィックスを決めたり、受け取った値に応じてどのような宣言を適用するかの処理をしたりしている。

プラグインはユーザー側でも簡単に作成できるようになっている。tailwind.config.jsに次のようなコードを書いていくだけだ。

const plugin = require('tailwindcss/plugin');

module.exports = {
  plugins: [
    plugin(function ({ addUtilities, addComponents, e, prefix, config }) {
      // Add your custom styles here
    }),
  ],
};

上記のコード例は公式ドキュメントからの引用。APIについても公式ドキュメントで解説されているので、適宜参照されたし。

これを使って、冒頭で例示したMixinのようなものを実装してみる。次のようなクラス名を記述することで意図した機能が実現できるようにする。

<div class="fluid-text-[24px,32px]">...</div>

プラグインのAPIにあるmatchUtilities関数を使うと、特定のクラス名の後ろ側に付与された値に応じてユーティリティクラスを生成する仕組みができる。

const fluidText = plugin(function ({ matchUtilities }) {
  matchUtilities({
    'fluid-text': (value) => {
      const [minSize, maxSize] = value.split(',').map((v) => {
        const matched = /^(\d+)px$/.exec(v);
        if (!matched) {
          throw new Error(`"${v}" is not a valid value`);
        }
        return Number(matched[1]);
      });

      return {
        'font-size': getFluidSize(minSize, maxSize),
      };
    },
  });
});

[]で囲われた文字列はそのままプラグインに渡される。,で区切られた箇所も、配列に変換されたりするわけではなく、単純に45rem,2remという文字列を受け取ることになる。その文字列をプラグインの実装で分割する。便宜上,で区切っているだけであって、このルールはどこかで決まっているものではない。

そして、このプラグインを使えば、次のようなCSSが生成される。

.fluid-text-\[24px\2c 32px\] {
  font-size: clamp(1.5rem, 1.25vw + 1rem, 2rem);
}

tailwind.config.jsの全体のコードは次のようになる。

const plugin = require('tailwindcss/plugin');

const rem = (px) => `${px / 16}rem`;

// https://www.smashingmagazine.com/2022/01/modern-fluid-typography-css-clamp/
const getFluidSize = (minSize, maxSize, minWidth = 640, maxWidth = 1280) => {
  const v = (100 * (maxSize - minSize)) / (maxWidth - minWidth);
  const r = (minWidth * maxSize - maxWidth * minSize) / (minWidth - maxWidth);

  return `clamp(${rem(minSize)}, ${v}vw + ${rem(r)}, ${rem(maxSize)})`;
};

const fluidText = plugin(function ({ matchUtilities }) {
  matchUtilities({
    'fluid-text': (value) => {
      const [minSize, maxSize] = value.split(',').map((v) => {
        const matched = /^(\d+)px$/.exec(v);
        if (!matched) {
          throw new Error(`"${v}" is not a valid value`);
        }
        return Number(matched[1]);
      });

      return {
        'font-size': getFluidSize(minSize, maxSize),
      };
    },
  });
});

module.exports = {
  // ...
  plugins: [fluidText],
};

プラグインを使えば、ほかにもいろいろなことができる。少なくとも、Tailwind CSSがデフォルトで提供しているようなことはすべて実現できる。corePlugins.jsの実装を眺めてみてもらえればイメージしやすいと思う。公式プラグインの実装も参考になる。

ブックマーク代わりにツイートしていた7000件のURLを精査してEvernoteに移行した

Sat, 12 Mar 2022 16:30:00 GMT

なにか気になったウェブページを保存したいというとき、以前ははてなブックマークを使っていた。たぶん2017年くらいまで。

しかし当時のそのインフラ的な事情か、ブックマークをしようとしてもエラーが発生してできない場面が頻発していた。いや、実際そこまでの頻度ではなかったのかもしれないが、僕がそこそこヘビーユーザーだったために出会す機会が多かった気がする。いずれにせよ、それが嫌になって徐々にはてブを使わないようになっていった。

代わりに、気になったページはTwitterでシェアするようになった。自分用ブックマークを兼ねたシェア。ツイートはすぐに流れていってしまうので記録にはならないと考えるのが普通だと思うけど、僕の場合は、自分の過去のツイートを検索して見つけるという使い方をしてきた。

たとえば、「Buttons shouldn’t have a hand cursor」みたいな記事があったなと思えば、「from:_yuheiy cursor」辺りのクエリで調べれば見つけられる。ただこれをやるには、記事タイトルにわかりやすいキーワードが含まれていたり、けっこう精度高くタイトルを覚えていたりしないといけない。

僕はこういう情報の手がかりを人より多少覚えているほうなので、ある程度はこの運用でなんとなかってきた部分があったけど、とはいえ見つけられなかった場面も多い。だからこのやり方をこの先も続けていくには無理があるなと思いつつも、別のやり方に乗り換えるのが面倒くさくて先延ばしにし続けていた。けれど、さすがにそろそろなんとかしようという気になってきて重い腰を上げることにした。

まずは移行先のサービスを選定する。過去の記録を掘り返すために検索性能を重視しつつ、オープンに記録するには微妙なものもあるのでこれからはプライベートなスペースを選びたい。そこで候補になるサービスとして、記録したページの全文検索ができる「Pocket」「Evernote」「Notion」という3つを挙げてみた。

Pocketははてブと同じくブックマーク専用ツール。EvernoteとNotionはざっくり言うと文書全般を扱う汎用ツールという感じで、ページを記録するためにはそれぞれにあるWebクリッパーという機能を使う。Webクリッパーでは、ページのコンテンツをスクレイピングしてアーカイブすることになるので、もし記録したページが消滅しても参照し続けられる。Pocketの場合でも、有料会員なら永久保存ができる。どのサービスでも、ページを丸ごと保存するというわけではなくて、本文らしき領域を自動的に判別して、簡易的な形式で取り込んでくれる。

また、EvernoteとNotionではWebクリッパーでスクレイピングのアプローチが違う。

いずれもブラウザ拡張をインストールした上で使うのだが、Evernoteの場合はそのブラウザでそのまま見えている状態を記録する。たとえば、開発者ツールでページの内容を書き換えてからWebクリッパーを実行すると、書き換えた後の内容が記録されることになる。ログインが必要なページなどを開いている場合でも同様で、ログインしないと表示できないようなコンテンツも記録できる。また保存形式を選ぶこともできて、ページを丸ごと保存するか、記事として簡易的な見た目で保存するか、たんにブックマークにするか、などを選べる。

一方Notionの場合、Webクリッパーを実行すると、ユーザーの手元のブラウザ経由でスクレイピングするのではなく、表示中のページのURLをNotionのWeb APIに送信して、URLだけを手がかりにしてスクレイピングする。したがって、ログインが必要なページのコンテンツを記録することができない。

検索機能についても比較してみる。いずれも全文検索が強みに思えるが、Notionの場合、キーワードがマッチする箇所ごとに1件の検索結果として表示されるようになっている。たとえばひとつのページに「cursor」というキーワードが18回登場する場合、検索結果としては同じページが18件分表示されることになる。これではかなり探しづらい。マッチする箇所をひとつひとつ確認したいわけではなくて、先に目当てのページを見つけたいがために検索するわけなので、フォーカスする粒度が合っていない。PocketとEvernoteでは、同じページが検索結果に複数回登場するということはない。

こういった尺度で検討してみて、最終的にはEvernoteに移行することに決めた。Notionは検索機能の面で無しとして、Pocketと比べたときに、Evernoteではログインが必要なページでも保存できるようになっていることと、それにかぎらずあらゆるものをストックするのに向いた設計になっていることが決め手になった。

そういうわけで、これからのブックマークはEvernoteで記録していく、ということでもいいのだが、僕としてはこれまで長きにわたってツイートしてきた大量のページたちをなかったことにするのが惜しいので、どうにかして移行したい。検索機能が強化されればもっと有用に役立てられるリソースも増えるはずなので。しかし正当なやり方はたぶんないので、泥臭くやっていく。

まず最初に、これまでの全ツイートのアーカイブをダウンロードする。Twitterの設定画面から「データのアーカイブをダウンロード」をリクエストすると、24時間くらい経ってから、アカウントのあらゆるデータが含まれたファイルをダウンロードできるようになる。

アーカイブはHTMLでできたSPAになっていて、ブラウザで開くとビューアーとして機能する。ツイートのXMLやJSONが含まれているわけではないけど、いちおうツイートのデータだけを含んで切り出された次のようなJavaScriptのファイル（data/tweet.js）があるので、それをもとにしていろいろ処理していく。

window.YTD.tweet.part0 = [
  { ... },
  { ... },
  { ... }
]

まずはこの中から、ツイートしたURLのみを抽出したい。Twitterではツイートの本文データの中にURLもいっしょに含まれているので、URLのみを抽出するためにはTwitter公式のパーサーであるtwitter-textを使う。

すると、これまでの全67000件のツイートのうち、25000件にURLが含まれていた。体感的にこれは多すぎるなと思って確認してみたところ、リツイートや画像ツイートの分のURLも含まれてしまっているようだ。これらは不要なので除去する。

ツイート本文内に保存されるURLはすべて「https://t.co/」から始まるTwitter用短縮URLになっているので、目的のURLを判別するためにひと通りリダイレクト先のURLに加工する。その後、「https://x.com/」から始まるURLを除去するという流れ。それに加えて、これまでにツイートしたURLの中で重複するものも除去した。

この時点で15000件になった。ページの内容を時系列で飛ばし飛ばしに確認してみて、古いものにはあまり価値がなさそうだなと判断したので、ざっくり半分くらいを捨ててしまって、残りが7000件くらいになった。

これで残ったものはひと通りEvernoteに登録していきたいところだが、どうやらEvernoteのWebクリッパーには公開Web APIのようなものがないらしい（ちなみにNotionのほうにもなかった）。したがってここから先は手動でやるしかない。Puppeteerとかを使ってブラウザ拡張を自動操作したら無理ではないかもしれないけど、それも簡単ではなさそうなので、今回はこれまでツイートしたURLを振り返る意味もあって自分で登録していくことに決めた。

残った7000件のURLはすべてTextwellに放り込む。Textwellにはテキストを処理するためのアクションという機能が用意されていて、ユーザーがJavaScriptをスクリプトを記述することで新たなアクションを登録できるようになっている。これを使って、「上から20行分のURLをブラウザで開いて、その後それらのURLは削除する」というアクションを作成する。後はそれを実行して、開いたページを処理しては、その後はまたアクションを実行する。これを最後までやる。

これが一番時間がかかって精神的苦痛も伴う作業で、数日では到底終わらない。ひとつひとつのページにざっと目を通して、いらなさそうなものはスルーして、後で見返したい気がするものは保存する。懐かしい気持ちになったりしてちょっと楽しくはあるが、いかんせん量が多すぎるので、まあ大変だった。こういう作業に向いてないからプログラマーをやっているのだ。

ちなみに、Textwellの代わりにシェルスクリプトでも同じようなことはできるのだけど、あえてTextwellを使っていることには理由がある。僕はいつもメールとかSlackとかのために作文するときにはTextwellを使っているのだが、そのTextwellを大量のURLで占拠してしまうとそうした普段の作業がやりにくくなるので、嫌でも気になって早く終わらせようという気持ちになる。これをもし差し障りのないようなところに置かれたテキストファイルで管理していたとすれば、半端なところで投げ出してしまっていたに違いない。

しかしその間いろいろ忙しかったりもしたので、けっきょく1ヶ月半くらいかかってしまった。それでも、すでに何度もEvernoteの検索機能と大量の記録に助けられたので、結果オーライだと思う。保存件数は1000件くらいになった。

加えて、ブラウザの余計なブックマークも減らすことができた。ツイートで済ませてしまうと後から探せなくなる不安が大きいので、いちおう保険としてブラウザのブックマークにも保存しておくかという気になっていたが、Evernoteだと検索性能がかなり信頼できるので、余計な不安を払拭できた。

ところで、僕がなぜこれまで執拗にブックマークにこだわるのかというと、偶然に任せることでしか摂取できない種類の情報というのがあるからだ。Googleで検索できる情報というのは所詮自分が多少なりとも知っていることだけで、関知しないことについてはキーワードがわからないので調べようがない。だいぶ検索精度が上がっているとはいえ、ゴミも増えている。だから、外部から供給される情報を受動的に浴び続けられるようなチャンネルに接続して、自分が意図しない情報に偶然出会う機会が重要になる。これがなければ能動的な探究もうまくできない。

そうした場で、少しでも気になる情報に巡り合ったときには、後から振り返ることができるように記録しておかなければならない。今すぐには十分理解できないなと思うような時こそなおさら。後から必要になる時が来るからだ。その時に、「無知の知」として機能する。昔偶然見つけたブログが、自分にとって見ず知らずの領域に立ち入るための入り口になるからだ。

Utopiaを実際の案件で使ってみて、うまくいったことといかなかったこと

Sun, 23 Jan 2022 16:35:00 GMT

少し前に担当したウェブサイト制作の案件で、Utopiaというツールを使ってみた。Utopiaを使うと、ビューポートの幅に応じて流動的に変化するフォントサイズとスペーシングの値のセットを生成できる。

— Designing with fluid type scales | Utopia

レスポンシブデザインのパターンとして、ビューポートの幅が狭ければテキストのフォントサイズは小さめで、広ければ大きめにしたい、という場面がよくある。そうしたとき、フォントサイズを変更するために、ブレイクポイントごとに値を上書きする設定をしていくと、組み合わせ地獄になってデザインルールが非常に複雑化してしまう。フォントサイズの数とブレイクポイントの数がかけ合わさった分のルールが生まれて、後から整理しようとしても手に負えない状況になる。

この組み合わせ地獄を回避するために、Utopiaのアプローチでは、まずフォントサイズを実際のピクセル数ではなく、ステップとして捉える。そのステップと対応する実際のフォントサイズは、ビューポートの幅に応じて自動的に導出される、という考え方になる。

CSSにおいては、特定のステップ数をフォントサイズの値として設定しさえすれば、それだけで自動的にちょうどいいサイズが適用されるようになる。そういう実装にする。結果、ブレイクポイントごとにフォントサイズを設定し直す必要がなくなる。

— Designing with fluid type scales | Utopia

フォントサイズの値が変化する始点と終点に当たる数値は、モジュラースケールによって導出される。

幅が375pxの場合——

基準となるフォントサイズは14px
モジュラースケールの係数は1.2

幅が1440pxの場合——

基準となるフォントサイズは18px
モジュラースケールの係数は1.25

こういう具合でUtopiaに入力すると、次のように値が出力される。

— Fluid type scale calculator | Utopia

フォントサイズだけでなく、似たロジックを使ってスペーシングの値のセットを生成する仕組みも備わっている。これらの値は、マージンや要素のサイズ設定などのために使用できる。

— Fluid Space Calculator | Utopia

案件を担当するデザイナーとはUtopiaの考え方について話して、これを使ってフォントサイズとスペーシングの値を設定してもらうことになった。Figmaで作るデザインカンプでももちろんこのルールに基づいてデザインする。

こうして案件をひとつ完遂したけれど、結論としては、次からは使わないと思う。しかしこれは必ずしもUtopiaのアプローチが合わなかったというわけではなくて、メリデメがいろいろあった上での総合的な評価結果にすぎないので、詳しい経緯を記録しておく。

うまくいったこと

スタイルとして設定する値について、あらかじめ正しく共通認識を持てるようになったことは普通によかった。いわゆるデザイントークンというやつ。これによって、デザインカンプがより精緻なものになって、「なにが正解なのかわからない状態」をかなり減らすことができた。

というのも僕の経験では、デザインカンプ上で各要素に適用されているフォントサイズやマージンの値に規則性を見い出せなくて、開発担当者がCSSとしてうまく表現できないような場面がよくある。すると、開発担当者がデザイン仕様をよしなに「調整」した上で実装し、それをデザイン担当者に確認してみて、フィードバックを受けて場合によってはまたそれをやり直すという余計な仕事が発生する。その際には細かい指示が増えがちで、「この箇所だけフォントサイズを2px大きくしたい」とか、「こことここはマージンを揃えて、あっちは少し広げたい」みたいな、人間同士でやるにはストレスフルになるようなやり取りをすることになる。しかしその実は、前工程での検討が不十分だったためとしか言えないような指示も少なくない。

問題は、設計段階においてその意図が明瞭になっていないこと。判断のブレを是正するための基準が設けられていないという場合が多い。そこで、Utopiaが生成したフォントサイズとスペーシングを導入することによって、判断の枠が設定されると、確然たる判断をするように半ば強制されることになる。そのおかげで、後でやり直したくなるような生煮えの判断を減らせるのだと思う。

レスポンシブデザインにまつわる事情が絡んでくると、この辺りの判断は余計に曖昧になる傾向があった。前述の組み合わせ地獄によって、ルールはより複雑に、より微妙になっていく。しかしこれについてもUtopiaのおかげで、「値はブレイクポイントにかかわらずステップとして一意に決定される」というシンプルなルールが打ち立てられて、曖昧さを解消できた。

またレスポンシブデザインにおいては、モバイル向けのデザインとデスクトップ向けのデザインで、スタイルはどの程度個別化されたり共通化されたりするのが妥当かという問題がある。どうにも場合によるところは大きいけれど、それぞれで視覚的な階層構造が共通している限りは、フォントサイズについてはステップ数さえ決まっていれば再設定の必要はほとんどないと言えそうだ。

開発は複数人で行った。Utopiaの採用によってルールの単純化が実現された結果、担当者ごとの実装のブレはかなり抑えられたように思う。特にレスポンシブデザインを採用する場合の開発では、通常、デザインカンプでは表現されない仕様が大量にあり、開発担当者によってまったく違った実装になってしまうことが珍しくない。こうした個人の解釈に依ってしまう部分がUtopiaによって補完され、いたずらな判断のばらつきを平坦化できた。

うまくいかなかったこと

すべてのフォントサイズの値が流動的に変化するのはやり過ぎだった。Utopiaを素直に使うと、ビューポートの幅が広がるにつれて、どのフォントサイズも漏れなく拡大されていくのだが、本文よりも小さいフォントサイズまでもいっしょに大きくなっていくのは不都合だった。全部の要素を大きくしたいのではなくて、メリハリをつけるためにジャンプ率を高めたいという場面が多いので、小さいテキストはそのままでいいことになる。

加えて、モジュラースケールはやはり使い勝手がよくなかった。「音楽、数学、タイポグラフィ」で指摘されたように、モジュラースケールでは導出される値の間隔はまばらになるが、より使用頻度が高いのは本文のフォントサイズ周辺の値だ。本文を中心としたデザインであればあるほど、そこからの差異を表現するために必要なギャップは少しでよくなる。それなのに、ステップ同士の間隔が空きすぎているとその辺りの調整がやりづらいことになる。

—音楽、数学、タイポグラフィ - シフトブレイン／スタンダードデザインユニット

スペーシングについては、Utopiaの値を使いつつも、けっきょくブレイクポイントで上書きする場面が多かった。フォントサイズと違って、マージンなどについては、一般化したルールに則ってやるのが難しかったということだ。

次に試していること

フォントサイズにまつわるルールの複雑化を回避するという意味では、Utopiaのように値を流動的に変化させるアプローチは別に必須ではない。ブレイクポイントごとにフォントサイズを上書きするにしても、その組み合わせをパターン化することさえできていれば問題にはならない。

たとえば「ヘッドライン」というパターンを作って、モバイルの幅では40px、デスクトップの幅では48pxというルールを定めておく。同様に、「ボディ」や「キャプション」なども追加した上で、テキストのスタイルは必ずこれらを参照して決定されるということにすればよい。

— Typography – Material Design 3

これらのパターンのなかに、行の高さやトラッキングなどもいっしょに含めておくと、さらにルールの一貫性を高めることができるし、開発も楽になる。いま担当している案件では、デザイナーがページの制作を進める傍らで、こうしたタイプスケールも定義してもらっている。

— The type system - Material Design

さらに、タイプスケールやスペーシングだけでなく、そのほかのいろいろな値（デザイントークン）を一元管理できればなおよい。そこで、Figma Tokensというプラグインを導入することにした。これを使えば、テキストやスペーシングに限らず、カラーパレットやボーダー、不透明度などもトークンとして管理できるようになる。Figma Tokensにトークンを設定すると、それらに対応するボタンが出現して、クリックするとレイヤーに適用できるという仕組みになっている。トークンの設定はJSONで入出力できるので、Tailwind CSSのデフォルト値をJSON化し、デザイナーと共有している。

『Every Layout』に到った背景と思想についての私の解釈

Mon, 27 Dec 2021 00:00:00 GMT

「Every Layout」をめぐる座談会

Thu, 16 Dec 2021 00:00:00 GMT

僕と梅、男梅シート

Sun, 05 Dec 2021 19:55:00 GMT

昔から梅が好きでよく食べる。実家にいたころは、口寂しくなるたびに冷蔵庫を開け、おやつ感覚で梅干しを食べては、塩分の摂りすぎだからやめろと母親に言われていた。ご飯を食べるときにもよく梅干しをおかずにしていた。

梅のジュースもよく飲む。最近はどこでも見かけるようになったけど、昔はけっこう珍しかった気がする。見つけたら買っておいてもらって、家ではそれがなくなるまで毎日飲んでいた。今でも見かけるたびに買って飲む。

テレビで毎日のように流れていた梅酒のCMを見るたびに、いったいこれはどういうものなんだろうとずっと気になっていた。大人になってからは、飲みに行くたびにほぼ毎回梅酒を頼んでいる。梅干しサワーを頼むこともあるけど、梅酒のほうが好き。

駄菓子屋ではいつもカリカリ梅を買って食べていた。母親といっしょに遠くのスーパーに行ったときは、そこでしか売ってない「スッパイマン」を買ってもらっていた。家からは少し遠いコンビニが行動圏内に入ってきたころには、干し梅をよく買うようになった。

男梅が発売開始したときはちょっとした衝撃だった。当時、はちみつ梅至上主義とも言える風潮があった商品棚の中で、あえてその酸っぱさを前面に出したback to basicsな感じはむしろ新鮮だった。

一方で、ねりうめ的なジャンルにはいくどか挑戦してきたけどなかなか馴染めなかった。グミとか、梅干しシートとかも同じで。あの手の製品って、梅酒くらいにほぼ別物として振り切っているというほどでもないんだけど、梅そのものともちょっと距離がある感じがして、どないやねんと思ってしまっていた。あの形式を目指す限り、たぶんなにか加工の技術的問題とかで、どうにもいい感じにはならないものなんだろう、と長年思い込んでいた。

しかし4年くらい前に登場した男梅シートを試してみて、これはまだ捨てたものじゃないと直観した。たんにコンセプト的問題だったのだと。けれど当時はリピートしたいと思えるほどの出来ではなかった。それからしばらく時間が経って、最近になってからまた男梅シートが目に入ったので試してみたところ、シート的形状でありながら、ほぼ男梅そのものというレベルに達していた。これなのだ、求めていたものは。そして、男梅の本質が凝縮されている。男梅よりも男梅なのだ。モノマネで言うところの本物より似ているというやつ。このエントリーを書き切るまでに3枚食べた。

追伸: 男梅シートのパッケージは4年前から変わっていないようなので、そのころからおいしさが変わったのかどうかは実際のところわからない。製法が変わったのか、僕の味覚が変わったのか。また、男梅シートの製法はほかの梅干しシート系の製品とはだいぶ違っていそうな感じもするので、単純比較はできないかもしれない。

文の途中でも流れを読み誤られないように作文することを心がけている

Sat, 04 Dec 2021 15:05:00 GMT

日本語の文では、文末に到達するまで話の方向性が読み切れないことがある。文を読むときに、途中まで読んだところで「あー、はいはい」となっていても、最後まで読み進めると「あれ、そういう話？」という感じになり、流れを読み誤っていたことに後で気づく。人がしゃべるのを聞いているときにはより顕著になる。しゃべる速度は読む速度よりも遅いので、どうしても焦ったくなってしまうものだ。

一方で英語の文では、最初にまずシンプルな表現で言い切ってから、補足的な言葉は後ろに修飾されていくので、大筋から順に話の方向性が確定していく傾向にある。これは便利だと思う。というのもこの形式であれば、言葉のひとつひとつを見聞きしたそばからすぐに解釈を開始できる。つまり、受け手にとっての思考のロスを削減することに加えて、より速く伝えられるようになるはずだ。

僕は日本語の作文においてもそれを実現すべく、言葉が並んでいる順に解釈できる文体を目指している。受け手が思う流れを裏切らないために、まず端的に言い切ったり、倒置法を活用したり、語順や言葉のまとまりを調整したり、などなど。

翻訳作業を経てから意識するようになったことのひとつ。

これはこれで逆に広げられない話は書けないみたいな縛りになっている

Fri, 26 Nov 2021 13:45:00 GMT

「言葉は違いから生まれる」というテーマで今日の分を書こうとしたけどあんまり的を射たことを言えそうにないのでやめておいた
— 全部入りHTML太郎 (@_yuheiy) November 26, 2021

「アイデアはメモリが解放されたときに生まれる」というテーマで一昨日の分を書こうとしたけどあんまり的を射たことを言えそうにないのでやめておいた
— 全部入りHTML太郎 (@_yuheiy) November 26, 2021

「一般化しすぎると言うことがなくなる」というテーマで今日の分を書こうとしたけどあんまり的を射たことを言えそうにないのでやめておいた
— 全部入りHTML太郎 (@_yuheiy) November 26, 2021

いつからかそういう癖がつき始めた。なんでもかんでもを「そのまま」書くわけにはいかないからという意識からなんだけど。散歩してるとかシャワーを浴びてるときみたいに、頭が暇な時間がありすぎると、考えがそっちの方向に進みすぎて、ざっと記事化するには手に負えない感じになってしまうことがある。ちょうどいい抽象度で書きたいことをドンピシャで書けるようなタイミングもあるんだけど、そういうときって今みたいな「まだそのときじゃない」と見送ってきたピースがちょうど繋がったときでもあるかもしれないな、ということに、今まで書いていて気づいた。しかしそれを感じるタイミングは割と頻繁にあって、「このタイミングは本当にマジのやつか？」があまりわからない。いやあるいは、あるテーマを考え終えるとき、別のテーマに頭が移っていく前のタイミングというのが、自分の中で一番満足するまで考え切ったタイミングだ、と言えるだろうか。それがマジのやつだろうか。

こうやって思いついた順に書き連ねるようなスタイルは、人に見せるには野蛮な感じがして通常憚られるが、日記としては役に立つと思う。なにも書かないとなにも残らないので、こうやって捻り出してる感じをわざと残すのもひとつの記録の仕方だ。

こと非同期コミュニケーションにおいては少しくどいと思うくらいに説明するのでちょうどいい

Tue, 23 Nov 2021 14:00:00 GMT

Slackのようなインターフェースを見ると、さも人と人が対面してしゃべるような言葉のやり取りがそのままできて、コミュニケーションとして成り立つと思ってしまうことがある。非常に限定的な状況においては可能かもしれないが、たいていはそうならない。

非同期コミュニケーションにおいては、人がひとまとまりの言葉を発する1ターンに重みがある。

対面してしゃべるときには、相手がしゃべっている途中でなにか引っかかりを感じれば、そこで割り込みをして質問したりすることが簡単にできる。

「いま言ってるAって、もしかしてBのこと？」
「あ、それでした」

この場合の割り込みはたいしたコストにならない。しかし、たとえばZoomとかになってくると難しくなる。通信による遅延があるからだ。しゃべってる途中で割り込もうとすると、間が悪くなる。

「さっき言ってたAって、もしかしてBのこと？」
「えっ、ごめんなんのこと？」
「あのさっきの」
「ああ、そんなこと言ってた？」

みたいになる。つまり、指摘や質問のコストが上がってしまう。これが一度切りだとすれば気にならないが、1時間とか話してるとそういう場面は何度もある。したがって、ちょっとしたことでいちいち流れを止めてしまうと申し訳ないとか、恥ずかしいという気持ちになるので、

「あの人が言ってるこれって、たぶんあれの言い間違えな気がするけど、わかってるよな」
「ちょっと違和感があるけど、これくらいのことならスルーしておいて大丈夫か」

という判断になる。あるいは、しゃべってる人が一息ついたタイミングでまとめて確認しようと思ってホールドしておく。すると、その人が間髪入れずにしばらくしゃべり続けるので、前提条件の確認がすごい後手に回ってしまったり、みたいなこともある。

この話がわかってないのって自分だけだろうかと思うときって、実はほかの人も同じようにわかってない場面も多くて、そういうときはズレをこまめに確認しておかないと、的外れな発言が頻発して時間の無駄になる。

非同期性によって、この「結局余計めんどくさい問題」が発生しやすくなる。解決策としては、できるだけいい回線を使うとか、ゆっくり目に間を置いてしゃべるとか、その辺だろうか。

テキストでのやり取りも同じような問題を孕んでいる。非同期性が高いのでじっくりやり取りできると思いきや、結局みんな時間はないので急いでしまう。そして、1ターンの重みはさらに増す。ひとつ反応をもらうのに半日かかるかもしれないし、もしお互いがそうであれば、言動はますます慎重にならざるを得ない。

そしてテキストである以上、対面してしゃべることとは性質が違うが、それにあまり配慮せずにいるとまた不健全性な方向に進んでしまう。

しゃべるときは相手と言葉だけでコミュニケーションしているわけではない。声の感じとか、間の置き方とか、表情とか、そういうところでつねに言葉以外のやり取りをして、相手の反応も伺いつつ話を進めている。

しかししゃべりの場と同じノリのままで、しゃべりの場をイメージして出てきた言葉だけを切り取ってテキスト化してしまうと、なにを言っているのかわからない人になってしまう。相手と共有されていない、自分のイメージの中だけで発生したしゃべりの断片を、相手に送りつけることになる。

すると相手としては、テキストからは読み取れない情報を補完するために、発信者はどういう思考の流れでこれを書いたのかというところまでさかのぼり、意図を探り当ててやらないといけない。そうして探り当てた意図が本当に正確なものであるかに不安があれば、「あなたが言いたいのってこういうこと？」と確認する必要がある。しかしその察されている状況までもが理解できない人にとっては、「いや、だからそう言ってるでしょ。早く次の話をしてよ」という反応になってしまう。

「人の立場になって考えましょう」というのは、簡単な精神論で終わる話ではなく、訓練を要する技術的な問題だと思う。人が自分の話について来れてないと認識できなかったり、そういう状況を軽視してしまう人は、話を伝えるということの実感に欠けている。

伝えるためには、その相手の知識レベルや考え方、立場の違いなどについてよく理解していないと、どこに向かって説明すればいいのかがわからなくなるはずだ。そして、相手を理解しようと努めてきた経験であったり、その経験から得られる想像力によって、相手への理解は育まれるものだ。

そしてこの違いは、1ターンの重みによって如実に現れることになる。指摘や質問をするコストが増大する状況であるからこそ、相手に対する配慮のなさから生まれるコストはただならないものになってしまう。だから発信側は相手にうまく伝えるために、よく考えるべきだ。

非常に端的で簡単なテキストでうまく伝えられるならば、それ以上のことはない。しかしどうしても、言葉に解釈の余地が生まれてしまうことは回避できないし、相手を完全に理解することもできない。だから大事をとって、できるだけ周到な形で伝えるようにしたいと僕は考えている。

相手がつまづいてしまいそうな要素は排除する。自分があたりをつけたところと相手が少し離れたところにいても、なんとか機能できるように、多少の読み違えをされてしまっても、続きを読んでいるうちに相手の理解が軌道修正されるように、少しくらいのズレは念頭に置いておく。受け取る側が察するよりも、発信側のほうが配慮する余地があるのだから、相手より先回りして書いておくくらいのことはやるべきだ。

しかしそういう意識で書いていると、自分の伝え方がなんだかくどくどしく見えてきて、うっとうしくて恥ずかしかったりすることもある。でも、相手にとってはだいたいそれくらいでちょうどいいものだ。相手は自分とは違う人間なので。それでうまくいく経験がほとんどだし、逆に、頓珍漢な方向にハッスルするような失敗をしてしまうこともあるけど、伝えるための努力をしていない人よりは全然マシだと思う。

Every Layout——モジュラーなレスポンシブデザインを実現するCSS設計論

Tue, 23 Nov 2021 00:00:00 GMT

田舎に回帰したい

Sun, 21 Nov 2021 19:00:00 GMT

いま住んでる部屋が結構ボロいので、いろいろ不満があって、引っ越したいなあと思いつつも、めんどくさくてずっとほったらかしていたけど、そろそろ本当にどうにかしたいと思って引っ越し先を考え始めた。

仕事は今はフルリモート環境になって、今後もこれが続く予定なので、どこに住んでも別に問題ない。しかし自由度がありすぎて決められないので、とりあえず今と同じ最寄り駅で探してみたけど、それだと家賃があんまり安くなくて、改めて考えてみるとやっぱり損だなと思い直したので、安いところで探すことに。

いちおう東京にはいたほうが安心かなと最初は思ったものの、試しにもう少し可能性を広げてみる。所沢辺りはいいかもしれないとか。でもそれはちょっと遠すぎか。とりあえず買い物とかは便利なところがいいけど、まあそれはだいたいどこでも便利だよねとも思う。そういう感じで、いまいちポイントが見つからないなと思っていると、ふと目についた田舎っぽい駅の写真にすごい惹かれてしまった。

僕は地元がそこそこな田舎で、あらゆる一帯が田畑とか山とかしかないみたいなところで育ってきたので、そういう風景に懐かしさを感じてしまう。地元ほどの田舎に住むと不便すぎるので、将来的に戻るとかはまったく考えられず、今後ずっと都会にいる気でいたけど、東京の利便性があるなかでそういう景色も拝めるのは悪くない。むしろこれこそが最適解な気がする。

その方向性で探してみて、いい感じに田舎っぽいところをリストアップできてきた。野菜の無人販売所とかある雰囲気がいい。似たところで、自然が多い街という感じの場所もイメージできてきたけど、そういうところが自分が求めている感じの場所かはまだわからない。とりあえず今週や来週にでも、それぞれいくつか候補地を回りたい気分になってきた。地元にいるときは外では自転車で走り回ってるのが当たり前だったので、またそういう生活をするのもよさそう。

ブログを書くのがなぜ難しかったのかを思い出してきた。ひとつは、タイトルが必要だから。つまりテーマをはっきりさせないといけない。思いついた順にただなんとなく書いているだけのツイートでは、書いてる側から次々テーマが変わっている。書きながら考えて、そのまま散らかしっぱなしになっている。これがいわゆる0から1のフェーズだとすると、記事化するにはその後の1から10のフェーズも経ないとダメだと思ってしまう。そして、それがないとちゃんとしたタイトルをつけられない。

あるいは、タイトルを先に書くか本文を先に書くかという問題もあるかもしれない。僕はだいたいタイトルが先に出るけど、本文を書き進めているうちに次々とタイトルも変わっていくことが多い。だいたいこの辺かなという目星を決めて始めてしまってから、後で方向修正してるというか。逆になにもタイトルらしきものなしに始めてしまうのが無理かもしれない。でも最初にタイトルが出るときって、このテーマで記事化できるなっていう直観が先にあるときでもあるな。そしてそれを形成する前段にはツイートのような小さなピースがある。だから、ブログを書くための大きな流れとしては「ツイート→タイトル⇄本文」みたいな感じかも。今やっているのは、その「ツイート→タイトル」の部分だけ切り出してやることで省エネにして、習慣化することで一回ごとの負荷を減らして、最終的にはまた「ツイート→タイトル⇄本文」を楽にやれるようにするためだという気がしてきた。

ここ数日の記事の内容がどこか混沌としているのはそういう事情だ。考えをクリアにして整理する過程を省いているのでこうなる。ちゃんとやってるつもりでもできてないときももちろんあるけど。細かい表現もそんなに気にしないようにしている。これくらいのものでも別にいいと自分が許容できるようになるための練習。

かわいいぬいぐるみとか見つけるとうわほしいぃって思うけどたぶん2ヶ月後くらいにはいらねえって思っちゃう

Sat, 20 Nov 2021 05:50:00 GMT

とんかつ屋。隣には、神経質そうな思春期の息子と、大雑把そうな年配の父親。

「ご飯のお代わりのためだけに呼ぶの悪くない？」と息子が言うと、「それも織り込み済みだからいいんだよ」と父親が答える。

わかるよ。それでも、個人としては微妙に嫌だろうと思うんだよ。そう考えちゃうし、考えたいよね。2人が呼んだ店員を僕は帰り際に呼び止めて、ご飯のお代わりを頼んだ。僕は昔から父親と全然しゃべらなかったので、父親と息子が淀みなく会話している光景を見ると非現実的に感じて、物珍しげに見てしまった。

「そんなに食べたら、さっき散歩した分が無駄になっちゃうよ」。一理ある。

帰りにセブンイレブンの前を通った。今月の27日から始まる、トムとジェリーのHappyくじというのがここで引けると同僚に聞いた。とくに「チーズを丸飲みしたジェリー」のフォルムがすごくいいので欲しい。

割とよくこういうのを見つけて欲しくなることがある。ぬいぐるみとかも欲しくなる。しかしそれらが増えてくると部屋が煩雑になるので、強い気持ちを持って、できるだけ買わないようにしている。

例外的に、プリントTシャツだけは50枚くらい持っている。なんとなく自分ルールで、これだけはOKということにしているのだ。ただ最近、衣装ケースに入り切らなくなってきたので、さすがに減らそうかなと思い始めた。本棚から溢れる本類はサマリーポケットに預けたりもしているが、Tシャツまでそれをやると運用が複雑になりすぎてしまう。

けっきょく捨てるようなら最初から買わないほうがいい。捨てるのは、どうもやり切れない気持ちになる。これがもし、Tシャツを何回も繰り返し着続けて生地がダメになったから捨てるというのなら、うまい付き合いができたと思って納得できるが、はたまたぬいぐるみだったり、「チーズを丸飲みしたジェリー」だったりした場合の、適切な捨てどきはいつなのだろう。

当初の目的を果たさなくなるという意味では、飽きたときや好きじゃなくなったときがその時なんだろうけど、これはモノの側の劣化とはたいてい関係がなく、持ち主の気持ちの変化によるところでしかないので、モノの側の問題——つまりやむを得ないものではない。持ち主を変えればいい。ただ、現実的にはうまくいかない。なんでもかんでもメルカリで売れるわけではないし。いやこれは半分嘘で、僕はまだメルカリを使ったことがない。

しかし譲渡の選択肢がないとして、モノに対する持ち主の気持ちの消失だけをわけにゴミになってしまうのがどうしても解せない。そのモヤモヤに蓋をして、今までたくさんのモノをゴミにしてきたわけなのだけど。その行為を割り切って考えてもいいのだろうか。ペットを飼うときには、生き物だからモノのように扱うなと言うが、同じような意味で、モノもただのモノのように扱うなとでも言いたくなるような感覚がある。そういったモノを捨てることには、うっすらとだが、生き物を殺処分するような罪の意識があるかもしれない。

3ツイするくらいの軽さでブログ書くタイプの人類になりたい

Fri, 19 Nov 2021 12:30:00 GMT

3ツイするくらいの軽さでブログ書くタイプの人類になりたい
— 全部入りHTML太郎 (@_yuheiy) November 19, 2021

3は極端かもしれない。6くらい。

ツイートのハードルが低すぎてなにもかもをそこに投下してしまうが、あれはたいてい記録にはならなくて、自分でもただただ忘れ去るだけになる。僕は割と残しときたい派なので、そうじゃないほうがいいけど、代わりにブログとかにしようとするとちゃんとやりたい病が発症してハードルが上がってしまう。しかしそれで結局なにも残さないのも本意ではない。

そういうわけなのでハードルを下げる必要があり、そのためにはこだわりすぎないための制約がいる。さっきラーメン屋でそういうことを思いついたので、帰り道を歩きながら全部書き上げてしまうことにした。

少なくとも140文字を超える程度の量のテキストを自由に書くことに固有の楽しみというのがあって、それはツイートとはまた種類が異なる。明示的な文字数の制約とか、タイムラインのコンテキストとか、そういうルールはとても無視できるものではない。

ゆっくり目に歩いていたけどさっき家の前を通り過ぎてしまった。とりあえず今日はこんなところでいい気がする。こういうタイプのしゃべるような書き方をしていると、段落を区切ることを忘れてしまう。ラフになればなるほど、全文がフラットになっていくような気がする。そういえば連ツイってそういう感じする。僕が今こうやって書いたのは連ツイせずに連ツイしただけのことなのかもしれない。まあでもいったんそれでいいです。

『Every Layout——モジュラーなレスポンシブデザインを実現するCSS設計論』、素直さという選択 #everylayout_ja

Mon, 11 Oct 2021 00:20:00 GMT

友人の腹筋ローラーの力を信じろさんと共に監訳を担当した書籍『Every Layout——モジュラーなレスポンシブデザインを実現するCSS設計論』が出版されます。現在、Amazonで予約受付中です。当初の予定よりもかなり遅れてしまいましたが、内容はいまだ鮮やかなままに思えます。

日本語版に寄せて
監訳者まえがき
Chapter 1: 基礎
- 1–01: ボックス
- 1–02: コンポジション
- 1–03: 単位
- 1–04: グローバルスタイルとローカルスタイル
- 1–05: モジュラースケール
- 1–06: 公理
Chapter 2: レイアウト
- 2–01: Stack
- 2–02: Box
- 2–03: Center
- 2–04: Cluster
- 2–05: Sidebar
- 2–06: Switcher
- 2–07: Cover
- 2–08: Grid
- 2–09: Frame
- 2–10: Reel
- 2–11: Imposter
- 2–12: Icon
索引

もとになっているのは、ウェブサイト「Every Layout」です。同サイトにある「Relearn CSS layout」というコピーの通り、本書は、すでにある程度CSSについての経験を積んでいる制作者のための書籍です。レイアウトがテーマではありますが、ある決まった見た目を模写する練習帳のようなものではなく、CSSのもっと抽象的な設計方法について論じたものです。

少し乱暴に言えば、「レスポンシブデザイン」と「CSS設計」と「デザインシステム」をまとめて一つの視点で解説したような内容になっています。これらは本来、CSSという技術領域の上で重なり合う分野であり、切っても切れない関係です。しかし議論としては各論に分散する場面が多く、それぞれの分野が相互に影響し合う領域については、あまり知識が集積されてこなかったように感じます。そうした分野の交差点において、体系化された理論を提示できることは、本書の一つの意義です。

また、CSSらしい考え方を身につけるための本とも言えます。1章では、CSS固有の性質をうまく活かしながら、いかにして効率的で堅牢なスタイリングを実現するかという基礎的な方法論について詳しく解説しています。経験豊かな開発者が無意識に身につけているものの、なかなか言葉にできなかったような経験則を、巧みに繋ぎ合わせて体系化しています。

2章では、これらを踏まえつつ、具体的なレイアウトパターンの紹介に移ります。一つ一つが「レイアウトプリミティブ」と呼ばれるコンポーネントになっています。非常に再利用性の高いコンポーネントであり、うまくプロジェクトに導入できれば、レイアウトのための必要なCSSが大幅に削減できて、結果的に全体の設計もシンプルになります。

このような書籍は私自身にとっても待望でしたが、一方で、これまで現れてこなかったのも仕方のないことに思えるのです。

CSSを巡る状況は非常に複雑です。

CSSはスタイリングのための言語であると同時に、ウェブデザインの素材そのものであり、「デザインのためにデザインされたもの」でもあります。つまり、デザイナー自身が使うためにあるのです。スタイルがどうあるかよりも、どうあるべきかを起点としながら事象を導くのがCSSの考え方です。言わばその遠回しなルールの記述こそがデザインであり、CSSの勘所です。

しかし、デザインカンプを中心としたワークフローでは、デザイナーはCSSに触れず、あるいはCSSについて意識することなく制作してしまうという状況が珍しくありません。すると自らのデザインにおいて、CSSが持つ構造との矛盾が生まれたり、前提の誤解があったとしても、それに気づくことができません。その結果、成果物を引き継いだCSSの担当者は、多かれ少なかれ不条理に苛まれることになります。筋の悪い構造を無理やり実現しなければならない場面も多く、管理するCSSは不必要に複雑なものとなっていきます。

また、デザインカンプ前提のワークフローからキャリアを始める多くの開発者にとっては、デザインカンプの通りに模写することこそが最重要事項と捉えられてしまいがちです。CSSをうまく活用したよい慣習について学べる機会も少なく、構造上の問題を覆すために設計の前提を見直すような発想に至れるだけの力も身につけられません。

昨今では、CSSのためのツール選定としては非常に多様な選択肢があります。CSS in JSやCSS Modules、ユーティリティファーストCSSなど、それぞれの思想をもってCSSの使い方を見直そうとする姿勢が見受けられます。とはいえ、いずれもCSSを置き換える類いものではなく、CSSを少し抽象化した、CSSの延長線上にあるものです。プレーンで普通のCSSをうまく使えるからこそ、こうした発展的な技術もよく理解できるのです。しかし、普通のCSSの経験が乏しいままに、いきなりこうしたツール群に気を取られてしまうと、学習としては遠回りなものになって、たくさんの時間を無駄にしてしまいます。

個人的な経験から言えるのは、CSSの難しさの割合の大部分を占めるのは、その周辺事情の複雑さだということです。ズレの積み重ねによって、CSSは本来よりもずっと難しい技術になっています。この問題を根本的に解決するには、ズレを少しずつ解消して、付随的な複雑さを可能な限り取り除くことです。そのためには、いくつもの方向からさまざまなアプローチが必要となるでしょう。

こうした状況がある中において、本書の最大の特徴と言えるのは、その包括的なアプローチです。CSS開発者のためだけの部分最適な理論ではなく、ユーザーを含めた全体から見て本質的にどのようにデザインすべきか。複雑さを本質的に取り除くためにはそうした視点が欠かせないのです。しかしそのためには大きな発想の転換が求められることもあり、目の前の仕事に適用するのが難しい場合もあるはずです。ワークフローを変える必要に迫られるかもしれませんし、見方によっては理想論と一蹴されてしまうでしょう。

しかし重要なのは、いくつもの「考え方」を持っていることです。目の前の状況を相対化して、よりよいものにしていくためには、多くのことを学び、選択肢の数を増やし、都度適切なものを選び取れるようにしておく必要があります。その意味で、本書は、多くの人にとって新鮮な驚きをもたらしてくれる一冊であるはずです。

翻訳のレビューとしては、terkelさんとろくぜうどんさんにご協力いただきました。文章として違和感があったり、表現が伝わりづらかったりした部分については、お二人の助言のおかげでかなり改善できたように思います。

リハビリ

Tue, 28 Sep 2021 17:59:00 GMT

ブログを書くのはおよそ8ヶ月ぶりになる。僕にとっては、それなりに長らく書かなかったことになる。

いろいろと忙しかった。だけど、それ自体が理由なのではなくて、「今はブログなんか書いている場合じゃない」というプレッシャーを感じて勝手に書けなくなっていた。

もちろんたまには、短期的にどうしても無理な場面はある。けど今はそれよりも、どうしても無理な場面がしばらく続いた結果、習慣が抜けて走り出せなくなっていた、というのが近いと思う。書かない期間が長引けば長引くほど、足取りは重くなり、無意識にハードルが上がってしまう。軽快さは徐々に損なわれて、うまくやれなくなる。

だから、再開するにはちょっとずつやったほうがいいだろう。大したことを書こうとせずに、投稿することだけを目標にしよう。

この記事は散歩しながら書いた。最近はできるだけ毎日、散歩するようにしている。一万歩って案外大変だ。歩数を測るようにしてみて初めてわかった。夜なので、風呂に入ったらさっさと寝よう。

垂直方向のマージンにはmargin-topを優先的に使う理由

Tue, 26 Jan 2021 17:13:39 GMT

margin-bottomではなくmargin-topを使う派である旨をツイートしたら理由を尋ねられたので、それに対する回答です。大きくは次の3つです。

末尾の要素の存在が任意である場合が多いため
Stackレイアウトとの取り合わせやすさのため
隣接セレクターを使った場合分けができるようにするため

CSS、基本コンポーネントの上にマージン取る派と、下にマージン取る派がいると思うですけど、自分は今までずっと下で。というのは、その方が直感的だと感じるからなんですけど、見出しの下って結構縮めるよね？それを上マージンでやると結構頭こんがらがらない？って思うんだけどどうなんだろう
— Takazudo (@Takazudo) January 12, 2021

上です
— 全部入りHTML太郎 (@_yuheiy) January 12, 2021

1. 末尾の要素の存在が任意である場合が多いため

コンポーネントやページなど、ある特定の区間内の末尾の要素は存在したりしなかったりすることが多い。重要度の高い情報を上から順に並べるとき、末尾の要素は相対的に重要度の低い情報を扱うことになり、ビューとしてはその有無が任意になったりする。

たとえばページタイトルは必須だけどページの説明文は任意になる場合。

<h1>{{title}}</h1>

{{#if description}}
  <p class='mt-3'>{{description}}</p>
{{/if}}

あるいはカードパターンの下部にあるリンクやボタンが任意になる場合。

<div class='card'>
  <p>{{title}}</p>
  <p class='mt-2'>{{description}}</p>

  {{#if link}}
    <p class='mt-3'><a href='{{link}}'>さらに詳しく</a></p>
  {{/if}}
</div>

カードパターンにはタグが含まれていることもあるかもしれない。

<div class='card'>
  <p>{{title}}</p>
  <p class='mt-2'>{{description}}</p>

  {{#if tags}}
    <ul class='mt-3'>
      {{#each tag in tags}}
        <li>{{this}}</li>
      {{/each}}
    </ul>
  {{/if}}
</div>

こういうとき、末尾の要素にはmargin-bottomがついていない方が都合がいい。

カードパターンなどでボックス状の見た目になっているときには、paddingやborderを使ってマージンが相殺されない状態になっている。するとボックスの下部には、親のpadding-bottomと末尾の要素のmargin-bottomが足し合わされた量の余白ができてしまって不自然な見た目になる。

この問題を回避するために、要素内の末尾の要素からはmargin-bottomを取り除くやり方がある。

.card > :last-child {
  margin-bottom: 0;
}

しかしそもそも最初からmargin-topを使うようにしておけば、このような規則を追加する必要がない。

もし先頭の要素の存在が任意である場合には、逆にmargin-bottomを使った方がよくなる。ただ末尾の要素が任意である場合に比べて、先頭の要素が任意である場合の方が経験則上は格段に少ない。僕は実際にそのような場面に出くわしたときのみ例外的にmargin-bottomを使うこともあるが、そうでない限りは基本的にmargin-topを使っている。

すべてをmargin-topに統一したければ、マークアップ側の工夫でmargin-bottomを使わないこともできる。

{{#if subtitle}}
  <p>{{subtitle}}</p>
  <div class='mt-2'></div>
{{/if}}

<h1>{{title}}</h1>

2. Stackレイアウトとの取り合わせやすさのため

StackレイアウトというのはEvery Layoutで紹介されているCSSのパターンのことで、具体的には次のような実装になる。

.stack > * + * {
  margin-top: 1.5rem;
}

<div class='stack'>
  <p>{{title}}</p>
  <p>{{description}}</p>
  <p><a href='{{link}}'>さらに詳しく</a></p>
</div>

こうすることで自動的に子要素の要素間にのみ同じ大きさの余白ができるようになる。すると末尾の要素の存在が任意になっていたとしても余白は自動的に調整されるので、余白の大きさが等しい場合にはStackレイアウトを採用すると先述の問題を回避できる。

あるいは余白の大きさが違ったとしても、都度隣接セレクターを使うことで、特定の要素同士が並んだ場合にのみ余白を設定する実装ができる。

いずれにしてもStackレイアウトを採用する場合にはmargin-topを必ず使うことになるので、Stackレイアウトを常用する僕としては、Stackレイアウトを使わない場面でも一貫性の意味でmargin-topに統一しておく方が混乱が少なくて済む。

また複数のStackレイアウトが横並びになった場合に、特定の要素の配置を下部に合わせる用法もある。

末尾の要素の前にmargin-bottom: autoを指定すると、要素の高さに関わらず次に来る要素が下部に揃うようになる。

.stack {
  display: flex;
  flex-direction: column;
  height: 100%;
}

.stack > * + * {
  margin-top: 1.5rem;
}

.stack > :nth-child(2) {
  margin-bottom: auto;
}

例では2番目の要素にmargin-bottom: autoが指定されているが、同時に3番目の要素のmargin-topが引き続き生きていることが重要になる。2番目の要素のmargin-bottom: autoによって、余っている領域いっぱいまで3番目の要素が下部へ移動すると同時に、3番目の要素自身のmargin-topによって、余っている領域の大きさに関わらずつねに空く余白の最低限の大きさが設定される。つまりこのレイアウトにはmargin-topとmargin-bottomの両方が必要になる。

margin-bottomはこのパターンを実現するために温存している。

3. 隣接セレクターを使った場合分けができるようにするため

コンポーネント等の組み合わせによって垂直方向の余白の大きさに違いがある場合、隣接セレクターを活用すると余白の大きさを場合分けできるようになる。「デフォルトでは段落の上に1.5remの余白ができて、段落が見出しと隣接する場合には少し狭めの1remにしたい」ということであれば次のようになる。

p {
  margin-top: 1.5rem;
}

h2 + p {
  margin-top: 1rem;
}

margin-bottomでは同様のやり方をするのは難しい。Aの隣のBに対して宣言するという表現になる以上、AとBとの間の余白を設定するためにはmargin-topを使うしかない。隣接セレクターを使ってmargin-bottomを調整できると役に立つ場面もあるかもしれないが、まれだろう。

ぜんぶかきなおす

Fri, 01 Jan 2021 02:56:21 GMT

丸2日くらいかけて、このサイトのHTML/CSSやサイト生成の仕組みを全部書き直した。わかりやすい変化としては、以前のバージョンではフォントサイズとか余白とかがビューポートのサイズに関わらずつねに一定だったところが、今のバージョンではビューポート幅にもとづいたファクターに応じてすべてのフォントサイズが変化するようになっている。

具体的には、まずビューポート幅にもとづいたファクターは次のように実装している。

html {
  --scale-factor: 7;
}

@media (min-width: 331.2px) {
  html {
    --scale-factor: 6.99;
  }
}

@media (min-width: 342.4px) {
  html {
    --scale-factor: 6.98;
  }
}

@media (min-width: 353.6px) {
  html {
    --scale-factor: 6.97;
  }
}

/* 同様に続く */

@media (min-width: 1417.6px) {
  html {
    --scale-factor: 6.02;
  }
}

@media (min-width: 1428.8px) {
  html {
    --scale-factor: 6.01;
  }
}

@media (min-width: 1440px) {
  html {
    --scale-factor: 6;
  }
}

もっとも狭いビューポート幅では7になって、1440pxまで広がると6になる。そしてこれらの間の幅では間の値で補間される。メディアクエリで地道にやっているのがダサいけど、考え得る限りではこれが一番簡単になりそうだった。Sassを使えば楽に作れる。

続いてこの値を用いて、調和数列にもとづいた計算方法でフォントサイズのスケールを定義する。モジュラースケールでもいいんだけど、問題は指摘されている通り。

html {
  --text-base: 1rem;
  --text-sm: calc(var(--scale-factor) / (var(--scale-factor) + 1) * var(--text-base));
  --text-lg: calc(var(--scale-factor) / (var(--scale-factor) - 1) * var(--text-base));
  --text-xl: calc(var(--scale-factor) / (var(--scale-factor) - 2) * var(--text-base));
  --text-2xl: calc(var(--scale-factor) / (var(--scale-factor) - 4) * var(--text-base));
}

このように宣言しておくことで、次のように計算されるようになる。

html {
  --text-base: 1rem;
  --text-sm: calc(7 / (7 + 1) * var(--text-base)); /* 0.875rem */
  --text-lg: calc(7 / (7 - 1) * var(--text-base)); /* 1.166rem */
  --text-xl: calc(7 / (7 - 2) * var(--text-base)); /* 1.4rem */
  --text-2xl: calc(7 / (7 - 4) * var(--text-base)); /* 2.333rem */
}

html {
  --text-base: 1rem;
  --text-sm: calc(6 / (6 + 1) * var(--text-base)); /* 0.857rem */
  --text-lg: calc(6 / (6 - 1) * var(--text-base)); /* 1.2rem */
  --text-xl: calc(6 / (6 - 2) * var(--text-base)); /* 1.5rem */
  --text-2xl: calc(6 / (6 - 4) * var(--text-base)); /* 3rem */
}

余白のサイズもこれにもとづいたものに設定している。外から見えるところとしてはそんなところ。後は裏側の、僕にしかわからないような変更点がいろいろ。

テンプレートエンジンをLiquidからHandlebarsに置き換えた
- RomeのウェブサイトはEleventy製なんだけど、Liquidが採用されているのを見て、Nunjucksより機能が絞れてて良さそうと思ったけど、いろいろ中途半端だった。気の迷いだった
Handlebarsを使うためのフィルターやデータフロー周りの調整
YAMLファイルをタブインデントを使って書いてパース時に変換していたけど、4スペースに変えた
- これもRomeのパクり。普通で良い
シンタックスハイライトを実装した
投稿のdescriptionは本文の最初の段落と同じ内容だったけど、同マークダウンファイルのFront Matterにコピペして設定していたので、自動的に本文から読み取るようにした
投稿の並びをファイル名順にしていたけど、publishedフィールドにもとづいて並べるようにした
フィードの生成をプラグインのサンプルとして示されているテンプレート（Nunjucks）そのままでやっていたので、一貫性のためにHandlebarsで書き直した
データファイルにいろいろ重複したデータがあったので一元化した
- おもにフィードのテンプレートでサボってたせい
- Hail2uのmetadata.jsonを参考にした
いくつかのテンプレートで同ファイル内にFront Matterを書いていたけどマークダウンファイル以外では全部外部ファイルに書くようにした
投稿ファイルを変更してGitHubにプッシュしたらGitHub Actionsで自動的に変更日時が書き換えられるようにしていたけど複雑なので廃止
Netlify CMSを使えるようにした
404ページを作成
フッターの「編集履歴」リンクを投稿の詳細ページ以外では出さないようにした
リンク一覧のコンポーネントを<article>と見出しでマークアップしていたけど、単に<ol>/<ul>と<li>にタイトルは<p>にした
アイコンの冗長なIDをシンプルにした
- icon-chevron-right → icon-chevron
- icon-arrow-back → icon-back
CSSファイルをインライン化していたけど外部ファイル化した
余白の名前をspace-smとかspace-lgみたいにしてたけど連番に変えた
Clusterパターンのmarginの設定が面倒なのでやめて、Flexboxにgapを使うようにした
- Safariには3月のリリースまで実装されないけど時は早く過ぎるのでオッケーにした
- 余白はClusterのモディファイア的に実装していたが、これによってgap用の汎用的なユーティリティクラスに分けられるようになった

まだいろいろある気がするけどとりあえずこんなところ。これらのことがかなりうまいやり方で達成できた。そこに満足感がある。

サイトの構造とか見た目はちょっとしか変わってなくて、そこだけ更新しようとすればまあできたんだけど、こういう微妙な負債みたいなものは累積してそのままになりがちなので思い切って全部書き直したりすることがある。声を大にしてはっきりと「これが生産性を下げている」と言えるわけではない微妙なやつがいろいろあるというのがポイントで、あるひとつの問題だけ片付けさえすればすべてがよくなるような状況はあまりない。なんとなくいまいちな設計が全体的に蔓延していて、うまく説明できないけどちょっとずつ一貫性が崩れてるとか、微妙にDRYになってないとか、橋渡し的なコードが多いとか。

すでにある程度できているコードベースを運用していると、あくまでそれを基準にして次に取る手を決めていくことになるので、それなりの理由がない限りは現状維持になるのが自然だ。一方で、一から作るなら全然違う完成形がイメージできるというのも当然あるはずで。現実的には、そう思うたびに都度全部書き直しているとどれだけ時間があっても足りないので、日々費用対効果みたいなものを意識しながら気持ちに折り合いをつけていくしかない。しかしことこのような個人的かつ小さいプロジェクトについては、むしろ積極的に全部書き直すようにしている。

「あくまで僕の場合は」と言っておくけど、一から書くという気になっていないと最善のコードは書けない。すでにある程度のコードを積み上げてしまっている限り、それを利用した上で次の手を選択するという狭い範囲の中で発想が無意識に制限されてしまう。「その状況においては」良い選択ができるかもしれないけど、制限が外れてしまえば第三者的には妥協の産物になる。

書き直すということは一度書いてしまってある程度わかっているものをもう一度書くということで、作る対象に対しての理解度がかなり上がっている状態からのスタートを意味する。やらないといけない仕事や起き得る問題は把握できていて、場当たり的な措置を取らざるを得なかった箇所も覚えている。一度書き終えることではじめて全体的に見渡せるようになって、本当にあるべきだった形がやっとわかってくる。人生は2周できないが設計は2周できる。

そしてこの2周目の経験というのは普段なかなか得難いものだと言える。全部書き直す機会はそうそうない。作ることのフィードバックとして受けた痛みに対して、小手先の対応でお茶を濁すのではなくて、根本的にどうすればこのような問題が起こらないのかを考えた上で、実証することがこのフェーズではできる。全部書き直すとまではいかなくとも、日々の1コミットの裏で積み重ねられる検証や意思決定の数々は紛れもなく設計の結果だろうが、これはまた焦点が別のところにある。真に全体を見るというのは究極的にはやはり全部書き直すことだと思う。

またそのプロジェクトだけの経験に限らず、新たにどこか別の場所で得た知見やコミュニティの中で共有されたものなんかもあるだろう。当時は満足していたコードが、久しぶりに見たらもう酷くダメな出来に見えることもある。そうなるだけの時間を経てきた今の自分が持てる知識のすべてを統合して全部書き直したとき、再構成された設計は見違えるようになるのはもとより、それを経た自分もまた変わっている。

コードの一貫性を壊すのは妥協だが、妥協せざるを得ない状況を作るのは設計である。つねに完全さを目指していれば選択のブレはなくなるが、既存の仕組みとうまく整合性が取れずにハマらない瞬間はどうしてもある。しかしそうなってしまう場面を減らすことはできる。

いつも全部書き直すことはできない。でもその経験のおかげで、新たに作るものであっても、部分的には書き直しの洗礼を受けた完成度に最初から到達できる。書き直しの経験はその場限りのものではなく、さまざまな解釈の可能性を将来に残してくれる。

歩行とか

Fri, 25 Dec 2020 18:25:04 GMT

「歩行 Advent Calendar 2020」を作ったけど、25日中15日しか歩行できなかった。作った当初は本当に25日分全部埋める気でいたけど、実際のところ3日目でいきなり穴を開けてしまっているし、この60%という微妙な達成度が僕の緊張感のなさを絶妙に体現しているようで、なるべくしてなった気がした。

中学、高校と運動部に所属していて、中でも高校では部はそれなりに厳しかったこともあり、体力は結構あった。それだけに、部活を引退してしばらくしてから、あるとき全力疾走ができなくなっていると気づいた落胆はなかなかだった。動きが全然イメージに着いて来なくて、自分がすごくダウングレードしたような気持ちになった。

それからは自発的にトレーニングするようになった。単に運動不足解消というレベルでなく、できるだけ動ける体を維持するために、それなりに。長距離のランニングと短距離のダッシュ、ウェイトトレーニングをやっていたけど、すぐにランニングに主軸を置いて長い距離を速く走るための練習をするようになった。

最初はひたすら長い距離を走ったりしていたけど、いくつか本とかを読んだりしながら、怪我のリスクを減らすために走行距離を抑えながら負荷を高めるためのインターバル走を取り入れたり、有酸素運動による筋肉量の低下を抑えるために並行してウェイトトレーニングをしたりしていた。

しかしまあ皮肉なことに、ふくらはぎを鍛えるためのカーフレイズを行っていたら、ある日そこが肉離れになって動けなくなった。負荷を掛けすぎてしまったのもあるし、冬場だったせいでもあるんだろう。数ヶ月後に予定していたハーフマラソンへの出場も絶たれてしまった。当時の怪我はいまだに寒くなってくると痛むし再発しそうになる。

代わりにウェイトトレーニングに主軸を移した。実家は田舎だったこともあり近所にジムがなかったため、数年分貯め込んだお年玉を使って重量可変式のダンベルとフラットベンチを買って自分の部屋に置き、日々トレーニングに励んでいた。いつも家族からはうるさいと苦情を受けていたが、たしかに今の自分にそういう隣人がいたらブチ切れているし、今では申し訳なく思う。

それから専門学校に進学するために都会で下宿を始めた。いやこれは半分は嘘で、都会で下宿を始められるような学校を選んで、その理由は伏せたまま進学させてもらった。ただこれは入学してから知ったことだけど、その専門学校は近くにある大きなジムと提携していて、1年を通して利用できる契約を3千円という破格で行えることになっていた。相場を知らない人のために言うと、民間のジムだと月に1万円とかはベタなところである。一見大盤振る舞いな感じがするけど、多くの学生は安いからとりあえず契約しておくものの全然通わないので余裕で採算が取れるらしい。

本腰を入れてバーベルを使ったトレーニングを始めたのはそれからだ。理由はよく覚えてないけど、ダンベルよりも重い重量を扱えるしフォームがシンプル、マシントレーニングよりも可動域が広い分より多くの筋肉に刺激を与えられる、プリミティブでかっこいい、みたいな感じだったと思う。基本的に種目はBIG3しかしなかった。スクワット、ベンチプレス、デッドリフトの3つを総称して、トレーニングの王様という意味で一般にそう呼ばれる。当時の僕のバイブルはAthleteBody.jpで、トレーニング内容としてはひたすらBIG3ルーティーンを実践していた。そのジムに通っていた2年間で一番ピークだったときでは、デッドリフトはMAXが140kgだった。ほかはそれほど強くなかったのでよく覚えていない。

ちなみにジムに入場した日数が一定の基準を超えていると学校の単位になるので数がカウントされていたんだけど、在学している2年間は僕の利用日数の多さは学校全体でずっと2位だったらしい。1位の人は毎日風呂だけを利用していたという。

当時はほとんど狂信的に食事に力を入れていて、僕は痩せ型なのでとにかく増量するために異常な量の飯を食べていた。1日に米6合と鶏胸肉600g、プロテインパウダー、ミキサーにかけたほうれん草とか。消化がしんどかったので強力わかもとを飲んでいた。これを半年くらい続けることで体重が8kgくらい増えて人生でもっともデカい状態に到達して、トレーニングでMAXを記録したのもその辺りの時期だったけど、胃は完全に限界だった。もう一日中吐きそうになっていて、でも少しウエッとなると栄養が無駄になってしまうので、どうにかして意識を散らして誤魔化していた。しかしさすがにすぐ無理になった。

就職のために東京へ上京してきたころから、できるだけ食事は普通にするように心がけてきた。量が少なくておいしいものを積極的に選ぶようにしたり。けどしばらく胃の調子はだいぶ悪かったと思う。このままでは改善されないんじゃないかという気もしていたけど、時間が経って少しずつマシにはなってきた。ジム通いは再開したけど、食事は普通にするようにした。それでも今でも少し悪い。

初めてゴールドジムに入会して、設備の充実具合にただただ感動していた。ジムのトレーナーに施設を案内されているとき、設備を見て「すごいですね」と言ったら、「すごいでしょう」と言われた。そのジムはビルの中でいくつかの階に分かれていて、地下2階にフリーウェイトのためのフロアがあり、マジの肉塊しかいない空間なんだけど、その中で僕もバーベルを握り始めることになった。

ただ残念ながら専門学生時代のピークまで到達できたことがない。これは食事のこともあるものの、トレーニングにあの頃ほどの時間を注げなくなったことが大きい。専門学生時代には、月曜・水曜・金曜にはなにがあろうとも絶対にジムに行くと決め込んでいて、なによりもそれを優先していた。授業もせいぜい夕方には終わる。仕事はそうでなくなって、遅くまで残業もすることもあったし、そこからジムで追い込もうという気持ちになれるほど体力が残っていなかった。代わりに週末に通ったりするようになったけど、それでも頻度としてはガタ落ちで、結局トレーニング量の減少には逆らえなかった。

そうしてモチベーションの上がらない中、ある日ジムでデッドリフトをしているとき、普段と違う変な力の入り方のままバーベルを引いてしまい、腰に鋭い痛みが走った。その日はそこで切り上げて帰ってそのまま寝たけど、翌日になるとベッドから起き上がれなかった。そこから数週間くらいはずっと痛くて、違和感は何ヶ月も続いた。その間、能動的な運動はきっぱりやめてしまっていて、長らく復帰できそうにないなと思っていた。

それをきっかけに腰周辺のいろんな部分が痛むようになってきた。それまでは意識したことすらなかったんだけど、寝るときに肩を下にして寝ると翌日の腰の調子が悪くなってしまうようになった。調べてみるとこの姿勢は腰への負担がそれなりに大きいらしい。あと椅子に座っている間ずっと鈍い痛みが続いたりした。この時期はずっとこの辺の不調にイライラしながら生活していた記憶がある。

それから結構な頻度で整体に通うようになった。だいぶ回復して来たような気がしたので、試しにジムを再開してみようと軽く腰を動かしたら、「ヤバい、死ぬ」という感じになって、これには時間が掛かると悟った。それからも整体へは通っていたが、この辺りでコロナ禍に見舞われて通院をやめてしまった。ジムへもそれ以来行ってない。

家から出るなと言われて、「いやあ僕はまったくそんなこと余裕ですけどね」とか思っていたら、異常に体力が落ちて最寄り駅まで歩いただけで筋肉痛になるようになった。寝てもすぐ起きてしまうし、明らかに生活に支障が出ていた。一方で腰の調子は、あの日から2年近くが経過してだいぶマシになっていた。

毎日歩いた方がいい、外
— 全部入りHTML太郎 (@_yuheiy) September 18, 2020

そこで僕はこう考えて、ごく短い距離から、できる限り毎日歩くことを始めた。最初は駅まで行って帰ってくるだけだったけど、その向こう側まで余計に歩くようにしたり、それを2往復するようにしたりだとかで、1日に8km程度歩く毎日が続くようになった。その状態で1ヶ月くらいは筋肉痛になったり疲れ果てたりしてたけど、歩き始めてから今日までで3ヶ月くらいが経ってだいぶ余裕が出てきた。

日常の中で筋力的な向上を実感した瞬間として、僕は昔から5本指の靴下を好んで履いていて靴下は全部これなんだけど、履くのがスムーズにいかない。ちゃんと履けるまでちょっと時間が掛かるので、弱っていたころにはこれが本当にしんどかった。これを今では立ったまま、片足立ちの状態でできるところまで回復した。全盛期にはこの片足立ちのバランス感覚にかなり自信があったんだけど、これが少し戻ったみたいで嬉しい。

ついでに歩くだけでは無酸素運動が不足しているので、2日に一度腕立て伏せをするようになった。これも最初は全然できなかったけど、最近では普通にすると負荷が足りないのでプッシュアップバーを使って、それもかなりストリクトなフォームで行えるようになっている。これに関してもかなり筋力が戻ってきた。

こういうルーティンには1時間半くらい掛かってしまっているんだけど、リモートワークで通勤時間がなくなったおかげでなんとか相殺できている。もっとも、通勤してたら不要な運動だったかもしれないが。

ここまで書いてきて、なんでこれを書き始めたんだっけと思ったけど思い出せない。ブログは最近あんまり書けていない。これは偶然というより、実はEvery Layoutの翻訳が遅れている罪悪感から精神的なアレで書きづらくなっているという理由でして、まだ出せてないことについては本当にすみません。進めてはいます。という感じなんだけど、なぜか急に筆がノッてしまったので書いてしまった。ついでにEvery Layoutについて言えば、ちょうど最近やっている仕事でこの理論をかなりうまく活用できていて、もしかしたら「実践的レイアウトプリミティブ」のその先の発展形の話をどこかの機会で出せるかもしれない。そんな気がする。

「JavaScript sprinkles in Basecamp turned Stimulus」の雑要約

Tue, 03 Nov 2020 08:59:05 GMT

「JavaScript sprinkles in Basecamp turned Stimulus」より。Stimulusの設計意図を理解できる貴重な資料なのでまとめた。

DHHにとってプログレッシブエンハンスメントとは、コンテンツのプログレッシブ性を実現するためというよりは、アプリケーション開発のための道標のようなもの。ベースとしてのHTMLはまずサーバーに生成させて、動的部分としての少しの差分をJavaScriptに扱わせる。BasecampやGitHubのように動的部分の少ないアプリケーションにとってはそれが適切なやり方。React/ReduxやAngular、そのほかクライアントサイドのMVCフレームワーク等を試してきたが、それによってプロダクトのコードが良くなることはなかった。

BasecampにあるJavaScriptを調査して、どのような慣習があるか、それを踏まえてどのようなスタイルが受け入れられるかのインスピレーションを得た。メンタルモデルに合わせたやり方をフレームワークによってバックアップされるとより良いコードが書けるようになるはずであると。

StimulusによってBasecampのコードに見られた特定の問題や悪いパターンを解決したかった。まず要素選択の方法について。ある要素の親の親の親を取得するなどしてDOM構造にべったりだった。誰かがマークアップを少し変更するとこれは簡単に壊れてしまう。CSSクラスをターゲットにするパターンもあったが、CSSクラスはスタイリングを関心とした名前を持っているので、JavaScript側の関心と合わない。スタイル変更のためにマークアップを変更したりしてしまうとすぐまた壊れてしまう。

Stimulusではコントローラーに固有なターゲット名をつけることにした。選択する要素は明示的になり、コントローラーの中で好きな位置に移動することができて、input要素でもbutton要素でもspan要素にでもアタッチできる。それだけでなく、HTMLを読んだときに、どの要素がどの振る舞いに使われるのかという目的がかなり明確になる。

またBasecampでは同じような機能を実装する重複するコードがいくつも存在していたが、CSSクラス名やHTML要素名と密になっていたので汎用化できなかった。Stimulusによってマークアップと疎になることで再利用性が獲得できる。Reactのようなコンポーネント指向のJavaScriptでも、振る舞いがテンプレートから切り離せなくなって再利用性がなくなるので好きじゃない。

次にアクションについて。これまでBasecampが行っていたのは、HTMLにdata-behavior属性と機能名を記述しておいて、イベントが発火されたときにこれらの属性を読み取って実行するというもの（Code Spelunking in the all new Basecamp）。DHHとしてはこれではHTMLを見ても何をやっているのかわからないのが嫌だった。このボタンをクリックするとどういうことが起こる、というのを明示的にしたかった。なのでHTMLに直接JavaScriptのイベントハンドラを記述するようにした。これでいちいちJavaScriptのコードを読む必要がなくなった。

これらをコントローラーというコンセプトのもとにカプセル化した。Basecampのさまざまな振る舞いを抽出するのに、ターゲットとアクション、コントローラーというシンプルな3つのコンセプトだけで十分だったのには驚いた。

また条件に応じてCSSクラス名を追加するような機能はどのようにして汎用化できるのかというと、StimulusのData MapsによってHTMLのdata-*属性に個別のクラス名を渡せるようになっている。これによってデザイナーが些細な変更のためにコントローラーを触る必要もなくなる。コントローラー内にはCSSクラス名を直接含めるべきではない。

非常に複雑なUIを作ろうとしているのであればReactなどのような重いフレームワークは理にかなっているが、一方でGitHubやBasecampのようなアプリケーションが取り組んでいるフレームワークは過小評価されているように感じる。昨今のJavaScriptフレームワークの盛り上がりによって、サーバーはJSONを生成するだけのものになって、クライアントサイドでもふたたび以前のサーバーと同じような仕事をするためにいろんなことをいちからやり直している。Basecampでは、必要があればサーバーが返したHTMLの破片をStimulusが使う。

BasecampのコードベースをStimulusへ移行するに当たって、HTML内に自己文書化されたコードが記述されるようになることでドキュメントの量をかなり減らすことができた。大量のコードコメントが意味するのは、複雑なコードを書いてしまったことか、あるいは抽象化されることを待っている一連の規則の存在である。

Stimulusでは状態はHTML上に保持されている。コントローラーのルート要素にデータ属性として状態を格納できるが、基本的にはこれは最小限にする。多くの場合、HTMLに付与されているCSSクラス名や属性の有無などで大抵の状態は表現できる。

Turbolinksは便利だが、jQueryや通常のJavaScriptの実装と組み合わせるのに難があって避けられていた。StimulusはMutationObserverを採用して動的なページ書き換えに対応することによってこのような問題をきれいに解決できた。

しかしTurbolinksは再評価されるだろうか。ある痛みは何か別の利益を得るためのトレードオフとなるが、まずメリットを得られるかわからない場合はコストが高すぎるし、メリットがゼロだと感じるならその人は自分には価値がないと言うだろう。そしておそらく、昨今のモダンなJavaScriptのフレームワークを採用することで、かなりのコストもかかってしまうことに気づく人も増えていて、それらを経験した人は、これはもうただただ苦痛だったと語るだろう。Basecampが取り組もうとしているのはこの痛みを取り除くことだが、あなたがその痛みに苦しむまではBasecampがやろうとしていることを十分に理解できないだろう。痛みを知るまでは評価できないだろう。

実際の痛みから切り離されたベストプラクティスは意味をなさないことがよくある。人はそれが必要なときになるまで自分ごとにする準備ができていない。誰かが何かに苦しむまで価値は理解されない。

しかし私たちは協力して歴史的背景を人に伝えることもできる。The Origin of Stimulus（和訳）はそれを意図したもの。ある技術を採用するためには「FacebookがReactを使っているから」だけでは十分な理由にならない。Basecampで解決しようとしているのとは違う問題と背景がある。Facebook自身でさえ、最初からいま確立されているやり方で始めてしまっていれば、Facebookそのものが存在しなかっただろう。

Basecampがこれらを推進しているからといって、誰もがこれを使うようになるという幻想は持っていない。Reactなどモダンなツール群には勢いがあって、そういうものだと思うし、これらの支配に勝つ必要はない。開発コミュニティは市場シェアがすべてであるような考えを持っていることがあるが、ウェブの素晴らしさはその多様性である。バックエンドは必要に応じてあらゆる実装言語で書くことができて、だからより多くの人が関わることができるし、自分に合うものを選択できるので、このおかげでDHHはRubyとRailsに出会うことができた。さまざまなパラダイムが増殖する中で、トランスパイラなどを用いて、JavaScriptの世界でもこの多様性が進歩すれば良いことだと思う。

画像ファイルもCSSやJSファイルと一元化したディレクトリで管理する

Fri, 18 Sep 2020 09:16:35 GMT

ウェブサイトのソースファイルはファイル形式にもとづいてディレクトリ分けされている場合が多いと思う。たとえば次のように。

.
├── dist/
│   ├── images/
│   │   ├── components/
│   │   │   └── header/
│   │   │       ├── background.png
│   │   │       └── logo.png
│   │   └── icons/
│   │       └── chevron.svg
│   ├── scripts/
│   │   └── main.js
│   ├── styles/
│   │   └── main.css
│   └── index.html
└── src/
    ├── images/
    │   ├── components/
    │   │   └── header/
    │   │       ├── background.png
    │   │       └── logo.png
    │   └── icons/
    │       └── chevron.svg
    ├── scripts/
    │   ├── components/
    │   │   └── header.js
    │   └── main.js
    ├── styles/
    │   ├── components/
    │   │   └── _header.scss
    │   └── main.scss
    └── index.html

images・scripts・stylesディレクトリがルートにあって、ファイルはまずそのいずれかに格納される。各ディレクトリの中では、その中にサブディレクトリを作成して、あるファイルが特定の目的にもとづいていることを表現していく。

ここからファイル形式によるディレクトリ分けを取っ払って、最初からその目的にもとづいた構造にしたい。たとえばこうなる。

.
├── dist/
│   ├── assets/
│   │   ├── components/
│   │   │   └── header/
│   │   │       ├── background.png
│   │   │       └── logo.png
│   │   ├── icons/
│   │   │   └── chevron.svg
│   │   ├── main.css
│   │   └── main.js
│   └── index.html
└── src/
    ├── assets/
    │   ├── components/
    │   │   ├── header/
    │   │   │   ├── background.png
    │   │   │   └── logo.png
    │   │   ├── header.js
    │   │   └── header.scss
    │   ├── icons/
    │   │   └── chevron.svg
    │   └── main.js
    └── index.html

ファイル形式で区別するのをやめて、すべてのファイルをassetsディレクトリに一元化するようにした。ファイルを探したり編集したりする上ではまずファイルが何のために存在しているかが重要になるし、近い場所に集まっている方がファイル同士に関連性を見いだしやすい。

ちなみに、componentsディレクトリの直下にheader.jsとheader.scssが配置されている点については気になる人がいるかもしれない。たぶん次のような構造の方が一般的だろう。

.
└── components/
    └── header/
        ├── header.js
        ├── header.scss
        ├── background.png
        └── logo.png

しかしこれは、特定のコンポーネントに含まれるファイル数が少ない場合には冗長になる。今回の例では、アプリケーション的ではなくドキュメント的なウェブサイトのソースコードを想定していて、そういう場合、JavaScriptファイルを必要としないCSSだけのコンポーネントがほとんどになったりする。

.
└── components/
    ├── breadcrumb/
    │   └── breadcrumb.scss
    ├── button/
    │   └── button.scss
    ├── card/
    │   └── card.scss
    ├── footer/
    │   └── footer.scss
    └── header/
        ├── header.js
        ├── header.scss
        ├── background.png
        └── logo.png

すると、複数ファイルを必要とするごく一部のコンポーネントに合わせたディレクトリ構造を実現するために、その他大多数のコンポーネントを取り扱うための手間が増えてしまう。ならば逆に複数ファイルを必要とするコンポーネントの方を例外として捉えて、単一ファイルでの完結が基本の構造にした方が合理的。

.
└── components/
    ├── header/
    │   ├── background.png
    │   └── logo.png
    ├── breadcrumb.scss
    ├── button.scss
    ├── card.scss
    ├── footer.scss
    ├── header.js
    └── header.scss

このようなディレクトリ構造を実現するためにはこれに合わせたビルド設定を行わなければならない。ブラウザに読み込まれたアセットファイルのキャッシュを破棄するために、ファイル名にハッシュ文字列を加えるCache bustingが利用できると望ましいので、その利用も前提として解説する。

webpackで画像などのファイル名をハッシュ化する場合、そのファイル名を指定するためには直接パスを書き込むのではなく、webpack経由で読み込んだデータを割り当てる必要がある。

NG:

// `src/assets/components/header.js`

const img = document.createElement('img');
img.src = '/assets/components/header/logo.png';

OK:

// `src/assets/components/header.js`
import logo from './header/logo.png';

const img = document.createElement('img');
img.src = logo;
// -> `/assets/components/header/logo.[contenthash].png`

CSSファイル内のurl()関数からもファイルを参照するためには、CSSファイル自体もwebpack経由でビルドする必要がある。そのように設定すれば次のように参照できる。

// `src/assets/components/header.scss`

.header {
  background-image: url('./header/background.png');
  // -> `/assets/components/header/background.[contenthash].png`
}

またwebpackの外からファイル名を参照したい場合には、Webpack Manifest Pluginを利用するとファイル名の対応付けをJSONファイルとして出力できる。出力されるJSONファイルを読み込めばwebpackの外の仕組みからもファイル名を参照できるようになる。

これらを前提とするとwebpack.config.jsはだいたい次のような感じになる。いろいろ簡略化している。

const path = require('path');
const sass = require('sass');
const Fiber = require('fibers');
const MiniCssExtractPlugin = require('mini-css-extract-plugin');
const TerserJSPlugin = require('terser-webpack-plugin');
const OptimizeCSSAssetsPlugin = require('optimize-css-assets-webpack-plugin');
const ManifestPlugin = require('webpack-manifest-plugin');

module.exports = {
  context: path.join(__dirname, 'src', 'assets'),
  entry: './main.js',
  output: {
    path: path.join(__dirname, 'dist', 'assets'),
    filename: '[name].[contenthash:8].js',
    chunkFilename: '[name].chunk.[contenthash:8].js',
    publicPath: '/assets/',
  },
  module: {
    rules: [
      {
        test: /\.(scss|css)$/,
        use: [
          MiniCssExtractPlugin.loader,
          'css-loader',
          {
            loader: 'sass-loader',
            options: {
              implementation: sass,
              sassOptions: {
                fiber: Fiber,
              },
            },
          },
        ],
      },
      {
        exclude: [/\.(js|mjs)$/, /\.json$/, /\.(scss|css)$/],
        use: [
          {
            loader: 'file-loader',
            options: {
              name: '[path][name].[contenthash:8].[ext]',
            },
          },
        ],
      },
    ],
  },
  optimization: {
    minimizer: [new TerserJSPlugin(), new OptimizeCSSAssetsPlugin()],
  },
  plugins: [
    new ManifestPlugin({
      fileName: path.join(__dirname, 'dist', 'webpack-manifest.json'),
    }),
    new MiniCssExtractPlugin({
      filename: '[name].[contenthash:8].css',
    }),
  ].filter(Boolean),
};

そしてmain.jsにはこのように書いておく。

// `components`ディレクトリ直下にあるすべてのSCSSファイルを読み込む
importAll(require.context('./components', false, /\.scss$/));

function importAll(context) {
  context.keys().forEach(context);
}

// webpackのモジュールからは読み込まれていないファイルもビルドに含めることで、
// `assets`ディレクトリに配置したあらゆるファイルを`webpack-manifest.json`経由で参照できるようにする
require.context(
  '.',
  true,
  /\.(jpg|jpeg|png|gif|eot|otf|webp|svg|ttf|woff|woff2|mp4|webm|wav|mp3|m4a|aac|oga)$/,
);

Sassファイルを読み込む上での注意点として、main.scssのようなSass用のエントリーポイントを作成せずに、JavaScriptファイルからファイルをひとつずつ読み込むようにしておいた方が良い。Sass固有のモジュール機能を使うと、css-loaderに渡ってくる前にコンパイルが済んで結合されてしまうので、url()関数で参照するファイルのパス解決がすべてmain.scssの位置を基準に行われてしまう。するとcomponentsディレクトリ内のファイルにおいてもmain.scssの位置からパスを記述しなければならなくなる。

次に、webpackのモジュールからは読み込まれていないファイルも、出力されるwebpack-minifest.jsonから参照できるようにするために、あらゆるファイルが自動的に読み込まれるようにしておく。もしこの設定を行わない場合も、JavaScriptからimportされたり、CSSのurl()関数に指定されれば、対象のファイルがwebpackのビルドに含まれつつJSONファイルにもパスが追加される。しかしそれ以外のファイルはビルドには含まれなくなってしまうので、JavaScriptやCSSから読み込まれていないファイルをwebpackの外から参照できなくなってしまう。

Jestを利用している場合、JavaScriptファイルから画像ファイルなどを読み込むとエラーになるので、jest.config.jsに次のように設定しておくと回避できる。

module.exports = {
  moduleNameMapper: {
    '\\.(jpg|jpeg|png|gif|eot|otf|webp|svg|ttf|woff|woff2|mp4|webm|wav|mp3|m4a|aac|oga)$':
      '<rootDir>/src/assets/test/__mocks__/fileMock.js',
  },
};

src/assets/test/__mocks__/fileMock.js:

module.exports = 'test-file-stub';

設定ファイルの詳細な書き方などは、前述したような設定に開発用ビルドなども含めたボイラープレートを公開しているので参照されたし。

ブログ投稿のハードルと雑さについて

Sun, 16 Aug 2020 09:33:36 GMT

個人的な話、Twitterにいろいろと長文も書いたりするようになってからブログをあまり書かなくなった。タイムラインのツイートはすぐに流れていく分、今パッと思いついた話とか、まだ十分整理されてないようなテキストを出しやすい。

アイデアをTwitterに書きやすいのは取り返しがつかないからだと言ってる人がいた。まず最初のツイートをすると、それが少なくとも何人かに読まれてしまった事実は取り返しがつかなくなるので、その責任の引き受けから連鎖してほかのものも書けると。その話を読んで、ツイートはリアルタイムにしゃべることに似ている気がした。一度しゃべり始めてしまった以上は、とりあえず着地するまではしゃべりを続けないといけないというのと似ている。

そうしたとりあえずのものがツイートとして消化されてしまうとすれば、ブログを書くためには「あえて」そうする動機が必要になってくる。「あえてのもの」は即席じゃないし、ある程度考えられていてまとまっている。しかしそれを書くためには、考えがキリのいいところまで到達したタイミングを見計らわなければいけない。半端なタイミングで書いてしまうと公開後にすぐ継ぎ足したくなる。つまりすぐ古くなる。

こうした問題に対して、Scrapboxは完成をなくす形でアプローチしている。書くことのすべての段階においてつねに最新の状態で公開されていて、完成を意味する印づけがない。ずっと途中なのでいつでも更新できる。考え続けるためのデザイン。

一方で僕はブログ投稿にはけじめをつける意味も感じている。その時点での自分のスナップショットを取って、いったん忘れるために考え終わらせる。適当な大きさの考えの塊を切り取って保存する。そして仮想メモリに空きを作って次に行く。

これは一見つねに更新し続ける考え方と相反している。しかしScrapboxのように塊をノードとして切っていくのは僕にとって難しかった。その切り取り方自体がもしかしたら毎日変わっていくかもしれないようなもので、日々ページに差分を加えていく運用よりは、捉え方も語り方もまるごと変わった新しい塊を都度作っていく方が向いているように思えた。塊として一度吐き出してしまえれば、忘れたつもりになっても自分の中ではある程度覚えているし、過去のその断片を足がかりにして今の自分が勝手に更新されている。もっともこれがどの程度スケールしているかはわからないし、自分ひとりで書いていく場合という前提の話でもある。

そんなわけで僕は都度完成させていくやり方を好んでいる。そのためにはツイートでは単位が小さすぎるし、連続ツイートでも書き捨ての向きが強すぎる。だからブログ投稿に執着しているが、依然としてそこにはハードルがある。

そこで僕はブログ投稿に雑さを取り入れようと意識してきた。ある程度キリがいいところまで来た感じがすれば——それもそこまでちゃんとしてなくても——、完成度をあまり高めないでも気楽に出せるように。僕は特に、ブログの投稿先にちゃんとしている感じがあると、どうしてもちゃんと書かないといけないモードに入ってしまう。ブログ投稿の側（がわ）であるところのブログという体裁そのものに力を入れてしまうと、ウェブ制作者としてはやはりかなり意識してしまう。ちゃんとしてないものを出しにくくなる。さらに体裁というのも古びてくるので更新したくなるが、これにはそれなりのリソースを吸い取られて、結果投稿自体をする気がなくなってしまう。僕はこれまでに自分用の個人ブログを10近く作っては捨ててきた。

だから側を見て見ぬ振りするためにあえてレンタルブログ（死語？）をしばらく使っていた。テーマもあらかじめ用意されているものの中から選んで、カスタマイズのためにオリジナルのCSSは書いたりしないという縛りつきにした。わかる人にはわかると思うが、ブログひとつ作るのでも徹底的にやろうとすると際限がなく、サイト生成用のスクリプトを延々とリファクタリングし続けたり、かっこいい管理画面を作ろうとしようしたりしてしまう。しかしレンタルブログは適度に機能が制限されていて、作るためにほとんど労力がかからずそれほど愛着も湧かないので、とりあえず書き続けるためにはちょうどいい代物だった。

しかしながら、ちょっとした「自分の」サイトを作りたいという人が生まれながらにして持つ欲求にはやはり抗えず、レンタルブログを使い続けながらもその気持ちだけが膨らんできた。完全にはコントロールできない外部サービスに自分のコンテンツを預けている不安も少し大きくなってはいる。ついでにサイトを作るコストも減っている。また出先ではレンタルブログの管理画面を使って記事の編集をする機会もあったが、引きこもりがちになってから書くことをローカル環境でやりやすくもなっているのでGitベースにするのもありだ。後々管理画面が必要になったらNetlify CMSでも入れればいい。

そうは考えつつも実際にこれを実行するきっかけになったのは、はてなブログマニアだと思っていた友人がはてなブログをやめたことだ。これも時代の流れなのかなみたいな自分への雑な言い訳がこのおかげでできるようになった。

自分のサイトを作りたいとは言いつつも、一応1ページだけのちょっとした自己紹介サイトのようなものは持っていた。この自己紹介サイトにサブドメインを生やして分離した別サイトを作ろうかとも思ったが、同一サイトを拡張する形にした。別サイトとして分けると、そこに専用性を感じて形式張ってしまうし、飽きたらサブドメインごと捨てるのが気軽にできてしまう。自分でもある程度参照する機会があるこのサイトにあえてブログを組み込むことで、意識する場面を増やしたり取り返しがつきにくいようにした。

ブログを組み込む前からこのサイトには、自分の投稿したさまざまな場所に散らばっているリソースを集約させる役割を持たせていた。以前のレンタルブログのほかにも、別のところで書いた記事とか、発表したスライドだけ独立させたページとかがいくつかあって、それらもスナップショットとして見返す場面があるので一覧できるようにしていた。列挙するほどでもないものは除外して主要なものだけを。そのリソースについてもいろいろなフォーマットがあって、メディア別に分類したり、「発表資料」のようなカテゴライズをするにも無理があったので、汎用的なビューにしてすべてを一元化して扱っていた。

サイトに生えたこのブログもその雑多なフォーマットの一部であって、また以前と同様に主要なリソースだけピックアップする形を継承したかったので、主要なリソースの一覧は従来通り維持しつつ、このサイトの投稿の一覧は別に作ることにした。

ついでに取り返しのつかなさと関連して、URLは未来永劫変わらないことが理想なので、後から気が変わっても大丈夫なようにサイト構造をURLに反映させないようにした。サイト内にあるブログカテゴリのURLであれば、

https://yuheiy.com/blog/20200817-zatsu

のようにサイト構造がパスとして表現される場合がよくあるが、

https://yuheiy.com/20200817-zatsu

というように階層を取っ払ったフラットなパスにした。将来的に「ブログ」という括りをやめたくなったとしてもこうしていれば問題ない。あとURLに日付を入れずにタイトルだけにする運用にも憧れていたが、実際にやってみて大変だったのでやめておいた。

もともとこのサイトが規模的にショボかったので、なにか増やせるならなんとなく増やしたいような気持ちもあった。実はこれが一番大きい動機かもしれない。

Tailwind CSSの設計思想を業務に活かす

Thu, 09 Jul 2020 00:00:00 GMT

UIにおける見えるけど利用できない非活性な領域の実装とinert属性について

Tue, 30 Jun 2020 00:00:00 GMT

CSSのユーティリティクラスと「関心の分離」——いかにしてユーティリティファーストにたどり着いたか（翻訳）

Mon, 25 May 2020 00:00:00 GMT

レイアウトプリミティブ

Mon, 16 Dec 2019 00:00:00 GMT

「代替」の意味を探して

Tue, 10 Sep 2019 00:00:00 GMT

レスポンシブデザインに見るデザインカンプと実装との溝

Mon, 26 Aug 2019 00:00:00 GMT

mix-blend-modeとスタックコンテキスト

Mon, 29 Apr 2019 00:00:00 GMT

制作者のためのHTML

Fri, 08 Mar 2019 00:00:00 GMT

ユーザー自身の道具になるためのインターフェイス

Mon, 18 Feb 2019 00:00:00 GMT

ページ内リンクの実装から考える、a要素のclickイベントとその振る舞い

Fri, 26 Oct 2018 00:00:00 GMT

yuheiy

段落間の余白の大きさを正しく均等に見えるようにする

Space Toggleハックを使ってcolor-schemeに応じた値の切り替えを実現する

参考資料

画像を囲うボーダーの色を半透明にしてコンテンツに馴染みやすくする

Astro Meetup Japan v0: パネルディスカッション

Tailwind CSSにおけるデフォルトのspacingとサジェストを無効化する方法

コンテンツに自律的に適応するレイアウトとコンポジション、アップデートされたレイアウトプリミティブ

レイアウトプリミティブ

パターンの紹介

Flow (Stack)

参考資料

Wrapper (Center)

参考資料

Cluster

参考資料

Repel

Sidebar

参考資料

Switcher

参考資料

Grid

参考資料

レスポンシブデザインの「間」を適切に設計するためのフルイドタイポグラフィとグリッドシステムの考え方——キャンバスインからコンテンツアウトへ

フルイドタイポグラフィ

Utopia

キャンバスインからコンテンツアウトへ

小さく始め、徐々に大きくして主要なブレークポイントを選択する

グリッドシステムとの向き合い方

参考資料

iframe要素の中身のコンテンツに応じて属性を自動設定できるAstroコンポーネントを作る

クリックしやすいターゲットエリアを実装する #web_ui_devs

ターゲットエリアを広げる工夫

iOSにおけるターゲットエリア

ターゲットサイズの基準

押せそうな場所は押せるようにする

無闇に広げすぎない

今回の勉強会についての余談

UIとフロントエンド技術が好きなエンジニア→デザインエンジニアを募集しています

package.jsonのdependenciesをアップデートする技術

Figmaのstylesをもとにして「Tailwind CSSのテーマ」「tailwind-mergeの設定」「Storybookのドキュメント」などの各種ファイルを自動生成する

Tailwind CSS 4をShadow DOM内で動作させる方法

Tailwind CSS 4において意図せずoutline-colorがtransitionしてしまう問題の対処法

1. transition-propertyのデフォルト値を上書きする

2. transitionユーティリティの対象プロパティを個別に指定する

3. フォーカス可能な要素すべてのoutline-colorプロパティにデフォルト値を指定する

4. すべての要素のoutline-colorプロパティのデフォルト値を上書きする

サードパーティウィジェットのアクセシビリティ

VSCodeのGenerate alt textを使って代替テキストを自動生成する

自動生成の使いどころと注意点

Generate alt textの実装を調べる

aria-label属性は何にでもつけられるわけじゃない

5.2.8.6 名前を付けることができないロール（名前は禁止されている）

当エンジニアブログで実施したアクセシビリティ改善の方法についての解説

アクセシビリティ学習の手引きとしての入門講座

ブロックリンク（もしくはカードUI）のアクセシビリティ上の問題と解決策

参考文献

リンクの下線の視覚的ノイズを軽減する

参考情報

特定の要素の外側すべてをinertにする

「段落と段落の間」と「段落と画像の間」の余白を均一にする

僕のホームページ遍歴

ハムスター島

リヴリーアイランド

ネパワ界

ライブドアブログ

ポートフォリオサイト

モダンフロントエンド

ベースライン

line-clampとhanging-punctuationを併用するときはoverflow:hiddenの代わりにclipを使う

なぜ僕はデザイナーの作ったデザインを「見づらい」と感じてしまうのか

npmパッケージの代わりに独自の仕組みを構築して定数ファイルを配布する運用に切り替えた経緯と移行プロセス

npmパッケージじゃない仕組みで共有ライブラリを管理する

Feature-Sliced Designのディレクトリ規約をAstroのプロジェクトに適用する

yuheiy

ソースコードを解析して社内向けUIライブラリの使用状況を自動で集計する

Astroのアセットをdynamic importで読み込んで間接的な変数をなくす

日本語におけるtext-wrapプロパティの運用

文節区切りでの改行の実現

balanceとprettyの使い分け

1. `transition-property`のデフォルト値を上書きする

2. `transition`ユーティリティの対象プロパティを個別に指定する

3. フォーカス可能な要素すべての`outline-color`プロパティにデフォルト値を指定する

4. すべての要素の`outline-color`プロパティのデフォルト値を上書きする

`balance`と`pretty`の使い分け

`render`メソッドの実装

`useArgs`フックの使用

`useArgs`フックの問題

`as` prop

`asChild` prop

自前のコンポーネントに`asChild` propを組み込む

Ariakitにおける`render` prop

Base UIにおける`slots` propと`slotProps` prop