{出振るい}{低下する}{発生していない}{心当たりがない}{一番気になった}{新規描出下書き抜控}{判別用}{Aejs_DG_rev}{長期的視野に立って}{更新方法}...=}(224)

{希哲16年5月23日の開発 K#F85E/E74C-8D2F}

輪郭選り手抜控機能整備概ね終えようやく出振るい出来た追い追い修正していけばいい程度の軽微な不具合はいくつか見つかったが,抜控機能整備についてはここで一段落とすることにした。

この出振るいにより,中途半端な実装だった輪郭選り手抜控機能一通りの機能揃った下書き抜控一覧使えるようになり,抜控把握容易になった予てから欲しかった新規描出フォーム消去復元ボタン抜控削除のため追加した18日の開発実装した描写拡縮ボタン使えるようになった。また,周辺の交度整理大きく進み,理腑としての意義大きかった

利便性信頼性向上はもちろんのこと,昨年から中途半端な状態引きずってきた当努片付いたことによる精神衛生上効果大きい昨年来他の当努本格的に着手していないか,着手して間もないので,ここから思考整理しやすくなる


抜控機能整備長引いた最大の原因は,他にやりたいこと多過ぎたことだが,これ自体も決して簡単な作業ではなかった。ただ,この間設計方針変わったり深刻な不具合気付いたりしたので,時間をかけたことで円滑に片付いたもある。

再描出知番でいいとして,新規描出をどうするか,というのは難しい問題一つだった。昨年7月28日6歩から検索語含めるようにして悪くなかったので,基本的にこれを踏襲することにした。ただし,全知検索窓から未送信検索語まで取っていたため,これを書き換える意図せず他の抜控上書きしたり消去してしまう可能性があった4月28日20歩書いた消失不具合原因だろう)。これは求頼文字列から取ることで回避した

下書き抜控一覧についても,表示条件領当てなど色々考えること多かった検討の結果再描出下書きは,検索語無し場合上部メニュー同様のみ輪郭一覧表示画面撮り新規描出下書きは,他の抜控がある場合のみ新規描出フォーム上に常に表示させることにした画面撮り邪魔になり過ぎない程度に気付きやすい。また,4月10日の開発決めた通り一覧省略などせずにそのまま表示することにした。描写部のように高さ固定することも考えたが,やはり,用合いの複雑化抜控溜め込み過ぎる懸念があるため見送った抜控溜め込み性能低下消失リスク増大(あるいはそれを補う作業コスト増大繋がる目障りになったら消化するようにしてもらいたい。

一番難しかったのは鍵仕様設計だった。一応鍵仕様変更時の更新方法考えていたが,手間考えるころころ変えるわけにもいかないので,長期的視野に立って設計する必要があった。これもなんとか落とし所見つかった一時仕様変更日時含めることを考えていたが,これは複雑化招くだけなので廃案とし,Aejs_DG_rev判別用文字列入れておくことにした。新規描出下書き抜控には自我知番含め自我切り替えにも対応した

その他,これまで描写のみ保存していたのを知名にも対応する消去ボタン復元ボタン実装する,などこまごまとした問題片付ける必要があった


出振るい後軽微な不具合がいくつか見つかったが,一番気になったのが,鍵仕様更新処理失敗だった。領下十分な手定めをしたつもりだが,本番環境では一部1回処理更新出来なかった結果的に3回実行する必要があった開発者通類localStorage内容見ても交度見返しても心当たりがない

少し迷ったが,時間が経つにつれ重要性急速に低下する部分なので,調査打ち切ることにした。最も使用頻度高い常連用者達が出振るい後普通に使えていることから,深刻な問題発生していない判断した今後同様処理書く際の注意点として記憶しておく。

=}
{👍}{希哲16年4月7日の開発}{希哲16年4月7日の進捗}{ページ遷移無し}{停止する}{フォームの送信}{-webkit-tap-highlight-color}{妙な効果}{タップ時}{用意されている}...=}(75)

{希哲16年4月7日14歩 K#F85E/E74C-D3A9}

進捗時限記録中略

細かい装体調整など。

iOS上のSafariで,横方向での閲覧時に引き入れ輪郭が不自然に大きく表示される」という不具合報告があったが,確かに手元iPhone同様現象があり,気になっていたデライトの不具合にしては不可解なのでもしかしたら舞覧稀なバグなのかと思ったが,再現性があるらしいことが分かったため調査した。

結局諸場舞覧自動拡大機能であり,text-size-adjust-webkit-text-size-adjust)という制御用CSS プロパティまで用意されていることが分かった。以下のようにして解決

-webkit-text-size-adjust: 100%;
text-size-adjust: 100%;

もう一つ諸場舞覧気になっていたことに,輪結ボタンタップ時妙な効果入るというのがあったので,ついでに調べてみると,これも諸場舞覧特有機能で,-webkit-tap-highlight-color不可視出来た


スマホ弄っているうちに,iOSSafari全知検索ボタン動き付け止まっていることに気付いた

これはフォームの送信などで描画処理停止する Safari 特有仕様であることが分かったSafari の問題といえばそうだが,実用上の問題はなく,まともな解決策無さそうなので放っておくことにした。

全知検索整備方針定まったことだし,そろそろページ遷移無し輪郭一覧更新出来るようにしてもいい頃だろう。

=}
{HTML}{進捗記録}{分かる}{見過ごしてしまった}{内部処理}{loading.html}{気付きかけた}{後方互換模動}{<iframe>}{<!DOCTYPE html>}...=}(57)

{希哲16年1月21日10歩 K#F85E/E74C-38B2}

進捗時限記録中略

領下手定め環境での開発者通類梱装がすっきりしたところで,<!DOCTYPE html> がなくて後方互換模動になっているという警告が出ていることに気付き,調査

結局FirefoxAutoPagerize AdvancedChromeAutoPagerize<iframe> 要素内に表示する HTMLDOCTYPE 宣言 が無いことによる問題だった。よく読めば拡張機能から出ている警告であることは分かるが,勘違い重なり気付くのに時間がかかった

まず,デライト出力するソースを見ると,以下のように不自然出力になっている。これは特に問題ではなかったが,ここでデライト出力に何か混入しているのかという勘違い発生した。

<!DOCTYPE html><html lang="ja-JP">

<head ...

ただ,試しにここを修正しても警告は消えないし,全知検索検索結果によって警告が出たり出なかったりする。ここで AutoPagerize Advanced問題かと気付きかけたところで,Chrome でも同じ警告が出ていることを確認。これで「拡張機能問題」という考えんでしまった。だいぶ前に Chrome にも AutoPagerize引装していたことを忘れていた

小一時間悩んだ挙句Firefox警告表示されている loading.htmlクリックしてみて正体分かった。これも一見内部処理関連っぽい名前なので見過ごしてしまった

何はともあれ,デライト問題がなくて安心した

=}
{HTML}{デライト}{外部スクリプト}{角括弧}{読み込む}{描画}{混乱}{記法}{検証}{検知}...=}(19)

{数式の描画について K#F85E/E74C-D7A6}

報告検証ありがとうございます。ご指摘を受けて調査してみたところ,単に角括弧を使った記法への対応が抜けていたことによる不具合のようです。

デライトでは,外部スクリプトが必要な記法検知すると外部スクリプト読み込むように HTML出力します。したがって,ページのどこかで数式検知されている(「標本: 数式表示」の場合は丸括弧による数式)と,単体では検知されていない数式も正しく描画されることになります。

出来るだけ早く修正いたします。混乱させてしまっているようでしたので取り急ぎご報告まで。

{調査}

{}