無し。

{希哲15年2月23日の開発 K#F85E/A-E74C-9061}
デライト文書構造最適化少々,高速化の作業方針検討,その他情報収集など。
前後景部でいくつか微調整したいことがあるため,すぐに終わる作業は中景輪符整理の前に,時間がかかる作業は「前後景部整理」として後回しにすることにした。

{希哲15年2月22日の開発 K#F85E/A-E74C-B03E}

{希哲15年2月21日の開発 K#F85E/A-E74C-0B9C}
デライト文書構造最適化の SEO 向けの作業は一段落した。
長いこと SEO に関しては放置状態に近かったが,HTML5 と Schema.org を活用してそれなりの形にはなった。 SEE にとっても大きな進歩だ。機会損失の最小化を考えると出来るだけ早く済ませておきたかったので割とあっさり終わって良かった。
これからの文書構造最適化は中景輪符整理など領当てや保守性の観点から必要な作業中心になるだろう。
SEO に加え第三次宣伝攻勢も始まればデライト高速化も急ぐ必要があるが,CDN に関してはやはり依存を避けつつ,体系的に上手く利用出来るようにしておきたい。
この体系を KNEST の一環として「KDN」(knowledge delivery network)と呼んでおくことにした。

{希哲15年2月18日の開発 K#F85E/A-E74C-5FF8}
輪符要素正規形を定めた頃から強く感じていたことだが,やはり今後の保守性を考えると場当たり的に HTML を扱うべきではない。輪郭法を HTML でどう扱うべきか体系化が必要になってくるだろう。「DGHTML」を仮称として考えておく。

{希哲15年2月17日の開発 K#F85E/A-E74C-C100}
デライト文書構造最適化少々。
そもそも Cμ や設計の極限に近い単純さは高速化と相性が良く,速度はデライトの大きな強みになりうる。
開発者が作りたいものと用者が欲しているものとの不一致が起きやすい機能追加などと比べ,用者は満遍なく恩恵を受けられ,検索演心最適化の観点からも利素効率化の観点からもやって損はない,というのもデライト文書整備に並行する作業としては好ましい。

{希哲15年2月16日の開発 K#F85E/A-E74C-9903}
「デライト文書構造最適化」に着手。
デライトの文書構造は,試行錯誤が多かったこと,開発初期 HTML5 要素の採用に消極的だったこともあり汎用要素,特に div 要素の多用が目立つ。
整理するならページ構成や領当ても固まった今が最善の時期だろう。HTML5 要素だけでなく,Schema.org 等の周辺規格も取り入れていく。
Web Share API を利用し,輪郭ページに汎用の共有ボタンを一つ置くというのは悪くない,と考え始めた。API 非対応であれば非表示にすればいいかと思ったが,よく考えると,ずらずら SNS のアイコンが並べられるのが嫌だったわけで,共有ボタンを押して選択肢として表示される分には問題ない。
