輪符補完機能などのため描写選り手で採用する予定だった contentEditable の導入について急遽再検討して終了。

contentEditable の導入はいったん保留とし，<textarea> の座標計算用の <div> を作る手法を先に試してみることにした。

前歩で再描出フォームの maxlength 属性を設定しようとして，ふと，contentEditable ではどうするのだろうと調べてみたら思いのほか面倒臭そうだった。これに限らず，どうもそこまで洗練されたものではないらしいということが分かってきた。

デライトではさほど複雑なことをする予定は無いので，よくある装体複製 <div> を使った手法で十分というかマシな気がしてきた。装体複製 <div> も初めて知った時はどうかと思ったが，それ以上に洗練された方法が無いなら仕方ない。

contentEditable はかなり前から導入する気でいたが，当初は念のため <textarea> の実装も残しておくつもりだった。contentEditable ももはや枯れた技術なので，<textarea> は切り捨てるべきか，と最近になって考えるようになった。まさかここで正反対の方向に舵を切ることになるとは思わなかった。

（進捗時限記録中略）

譜類添付機能調整で終了。

SVG 対応を終えた。未出振るい。

WordPress を参考に HEIC 対応も考えた。交度は書けたが，また ImageMagick のパッケージ問題で中断。素出からの再引装を検討している内に，特許問題があることに気付いた。現時点で必要性は高くないため保留とすることにした。

（進捗時限記録前略）

公式の見本ページを参考に Mermaid の装体調整で終了。

なぜか円画表が必要以上に大きく表示され見にくかったため，aria-roledescription="pie" の場合のみ <svg> に max-width: 75% を設定した。他の画表は横幅によって中央寄せが適切でない場合があるが，円画表はある程度一定の大きさで目立つように表示されるため中央寄せにしておいた。これで概ね見本通りに表示されるようになった。

幅狭領当てで円画表の見出しや凡例が見切れてしまうことがあるが，これは公式見本でも同じなのでいったん保留。

違了表示が梱体を突き抜ける問題もあったため，親要素に overflow: hidden を設定しておいた。

「輪郭ページ改良」の方針をまとめ終了。

現状は後景一覧ページを利用している輪郭ページを出来るだけ早く，完全に切り分けることにした。ただし，用合いは共通化の方針を明確にし，あくまでも検索演心など機械向けの最適化に主眼を置く。

輪郭ページの方針は長いこと保留にしていた問題だが，15日14歩がきっかけで検討が進んだ。用合い上の差別化とは別問題として切り分けを進める点でこれまでと異なる。

詳細は実装後にまとめる。

（進捗時限記録中略）

ついでに新規描出フォーム固定機能についても検討して終了。

こちらは「限りなく廃案に近い保留」となった。

全知検索窓固定機能同様，デライト最初期に実装・削除したものだが，これは広告との相性以前に，用合いとしていまいちだったということが大きい。

新規描出フォームを固定出来れば，輪郭一覧を眺めながら描写を書くことも出来て便利に違いない，と素朴な期待から実装してみたが，これが帯に短し襷に長しという感じで思いのほか使えなかった。

大きな原因は，ページ遷移までのちょっとした間固定されるだけ，という中途半端さにあった。あちこち飛びながら作業しているといちいち解除されるので，自然に使わなくなっていく。

これに対処しようとすると画面分割機能に近い大掛かりな仕掛けが必要になる。画面分割機能は何度も検討したが，やはりデライトには過剰と判断して，複数窓で使いやすくする方向で単純性を保ってきた。今考えてもこれは英断だった。

自動ページ展開や輪郭一覧動的更新がある今なら当時よりは使いようがあるかもしれないが，その分，ページ遷移の条件が分かりにくくなっているので，かえってストレスかもしれない。

複数窓が使いにくいスマートフォンなどでも，新規描出フォームと柔品キーボードで画面がほとんど占有されるため恐らく使いものにならない。当時は諸場で使える状態ではなかったので想像ではあるが，複数タブで使う方がマシだろう。

結局，構造的にデライト向きではないのだろうと思うが，急いで結論を出す必要もない。そのうち適当な活用法が見つかればいいし，見つからなくても問題ない。というわけで，しばらく放置しておくことにした。

迷いが一つ消えたのは収穫と言える。

（進捗時限記録中略）

全知検索窓調整。

全知検索窓にも大きな実用上の問題はなくなっていたが，使い込んでいるといくつか気になることがあったため，ここで解消しておいた。

まず，& ボタンが意図せず無効化されやすい状況として，検索語が全選択状態になっている場合が残っていたため，BackSpace での & ボタン無効化条件に選択範囲が無いことを加えた。

BackSpace 押しっぱなしによる & ボタン無効化抑止のために使っていた KeyboardEvent.repeat が一部舞覧で意図通り機能しない問題も再調査したが，これは解決しなかった。一部舞覧といっても Android 版 Chrome くらいで，総合的に見て大きな問題ではないので再び保留としておく。

検索語の削除・復元ボタンの切り替えに若干違和感を覚えていたが，これは要素の参照方法を間違えていたせいで，削除ボタンを押した後の復元ボタンが検索語の再入力時に削除ボタンに戻らないという問題だったためすぐ修正出来た。違和感の原因も不具合の原因もはっきりして良かった。

出振るい済み。

不具合修正で終了。

現時点で自己輪括を使う人はいないという前提で26日21歩では保留としたが，不具合報告を受けてしまったので，dg_xg() で除外するようにした。誤操作でも十分起こりうる。

表示輪数と実際の輪数が合わないという場面は今後の輪郭削除機能でも増えそうなので，現状の「未公開輪郭が含まれています。」という表示を「表示出来ない輪郭が含まれています。」に変更した。

未出振るい。

（進捗時限記録中略）

報告1，報告2の不具合修正で終了。

吊るし輪郭と同じ輪郭が輪郭一覧にあると輪郭情報の取得に失敗するという不思議な現象だったが，最近 DG::fnd_T を返すようになった DG_T::fnd() が連続した同一知番を想定していないことが原因だった。

それ自体は間違った仕様ではないので，dg_fnd() で検索結果から吊るし輪郭を除外することで暫定対応。dg_cnt_fnd() と合っていないため「未公開輪郭が含まれています。」と表示されるが，輪数取得は近いうちに改良予定なので保留。自己輪括の問題もあるが，これも風船輪郭で利用するため保留。

第二次用合い改良。

途中で終了。

ドラッグ＆ドロップ周りの不具合修正。

Firefox で輪符要素の a.knm 内に子要素がある場合ドラッグイメージが出ない問題だけ解決しなかった。出与えの取得は正しく行われていて，動作も問題ない。Firefox のドラッグイメージは挙動が元々怪しいので保留。