長期安定体制の完成に向けた仕上げの月が始まったが，すでに落ち着いて楽しく日々を過ごせているので，早速大成功という感じだ。特に第五次生活習慣改善の進展は目覚ましく，健康面・美容面では毎日何かしら良い変化を感じるので楽しい。
ふと，これこそデライトの完全な成功に至らない最大の理由かもしれないとすら思った。結局，恵まれ過ぎていて切実さに欠ける。俗に言う成功を収めなくても幸せに生活出来てしまうのだから，必死にならないわけだ。そもそも，デライト以前にデルンを一人で使い続けられたのも，そんな生活が楽しかったからだ。その上「デライトの不完全な成功」を果してなお余力があること自体奇跡だ。甘やかされ過ぎている気がしないでもない。
だとしても，いまさら背水の陣という気にもなれないし，方針が変わるわけでもないが，微かな心の揺らぎを感じた。まあいつものことで，妙に冒険したくなるのは安定期に入った証拠だ。
SVG スプライトを background-image などでも利用出来るようにする実装について考えていたが，ここは割り切って，原則，SVG アイコンは引連 SVG としてのみ扱う方針を決めた。
実装上の都合で background-image を使っているだけのアイコンは別として，現状，背景とアイコンの二つの役割を持たせている二輪鎖を念頭に置いた検討だったが，背景としての二輪鎖も特定要素の端っこに置いているだけなので，一番楽な方法ではあるが background-image を使う必要は無い。
<view> の舞覧対応状況に不安があることはさておき，フラグメント識別子を付けると多重立求が発生する舞覧があることがどうしても気になる（手元の Linux 版 Firefox でも発生する）。background-image を使いたいのが二輪鎖だけだったのでまだ問題は小さいが，SVG スプライトが十分に軽量でフラグメント識別子での参照が十分に少ないという状況でしか効率的ではない手法は範枠化出来ない。
スクリプトで補完した要素に background-image を設定することも検討したが，そうすると実装コストが動的引連 SVG と変わらない上に，より柔軟性の低い参照方法でしかなくなる。
結局，アイコンはアイコンらしく，要素と一対一で扱うものと割り切った方が何かとすっきりする。
主にインポート・エクスポート機能仕様検討（6歩，7歩，8歩）。
にわかにインポート機能の実装イメージが固まり，それに伴いエクスポート機能の実装イメージも引き締まってきた。
アイコンなどの画像形式に関しても，WebP と CSS の使い分けで当面の方針が固まった（2歩）。検討していた SVG 化は必要が生じるまで見送る。
添付譜類はあくまでも添え物として最小限の役割に留め，エクスポート機能でも実譜類の出力には今後対応しない方針を固めた。
元々添付譜類は添え物として設計しているが，実際に譜類添付機能が出来，エクスポート機能を実装しようとしてみると，実質的な役割の落とし所が意外に難しい。意図に反して，変に使われ過ぎるのも問題だ。
エクスポート機能では，とりあえずは代替 HTML などで済ませ，ゆとりが出来たら実譜類にも対応するか，などと考えていた。そもそも，どんな大企業のクラウドであれ消えて困るような譜類の唯一の保管場所にすべきではないし，そこまで神経質な人が手元に抜控を持っていないということも考えにくいので，実はさほど必要性の高い付徴ではない。とはいえ，エクスポート時の負荷や帯域だけが問題なら金で解決出来るのだから，将来的に対応しないというほどの動機もない。
しかし，添付譜類がエクスポート出来てしまうことで譜類倉庫的な利用が増え，それに伴い譜類保全の責任が増せば，将来にわたって無視出来ない経営上の問題になる。ということについさっき気付いた。描出公開原則同様，ここは割り切った用者文化を育てていくべきだろう。
これに気付いてみて，最近，添付譜類の役割を広げようとし過ぎていたことにも気付いた。譜類添付機能のサイズ上限や拡張子制限の緩和も考えていたが，これも最小限に留めることにした。拡張子制限は制危面もあるが，献典として非効率だったり無意味だったりする譜類の上信抑止といった効果も望める（例えば .bmp をそのまま上信して欲しくはない）。
デライトの強みは，知番による意味符号化で文字献典の情報密度を極限まで高め，その軽さを最大限に活かせることだ。譜類倉庫的な方面で消耗するのは差別化戦略として明らかに悪手だ。譜類添付機能実装以降，その軸が微妙に揺らいでいることはうっすら感じていた。今日は妙に頭がもやもやしていると思ったら，どうも脳がそれを訴えていたらしい。気付いたら非常にすっきりした。
描出公開原則のように何かこの方針に名前を付けたくなったが，「譜類添付機能」という名前で趣旨は表現出来ているので，それに立ち返るということで十分だろう。
上信に時間がかかる場合や，貼り付けでの添付に対応した場合のために，埋め込み記法の挿入位置に編注記法を使った代置子を挿入しておくことを思い付いた。
<!-- +読み込み中... --> のような形式を想定。ピリオドの数で固有性を持たせることも出来る。
輪括を含まないように簡素化することは決めていたが，添付譜類も含まないようにする方針を固めた。実際に譜類添付機能が出来てみると，全ての添付譜類をエクスポートするのは現実的ではないことに気付いた。重要な譜類なら各自抜控を取っていることを前提として問題ないだろう。
エクスポート機能実装は次の主要当努だったが，先に譜類添付機能実装を済ませたのは正解だった。
N の導入を機に，新規描出フォームに飛ぶ機能一般で知名欄に自動捕活するようにした。
最近，全知検索窓固定機能実装を契機として省割キー整備についての検討が進んでいた。
現時点では，舞覧機能との干渉を避けるため修飾キーを避けることや，広く共有されている文化を利用し極力無難にまとめる方針が固まっている。長年の経験から，「理想のキーバインド」の追求は泥沼だと悟った。
テーマ切り替えボタンの用合い検討（4歩），新規描出フォームへの移動機能として吹き描き外背景のダブルクリック用合いの復活（10歩），全知検索ページャー周りの調整（16歩），こまごまとした領当て・装体調整（17歩）といった雑多ながら充実した作業を片付け，ついに描写後略機能を一段落させた（21歩）。出振るい・手定め済み。
描写後略機能により，デライト最初期から吹き描きの構造的問題だった「不必要な出与え読み込みの多さ」という問題が解消した。表示速度向上，通信量削減，SEO 強化，迷惑行為対策など多大な効果が見込める。
昨年末の壊衝不具合修正以後，デライトは速度・安定性ともにウェブ相振りとして十分な水準に達していたが，今回の高速化を経て，明らかにもう一つ壁を越えた感がある。体感として，「ウェブ相振りなら特に不満のない速さ」から「単動相振りと比べても遜色のない速さ」になった。
一昨年4月9日に掲げた「全ページ0.3秒以内表示」という目標は埋め込み利素を考えると現実的ではない気がしてきたものの，軽いページでは200ms台，重いページでも概ね300ms台で応答出来るようになっている。実感として欲しかった速度は手に入れられたし，最適化余地はまだまだ残しているので「埋め込み利素を除いてほぼ全てのページで0.3秒以内表示」なら十分手が届く。いよいよ本格的に，速さがデライトの武器になってきた。
ここで新生デライト開発におけるデライト高速化は一段落とし，今後は機能追加やトラフィックに応じた微調整に留め，別の機能整備に集中することにした。
その先のデライト高速化については，大きなところでは CDN 導入，KNEST による水平拡大，請い手の隠し機能整備，描写 HTML 隠し以外の HTML 隠し実装，そして中途半端な状態で放置しているページ付け求頼改良があるが，どれも現時点での優先順位は低い。
取り急ぎテンプレートを整理して，輪郭ページの吊るし輪郭を入れていた要素を <header> から <main> へ，輪郭ページの輪郭一覧を <main> から <div> に切り替えた。前後景一覧ページでは従来通り。
特に急ぎたかった部分が上手く片付き，残るは内部的な問題のみなので，輪郭ページ改良はここで中断することにした。
閲覧専用模動の実験をしていた時，輪郭ページの輪郭一覧を隠すと <header> だけのページになってしまうことに気付いたのが事の発端だった（15日14歩）。
あまり意識してこなかったが，輪郭ページの概念と実装に大きな不一致が生じていた。一時凌ぎのつもりで後景一覧ページを輪郭ページに使うようにしたのはデライト離立補完中の希哲14年8月5日だった。当時と今とでは輪郭ページの捉え方も輪郭の充実度も全く違う。
予てから検索模動・輪郭模動の内部的な切り分けが中途半端なまま進んでいない問題もあったため，抜本的な輪郭ページ改良の方針をまとめた（17日8歩）。
最近の検索演心はそこまで神経質ではないと言っても，<header> と <main> の違いは流石に小さくないだろう。何より，気付いてしまうと表現として気持ち悪いので早く解決したかった。