デライトの HTTP/3 対応についての再検討で終了。
導入は簡単そうだが,まだ逆効果になる場合も少なくないようでちょっと迷った。低品質な通信環境に強いなど総合的な利点は大きいので,全体最適化を期待して近いうちに導入実験をしてみることにした。
導入は簡単そうだと思ったが,nginx ではまだプレビュー版らしく備立の管理が面倒臭そうだった。本体に取り込まれるのを待つべきか。
デライトにおける νS(JavaScript)渡配についての検討などで終了。
しばらく,ES5 への渡配をやめて様子見することにした。備立環境は調整済み。次回の前縁出振るいで本番環境にも反映されるだろう。
希哲13年8月23日の開発以来,νS では ES2015 を基礎にしているが,同時に Babel を導入し,配信スクリプトは ES5 に渡配していた。それから4年近く経ち,デライトの舞覧対応方針は洗練され,ES2015 の対応舞覧も十分な市影を有している。もはや ES5 との互換性を引きずるべきではないと判断した。
とりあえず,--presets
応付子を外して,babel --no-babelrc --minified --no-comments
だけで換配するようにしてみると,ae.js
の譜類サイズは20kB近く減った。譜類サイズ削減以上に,スクリプトの複雑化に伴うオーバーヘッド増加抑制も期待出来る。
ES2016 以上の交度がうっかり紛れ込む(紛れ込んでいる)可能性を考えると ES2015 への渡配をしておいた方がいいかと思ったが,どうもそういう考え方をする時代でもなく,Browserslist を使った手法が主流らしい。確かに,舞覧の対応状況が非常に流動的なので実態に合わせる方が合理的ではあるが,ブラックボックス化は避けたい。これまで通り,導入付徴の対応状況は個別に把握しておくことにした。デライトの能力が活かせるだろう。
いずれにせよ Babel の設定で後からいくらでも調整出来るので,いったん渡配無しで様子見する。
ついでに,変数名などの短縮などについても再検討したが,やはり外部通類への依存度を高めず保守性を維持するのは難しいため見送った。交度英語のおかげで一定の短縮性は保たれている。
輪符補完機能などのため描写選り手で採用する予定だった contentEditable
の導入について急遽再検討して終了。
contentEditable
の導入はいったん保留とし,<textarea>
の座標計算用の <div>
を作る手法を先に試してみることにした。
前歩で再描出フォームの maxlength
属性を設定しようとして,ふと,contentEditable
ではどうするのだろうと調べてみたら思いのほか面倒臭そうだった。これに限らず,どうもそこまで洗練されたものではないらしいということが分かってきた。
デライトではさほど複雑なことをする予定は無いので,よくある装体複製 <div>
を使った手法で十分というかマシな気がしてきた。装体複製 <div>
も初めて知った時はどうかと思ったが,それ以上に洗練された方法が無いなら仕方ない。
contentEditable
はかなり前から導入する気でいたが,当初は念のため <textarea>
の実装も残しておくつもりだった。contentEditable
ももはや枯れた技術なので,<textarea>
は切り捨てるべきか,と最近になって考えるようになった。まさかここで正反対の方向に舵を切ることになるとは思わなかった。
前後景一覧は別として,検索語無指定の場合の輪郭一覧で描写のない他輪郭を非表示にすることを検討。以前からあった案だが,いくつか懸念もあり見送ってきた。
輪郭の展示としては知名のみの輪郭は邪魔に見えることが多いが,非表示にする条件の導入により挙動が複雑になることで多少用者の混乱を招くだろう。読みやすくなる代わりに,内容のあることを書かなくてはならないという誤解で書きにくくなるかもしれない。また,知名のみの輪郭での表現にも有用なものはあるので,全て非表示というのももったいない。かといって,後景輪があるものを例外にすると中途半端で現状と大差ない。
いずれにせよ,自我で輪郭一覧の見せ方を変える仕組みは公開設定機能で整える必要があるので,その時に再検討することにした。
越化周りの客体表現化を考えるついでに文字参照の越化について再検討して終了。
HTML 越化仕様を決めた昨年5月20日12歩以来,越化目的で使う可能性がある文字参照のみを許容していたが,これは修正し,いったん全ての文字参照を許容することにした。
4日21歩でも再検討したが,越化記法同様,デラングにおける特殊文字を白表方式で管理するのは無理がある。損われる保守性に対して利点が乏しい。
当初は制危というより迷惑行為対策など運営上の都合で必要になるのではないかと思っていたが,Wikipedia はじめ大規模サイトで開放されている例も珍しくなく,少なくともデライトの言語仕様にするほど必要な制限とは言えない。文字参照で制危上致命的な問題があればそれは舞覧の問題だろう。迷惑行為対策としてもあまり本質的ではない。
何か問題があれば制限する,で十分なはずなので,実装都合で制限してもいいことにする。
文字参照には,表示や入力に難がある文字が記述しやすいという有用性も一応ある。