Webの気にくわない所 その2

# 前回の要約
前回の記事はひと月近く前なので要約から始める。長いしね。

まず現状のウェブの条件としてこんなのがある。

1. サーバー側は低コスト、ユーザー側はそれなりの高コストで処理するべき。従って処理はできる限りクライアントサイドでやるべき。
2. アクセスは検索エンジンから。クローラに理解させないといけない。
3. セキュリティ重要。
4. デザイナとプログラマは分けないとね。

現状はAJAXも静的サイトも動的サイトも問題含みだからいかんね。
だからXMLサーバーとか良いんじゃない、という話だった。

# 忘れていた事
前回書き忘れていた。意識はしていた気がするんだけど。
というわけで条件に以下を追加。

5. ファイルアクセスの粒度はできるだけ大きい方がいい。
    1. ハードディスクはランダムアクセスが苦手。
    2. SSDは高い。使いたくない。
    3. ネットの速度はかなり速くなった。スマホで動画とか見る。
    4. 現在のウェブサイトは一ページ数MBとか。
    5. 大抵のサイトのユーザーデータは一人で1MBもない。
        1. Evernoteとかメールとかはその限りではないけどね。それでも一画面の一覧は1MB以下程度だろう。
    6. 粒度を細かくする為に色々するのは手間でバグの温床。統一的な取り扱いもしにくい。

前回のXMLサーバーはそういう点でもメリットがある。

今回以降は、非現実的だけど新しく設計するとしたら、という提案を行おうと思う。

# HTML+CSSはUI構築言語ではない
## 要約
HTMLは意味論が混ざってレイアウトもしづらいゴミ。
だから、CSS的なものが混ざった新レイアウト言語を作るべきじゃない。XAMLみたいな。
HTMLは意味論だけやってもらって、やりやすいようにサブセットのプロファイルを用意すればいいんじゃないか。
HTMLはレイアウト言語に変換するイメージならレイアウトも直感的でわかりやすいよね。

以下本文です。
## 本文
HTMLの大きな不満点はレイアウトがめんどくさいってのがあるだろう。
特にXAMLなんかを使っていると、HTMLなんか欠陥言語だと思いたくなる。
そもそもHTMLはリフロードキュメントを定義する意味論を持つ言語だ。にもかかわらず現在はたいていUIの構築に使っている。

具体的な問題はこんなのだ。

1. レイアウト周りの機能が少ない。MVVMもない。UI構築には不要な意味論が付与されてる。
    1. XAMLやAndroidのXMLに比べるといろいろと欠けてる。
2. レイアウトを定義するにはCSSを知らないといけない。
3. CSSはデザインしにくい。結果が分かり辛い。難しい。
    1. しかもなぜかXMLではない。覚える事が増えるし補助機能も作りづらい。
4. CSSだけではデザインできない。HTMLを変えないとできないレイアウトがある。
5. ドキュメントを定義するという点ではHTMLは高機能すぎる。

## 解決策
### 新しいレイアウト定義言語
UI構築用のレイアウト定義言語を新たに作るというのが私の解決策だ。
XAMLみたいなのが良い。
強力なレイアウト機構を持ち、意味論は存在せず、デザインも一貫してできる。

そしてHTMLのような意味論用の言語はドキュメントの意味を示す役割に徹底してもらう。
結果的にデザインはHTMLからこの新言語に変換する形で行う事になる。
それはXSLTのようなものでもいいし、JavaScriptとかC#的な言語でもいいし、CSSの延長でもいい。
めんどくさい人は意味論なしでこの新言語で書くことになるだろう。
それはパーサーにはあまり理解されないがドキュメントではないから仕方ないし、現状程度の理解はできるだろう。

イメージで言うと、セマンティックなHTML→XSLTとか→レイアウト用言語って事。
追記：その前段に、用途に応じたXML→XSLTとか→HTML、という形も積極的に取り入れるべきだ。現状でもあるけどレイアウトを考えなくていい分やりやすくなるだろう。
### HTMLのサブセット
HTMLは意味を持つドキュメントを担当する。
その意味で現状のHTMLは高機能すぎる。
それはHTMLをUI構築言語として使い、なんでもかんでも詰め込んだからだ。
現実の大抵のドキュメントには機能過剰だし、一方でMS Wordとかと比べ欠けている基本機能もある。

Markdownのような軽量マークアップ言語が必要なのはそういう経緯だ。
具体的には以下のような問題への対処だ。

1. HTMLは高機能すぎて統一的な取り扱いがしづらい。
    1. レイアウトが崩れる。
    2. CSSで十分定義していないタグが書けてしまう。
2. そのままテキストとして埋め込むと権限外の事が出来てしまう。サニタイズ必須。
3. レイアウトだけが必要な場合、意味論だけが必要な場合がある。

別にMarkdownは難しくはないし便利なんだが、なんで一々別の記法を覚えないといけないのか。ばかばかしい話だ。
コードを書くのも、統一的に扱えないのも、方言があるのもバカバカしい。

私が提唱するのはHTMLのサブセットを作る事だ。
具体的にはいくつかの定義済みプロファイルや自由な定義で利用可能なタグを限定する事だ。
例えば、markdownと同等のタグを定義すれば、それをmarkdown代わりに使える。
あるいは、レイアウト周りのタグのみを定義すれば意味の不在を強調できる(ワードパッドのイメージ)。
CSS的な物を使うにしてもフルで定義が出来ている事を担保できる。PDFとかへの変換もしやすい。

しかしサニタイズの問題はXMLでやる以上難しい。
解決策の一つは上に挙げたレイアウト言語のレイヤーで取り扱うという事だろう。
あるいはより扱いやすい、レイアウトの適用を外部からできたりするインラインフレームとかだろうか。

#次回
長くなったので続きは次回。

次回以降はこんなことを言うと思う。

1. 一々サーバーサイドで処理をするんじゃなくて、サイトアクセス時にレイアウトやリソース・ロジック・ユーザーデータを一括でダウンロードしてサイト滞在中はローカルで処理するべき。
    1. ファイルアクセスの粒度が大きくなって、サーバーの処理は単純になって、キャッシュも分かりやすい。いいことづくめだよね。
    2. AJAXも似たような事がしたかったんだろうけど惜しかったよね。ブラウザバック周りとか。
    3. それってモバイルアプリじゃないの？でも確かに規格を統一して軽くアクセスできれば便利かな。
    4. ついでにデータをローカルやサードパーティークラウドで保存できるようにすれば信頼できる。でもますますアプリだね。
2. JavaScriptやめろ。
    1. みんな知ってる事だから一応触れておく。
    2. でも、あんまり経験ないから大した事言えないんだよね。
    3. C#最高。
3. 自然言語レベルの事を機械可読にできないだろうか。
    1. なぜWebはCyc(知識ベース)的な方向に進まず、自然言語のごみを量産する方向に進んでしまったのか。
    2. 辞書の全単語に番号を振って、自然言語の構造をXMLか何かに起こせば便利だよね。絶対やりたくないけど。
    3. そうすれば多言語対応が簡単、中間表現からドキュメント作成とコード作成が同時にできて業務改善、無理やり解析するAIどころではない頭の良さ、翻訳システムの中間表現に手を入れて品質向上。素晴らしすぎる。
    4. 入力は大変だろうから自然言語で入力して意味を尋ねられる形になるのかな？

この要約だけでも割と十分だから一々書かないかも。