1.125 (v9.31.0)

巨大なハイパーリンク

まず、かつてTwitterとして知られていたプラットフォームへ投稿する時に使う、短めの概要を別に作るようにする。それに使うだけではもったいないので、ホームの投稿一覧をリストからセクションに変えて、そこでも使うようにする。その流れでsection要素全体をハイパーリンクにするようにし、その結果CSSが複雑になる。ここで言う「複雑」とは、やりたいことと実装に大きな乖離があり、レンダリング結果とコードのどちらからも互いに見通しが悪いというような意味だ。

親のa要素が持つtext-decorationプロパティーを、子孫要素で上書き(に近いことが)できるのに削除できないことによる。この場合だと日付や短い概要の下線を消したいだけなのに、一旦すべて消してから見出しでのみ改めて引くという大回りな実装になってしまう。何を言っているのかわからないかもしれないし、なぜそうなのかもわからないかもしれないし、正直なぜそういう仕様になっているのかは僕も知らない。まだまだ世のウェブサイトで「続きを読む」やら「Read more」やらが多い理由は、最終的にこの辺に求められるのではないかと思っている。

HTML側でsection要素の各子孫要素へa要素をばらまくと、それぞれにtabindex属性が必要になるし、各子孫要素の外側の余白がハイパーリンクではなくなるし、CSSは複雑なままだし、良いことが無い。消したい要素のみdisplay: inline-blockにする(仕様的に言うならatomic inlineにする)という手段もあるが、目に見えない何かが壊れそうな気がする。

また、この過程でCSSを簡単にするため:has()を解禁したが、再封印する。Firefox ESRを使っているわけではないが、これを安全ラインとしたい気持ちになっている。年1回くらいは更新されるようなので、そうそう時代遅れとはならないし、良い落としどころであり、かつ忘れがちなFirefoxのことを思い出す役にも立つ。たまにFirefoxだけで実装されているものをうっかり使ってしまい失敗することもある(overflow-inlineプロパティーでやらかした)。

fs.glob()

内部的にはfs.glob()への書き換えがある。isaacs/node-globパッケージでは配列でPromiseが履行されるが、fs.glob()ではAsyncIteratorで返ってくるので、そのまま置き換えることはできない。AsyncIteratorをきちんと扱うように書き直すか、Array.fromAsync()で配列に直す。配列をPromise.all()とArray.map()で並行処理をするように書いていた場合は、Array.fromAsync()の第二引数にArray.map()に渡していた関数を指定するだけで良い。

import fs from "node:fs/promises"
import { glob } from "glob"

const toLowerCase = (str) => str.toLowerCase();

const isaacsGlob = async () => {
  const files = await glob("**/*");
  return Promise.all(files.map(toLowerCase));
};

const fsGlob = async () => {
  const files = await fs.glob("**/*");
  return Array.fromAsync(files, toLowerCase);
};

Fluid Typographyの見送り

いわゆるFluid Typographyなどと呼ばれている描画領域に応じて文字サイズが変わる機能も復活させていたが、結局はまた見送る。利用者の文字サイズ設定には追随するものの、その動機とはうまく噛み合っていないと感じるからだ。利用者が文字サイズを変えているのなら、Fluid Typographyが行う読みやすさの提供は利用者が既に行っていると見做せると思う。

また、rem単位での実装とすると、大きくしているとそれに応じて文字サイズが二重に大きくなってしまうし、小さくしているなら忌避したはずの標準の大きさをいとも簡単に超えてしまう。もちろんpx単位で実装した場合はそういう問題は起きないが、文字サイズの設定を完全に無視する。どちらの場合でもウェブサイトのさじ加減として許せる範囲を超えていると利用者が感じてしまうかもしれない。

このウェブサイトが112.5%くらいに抑えている理由もこの辺りにある。これなら利用者が12pxくらいにしていても13.5px、32pxにしていても36pxに抑えられる。小さくしている場合に既定の16pxを超えることはまずないし、大きくしている場合でも6px以上巨大化することはまずない。おおむね「さじ加減」として許容されるのではないかと思う。

clamp()などでinitialキーワードを利用できれば、Fluidしつつユーザー設定とも比較できるので、うまく馴染ませられそうだが、できないものはできない。メディア・クエリーで利用者の文字サイズ設定が引ければ良いのかもしれない。アクセシビリティーという観点からの実装になりそうなので、例えばprefers-text-sizeメディア特性などがあり、prefers-contrastメディア特性のようにno-preferenceという値を取れれば、その中でのみFluid Typographyを実装できるだろう。現状では、JavaScriptを使って既定の16pxではなさそうな場合はFluidしない、というあたりが現実的な落としどころだろうか。

:root {
  --ratio-1: calc((3 * 3) / (2 * 2 * 2));
  --ratio-2: calc(var(--ratio-1) * var(--ratio-1));
  --ratio-4: calc(var(--ratio-2) * var(--ratio-2));

  font-size: clamp(
    var(--ratio-1) * 1rem,
    1rem / var(--ratio-1) + 1vi / var(--ratio-4) / var(--ratio-2),
    var(--ratio-4) * var(--ratio-2) * 1rem
  );
}

実装は上記のようなコードになっていた。すべて計算されていて楽しい、というくらいしかない。文字サイズの拡大は750pxくらいから始まり、3700pxくらいで最大値に到達する。ブラウザーの文字サイズ設定が既定の16pxの場合、横長で幅1280pxの画面だと20pxくらい、幅1920pxの画面だと24pxくらいになり、3700pxくらいで最大値の32pxくらいになる。Firefox ESRが更新されて、CSSの計算でpow()が気軽に使えるようになると読みやすくなりそうだ。