動機

もともとはNHK放送文化研究所の『NHK漢字表記辞典』を基準にしたルールがほしかったという事情があります。

「新用字用語辞典の概要まとまる（１） | ことば（放送用語） - ことばの研究 | NHK放送文化研究所」のPDFを見ると分かるように、NHKの基準は常用漢字とは異なっています。

ほかに、日本新聞協会の新聞用語集（2010年版, PDF）を見ると、新聞常用漢字は常用漢字の一部を使わないようにしたり、特定の熟語の場合は使えるように、などとなっています。

こういった状況に対応できるようなtextlintルールがほしかったのです。

とはいえ、必要な漢字セットを更新し続けるというのも自分にはできそうになかったので、いくつかの漢字プリセットを用意し、そこから漢字を除外したり追加したりできるようにしました。
熟語の対応は、特定パターンの場合は許可するオプションを追加して対応しました。

設定例

リポジトリのREADMEにも似たものがありますが、オプションの例を出します。
次のコードはtextlintの対象とするテキストです。

職権濫用の諜報から得た情報です。
川が氾濫したそうですが、今日のおかずは野菜炒めです。炒飯もあります。

豆を炒るのは明日です。

むちゃくちゃな文章ですが気にしないでください。
これに対して当ルールを初期状態ままtextlintを使うと次のような結果が得られます。

1:6   error  「諜」は許可されていない漢字です。  ja-allowed-kanji
2:22  error  「炒」は許可されていない漢字です。  ja-allowed-kanji
2:27  error  「炒」は許可されていない漢字です。  ja-allowed-kanji
4:3   error  「炒」は許可されていない漢字です。  ja-allowed-kanji

初期状態では常用漢字のみを使うようにしているので、このような結果になります。

次に、先ほどのNHK漢字表記を参考に、「濫」を「氾濫」のみに限定し、「諜」を許可、「炒」を「炒め」の場合のみ許可する設定です。

{
  "rules": {
    "ja-allowed-kanji": {
      "preset": {
        "regular": true, // 常用漢字のみの場合はpresetごと無指定でもOK
      },
      "exclude": "濫",
      "allowKanji": "諜",
      "allowPatterns": [
        "氾濫",
        "/炒(?=め)/"
      ]
    }
  }
}

この設定からは次の結果が得られます。

1:3   error  「濫」は "氾濫" 以外のパターンでは許可されていない漢字です。        ja-allowed-kanji
2:27  error  「炒」は "/炒(?=め)/" 以外のパターンでは許可されていない漢字です。  ja-allowed-kanji
4:3   error  「炒」は "/炒(?=め)/" 以外のパターンでは許可されていない漢字です。  ja-allowed-kanji

やりたいことはできた

ひとまず、自分の要望を満たすルールは完成したので満足しました。
同じ要望を持つ方にも使ってもらえたら嬉しいです。

省略されたテキスト

overflow: hiddenとtext-overflow: ellipsisまたは-webkit-line-clampによってテキストが省略された場合、その省略部分がページ内検索にヒットすると非常に探しづらいです。
特に、グリッドで区切られたアイテムが複数列・複数行で並んでいる際に顕著です。

以前の記事のとおり、わたしはYouTubeでよく遭遇します。

下記のデモは、1000個のアイテムを並べたものです。
このうち、「Red Rose」というワードは12個のアイテムに含まれています。
デモを開いて「Red Rose」でページ内検索をしてください。

• テキストが省略されたグリッドアイテム
• テキストの省略のないグリッドアイテム

テキストが省略されたデモでは、2、4、6、12番目にヒットしたアイテムがどこにあるのか判断できないと思います。
フォーカスが移動するわけでもありませんので、document.activeElementを使っても判断できません。

なお、Safariの場合はこの問題に遭遇しません。

スクリーションショット画像は2件目を表示したときのものです。
ページ全体が暗くなり、ヒットした部分だけがハイライトされます。

さらに、ヒットしたテキストが省略された部分であっても、文の途中を省略してすることでヒットしたテキストを表示しています。
ヒット部分の1行目の末尾が省略記号になっているのが分かります。

text-overflowの場合はヒットしたテキストの表示はうまくいっていないように見えますが、画面が暗くなってヒットした部分のハイライトは行われますので、どこにヒットしたテキストがあるのかは判断できます。

仮想スクロール

仮想スクロールは大量のデータを表示する際に、パフォーマンス向上を目的として使われるものです。

その原因と仮想スクロールの仕組み上、画面に表示されないアイテムはDOMツリーから取り除かれます。結果として、ページ内検索にヒットしなくなります。

次のデモは、前述のデモと同じデータを使ったものです。デモを開いて「Red Rose」でページ内検索をしてください。
仮想スクロールにはvirtual-scrollerというライブラリーを使用していますが、これは他のものを使っても同じです。

• 仮想スクロールのリスト
• 普通のリスト

仮想スクロールでは、実際に見えている部分とその前後少しに対象ワードが存在する場合にのみページ内検索にヒットします。

このときもっとも理不尽に感じるのは、上から順にスクロールしながら見ているときです。
特定のワードが確実に存在することが分かっているのに、実際にはページ内検索にヒットしないので頑張ってスクロールしながら探さなくてはなりません。

わたしの場合、この現象はTwitterの検索結果ページで発生します。

これはユーザー側でどうにかできるものではありませんので、余計に不便です。
テキスト省略の場合は、開発者ツールで該当スタイルを削除すればどうにかなりますが、仮想スクロールの場合はそうではありません。

制作側としては専用の検索フォームを用意するのが解決策となると思います。
しかしユーザー側としては、本来はCtrl/Cmd+Fで済むのに、サイトごとにフォームの位置を覚えたり、仮想スクロールかどうかを調査しないといけないのは手間に感じます。

大量のデータを一気に描画して落ちるパフォーマンスを改善するのは重要だとは思います。
使われるか分からないページ内検索よりも、必ず表示されるデータのほうが優先度は高いでしょう。

まとめ

最初にも書いたように、「採用するとページ内検索が機能しなくなるが、採用したほうが多くの場合は有用である」という類いのものは非常に悩ましいです。

ページ内検索は、モバイルブラウザーではアクセスが少し面倒ですので、使われる場面がデスクトップブラウザーより少ないと思われます。
画面が小さく、処理能力もPCより劣るモバイルデバイスを考えると、ページ内検索の優先度はさらに下がるでしょう。 WICG/scroll-to-text-fragmentによると、Android Chromeでページ内検索を使うユーザーは1%もいないということです。

テキストの省略は機能としてはあってもなくても変わりませんが、デザインの都合や意思決定者の強い要望によって採用されることも多いでしょう。
セレクターにページ内検索がヒットしている状態の疑似クラスがあれば解決できそうです。
もしくは、各ブラウザーのページ内検索がSafariのようになるかです。

仮想スクロールについては何も思い浮かびません。
ユーザー側としてはおとなしく用意された検索フォームを使うしかないでしょう。
Twitterの検索結果ページの場合、さらに検索ワードを追加して検索し直す、という流れになるでしょうか。

HTML Standard - 6 User interaction - 6.9 Find-in-pageを見ると、window.find()という形でAPIが予定されてはいるようです。
該当Issue「Potentially standardize window.find() · Issue #3539 · whatwg/html」を見ると、議論の経過が分かります。

現行ブラウザーでもwindow.find()は使えるのですが、それは非標準なもので、非推奨になっています。

このAPIによってページ内検索でイベントが発生するようになったり、該当のノードを取得できるようになれば、今回の問題はどちらも解決するかもしれません。

なんでこんなことをしたかったのか

大量の小さな画像が配置されたウェブページを作っていましたが、それらの大半はユーザーが操作しない限り表示されないUIでした。
表示されるかどうか分からない画像をダウンロードさせるのもイマイチな気がして、ダウンロードを遅らせたかったというのが理由です。

通常のimg指定

デモを作ってありますので、確認してみましょう。
display: noneになっているのは親要素ですが、自身につけても変わりません。

p {
  display: none;
  padding: 10px;
  overflow: auto;
  resize: both;
  background-color: gainsboro;
}

img {
  display: block;
  max-width: 100%;
  height: auto;
}

<button id="button">画像を表示する</button>
<div id="container" class="container">
  <img src="./long-tailed-blue.jpg"
       class="image"
       width="2048"
       height="1536"
       alt="写真：ウラナミシジミ">
</div>

<script>
const button = document.querySelector('#button');
button.addEventListener('click', function() {
  const container = document.querySelector('#container');
  container.style.display = 'block';
  this.disabled = true;
});
</script>

デモページで開発者ツールを開き、ネットワークパネルを見てもらうと分かるように、ページを開いた時点で画像がダウンロードされています。
これを、ボタンが押下されて.containerがdisplay: blockになったときにダウンロードさせたいというわけです。

表示されてからダウンロードを開始する

ご存知のように、CSSのbackground-imageで指定された背景画像は、対象がdisplay: noneになっているとダウンロードされません。
これはbackground-imageというより<image>型で扱われるリソースがそうなっているのではないかと思うのですが、ちょっとソースが分かりませんでした。CSS Images Moduleあたりかなと思ったんですが、仕様ではなく実装のほうなのかもしれません。

ともかく、背景画像にすればdisplay: noneのときにダウンロードされないようにはできるのですが、非常に不便です。
背景画像を使うということは、該当要素のサイズ指定が必要になりますが、そのためには画像のサイズを知っていなければなりません。

そこでcontentプロパティによる要素置換を使います。

デモをご覧ください。
画像として扱う要素がimgからdivになっている以外は同じです。

<div id="container" class="container">
  <div style="content: url(./long-tailed-blue.jpg)"
       class="image">
  </div>
</div>

開発者ツールのネットワークパネルを見ると、ボタンを押下してdisplay: noneな.cotainerがdisplay: blockになって初めて画像がダウンロードされているのが分かります。

.cotainerをリサイズすると、それに合わせて画像になっているdivのサイズも変わります。これはimg要素で読み込んだときと同じ動作です。

読み上げ対応

contentプロパティに<image>型が指定された要素は、アクセシビリティツリー上では画像として扱われます。
開発者ツールで確認してみてください。
こういう点では問題ありません。

しかしdivにはalt属性が使えませんので、代替テキストが指定できません。
この問題に対しては、次のように解決されることが望ましいでしょう。

content: url(./long-tailed-blue.jpg) / "写真：ウラナミシジミ"

contentプロパティ値の/（スラッシュ）で区切ったあとの文字列は代替テキストとなります。
構文的には次のようなものです。（2021年5月17日版 Editor’s Draft）

normal | none | [ <content-replacement> | <content-list> ] [/ [ <string> | <counter> ]+ ]? 

しかし、2021年5月現在、スラッシュ後の文字列に対応している環境はBlinkエンジンのみです。GeckoやWebkitでは使用できません。

対応している環境、たとえばGoogle Chromeを使って読み上げてみると、ちゃんと画像であることを伝えてくれます。
そうではない環境では、不正なCSSとしてcontentプロパティ自体が無視され、画像すら表示されません。

対処方法としては、替わりにaria-labelを使うことでしょう。

<div style="content: url(./long-tailed-blue.jpg)"
     class="image"
     aria-label="写真：ウラナミシジミ">
</div>

両者を比較するデモをご覧ください。
このデモを使って開発者ツールを確認すると、ここまでの説明がわかりやすいかと思います。

問題点

img要素ではありませんので、widthまたはheight属性が使えません。つまり、画像のロードが完了しないとレイアウトが完了しません。
ただし、そのような場合は画像のサイズが分かっていることが前提ですので、CSSで指定すればいいでしょう。

.image {
  max-width: 100%;
  height: auto;
}

<div style="
       content: url(./long-tailed-blue.jpg);
       aspect-ratio: 2048 / 1536;
     "
     class="image"
     aria-label="写真：ウラナミシジミ">
</div>

また、img要素ではないことから、loading属性が使えません。
そもそもこの方法を採用するのは特殊なケースかと思いますので、ビューポート外の画像を遅延ロードさせたいなら普通にimg要素を使ったほうがいいのではないかと思います。

レスポンシブ画像はCSSのimage-set()関数を使えば解決できそうです。

まとめ

わたしが使ったケースとしては、タブが20個あるタブUIで、そのコンテンツはリンク集であり、各リンクに小さな画像がついているというものでした。
タブUIの中身というものは、表示されるかどうか不明という意味では代表的なものかもしれません。
他にはdetails要素でしょうか。

ほとんどの場合、img要素を使うべきだと思いますが、このような方法もあると知っていれば役に立つことがあるかもしれません。

モチベーションとか

日頃からいろいろなことを検索してTwitterでツイートしたりしているのですが、ツイートだとタイトルとURLでかなり文字数を使ってしまいます。
文字数に制限があるTwitterではそれ以外に何か書こうとしてもほとんど書けないので、せっかく調べたことを残せません。
オンラインで閲覧可能なメモ用サービスとかを使うことも考えましたが、どうもあの手のツールは向いていないようで、すぐに使わなくなってしまいます。
結果、自分のサイトに置いておけばいいではないかということになりました。

実際にやってみて、普通のブログ記事にするには短すぎたり中途半端すぎたりするような、雑なものでも調べた部分だけメモっておけるというのはかなり気が楽です。

いまのところ楽しくできているので、飽きるまでは続けようと思います。

技術的な部分

モチベーションを保つために、雑に書いて雑に公開できる、ということはとても重要でした。
メインのブログ記事はHTMLで書いてGitHubにPushして公開というフローですが、きっちりできる反面、雑な公開には向いていません。

かといっていまさらCMSをインストールして……とかはやりたくなかったので、どこかのブログサービスを使うとか、それこそnoteを使うとかも考えました。
結論としては、Eleventyで作っているんだからヘッドレスCMSを使えばいいじゃないかということで、microCMSを使うことにしました。

microCMSで1項目ごとにタイトルと本文だけの記事を作成し、EleventyでAPIを叩いて記事をすべて取得。
microCMSのデータには自動的に公開日時や更新日時が入るので、データ内の公開日ごとに記事を整理し、日付ベースでページを作成するという処理をしています。

普段の記事はHTMLですが、検索メモはMarkdownで書いています。これも雑にやるという目的があります。
しかしMarkdownの範囲を超えるようなもの（画像をfigureでマークアップする、など）はどうにもならないので、そこはHTMLで書いています。

内容について

検索メモの内容はバラバラです。
JavaScriptライブラリだったり、動物だったり、食べ物だったり、本当に興味本位で検索したものや偶然知ったものをメモしています。

動物のメモには写真がある場合もあるので、そういうのが苦手な人はその日付をスキップしたほうがいいかもしれません。

キーボード操作のみでのアクセス

ホイール機能のついたマウスにおいては、スクロール・コンテナーまでカーソルを移動し、ホイールを実行することでスクロールが可能です。

それに対し、キーボードではスクロール・コンテナー自身、またはそのコンテンツ内にフォーカスを移動しなければカーソルキーや、その他スクロール操作を行うキーによるスクロール動作を行うことができません。

iframeやtextareaなど、初期状態でスクロールが可能な要素は、tabindex属性を指定せずともキーボード・ナビゲーションによるアクセスは基本的に可能です。
しかし、そうではない要素に対し、ページの著者がCSSでoverflowプロパティ（overflo-x、overflow-yも含む）をscrollやautoにした場合はどうでしょうか。

「HTML Living Standard - 6 User interaction」の「Focusable area」には次の文が含まれています。

inert（不活性）ではないスクロール領域はフォーカス可能である、ということがHTMLの仕様に掲載されていることがわかります。

デモを作成しましたので、ご確認ください。
以下はデモページのHTMLとCSSの断片です。

<div class="content">
  <p class="scrollable">
    ...
  </p>
</div>

:focus {
  outline-width: 2px;
  outline-style: solid;
  outline-color: skyblue;
  outline-offset: 2px;
}

.content {
  border-width: 1px;
  border-style: solid;
  border-color: gray;
  padding: 1em;
  width: 20em;
}

.scrollable {
  margin: 0;
  overflow: auto;
  height: 10em;
}

それぞれのp要素にはoverflow: autoが指定されています。3種類のケースの違いは次のとおりです。

Case 1-A

スクロールの必要がない程度のコンテンツ

Case 1-B

スクロールが必要な量のコンテンツ

Case 1-C

スクロールが必要な量のコンテンツで、内部にボタンがある

どうですか、すべてのケースでマウス、またはキーボードで最後まで見られましたか。
キーボードのみの操作ではFirefox以外を利用している方は見られなかったのではないかと思います。

先ほど示した仕様に準拠しているのは、2020年3月現在、Firefoxのみです。

Chrome（というよりBlinkエンジン）では該当イシュー「Issue 585413: Scrollable area does not get focus with TAB focus navigation」は2019年にFixedになっているものの、動作していないように見えます。
これは現段階ではフラグ付きの実装のためです。chrome://flagsから「Experimental Web Platform features」を有効にすることで動作を確認できます。

Safari（Webkit）については特に見つかりませんでした。
またMicrosoft Edge レガシ、Internet Explorerでも動作しません。

このような状況で、スクロール・コンテナー内のコンテンツにアクセスするにはどうしたらよいのでしょう。
キーボードでフォーカス可能な要素がコンテンツ内にある場合はスクロール位置がそこまで移動してしまうものの、要素のスクロール自体はキーボードのみで可能です。
そうではない場合、スクロール・コンテナーへフォーカス可能でないブラウザーの利用者はキーボードでアクセスできないのでしょうか。

思いつくのはスクロール・コンテナーである要素にtabindex属性を付与し、その値を0以上にすることです。
これはシンプルでスマートな解決法に見えます。

該当要素にoverflow: scrollが指定されているのならば、この方法はうまくいくでしょう。

しかし、overflow: autoの場合はどうでしょうか。スクロールの必要がない量のコンテンツの場合、特に意味のないフォーカス可能要素が生まれてしまいます。致命的な現象ではありませんが、違和感のある動作になってしまいます。

これを解消するには、JavaScriptの力が必要となります。
該当要素の矩形と、コンテンツ量に応じて必要とされる矩形を比較し、tabindex属性をつけ外しすることになります。
また、レスポンシブなレイアウトにおいては、要素のサイズを監視する必要もあるでしょう。

当然それには制作コストがかかります。
Firefoxは対応済み、Blink系統のブラウザーもそのうちフラグが外れるでしょう。こういった状態で追加コストで対応するかどうかはチームで判断するしかないでしょう。

• ページ内のコンテンツにスクロールが必要なパーツを作らない
• スクロールの必要があるのならば、overflow: scrollとtabindex属性を指定し、コンテンツ量によってはスクロールの必要がない状態でもスクロールバーが表示されるのを許容する
• それもできないのならばJavaScriptで頑張る
• そもそも仕様ではスクロール・コンテナーはフォーカス可能であり、対応も進みつつあるので何もしない

といった選択肢があります。
いえ、わたしが思いつかないだけできっともっとあるでしょう。

マウスとキーボードを併用している場合

レアケースかと思いますが、マウスでスクロール・コンテナーにアクセスし、スクロール操作自体はキーボードで行う場合があります。

わたしがそうなのですが、スクロール・コンテナー内の任意を場所をクリックし、カーソルキーでスクロールをすることがあります。
事情としてはマウスを頻繁に長時間使い続けて右手首の腱鞘炎を起こしたことがあり、マウスに触れる時間を少しでも減らそうとした、というものです。

マウスの利便性を保ちつつ、非常に単純な操作はキーボードで済ませる、という使用方法です。

既出のデモページで、同様の操作（スクロール・コンテナー内をクリックしたあとでカーソルキーでスクロール）を行ってみてください。
問題なく操作できるはずです。

しかし、この操作方法が不可能なパターンがあります。
それはスクロール・コンテナーの先祖にtabindexが指定されている場合です。

先ほどと同様にデモを作りましたのでご覧ください。
1つ目のデモのスクロール・コンテナーの親要素にtabindex="0"を追加したものです。

スクロール・コンテナー内をクリックすると、その親にフォーカスを奪われるのでスクロール・コンテナーをキーボードで操作できません。
これはスクロール・コンテナーにキーボードでフォーカス可能なFirefoxでも同様です。

これを回避するには、やはりスクロール・コンテナー自体にtabindex属性を付与するしかないのですが、すでに述べたように、この方法にはいくつかの解決すべき問題があります。

この現象に遭遇するパターンとしては、わたしのような使い方をしている場合、または、ホイール機能のないマウスを利用していて、結果としてわたしと同じような操作をしている場合でしょう。

非常に限定的なパターンかつレアケースではあると思いますが、このようなシチュエーションも存在します。