{高さ制限}{内容の高さ}{機能的に}{混乱させない}{用者層}{利用率}{ウェブ利用者}{影響しない}{設定しておく}{最初以外}...=}(92)

{希哲16年5月30日の開発 K#F85E/E74C-DB91}

自動ページ展開機能実装一段落した細部に課題はあるが,実用出来る水準に達した出振るい手定め済み

これに伴い正式離立前試していた全知検索窓新規描出フォームの固定表示復活させる検討大きく進んだ。また,輪郭一覧動的追加仕組み整えたことで,検索新規描出時にも応用出来るようになった。輪郭一覧の更新効率的に行えるようになり,高速化にも大きく貢献するだろう。


AutoPagerize 対応どうするかというのが難しい問題だったが,これは挿入監視して削除注意書き表示する方向落ち着いた最初以外 .autopagerize_page_elementdisplay: none設定しておくことで表示には影響しない

AutoPagerize は,ウェブ利用者全体ではわずかな利用率だが,デライト用者使っているのを見て私自身使うようになったというのもあり,用者層重なり小さくない出来るだけ混乱させないようにしたかった。


今後広告の調整重要になってくるため,ここで運営者開発者向けダミー広告表示する仕組み整えたダミー広告の様子

AdSense は,設置者によるクリックもちろん無闇に表示させることも避けるべきとされているので,これまでは単に非表示にしていた


機能的に自動ページ展開機能似たところがある描写後略機能実装方針検討ほぼ完了

内容の高さ高さ制限足りない場合どうするか最後の課題だったが,これは舞覧側で追加取得すればいいことに気付いて解決した


=}
{需要がある}{地味ながら}{厳密に考える}{見分けが付く}{開いている時}{実装出来た}{現仕様}{万能ではない}{resize: vertical}{高過ぎず}...=}(116)

{希哲16年3月30日の開発 K#F85E/E74C-7061}

描写欄高さ問題きっかけ自動リサイズ機能字数計実装出来た。ほか装体調整など。

出振るい済み

自動リサイズ機能

旧輪郭選り手では,描写欄出放り高さ新規描出フォーム10em再描出フォーム15emとしていたが,新輪郭選り手ではたまたま15em統一されていた画面撮り10emでは長文書きにくいのでこれはこれでいいかと思ったが,やはり新規描出フォーム一言だけや知名だけの描出使うことも多いためこの高さでは邪魔臭い

ここで,予てからぼんやり検討していた自動リサイズ機能導入考えた一応 resize: vertical設定してあるが,万能ではない10emから20em程度までの範囲で,改行毎に自動リサイズさせる。導入予定字数計では字数情報必要になるため,一緒に行数保持させることにした。

実際に試してみると,1em刻みでも2em刻みでも違和感があったため,10emから19emまで1.5em刻みリサイズするようにした画面撮り初期状態最大自動リサイズ19emだと個人機でも低過ぎず高過ぎずスマートフォン縦向き柔品キーボード表示させてもちょうど収まる程度の高さになる。折り返し多い1行もありうるため,厳密にするなら字数考えるべきだが,とりあえずはこれで様子を見ることにした。

再描出フォームに関しては,さほど目立つものでもなく,描写部高さ合わせて描写欄開くようになっている現仕様悪くないので,現状維持様子見しておく。

字数計

字数行数保持出来たことで字数計難無く実装出来た描出ボタン時印左側邪魔にならないように表示させてみた字数計の様子

下見字数分けようかと思っていたが,下見開いている時下見字数置換すれば十分であることに気付いた一応見分けが付くようにに「」を付けるようにした。

これも,厳密に考える特殊な文字符号などを考慮する必要があるが,キリがないのでとりあえず .length による概算でよしとしておく。

字数計は,地味ながら意外に需要があることを市場調査通して知った自分でもたまに欲しくなることがあった。

{用者}{希哲16年3月12日の開発}{希哲16年3月12日の進捗}{`}{解釈出来る}{完了させた}{中途半端な実装}{使用経験}{書き換えずに済む}{意図の明示}...=}(133)

{希哲16年3月12日7歩 K#F85E/E74C-8A2F}

交度記法改良

以下の作業終えたため,ここでいったん終了

これにより,デラング記法例示洗練された

```txt
これまでのデラング記法の例示
```

``dlng
これからのデラング記法の例示
``

交度部区記法開始記号終了記号については,これまで ``` 固定だったため,交度部区記法内で交度部区記法について例示出来ないという問題があった

行内交度記法逆括点の数を調整出来るようにして1月17日15歩から,この方式統一することを考えていた

これを機に逆括点の数は2個でもとした。区切り線記法最初から Markdown などで一般的な3個以上ではなく2個以上-導入したが,交度部区記法では確信が持てなかった

交度部区記法実装からちょうど一年経ち3個以上でなければならない理由はない,と使用経験から判断したなんなら1個でも解釈上問題はないはずだが,目印としての機能考える2個限度だろう。他の記法との統一感もある。


これまで外部ライブラリhighlight.js任せだった交度部区記法言語名自主的に管理する第一歩として,取り急ぎデラングνS対応した

デラングdelangdlngdlntxt に,cuucppに,νsvsjs に,それぞれ Dex 側で変換するとりあえず大文字小文字区別しない

これまではデラングtxt などと書いていたが,意図の明示という観点から問題があった。これなら今後構文ハイライト対応した時に書き換えずに済む

言語名対応関係については実装委ねるべきかとも考えたが,将来的に混乱の元になりそうな部分なので,対応関係言語仕様規定し,構文ハイライトなどは任意実装とすることにした。

また,用者未定義言語名使用出来るように,例えば ```newlang(oldlang) のように代替言語名指定出来る記法検討開始している


1月17日15歩で,外側逆括点の数を調整出来る仕様にしたが,`` `a` `` のように外側より少ない個数でないと上手く解釈出来ないなど中途半端な実装だったことを思い出し実装完了させた

これで ` ``a`` ` でも `` `a` `` でも `` `a`` でも,対応する逆括点さえ判別出来れば問題なく解釈出来るようになった。


全て手定め出振るい済み

=}
{出振るい済み}

{}