{しやすくなる}{交流したくない人}{交流したい人}{判別出来る}{権限確認用函数}{付けない}{前回の}{拡張出来る}{十分だった}{実際の}...=}(109)

{希哲16年7月13日の開発 K#F85E/E74C-3D0B}

公開設定機能部分実装一段落した出振るい手定めともに円滑に完了した

全体として,当初想定よりは時間がかかったが,想定以上にすっきりまとま満足出来た

{完成の域に達した}{表記的}{写し取りたい}{共有目的}{貼り付けたい}{外部媒体}{適当な時期}{整理中}{省略された}{写し取り時}...=}(145)

{希哲16年6月17日の開発 K#F85E/E74C-9EA6}

自我知番省略機能実装終え第二次知番改良完了とした20歩ここでやっておこう思ったのも,途中で第零番節の削除転換したのもあまりにだったが,その割には終始円滑にり,収穫想定はるかに越えて多大だった。全体として大成功言っていいだろう。

第二次知番改良経て知番表記的にも内部的にも完成の域に達した。あとは仕様実装微調整繰り返していく

まず,当初の目的だった知番の簡略化言うまでもなく大きいこれまで一般のデライト用者最短でも K#9-XXXX/A-YYYY という15文字知番輪郭扱う必要があった。それが第零番節の削除によって11文字K#XXXX/YYYY になり,自我知番の省略によって7文字K#/YYYY になった。知番表記仕様に関しては理想的な形だ。

第零番節の省略」から「第零番節の削除」に転換したことで,知番周りの交度出場整理劇的に進んだ。これにより,効率性保守性大幅に向上したのはもちろん,「新括体採番法の完成」という思わぬ収穫繋がった未実装だった自動知番拡張もここで実装出来た今のところ第二番節しか使っていない状況だが,そろそろ必要かという丁度良い時期だった。

波及効果想定以上に大きかった出場見通しの悪さなどが障害になっていた機能実装に関しては大幅な所要時間短縮見込めるようになった特に見通しが悪い課題だった KNEST 隠し出与え構造がこの期間固まり,一気に実装可能性高まった自我知番省略機能Dex との連携必要になったことで,他の記法でも活かせる出与え共有機構整った。これが無番輪符改良などにも繋がっている

将来的に長い知番増えた時のための「知番略記法」を中心とした第三次知番改良方針固まった。この長年の課題にも解決の見通しが立った。

一つ見送ったこともある。自我知番省略された知番写し取り時自我知番付け自輪郭描写欄などへの貼り付け時自我知番の省略をする4月8日の開発記録,というのは,やはり用合いとしては理想的盛り込みたかったが,今回見送った。このあたりの事象Aejs整理中なので,どうしても場当たり的交度になってしまう。他輪郭素出から写し取りたい時や,外部媒体厳密な知番貼り付けたいという時には便利だが,現時点必要としている人少ない共有目的なら共有ボタンがある。交度整理しながら適当な時期実装することにした。

{用者}{進捗記録}{越える}{分かる}{知番}{希哲15年12月24日の開発}{導入しなかった}{完全に隠す}{繋がりうる}{知番の強み}...=}(116)

{希哲15年12月24日6歩 K#F85E/E74C-9D02}

自我知番の省略についての検討終了

昨日の開発から本格的に検討始めた自我知番の省略だが,描写内では輪郭自我知番全知検索などでは録入り中自我知番指す略記法として導入することを決めた

仕様として導入することに大きな問題はないが,難しいのは用合いにどう調和させるかで,これは今後の課題とする。

利点言うまでもなく文字列としての短縮性だが,変則性を一つ加えることで扱い難しくなる懸念もあった。省略有無混乱の元になる可能性もあるため,極力混同させないようにしつつ,ある程度は混同されることを想定した用合い提供する必要がある。この難しさは,これまで導入しなかった正しさでもある。

現状のように自我知番4桁収まっている間は,まだ略記法利点欠点拮抗するだろうが,そのうち8桁になれば流石に邪魔になってくるだろう。将来的に知番の長さ補う方法必要になってくるということは考えていたが,この課題解決策にもなることに気付いたことが決め手だった。

第零番節を除き輪郭知番8桁越えることは機械的な描出でもしない限り)考えにくいが,自我知番4桁なのはむしろ例外的な時期で,いずれ8桁標準になるし,遠い将来には12桁になることも考えておく必要がある。つまり,知番全体20桁まで長くなる現実的な可能性がある。

ここで自我知番の省略が出来れば,少なくとも自輪郭に関しては4桁から8桁輪郭知番だけ考えればいいので,十分な短縮性と言える。他輪郭なら20桁でも扱えなくはない

もっとも,自我知番12桁になるのは40億用者越えてからのことで,輪郭知番4桁もそう簡単には埋まらないので,現実には12桁から16桁知番模量層になるだろう。司組用者成熟度合わせて長くなっていくのが知番の強みだ。


考えている内に,自我知番の省略には無用な自我知番露出避けられる利点もあることに気付いた

テプラ機器知番ったりしているが,人目に触れる場所ではこれも個人情報流出繋がりうる自分だけ分かればいいなら自我知番表記しておく必要はないし,未公開にして完全に隠すことも出来る。

=}
{デラング}{平仮名}{進捗記録}{領当て}{デラング記法}{希哲15年3月23日の開発}{ややこしい}{見え方ボタン}{閉じるボタン}{最有力候補}...=}(72)

{希哲15年3月23日7歩 K#F85E/E74C-66D7}

デラング整備,「描き方ボタン」について仕様をまとめて終了。

デラング多機能化に伴い,学習宣伝等の観点から,他輪郭描写素文をもっと閲覧しやすくする必要が出てきた。

現状,Ctrl + ダブルクリックで閲覧することは出来るものの,ボタン自輪郭描き直しボタンのみ表示しているため,説明されなければどのように素文を見るのか初心者には分からない。

描き直しボタン追加時からしばらく全ての輪郭でそのまま表示していたが,紛らわしく,用合いもずっとごちゃごちゃしている時期だったため他輪郭では非表示にするようになった。

調整して復活させることは度々考えてきた。そのたび見送っていた大きな理由に,良い表現が見つからないということがあった。特にボタンラベル等に使う文言難しかった

簡潔かつ直感的ということで最有力候補は「覗く」だったが,漢字を使うと少し印象が硬い,平仮名で「のぞく」では「除く」と紛らわしい,語感もあまり良くない,そもそも何を覗くのか初見分かりやすいとも言えない,と一番マシな案が難点だらけだった。

今回の再考で,「描き方」が使えることに気付いた

描き直しボタンアイコン領当てはそのままに,ボタンラベルは「描き方」に変える。機能描写部Ctrl + ダブルクリックした時同様,描写欄のみ開く。

知名欄でも一部デラング記法を使えるようにする予定はあるが,利用頻度を考えると余計に感じることが多いだろう。従って,描写部が無い他輪郭では引き続き非表示とする。見る手段がないわけではないので困ることは少ないはずだ。

描き方ボタンで開いた場合,完了ボタンはもう少し自然に閉じるボタンにする。「見え方ボタン」にするのも面白いかと思ったが,かえってややこしいかもしれない。

「〜で描き直す」「〜で完了」から変えていなかった通注も「〜で描き方を見る」「〜で閉じる」とする。

=}
{HTML}{進捗記録}{<iframe>}{渡括記法}{共有用 URI}{埋め込み交度}{注意表示}{希哲15年3月14日の進捗時限}{希哲15年3月14日の進捗}{希哲15年3月14日}...=}(49)

{希哲15年3月14日4歩 K#F85E/E74C-7B1F}

デラング整備HTML タグ切り替えについて再検討

iframe 要素sandbox 属性を使い,自輪郭については allow-scripts を加えてスクリプトもある程度使えるようにし,他輪郭についてはスクリプト禁止しつつ注意表示をした上でタグを有効化出来る,という方向で考えていた。

ただ,自輪郭はこれでいいとして,他輪郭については用合いとして少し煩雑かという気もしていた。例えば,ちょっとしたタグが1つ使われているだけでも切り替えて見なければならない。読み手にとってはもちろん,柔軟表現のためにタグを使いたい書き手にとっても好ましい用合いではない。

そもそも HTML安全性についていちいち検査したくない,というのが動機だったが,Dex によってそれも大した問題ではなくなってきた。

他輪郭についても,ある程度制限はした上で安全なタグは普通に利用出来るように軌道修正することにした。


YouTubeTwitter 等の埋め込み交度にもある程度対応することにした。

これも検査が面倒という点で避けていたが,よく考えると,それらしい入力から最小限パラメーターだけ拾って,予め用意しておいたテンプレート置換して出力すれば安全性は容易に担保出来る。

共有用 URI の先頭に + を付けるだけという渡括記法もあった方が良いが,慣れない人は埋め込み交度を貼り付けてくる可能性が高い。

可読性を考えると,描出時に渡括記法に置換してしまうのが良さそうだ。

=}
{用者}{第三次宣伝攻勢}{HTML}{進捗記録}{領当て}{<iframe>}{希哲15年2月28日の開発}{実装方針}{allow-scripts}{ブラウザ対応状況}...=}(59)

{希哲15年2月28日2歩 K#F85E/E74C-D345}

少し忘れていたが,第三次宣伝攻勢を始める前にもう一つやっておくべきこととして,HTML タグ切り替えがあったため再検討この描出を見て必要性再認識した。

考えてみれば,HTML タグを使うつもりがなくても引用で入ってしまう可能性がある。誤った HTML放置されていれば用者にとってはもちろん SEO 上の障害にもなる。

基本的な方針はデライト公式で書いた通りだが,実装にあたっては若干の課題も残っていた。

他輪郭描写原則として HTML タグ無効化するとして,有効化した際にスクリプトだけ無効化するというのは意外に難しい

script 要素禁止するだけでは十分でなく,on- 属性iframe 要素等の抜け道も塞がなくてはならない。

on- 属性 に関しては,on で始まる属性を一律削除するか non- にでも置換してしまうことを考えたが,そもそも on- が HTML において予約接頭子なのかよく分からない。

いずれにせよ,HTML拡張性や近年の仕様変更の激しさを考えると,ブラックリスト的な検査は避けたい。

ここで iframe 要素sandbox 属性が使えることに気付いた。これならスクリプト禁止意図明示出来る。ブラウザ対応状況も悪くない。

スクリプトのみならず,iframe なら誤った HTML によってページ全体の領当てが影響を受けることも簡単に避けられる。自輪郭では allow-scripts を加えるだけでスクリプトを許可出来る。

いっそのこと全ての描写部砂房にして原則タグ有効に出来れば話は簡単だが,iframe 要素は色々な意味で重くSEO にも向かない。タグを悪用した迷惑行為フィッシング等の可能性が完全になくなるわけでもなく,iframe 以前にタグの処理は重いのでやはり原則無効化,有効化時のみ iframe に置換するというのが現実解だろう。

これで実装方針は固まった。実装自体は半日もあれば出来るだろう。

{他輪郭}

{}