{希哲17年5月7日の進捗}{希哲17年5月7日の開発}{希哲17年5月7日}{一番楽}{アイコンらしく}{補完した}{柔軟性の低い}{そうすると}{範枠化}{効率的ではない}...=}(87)

{希哲17年5月7日5歩 K#F85E/E74C-BDDE}

動的引連 SVG アイコン実装

途中で終了

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

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

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

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

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

{デライト}{👍}{希哲17年4月17日の開発}{希哲17年4月17日の進捗}{希哲17年4月17日}{.bmp}{して欲しくはない}{制危面}{表現出来ている}{名前を付けたくなった}...=}(148)

{希哲17年4月17日13歩 K#F85E/E74C-3416}

進捗時限記録中略

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

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

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

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

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

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

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

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

{実装}

{}