{出振るい}{低下する}{発生していない}{心当たりがない}{一番気になった}{新規描出下書き抜控}{判別用}{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内容見ても交度見返しても心当たりがない

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

=}
{デライト}{なおかつ}{制御しやすい}{握接出来る}{選り手を開く}{操作手順}{複製輪郭}{ボタンを押す}{ずっと考えていた}{視認出来る}...=}(116)

{希哲16年5月18日の開発 K#F85E/E74C-2BA8}

長い間課題だった描写拡縮ボタン輪郭複製機能について大きな進展があった。

描写拡縮ボタン

昨日の開発最大化アイコン出来たことをきっかけに,描写拡縮ボタン実装イメージ固まり,実装手定めまで概ね完了した想像以上に早く上手くまとまった下見機能との相性も良い。ただし輪郭選り手抜控機能整備途中であるため未出振るい

描写拡縮機能的には単純だが,用合い特に領当て難しかった最近描写部下境界重ねる形での実装考えていたが,描写部飛び出す他の要素干渉してしまう。かといって余白無駄に広げたくない。これは,下部陰影重ねつつ,初期化時点スクロール可能な場合は下余白追加することで解決した文字暗い背景色重なっても視認出来るように,半透明白背景付けた

拡大ボタンスクロール可能であることの目印としても効果的なので,これを活かしてスクロール完了時には透明度を上げ,それと分かるようにした。

これで,外観操作感ともにデライト調和した描写拡縮ボタン出来た描写部高さ固定一覧性確保するために必要なものだったが,用合い上弊害小さくなかった陰影付きスクロール最大化アイコン,そして描写拡縮ボタンによって,ようやくこの問題解決した

輪郭複製機能

輪郭複製機能課題としてずっと考えていたが,用合い上難しさがあった。

ボタンを押すことで複製輪郭出来る,というのは使用頻度考える誤操作懸念の方が大きい。となると,目立たないように置くしかない。かといって,操作手順増えると,選り手を開いて写し貼りするのと大差ない

簡単に握接出来て,なおかつ制御しやすい用合い必要だった。ここで,「知名描写複製して新規描出フォーム移動するボタン」があればいいことに気付いた。これなら,自輪郭常に表示しておいてもいいだろう。

輪郭選り手では×ボタンがある位置置けそうだ。

{用者}{HTML}{HTML5}{デラング}{進捗記録}{高い}{あれ}{役割を持たせる}{役割を持つ}{緩衝的}...=}(248)

{希哲16年2月15日10歩 K#F85E/E74C-2CA8}

進捗時限記録中略

昨日寝る直前にまた脳爆発があり,今朝にかけて文字装飾記法タグ記法周りの概念整理仕様整理急速に進んだ

文字装飾記法は,「文字装飾を伴う慣用表現」のための記法位置付けることにした。太字記法##斜体記法//下線記法__打ち消し線記法~~翌日のまとめで「打ち消し記法」から改称4記法基本とし,それぞれ所定装体スタイルを伴う <b><i><u><s> HTML 要素対応する

@ を使った文字サイズ記法% を使った色記法検討していたが,タグ記法概念が出来たことで中途半端なものになるため,これは廃案とする。

文字装飾記法はこれがほぼ完成形か。

検討過程

3つ検討方針

実装自体は容易部類で,記法概ね固まっていたにもかかわらず文字装飾記法実装踏み切れなかった理由として意味論的な問題があり,これが思いのほか難題だった。実装方針3通り考えられる

  1. 完全に意味論的な記法にする
  2. 完全に装飾的な記法にする
  3. 意味論装飾重ね合わせた記法にする

記法趣旨からしても,軽量標記マークアップ言語特性を考えても,1つ目に無理があるのは明らかだ。対応する HTML<b><i><u><s> は,私が何度解説を読んでもややこし感じる代物だ。それを多くの人正しく理解して使うのは不可能だろう。そもそも「文字装飾記法」という分かりやすい説明体系捨てることになるが,代替案があるわけでもない。

かといって,2つ目ももったいない。要は <span>装体指定だけにするということだが,例えば,太字にはしたいが <b> にはしたくない場合打ち消し線引きたい<s> にはしたくない場合がどれだけあるのかと考えると,無難通り越して臆病過ぎる失う可接性アクセシビリティ応用可能性釣り合わない

最終的に採用することになった3つ目も,全く考えなかったわけではないが,柔軟性に欠け,前の2つの悪い所組み合わされる気もして,有力案にはなっていなかった。

タグ記法による書き分け

この膠着状態変えたのは,前日概念としてまとまったばかりのタグ記法だった。

これまで,デラングにおける HTML は,どうしてもデラング出来ない表現をしたい場合などの“抜け道”とか“救済措置”に近い位置付けで,積極的に使うことを想定していなかった。実際個人的にはほとんど使っておらず放置している不具合多い部分だった。

デラングタグ記法として間接的に HTML使うことで,略記法導入可能になり,HTML 側の仕様変更に対しても一定の緩衝帯設けることが出来る。ここに来て初めて文字装飾記法でも「書き分け」が考えられるようになった文字装飾記法対応しうるのが全て1文字要素だったことも幸いした

昨日寝る直前に,##太字的な表現##<{font-weight:bold}>太字</> のように書き分けるよりも,##太字##<b>太字的な表現</b> のように書き分ける方がマシであることに気付いて,1つ目の実装方針完全に潰せた

これにより一時的に2つ目の実装方針再浮上したが,標準的に使う記法として標準的な用途最適化不足なのはやはり否めなかった

決着

最終的に,「文字装飾を伴う慣用表現」という用者自然に理解出来る範囲での意味論的位置付け与え逸脱する用途ならタグ記法書き分けるのが使用頻度に対して最適だろうという結論に達した。3つ目の実装方針洗練させた格好になる。

例えば##太字## は「太字装体<b>」に対応する装体邪魔なら <b>太字的な表現</b>書けるし,意味邪魔なら <{font-weight:bold}>太字</>略記法検討段階のように書けるが,これらの場合稀少なのは明らかで,記述量上手く釣り合うワープロならともかく,軽量標記言語手書きしようという人にとって難しい使い分けではないだろう。

そもそも<b><i><u><s> は,古くからある視覚的要素HTML5慣用的な用途引き継いで意味論化されたものなので,「文字装飾を伴う慣用表現」と非常に相性が良い相互変換にも全く問題ない

何より,直感的に入力すれば構造的に出力されるというデラングの理想適っている

文字サイズ記法色記法廃案

文字装飾記法を「文字装飾を伴う慣用表現」と位置付けたことで,慣用表現を持たない文字サイズ記法色記法仲間外れになるが,タグ記法によって出る幕がなくなった感があるので,ここで廃案にすることとした。

第一に,タグ記法略記法整備した方が一貫性応用可能性高い特定プロパティ省略出来るようにし,<{white}>白い文字</> のように書ければ,%white%白い文字%% と書くのと記述量大差ない

もともとパラメーター必要とする記法異質感はあり,文字装飾記法統一感損うかという懸念はあったので丁度良かった

波及的検討

波及的に,いくつかこまごまとした検討進んだ

組み合わせは「」ではなく「入れ子」へ

これまで,複数文字装飾記法組み合わせ#/太字と斜体/# のように,「記号を1つずつ逆さにした終了記号挟む」といったややこしい説明考えていたが,##//太字と斜体//## のような「入れ子」を #/太字と斜体/#短縮出来るという考え方にした方が分かりやすいため改めることにした。

タグ記法発展

今回検討で,タグ記法早くも実践的な役割を持つことになり,デラングにおける存在感一気に増した

タグ記法HTML仕様変更対する緩衝的役割を持たせること,要素名省略<span> にすることを考え始めた

{進捗記録}{高い}{希哲16年2月7日の開発}{表示された}{0.1em刻み}{狭まってしまう}{滅多に使わない}{階層の深さ}{変わってしまう}{4階層}...=}(87)

{希哲16年2月7日16歩 K#F85E/E74C-5EF4}

{HTML}{::after}{文字サイズ}{進捗記録}{目立ってしまう}{制御しにくい}{double}{果した}{調整余地}{font-weight}...=}(121)

{希哲16年2月6日12歩 K#F85E/E74C-06F4}

デライト装体調整終了

見分けにくかった見出し装体視認性大きく向上した修正前修正後

見出し装体固定化

まず,これまで中景輪符<h1>始まる<h2> で始まる前後景輪一覧かで描写内見出し装体1階層ずつずれていたが,これはいったん固定することにした。

ずれるのも HTML文書構造からみれば間違った表現ではなく,中景輪符表現も少し変えるべきかと考えていたが,これもなかなか難しい中景輪符知名部は,現状 <h1> でも <h2> でも font-size: 1.4emfont-weight: boldletter-spacing: 0.05em という装体になっている。輪郭という情報単位粒度考えた時,これ以下は小さ過ぎ,これ以上は大き過ぎという所だ。

他の要素も,要素同士の対比考えて細かく装体調整しているため,それらまで見出し装体変化合わせる保守性悪影響を及ぼす。将来的にどうかはともかく,現時点でそこまでする利点は無いだろう。

CSS では h1 ~ .dln h2, h2 ~ .dln h3 のように兄弟結合子使えば簡単に実装出来る。

装体調整

あくまでも描写内での見出し階層装体固定することにした上で,第1階層から第4階層までの描写内見出しには二本線一本線破線点線4種類下線を付けることにした。これまでは第1階層2px第2階層1px一本下線のみだった。

二本線border-styledouble では制御しにくいため ::after使い,1px2px間隔をあけた。また,点線舞覧によって破線より目立ってしまう場合があるため,調整することにした。

最初は,第1階層二本線第2階層一本線があれば十分かと思ったが,結局文字サイズだけの変化ではぱっと見分かりにくい。各描写内見出し図形的特徴があった方が良い。

文字サイズは,これまで 1.3em1.2em1.1em1.05em1em だったのを 1.3em1.2em1.15em1.1em1.05em とした。

1.3em から 1.1em まで0.05em刻みの方が数字的には綺麗かと思ったが,下線特徴を付けても,特に第1階層第2階層一見して見分けにくかった画面撮り。それ以下は使用頻度も低いので0.05em刻みでも大きな問題はないだろう。

letter-spacingfont-weight調整余地はもう少しありそうだが,視認性改善という目的十二分果したのでここで一段落とした。

2px一本線よりも1px二本線の方がすっきりした印象になるのが意外だった。

{進捗記録}{導入する}{文字装飾記法}{下線記法}{斜体記法}{太字記法}{打ち消し線記法}{希哲16年1月23日16歩}{微妙な要求}{たまにあった}...=}(94)

{希哲16年1月23日12歩 K#F85E/E74C-5AE3}

進捗時限記録中略

3歩きっかけ久しぶりに実装予定文字装飾記法について見直し,以下のように基本的方針整理した

<<大きい文字>>
>>小さい文字<<
##太字##
//斜体//
__下線__
~~打ち消し線~~

下線記法については,_下線_有効にすることも考えていたが,適当に書いた時の誤解釈増える懸念もあり見送ることにした。文字装飾記法2個以上記号統一した方が綺麗にまとまる簡潔な記法追加するより削除する方がずっと難しいので,使用頻度考えてもいまあえて導入する動機に乏しい

……ここまで考えて昨年6月23日10歩でも同じ結論を出していたことに気付いたが,再確認出来た。


太字記法については,昨年6月23日9歩では ++太字++検討しているものの,最近 ++行内埋め込み記法利用することを考えているためこれは避けたい。そもそも「強調ではない太字」という微妙な要求のための記法であり,廃案脳裏をよぎった

分かりやすい代替記法がありうるのかと思ったが,意外と ##太字##悪くない。「くっきりした」という意味シャープにもかかっているし,見た目濃さ丁度良い後述文字サイズ記法同様,記号の数濃さ調整出来ても面白い


ついでに<<大きい文字>>>>小さい文字<< という文字サイズ記法思いついた大きさ小ささ記号の数調整出来てもいい。直感性申し分ない

あまり文字を大きくしたい思ったことはないが,小書き括弧記法を使わずに文字を小さくしたいと思うことはたまにあったので良い拾い物だった。


斜体記法打ち消し記法については特に変更無し


上線記法検討していたが,ここまでで HTML の要素相当するものはい,軽標記言語としての表現力十二分なので,いったんここで一区切りとすることにした。

{時印更新}{進捗記録}{自輪郭}{他輪郭}{希哲15年2月13日の開発}{時印更新ボタン}{目立ち過ぎる}{希哲15年2月13日の進捗時限}{希哲15年2月13日の進捗}{希哲15年2月13日}...=}(51)

{希哲15年2月13日6歩 K#F85E/E74C-F2A8}

知名編集周りの不具合修正調整

いったん終了。

無名輪郭描写だけを編集保存した際,知名「あれ」が設定されてしまう問題他輪郭知名欄を開いても読み取り専用になっていない問題,輪結URI 符号化が出来ていなかった問題,その他表示上の調整を終えた。

全て実用上大きな問題ではないが,微妙違和感使いにくさを感じさせる要因ではあった。

他輪郭知名欄は開けても仕方ない気もするが,将来的に特殊記法を導入する可能性があり,写し取りしやすいという実用上利点も一応ある。

知名欄を開いて閉じるだけで更新されてしまう問題だけが気になるが,これは近いうちにやる同期見直しとまとめることにした。

ここでふと,時印更新用のボタン描き直しボタン表示させるようにすることを思いついた。

自輪郭更新日時の記号をボタンに変え,押すだけで時印更新出来るという方向検討していたが,想定される使用頻度の割に目立ち過ぎ誤操作誘発しかねないという問題があった。

描き直しボタン輪郭更新にかかわるウィジェットを全て表示するボタンと捉えれば,時印更新ボタン表示させる機能を兼ねさせるのも理に適っている。

=}
{使用頻度}

{}