{〈lookahead〉}{正規表現}{先読み}(3)
{進捗記録}{描写}{進捗}{用者}{希哲15年3月11日の開発}{通信失敗}{再試行ボタン}{引っかかり}{希哲15年3月11日9歩}{希哲15年3月11日の進捗時限}(33)

{希哲15年3月11日10歩 K#F85E/E74C-264E}

描写後略機能仕様検討

前歩で考えた溶暗式の用合いを踏まえ,一定以上の位置スクロールされた時点で描写続き先読みすることにした。

底に到達した時に読み込むのでは用者が気付かない可能性があり,通信状態によっては引っかかりを感じさせてしまう。

途中で読み込みを発生させればつづきボタンのようなものは不要になる。せいぜい通信失敗時のための再試行ボタンのようなものがあればいい。

最近の用者は無限スクロール普及でこの手の挙動には慣れているので,特に違和感も無いだろう。

これで描写後略機能仕様は固まり,実装を残すのみとなった。

{進捗記録}{}{文字}{進捗}{<img>}{希哲14年9月19日の開発}{両立}{立求回数}{スプライト化}{希哲14年9月19日の進捗}(40)

{希哲14年9月19日6歩 K#F85E/5B28-9F8A}

デライト用合い改良デライト・アイコン集制作

途中で終了。

昨日,アイコン画像マウスオーバーなどで切り替える時,初回だけ一瞬画像が消えたように見える問題に気付き,適当に img 要素先読みさせる方法で回避したが,もっと賢いやり方がないか考えていた。

こういう場合,何らかの方法で先読みさせておくというのが定石らしいが,技術的には無駄が目立つ。画像が読み込まれた時点で切り替える簡潔な方法があればそれが理想だが,そんなものはなさそうだ。

ここで,各種アイコンスプライト化を考え始める。保守性観点からこれまで避けてきたが,要素が固まってきた今なら修正頻度はそう高くないはずだ。先読み同様通信量効率性に難はあるが,その代わり立求回数が大きく減る利点は大きい。

例えば,メニュー用,検索窓周り用,ページャー用など,互いに関連性の強いものをまとめておけば最適化保守性を高い水準で両立させられそうだ。

これまでボタン類をほとんど文字で作ってきたことで随分していたのだなと思った。

{先読み}

{}