rotate}{scale}(63)アイコンの縮尺問題は .sz16 や .sz32 といった分類名で CSS 変数 --icn-sz を設定することでいったん解決した。これで width，height を設定し，基本的に各数値は比率で設定する。border-width などパーセント指定が出来ない場合も var() と calc() を使って計算出来る。
当初，32px四方を基準に値を調整し，最終的に transform の scale() で縮尺を調整するということを考えたが，rotate() などを使いたい時に組み合わせの数だけ transform の記述が必要という問題があった。最近は scale や rotate という個別指定プロパティもあるが，対応舞覧の普及率にまだ若干難がある。
広告関連ボット対策（〜5歩）を終えてから引き入れ用合い改良に着手，Aejs 交度整理も進めながら，まずは前後景輪数増減表示の実装を終えた（19歩）。
前後景輪数増減表示によって輪括操作の効果がぐっと分かりやすくなった（様子）。デライト最初期からの大きな課題がまた一つ解決した。
不統一感が気になってきたため，ダブルクリック／ダブルタップでの新規描出フォームへの移動機能に合わせて基本的なページ内移動で半溶暗するようにした。これでちかちかする問題はほぼ解決した。
ついでに，全知検索ページャー周りの点検・調整。普段さほど使わないので，意外な挙動や課題を把握しておいた。
ちょっと困ったのが，更新輪結による輪郭一覧動的更新で条件によって大きくスクロール位置がずれることだった。結局，要素の削除・追加で生じるらしいことが分かり，スクロール位置を記憶しておいて復元することで解決した。
一部条件で数式記法が処理されない不具合修正で終了。出振るい・手定め済み。
動的更新を除き，全ての描写に数式記法が無く，それ以外の要素で数式記法がある場合，数式記法が処理されていないことに気付いた。
原因は，後縁が描写内のデラングだけで <script> 出力を切り替えていて，（読み込み改良以後）前縁がそれに依存して処理の必要を判定していたことだった。先日のスクリプト読み込み改良で無駄を無くしたことで，気付かなかった論軸上の問題が露呈した。
今のところ知名デラングで外部スクリプトが必要なのは数式記法だけなので，数式記法では後縁に頼らず前縁で要素を検出するように修正して解決した。
新生デライト要件外だった全知検索窓固定機能（6歩），閲覧専用模動（14歩）の実装イメージも急速にまとまってしまった。これを機に新生デライトに組み込んでしまうことにした。
全知検索窓固定機能では，同じく長いあいだ課題だった新規描出フォームへの握接の問題も解決してしまった（18歩）。新規描出フォーム固定機能についても当面考えなくていいことにし，実質的に解決した（10歩）。
譜類添付機能実装の課題だった用合いについて実装イメージが急速にまとまったので少し整理して終了。
希哲15年3月24日5歩で渡括記法を利用した添付譜類管理方式を考案し，その方向で進んできたものの，一点だけ，「埋め込みたくない添付譜類をどうするか」という問題が浮上し停滞していた。
これに関しては，ひとまず編注記法を活用することを思い付き，必要なら追い追い記法調整していくことで解決した。+[拡張子] を -[拡張子] のようにすれば非表示に出来るという記法も考えたが，埋め込み記法全体の整合性も考える必要があり，なかなかまとまらなかった。
昨年から輪郭選り手に添付譜類管理用の部区を設ける案も再検討していたが，やはりどう考えても美しい用合いにはなりそうにない。アイコンと拡張子を並べるとすると，当然添付譜類が多くなればごちゃごちゃしてくるし，少なければ無駄が大きくなる。何より，現状の輪郭選り手が理想的なばら成しなので，これ以上余計な部品を加えたくない。
渡括記法を利用した添付譜類管理方式の再評価の機運が高まっていたところで今日の思い付きが決め手となった。
輪郭選り手の変更有無表示機能を含めた取り消しボタン周りの改良（12歩），知名欄・描写欄の捕活に関する仕様まとめ・実装（20歩）。どちらも最近の課題だったが，上手く解決した。
昨日の開発から連鎖的に輪郭選り手改良が進み，より快適になった。
position: fixed}{希哲16年12月16日の副日記}{誤表示}{誤移動}{再認識出来た}{どうにもならなそう}{数値を弄る}{ずれ方}(134)前縁の問題をいくつも解消。特に諸場用合いはだいぶ良くなった。
Android 版 Chrome で，全知検索窓を捕活している（ソフトウェアキーボードが表示される）時に輪郭小窓が表示されると全知検索窓までスクロールしてしまう問題を修正。iOS Safari 含め他の舞覧では再現しなかった。
とりあえず，touchend で document.activeElement.blur() を使って捕活を外すことにした。
iOS 版 Safari で輪郭小窓が開く前に輪結先に移動してしまうことがある問題を修正。
iOS 版 Safari でのみ同じようにタップしても10回に1回程度の割合で生じる謎の現象だったが，実験を繰り返した結果，どうも click 事象が余計に発生しているようだった。
いったん click 事象を抑制し，touchend で輪結先に移動するようにしたら，意図しない移動がなくなった代わりに，同程度の頻度でタップしても輪郭小窓が開かない問題が生じるようになった。条件はありそうだが，感覚的には全くの不規則なのでどうしようもない。
新生全知検索整備，ページ付け求頼改良，サイトマップ改良，不具合修正など。
これまでサイトマップは全知検索ページャー同様，一定輪数を LIMIT 句・OFFSET 句で区切ったページを返していた。OFFSET 句の値が多くなると遅くなるため，最大でも最新10,000輪（100輪×100ページ）が限度だった。upub 導入後は更に低速化したため，9,000輪まで減らしていたが，それでも後半になると応答時間が10秒以上になることがあった。
今回のページ付け求頼改良で時印を使ったページ付けに移行しようとしていたため，これをサイトマップにも応用出来るのではないかと考えていたが，サイトマップの場合，サイトマップインデックスで各サイトマップ URL の一覧を生成する必要があり，この効率性が問題だった。HTML 隠しの利用も考えたが，タイミングも難しく，大袈裟過ぎる気がしていた。
サイトマップの場合，各ページの輪数が揃っている必要はないのだから，一定期間で区切ってしまえばいいのではないか，ということに気付いてからは速かった。
まず，デライト上で最古の時印（2012-02-10 19:09:33）から現在時刻までを30日で割って必要なページ数を割り出し，サイトマップインデックスは従来通りの形式（/see?pg=[n]）で生成する。dg_see() ではページ番号から期間を計算してその範囲内で上限輪数までの最新輪郭情報を返す。上限輪数はとりあえず10,000輪にしておいた。数値は様子を見ながら調整していく。
インターフェイスはそのまま利用したため修正は最小限で済み，互換性も維持出来たが，元々 dg_see() に余計な列が多い問題があったのでそのあたりも最適化しておいた。
実作業は出振るい・手定めまで正味3時間ほどで済み，結果として，サイトマップの速度・ページ数・対応期間の長さがはるかに向上した。現在時刻が基準なので，上限輪数から漏れた分も待っていれば載ることになる。ここまでページ数が多いサイトでは網羅性と効率性を完全に両立させることは不可能なので，ここが良い落とし所だろう。デライト特有の要求に適ったサイトマップ設計という，大きな問題がまた一つ解決した。
輪数取得改良，前後景時印の導入などを経て，サイトマップは高負荷求頼が発生しやすい最後の箇所になっていたため，これでデライトの安定稼動における不安要素が払拭出来た。ページ付け求頼改良を急いでいた理由でもあったが，最近の出振るいで，全知検索でもページ番号の直接指定に上限を設けたため，高負荷求頼の問題は一応解決している。これでページ付け求頼改良の優先順位が少し下がった。
_dg}{想定を越える}{複合索引}{後景時印}(74)一部の輪郭の応答速度が異常に遅い現象があったが，どうもこれは最適化系が混乱していたせいらしい。前後景輪の取得部分で遅くなっていることは把握していたが，輪括量にかかわらずあったため不可解だった。
ts_fg，ts_bg の追加後も，多少の改善は見られたものの，まだ異常な遅さの範疇だった。現象が不安定なので，不安定な要素に起因していると睨んで実行計画をよく観察してみると，_dg の時印の索引が選択されている時に知番の索引が使われていないことに気付いた。
そこで，前景知番と後景時印，後景知番と前景時印の複合索引にすると，全ての求頼でしっかり索引が使われるようになり，把握していた全ての当該輪郭の問題が解消した。さらに，低負荷求頼でも索引が有効利用されるようになり，想定を越えるデライト高速化に繋がった。膨大な輪括量が問題だとすると捌き手の性能の限界かもしれないと思っていたのでこの不安が無くなったのも大きい。