動機

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

開発中の話

初めてLuaを書きましたが、とりあえずエラーなく動いているので大丈夫だと思います……というか、基本的にifとforくらいしか使っていません。
どちらかというとゲームのAPIのほうが苦戦しました。
APIの非公式Javadocはあるのですが、説明とかがあるわけではないので、それっぽいものを探して試すを繰り返しました。

並べ替え処理の話

たとえば「包丁」という武器カテゴリーアイテムが複数ある場合は次のような表示になります。

▶ 包丁 (5)

これをクリックするとスタックが展開されます。

▶ 包丁 (5)
包丁
包丁
包丁
包丁
包丁

その際に、耐久値などのバーが表示されますが、パラメーターによってはマウスオーバーでツールチップを表示させなければなりません。

このゲームの重複アイテムスタックは任意のアイテムを取り出せますが、スタックに突っ込むときは最後にしか入れられません。
例えば上記の包丁の場合、3番めのアイテムを取り出すのは問題ありませんが、戻したときは5番目になります。

Mod作成の場合、収納の中身を並べ替えてデータを書き換えるという処理も可能ですが、若干チート気味なので個人的には避けたく、バニラで可能な動作のみで完結させたかったのです。
チートっぽいと感じるのは、アイテムの取り出しや収納にはゲーム内時間が経過しますが、一気に書き換えるとノータイムで並べ替えが完了するからです。

この最後にしか追加できないという状況で、最少の手順をどうやって考えればいいのかというのが課題でした。
一番最初に出したバージョンでは、たとえば耐久値が「低 → 高」の順で並べ替える際に、最低値以外はすべて並べ替えるという処理をしていました。目的は達成できますが、とても無駄が多かったです。

ちなみにアイテムスタックの中身を並べ替える場合、キャラクターに次の動作を行わせます。
これはバニラの状態で手作業でやるものですが、これをModで自動化したいというわけです。

1. スタックから任意のアイテムを取り出す（ゲーム内時間が経過）
2. 取り出したアイテムを元のスタックがある収納に入れる（ゲーム内時間が経過）

これを耐久値などの、アイテムカテゴリーごとの重要パラメーターを見ながら行います。
アイテム数が10未満だと手作業でも大変ではないですが、そもそもアイテムの種類が多いのと、わたしのような収集癖があるプレイヤーは50個以上のスタックがあってもおかしくありません。
また、マルチプレイの場合は複数人分のアイテムスタックも存在するでしょう。
（Modの説明にはマルチプレイでテストしていないと書いていますが、サーバー機能は使っていないので普通に動くはずです）

最少手順を考えなければ、先に書いたように最低または最高の状態以外のアイテムを全部並べ替えれば完了です。
しかし実際に使ってみると「このキャラクター手際が悪いな」と感じます。

たとえば次のようなアイテムスタックがあるとします。
展開したアイテムに付いている角括弧内の数値は耐久値だと考えてください。

▶ 包丁 (5)
包丁 [1]
包丁 [3]
包丁 [10]
包丁 [10]
包丁 [5]

このとき、耐久値が低い順に並べ替えるなら、耐久値が10のアイテム2つを取り出して戻せばいいだけです。
ところが何も考えていない場合、耐久値が1以外のアイテムを351010 の順で取り出して戻すことになります。
手際が悪いです。

結局どうしたとかというと、並べ替えるアイテムを選択するためのデータを作成して、それで必要分を選び出すという処理をしました。

まず、元の並びのアイテムスタックのデータを取り出し、次のように変換します。
（アイテムスタックのデータを取り出すのもちょっとややこしいのですがスキップします）。

{
  {
    condition = 耐久値,
    index = 元の並びのインデックス,
    item = {アイテムのデータテーブル}
  },
  ...
}

ここでは耐久値ですが、他にも色々なパラメーターを利用しています。それらの値はメソッドで取得するので、この時点で取得して適当なキーに値を入れておきます。
次は値ごとにアイテムをまとめます。

{
  [耐久値] = {
    value = 耐久値,
    last = 該当耐久値が一致する最後のアイテムのインデックス,
    items = {各アイテムのデータテーブル}
  },
  ...
}

ここまで終わったら、昇順または降順に応じて、上記のテーブルを耐久値で並べ替えます。これはsortを使うだけなので難しくありません。

問題の並べ替えるべきアイテムのフィルタリングは次のようにしています。

local function createTransferItems(data, itemsCount)
    local transferItems = {}
    local previousLastIndex = 0
    for index, baseDataItems in ipairs(data) do
        for _, itemData in pairs(baseDataItems.items) do
            if itemData.index < previousLastIndex + 1 then
                if index > 1 then
                    table.insert(transferItems, itemData.item)
                end
            end
        end
        if #transferItems > 1 then
            previousLastIndex = itemsCount
        elseif previousLastIndex < baseDataItems.last then
            previousLastIndex = baseDataItems.last
        end
    end
    return transferItems
end

引数dataには、前述の値ごとにまとめたアイテムのテーブルを渡します。itemsCountはそのままアイテム数です。
やっていることですが、たとえば低い順に並べ替える場合、現在の耐久値より低い耐久値のアイテムテーブルの最後のインデックスより前にある現在の耐久値のアイテムは並べ替えるべき、という感じです。

あとはこのフィルタリングしたデータにそって取り出して戻すという処理をキューに追加するだけです。

もしかするともっといい方法があるのかもしれませんが、わたしが思いついた方法は以上です。

ModのソースはGitHubにあるので、興味のある方は見てみてください

matori/pzmod-reorder-duplicates-by-condition

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

大量の小さな画像が配置されたウェブページを作っていましたが、それらの大半はユーザーが操作しない限り表示されない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要素を使うべきだと思いますが、このような方法もあると知っていれば役に立つことがあるかもしれません。