{知番欄}{文字入力要素}{字間無しのプロポーショナルフォント}{プロポーショナルフォント}{字間無しの等幅フォント}{調和感}{見たまま方式}{文字だけ方式}{希哲15年7月3日}{描写選り手の字間調整}...=}(37)

{希哲15年7月3日の開発 K#F85E/A-E74C-E936}

デライト文字入力要素は,原則として字間無しの等幅フォント統一することにした。

描写選り手の字間調整知名欄描写欄字間無しの等幅フォントになったが,全知検索窓含め文字入力要素は原則 letter-spacing: 0.1emプロポーショナルフォントだったため,少し違和感があった。字間無しのプロポーショナルフォントでもいいかと思ったが,やはり細かい文字記号での視認性があった。

これで調和感が戻ってきた。引き入れ欄でも間延びしなくなり視認性向上した。

例外として,例えば録入りフォーム知番欄は一字毎の視認性のため letter-spacing: 0.1em くらいにしておいた方がいい。

もともと,WYSIWYG に近い感覚にするため統一していたフォント設定で,4月23日12歩でも極力残すように考えていたが,本格的に WYSIWYG を導入して,従来方式と共存させることを考えると,はっきり切り分けておいた方が良さそうだ。


将来的に導入する WYSIWYG のため,「見たまま方式」や「文字だけ方式」という極力分かりやすい用語も考えておいた。

=}
{最短知名原則}{完全名称}{Firefox}{短い名前}{扱い方}{希哲15年6月5日の進捗時限}{希哲15年6月5日の進捗}{希哲15年6月5日}{描出通称原則}{輪郭整備}...=}(41)

{希哲15年6月5日6歩 K#F85E/A-E74C-4D4A}

描出通称原則についての検討で終了。

固有名詞などで複数の表記がある場合,原則として認識しやすい通称とすることにした。

輪郭整備体系化を考え始めたこともあり,表記揺れが発生しやすい知名扱い方について方針を決めておきたかった。

これまでは特に方針もなく,感覚的に知名を付けていたが,どちらかというと長い名前正式名称完全名称など)を主とすることが多かった(例:FirefoxMozilla Firefox

これは Wikipedia 等でよく行われている方法だが,ウィキと異なり知番のあるデルンでは名称厳密化する必要は無く,短い名前の方が全知検索との相性が良い

経験上,正式名称を主にしているつもりでも,結局すぐ握接出来る通称の方に引き入れすることが多くなっていたりする。

=}
{Dex 改良}{文字参照}{希哲15年5月20日の開発}{Dex::esc_HTML()}{小なり記号}{大なり記号}{HTML 越化仕様}{記法実装整理}{希哲15年5月20日の進捗時限}{希哲15年5月20日の進捗}...=}(31)

{希哲15年5月20日12歩 K#F85E/A-E74C-8EBB}

デラング整備Dex 改良記法実装整理

途中で終了。

ここで HTML越化エスケープ仕様Dex::esc_HTML()確定させておくことにした。

大なり記号小なり記号に加え,アンパサンド単括点シングルクォーテーション二重括点ダブルクォーテーション原則として越化し,必要な場合のみ有効化する。

括点の越化は場合により要らないこともあるが,統一しておいた方が扱いが単純になる。

アンパサンドの越化は HTML 仕様上必要とされていたものだが,実際に問題が起こることは少なく,文字参照を使うのに便利だったこともあり放置していた。今後は越化目的で使う可能性のある文字参照のみ有効化することになる。

結局,一般的な越化仕様を採用することになった。

=}
{希哲15年2月28日の開発}{実装方針}{allow-scripts}{ブラウザ対応状況}{スクリプト禁止}{予約接頭子}{on- 属性}{自輪郭}{他輪郭}{HTML タグ切り替え}...=}(59)

{希哲15年2月28日2歩 K#F85E/A-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 に置換するというのが現実解だろう。

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

{希哲館訳語}{開発者コミュニティ}{リスク低減}{費用削減}{困難さ}{隠すべきものを持たない強み}{希哲15年2月1日3歩}{きっとん}{素交非公開原則}{素交公開原則}...=}(89)

{希哲15年1月30日の日記 K#F85E/A-E74C-E10D}

日本の情技業界を騒がせている業務素交流出事件に思うところあり,希哲館でも原則として素交公開していく「素交公開原則」の採用本格的検討し始めた。

昨年の今頃もそんなことをぼんやりと考えていたが,特にこの頃,描出公開原則成功確信が持てるようになったり,政治参加方針公開が考えられるようになったり,「隠すべきものを持たない強み」を実感することが多くなっていた。となれば,素交公開自然流れだろう。

もともと虎哲関係の素交独自性が強過ぎ,動作環境備立方法も特殊文書込め言には独自用語と希哲館訳語満載という状態であり,盗んだところでまともに運用するのは不可能だ。これを「自然難読性」と呼び,ある種の強みと考えていた。

それでもいわば「素交非公開原則」で来た理由はいくつかある。

第一には,私自身の完璧主義的な性格であり,見せる必要もないところで不完全なものを晒したくなかった。

次に,希哲館事業収益化不可能に近い困難さがあった。万が一にもなさそうだった成功可能性を探る上で,万が一でもその障害になりそうな要素排除しなくてはならなかった。手札は一つでも多い方が良かった。

これについては,デライト収益化実現してしまえば無用心配になる。

もう一つ,技術的問題もある。昔から,デルン基礎にした版存管理司組構想してきたこともあり,素交公開するなら独自基盤でと考えていた。無論,そんなものを開発する時間は無かった。

色々な意味で余裕が必要になるので,いずれにせよデライト収益化後に決断することになるだろう。

素交公開原則利点はいくつも考えられる。献典としては死蔵してきた希哲館技術体系宣伝デライトも含めた希哲館事業全体の透明性信頼性向上機密保持に関する費用削減リスク低減,そして最も大きいのは開発者コミュニティを作れることだろう。

KitHub」というのは一昨年思いついたことだが,それこそ GitHub のように成長すればそれだけで希哲館事業の強力な武器になる。

この日は久しぶりに希哲館マスコット構想「きっとん」を思い出し,具体的なイメージを練ったりもした。これがのらくろに似ていることに気付いたのは収穫だった。

2月1日振り返り日記

{原則}
{}