動的引連 SVG アイコン実装。

@icn の実装も概ね完了し，ひたすら調整を繰り返す段階に入った。

動的引連 SVG アイコン実装。

既存画像アイコンの SVG 化は完了し，@icn の実装と画像アイコンの置換作業に入った。

動的引連 SVG アイコン実装。

ここから @icn の実装と画像アイコンの置換作業に入る。

途中で終了。

動的引連 SVG アイコン実装。

途中で終了。

SVG スプライトを background-image などでも利用出来るようにする実装について考えていたが，ここは割り切って，原則，SVG アイコンは引連 SVG としてのみ扱う方針を決めた。

実装上の都合で background-image を使っているだけのアイコンは別として，現状，背景とアイコンの二つの役割を持たせている二輪鎖を念頭に置いた検討だったが，背景としての二輪鎖も特定要素の端っこに置いているだけなので，一番楽な方法ではあるが background-image を使う必要は無い。

<view> の舞覧対応状況に不安があることはさておき，フラグメント識別子を付けると多重立求が発生する舞覧があることがどうしても気になる（手元の Linux 版 Firefox でも発生する）。background-image を使いたいのが二輪鎖だけだったのでまだ問題は小さいが，SVG スプライトが十分に軽量でフラグメント識別子での参照が十分に少ないという状況でしか効率的ではない手法は範枠化出来ない。

スクリプトで補完した要素に background-image を設定することも検討したが，そうすると実装コストが動的引連 SVG と変わらない上に，より柔軟性の低い参照方法でしかなくなる。

結局，アイコンはアイコンらしく，要素と一対一で扱うものと割り切った方が何かとすっきりする。

（進捗時限記録中略）

デライト全体における添付譜類の方針検討で終了。

添付譜類はあくまでも添え物として最小限の役割に留め，エクスポート機能でも実譜類の出力には今後対応しない方針を固めた。

元々添付譜類は添え物として設計しているが，実際に譜類添付機能が出来，エクスポート機能を実装しようとしてみると，実質的な役割の落とし所が意外に難しい。意図に反して，変に使われ過ぎるのも問題だ。

エクスポート機能では，とりあえずは代替 HTML などで済ませ，ゆとりが出来たら実譜類にも対応するか，などと考えていた。そもそも，どんな大企業のクラウドであれ消えて困るような譜類の唯一の保管場所にすべきではないし，そこまで神経質な人が手元に抜控を持っていないということも考えにくいので，実はさほど必要性の高い付徴ではない。とはいえ，エクスポート時の負荷や帯域だけが問題なら金で解決出来るのだから，将来的に対応しないというほどの動機もない。

しかし，添付譜類がエクスポート出来てしまうことで譜類倉庫的な利用が増え，それに伴い譜類保全の責任が増せば，将来にわたって無視出来ない経営上の問題になる。ということについさっき気付いた。描出公開原則同様，ここは割り切った用者文化を育てていくべきだろう。

これに気付いてみて，最近，添付譜類の役割を広げようとし過ぎていたことにも気付いた。譜類添付機能のサイズ上限や拡張子制限の緩和も考えていたが，これも最小限に留めることにした。拡張子制限は制危面もあるが，献典として非効率だったり無意味だったりする譜類の上信抑止といった効果も望める（例えば .bmp をそのまま上信して欲しくはない）。

デライトの強みは，知番による意味符号化で文字献典の情報密度を極限まで高め，その軽さを最大限に活かせることだ。譜類倉庫的な方面で消耗するのは差別化戦略として明らかに悪手だ。譜類添付機能実装以降，その軸が微妙に揺らいでいることはうっすら感じていた。今日は妙に頭がもやもやしていると思ったら，どうも脳がそれを訴えていたらしい。気付いたら非常にすっきりした。

描出公開原則のように何かこの方針に名前を付けたくなったが，「譜類添付機能」という名前で趣旨は表現出来ているので，それに立ち返るということで十分だろう。

設定ページ整備，エクスポート機能実装など。

気になっていた改行交度周りの仕様・実装も整理出来た（14歩）。