新着確認機能実装を一段落させた。10日12歩の修正とともに出振るい・手定め済み。

新着確認機能により輪郭一覧の更新状況がぐっと把握しやすくなった。サービスの性質上，自動更新など気が散る実装を避けてきたが，あちこちページや画面を切り替えながら作業していると，輪郭一覧の鮮度が気になることが多々あった。必要以上に輪郭一覧を更新する癖がつく問題もあった。

実装の要点は次の通り。

• 待機状態では初期化から15秒間隔で4回，20秒間隔で3回，30秒間隔で2回，計約3分間・9回の更新確認を行う。
  • 捌き手の応答時間が長い時でも立求が詰まらないように，立求処理の完了後に遅来させる。
  • 輪郭一覧が更新されている場合，更新有り表示を行い停止する。
  • 輪郭一覧が更新されないまま9回の更新確認を終えると，更新不明表示を行い停止する。
• 交差監視により，画面内に更新輪結が入ると待機状態に入り，画面外に出ると更新不明状態に入る（更新有り状態ではない場合）。
  • 初回ページ読み込み時の始動も交差監視で行っているため，吊るし輪郭が長い場合，舞覧がスクロール位置を復元した場合など，更新輪結が見えなければ動作しない。
  • 更新不明状態の更新輪結が画面内に入ると，即座に更新確認を行い，最初から待機状態に戻る。
  • 全知検索窓固定機能同様，デライトにとって本質的な機能ではないため，新着確認機能自体 Intersection Observer API が使える環境でのみ有効とすることにした。
• 前縁では機能を @DG.upd に集約し，他機能からも輪郭一覧更新を促すなどの目的で利用しやすくなっている。
  • 引き入れ用合い改良からやりたかった，吊るし輪郭の輪括操作時の更新有り表示も実現出来た。
  • 再描出時にも更新有り表示に対応しておいた。
• 後縁では，形式上輪数を返せるように設計しているが，実際には更新有無を表す0・1の二値のみを返す。
  • 元々新着輪数表示を考えていたが，現時点では実用上不要と判断した。
  • 将来的な拡張は容易な状態になっている。
• 更新有り表示・不明表示のアイコンは，メニューの「使い方」・「利用規約」の疑問符・感嘆符アイコンに filter をかけて使っている。
  • 最初，赤・黄色の組み合わせを試したが，必要以上に目立ち過ぎ，違了にも見えてしまうため，黄色・灰色に落ち着いた。

新生デライト開発の当努としての新着確認機能実装は優先順位が低く，最後の方になるかと思っていた。最近になって，メニューのアイコンが使えること，輪数は必要ないこと，交差監視が使えること，と立て続けに実装上の気付きがあり，高い時間対効果・負荷対効果が望めるようになっていた。

マイクロブログなどの投稿数と異なり，1輪の長文もあれば10輪の知名のみの輪郭もあるのがデライトの輪数なので，文脈を限定せず，ましてや2桁程度の表示幅では情報量の尺度として機能しないことに気付いた。

全知検索窓固定機能で採用した交差監視が使えることに気付いたのが駄目押しだった。無駄な再読み込みを抑制する効果も望めるとはいえ，多少なりとも立求が増える機能なので，悪影響の懸念が拭えずにいた。交差監視によって無駄なく効果的に待機状態を制御出来る見通しが立った。流石に高速化までは行かないにしても，十分な低負荷実装になった。

全知検索窓固定機能実装。

途中で終了。

交差監視には Intersection Observer API を利用することにした。絶対に必要という機能ではないため，全知検索窓固定機能はこの API が利用可能な環境でのみ有効とする。

（進捗時限記録中略）

吹き描き外背景のダブルクリック／ダブルタップで新規描出フォームに移動出来るようにして終了。出振るい・手定め済み。

デライト最初期，新規描出フォーム固定機能で試していた（希哲13年8月1日4歩）用合いだったが，自分でも驚くほど忘れていた。固定機能の削除以後，何度か再活用を検討した記憶はあるが，今ほど全体的な用合いの方向性が定まっていなかったからか放置していた。新規描出フォームへの握接について先日あれだけ検討していたのに全く思い出さなかった。ついさっきふと思い出した。灯台下暗しというやつか。

初見で分かりやすい用合いも必要なので全知検索窓固定機能の輪結も予定通り実装するが，スマートフォン右手持ちではタップしにくい位置だとは思っていた。個人機でもマウスカーソルの移動距離は短くない。しかし，これならよくある固定表示ボタンよりよほど賢い。上手い補完手段が出来た。

面白い発見も二つあった。

• 吹き描き眼形の角丸が幅狭領当てでタップの余白を作るのに丁度良い
  • 吹き描きの形が出来たのはダブルクリックによる新規描出フォーム固定を考えて間もなくだが，当時そこまでのことを考えていたかは定かではない。
• スムーススクロールには半溶暗・半溶明が有効
  • 位置関係を理解しやすくするためページ内移動では基本的にスムーススクロールを使っていたが，ちかちかする問題があった。
  • 輪郭一覧動的更新で採用した半溶暗・半溶明（opacity: 0.7 まで溶暗してから溶明する）を使ってみたら良い感じだった。
  • 他のページ内輪結にも採用することにした。

現状の幅狭領当てでは吹き描き外背景が小さ過ぎて誤タップしやすいが，これは縦方向の吹き描き間マージンを調整していくことにした。

全知検索演算子 ... に対応する …（三点リーダー），--- に対応する —（エムダッシュ）を追加して終了。

ある要望をきっかけに，iOS や macOS の自動修正機能が <input> で働いてしまう問題を認識した。この機能を設定で有効にしていると，全知検索窓では ... が … に，-- が — に変わってしまう。いっそ，これらも全知検索演算子にしてしまうことにした。

元々同じ意味の記号に対応することは考えていたため特に抵抗は無かったが，こういう動機で実装することになるのは意外だった。

出振るい済み。

録入り状態照合処理実装。

出振るい・手定めをして終了。想定以上に円滑だったので，以前作った警告表示機能を汎用化し録入りページに誘導するようにした（録入り状態異常の様子）。最初は暫定的に通注で済ませようと思っていたが，意外と十分な実装になった。これで信頼性の問題はほぼ解消した。

KNEST の新規描出・再描出では ego として自我知番を送ると録入り状態照合処理が走るようになったが，知機駒手などで従来通り使えるように省略可能にしておいた。

文言はとりあえず「ログイン状態に異常があるため、再度ログインが必要です。」としておいた。さらに，localStorage が有効な場合は「下書きは保存されています。」と付け加えるようにした。

予定通り臨時休業にした。久しぶりに気楽に過ごせた。

ここのところ半休にすることが多かったが，今のように過熱しがちな時期には全休が有効なようだ。半休では進捗が出るまで気が休まらないし，進捗が出だすと熱中して止まらなくなる。

そもそもなぜ半休が多くなったのかといえば，脳過熱で定休日前に臨時半休にすることが増え，その代わり定休日も半休にして……と調整していたからだ。

臨時半休は仕方ないとして，今後，定休日は常に全休とすることにした。

休日の過ごし方として，気ままに輪郭整備をするのはやはり良い。娯楽のようなものでもあり，頭の整理にも献典整備にもなる。

（進捗時限記録中略）

3歩がきっかけで久しぶりに実装予定の文字装飾記法について見直し，以下のように基本的な方針を整理した。

<<大きい文字>>
>>小さい文字<<
##太字##
//斜体//
__下線__
~~打ち消し線~~

下線記法については，_下線_ を有効にすることも考えていたが，適当に書いた時の誤解釈が増える懸念もあり見送ることにした。文字装飾記法は2個以上の記号で統一した方が綺麗にまとまる。簡潔な記法は追加するより削除する方がずっと難しいので，使用頻度を考えてもいまあえて導入する動機に乏しい。

……ここまで考えて，昨年6月23日10歩でも同じ結論を出していたことに気付いたが，再確認出来た。