この文書の諸情報
- この文書の永続的URI
- http://kuruman.org/diary/2007/06/03/html5-is-not-so-bad
- 公開日時
- 2007年6月3日 午前5時43分03秒
- 最終更新日時
- 2008年1月30日 午後2時10分00秒
- ヘルプ
- フィードバックについて
-
更新情報 - http://kuruman.org/note/index.xml
.
XHTML+CSS (r)evolution, 3nd スライド・音声データ(原文ママ)も公開されたようですので、今回のプレゼンテーションに対して補足と説明を加えておきましょう。プレゼンの内容をほとんど否定しているのは気のせいということにしておきます。公開されているスライドPDFと併せてご覧になると良いでしょう。
上記リンクを辿るとサーバのなかを思いっきり探し回ったのですが、ファイルが見つかりませんでした
と言われてしまうようです。いつの間にデッドリンクとなったのか定かでありませんが、資料へのリンクはそのまま生きているようです。また、おそらく一字一句違わぬエントリーが下記より参照できますのでこちらも併せてご覧下さい。
この文書が長いと思う人は見出しだけ読めば良いでしょう。概略はつかめるはずです。HTML 5はそれほどに無茶苦茶な提案ではありません。
HTML 5を世間が最初に知るきっかけとなったTim Berners-LeeのReinventing HTMLというエントリーがある。益子さんはこのエントリーに含まれるinventの語義に最初から作り直すという意味があることを指摘し以下のように述べた。
……つまりrevise、単なるこうちょっとした修正というよりは、reconstruct、再構築のために作り直す、一旦、こう、潰して作り直すっていう本当にこう、drasticな改訂という風に考えて良いと思います。……
思います
なんて曖昧な表現はやめてほしい、という話はさておき、再構築の本当の意味については、ディスカッションにてW3Cのカール氏が説明していた。その内容は文字起こししてある通り、内容的なものではなく体制の一新といったところだろうか。
内容が本当に作り直されているのかについては実際にHTML 5仕様の目次をみてみると良い。3. Semantics and structure of HTML elements
がほぼ既存のHTMLに該当する部分だ。リンクタイプの定義が4.4.3. Link types
にあるなどといった例外はあるが、ほぼそれで網羅することができる。
ここには知らない要素もいくらか登場する。だが、既存の要素のほぼすべてはそのまま残っており、基本的な概念は変わらない。drasticな、徹底した改訂という印象を受けるほどではないと思う。
HTML 5はそもそもXHTML 2より既存のHTML仕様、つまり最新版であるXHTML 1.0やその元となった非XMLベースのHTML 4に近いものだ。それが全くの作り直しになるはずもない。
なお、新たに追加定義される内容については追加定義される多数の要素の項で少しだけ紹介している。
XHTML 1からXHTML 2への改訂がdrasticだ、と言うのであれば何となく理解できる。妥当で想定される範囲の改訂だが、既存の仕様と比較すると大きな違いを感じる人が居てもおかしくない。
Ianが5月9日にWHATWGのMLへ投げたメールに書かれている内容の冒頭を稚拙ながら訳しておこう。
本日、W3CのHTMLワーキンググループはWHATWGが現在進めている著作物を始めることを決議した。明確に、グループは我々の作業を再検討することを決議した。十中八九WHATWGが現在進めている著作物に基づいてHTMLの議論を進めることとなるだろう。
また、彼らはこの著作をHTML5と呼ぶことも決議した。
従って、「Web Applications 1.0」仕様は今、公式に「HTML5」と呼ばれるのだ!
名前が変わったのはW3CのHTML WGでの議論を受けてのことと考えるのが妥当ではないだろうか。このようなメールが流れているのを見る限り、益子さんの唱えるHTML 5の名称の方が有名になったからという理由が妥当とは考えにくい。
なお、表題の記録は5月10日0時56分のRevision 799からヘッダが別ファイルに分離されたのを最後にトラッキングすることができなかった。しかしこのRevision 799はIanのメールが投げられる後の更新である。そして、この更新時にはまだWeb Applications 1.0と呼ばれていたようだ。
今回のイベントでは著作権情報として記載されている内容から益子さんが類推した内容は語られたが、なぜ著作権情報が存在しているのかについては一切語られなかった。これについてはマイコミジャーナルがうまくまとめているのでそれを参照するとよいだろう。
要素名だけ紹介するのはあんまりでしょう。数だけ紹介してもその意義は全く伝わらない。HTML 5はただ複雑になっただけという印象を与えるだけだ。だが、HTML 5はただ複雑になっただけではない。具体例をいくつか紹介しよう。
先日公開したエントリーのURIがhtml5-dis-eventであるのはここに由来していると言っても過言ではない。HTML 5の説明すらしていないじゃないか。
HTMLでは文字コードを指定するためにcontent-typeを記述する。ここに疑問を抱いたことはないだろうか。今まさにHTMLを書いているのに何故HTMLであることを明示しなくてはならないの、今指定したいのは文字コードなのに、と。
HTML 5ではmeta要素にcharset属性が導入される予定だ。これが導入されれば今まで<meta http-equiv="content-type" content="text/html; charset=utf-8">などとまどろっこしい記述を強いられていたのが、<meta charset="utf-8">とだけ記述すればよくなる。
もちろん実装されるまでの期間は併記する必要があるだろうが、この程度の実装が長々と放置される可能性は決して高くないだろう。
HTTP通信中に得られたcontent-typeに含まれる文字コード情報と文書中にcharset属性で記述された情報が矛盾している場合の処理についても、その処理順がきちんと仕様に明記されているため安心だ。
フッタに使われうる要素としてaddress要素型がある。かつて論文を公開するにはこれで事足りていたのかもしれない。しかしこれが今の用途を満足させるものではないことは、説明するまでもない。
多くの人は<div class="footer">などとマークアップしている。だが、こんなことを考えたことはないだろうか。
hr要素を前に置くことで伝えられるかもしれないhr要素も存在するhrは本文との関係性を断ち切るには力不足hrを併用したらどうだろうhrを入れたからと言って見出しの木構造が断ち切られるわけではないHTML 5は、新しくfooter要素型を定義することでこの悩みを解消してくれる。さらに、ここには見出しの類を中に含んではならないと定義してある。もう悩む必要はない。ただfooter要素でマークアップするだけだ。
dialog要素型資料では
とだけ説明されている。これだけをみると別にdialog (会話文)dl要素で良いじゃないか、と思うかもしれない。だが、ちょっと待ってほしい。
実際に会話文のマークアップを考えてみよう。多くの人は次のようなマークアップを想像するだろう。
<dl>
<dt>鈴木</dt>
<dd>今日田中が<q>調子悪いから休む</q>って言ってたよ</dd>
<dt>佐藤</dt>
<dd>そうなんだ</dd>
</dl>しかし、会話の内容はそれ自体が文書にとっては引用で、話し手はその出典である。そう捉えると、以下のマークアップの方が妥当だ、と思えてこないだろうか。
<dl>
<dt><cite>鈴木</cite></dt>
<dd><q>今日田中が<q>調子悪いから休む</q>って言ってたよ</q></dd>
<dt><cite>佐藤</cite></dt>
<dd><q>そうなんだ</q></dd>
</dl>どちらが妥当かという論議はさておき、HTML 5のdialog要素型はこれをスマートに解決している。
<dialog>
<dt>鈴木</dt>
<dd>今日田中が<q>調子悪いから休む</q>って言ってたよ</dd>
<dt>佐藤</dt>
<dd>そうなんだ</dd>
</dialog>HTML 5のdialog要素型の項では以下のことを明記している。
dialog要素内のdt要素の中の文字列は後続するdd要素の中で与えられる文字列の出典を暗示するdd要素のコンテンツは暗黙のうちに話者からの引用であるとするciteやq、blockquote要素を含む必要はないdialog要素内のdd要素の内側のq要素は、その人の会話が誰か他の人の引用であったことを実質的に暗示するdl要素でのマークアップより素直だと感じてこないだろうか。
canvasの実装状況の誤りイベント中ではFirefox 1.5とSafariで実装されていると述べられていたが、Opera 9も実装している。もっともこの件はWebで公開されている資料では、さりげなく修正されているようだが。
また、canvasは先行実装ではない旨をTakenさんが示している。
videoの実装状況の誤り先日公開したエントリーで補足した通り、Opera 9.2 Betaにvideoは実装されていない。videoが実装されたのは実験的ビルドである。
jp.opera.comなどからダウンロード可能なOpera 9.2では、資料に記載されるhttp://people.opera.com/howcome/2007/video/opacity.htmlを参照しても、何も起こらない。Haavardの紹介する通り、video要素が実装されたのはlabs.opera.comで公開された実験版である。
この実験版をOpera 9.2 betaと呼ぶのは誤りである。Opera 9.2 ベータというバージョンは別に実在しており、その更新履歴にもvideoが実装された旨は記載されていない。言うまでもなく先の実験的ビルドとこのOpera 9.2 ベータは別のものなのだから。
まず、スライドからポイントとしてあげられていることを引用する。ポイントは大きく2つに分けられるだろう。
まずはXMLの話。
- XMLワールドではXHTMLは単なるボキャブラリ集のひとつ
- XHTMLもXMLベースで開発されるならやはり単なるボキャブラリ集のひとつ
- 今後の(X)HTMLはひとつの言語体系というよりさまざまなXMLアプリの複合文書と考えるべき
- 複合文書=Compound Document
- WebページへXHTMLのボキャブラリを提供
- WebページへSVGのボキャブラリを提供
- WebページへMathMLのボキャブラリを提供
そして仕様を拡張する具体的な方法に関する話。
id/class志向(W3C仕様を尊重)=microformats- 要素/属性志向(W3C仕様を逸脱)=HTML 5
スライドの14枚目に記載されている内容をそのまま引用する。
An extensible, serialized form of such a language, using XML.
A serialized form of such a language using a defined, non.XML syntax compatible with the 'classic HTML' parsers of existing Web browsers.
(XMLベースだけでなく非XMLベースにも対応。前方/後方互換性の確保)
これはまさにその通りで、HTML 5にはXMLベースのものと非XMLベースのものが用意される予定だ。従ってXMLワールドに於いてはHTML 5も単なるボキャブラリ集のひとつとして扱えると考えるのが妥当だろう。もちろん複合文書として扱うこともできるようになると推測される。
ドラフト草案すら公開されていない仕様であるため推測以上のことを語ることはできない。しかし、これだけは言っておきたい。私にはなぜここにきてXMLの話がポイントになるのかさっぱりわからなかった。HTML 5もXMLとして扱えると自分で述べていたではないか。質疑応答で問おうと思っていたが、その時間は残念ながらとられなかった。
HTML 5の仕様が定義され、それに従って文書を作成し、HTML 5で定義される新しい要素や属性を使う。これの、どこが仕様の逸脱だというのか。まさか勧告すらされていないHTML 5の要素や属性を、既存の文書型定義に基づいた文書で利用することに関して発言しているのだろうか。それならば確かに逸脱だが、それは当然である。
microformatsは現時点の仕様に則ってsemantic Webを実現しようとする素敵な試みだ。しかしそれは新しい言語であるHTML 5と比較すべき対象ではない。microformatsはAbout microformatsに書かれているとおり新しい言語ではないのだから。
microformatsと比較するのはナンセンスとしか言いようがない。
HTML 5と比較されるべきはXHTML 2だ。どちらも今策定途中であり、現行のHTMLに代わることを目指す仕様だ。
思えば今回のプレゼンにはXHTML 2という単語がほとんど出てこなかった。不思議なものである。
いま話題の「HTML5」とHTMLの再開発
という題目で行われているにもかかわらず肯定的な話を一切せずに終始否定し続けるのはいかがなものか。聴衆が再開発
について考えるにはあまりに情報が偏りすぎている。端的に言ってしまえば、これは情報操作に近い。
僕もそれほどHTML 5について知識を持ち合わせているわけではないので、利点と欠点は他の人の資料を見ていただこうと思う。
たとえばOperaからHTML WGに参加しているAnneが次のような資料を用意している。英語のプレゼンテーション資料(Opera Show)だが、簡潔にHTML 5の利点がまとめられていると考えられる。
たとえばUAIアクセシビリティセミナーで梅垣さんが行ったプレゼンではXHTML 2を前提としているWAI-ARIAと、W3CのHTML系列の新しい仕様開発との関係
を懸念事項として挙げていた。これはHTML 5の仕様如何では問題になるだろう。
益子さんのプレゼンテーションでしばしば繰り返し述べられていたのは以下の主張であった。
もちろん永久に実装されることのない仕様に価値はない。しかしHTML 5は本当にそうだろうか。今回のプレゼンテーションでは実装されないという主張を多く口に発していたが、その根拠は提示されなかった。
むしろcanvasなどが実装されていることを紹介していた。紹介されていない部分ではOpera 9のWeb Forms 2.0の先行実装が挙げられる。Web Forms 2.0はHTML 5に含まれるだろうとされるフォームの拡張案である。これもHTML 5の実装といえる。
HTML 5はまだ策定が始まったばかりの新しい仕様だ。長期間公開された状態で議論が進むからこそ徐々に実装が進んでゆくのではないだろうか。そして一部は既に実装されている。
これが仕様を先に策定することを否定しているのだとしたら、とんでもないことだ。それは健全な競争を阻害することと相違ない。せっかくWebブラウザに競争が生まれつつあるというに。仕様が先に策定されないと云うことは、実装がすべてということ。つまり、実装を持ってそれが仕様となる。その仕様すら公開されない場合、実装を元にほかの環境が似て似つかぬ実装を行うことになるのだ。公開されたとしても、実装までの期間には相当な差が生まれることとなる。
むしろHTML 5やXHTML 2の仕様が先に決められゆく流れは良い傾向だと思うのだが。
同様に仕様が先に定義されつつあるXHTML 2についても若干補足しておく。XHTML 2ではフォームとしてXFormsを採用する予定である。この実装は、着実にMozilla内で進められているのだ。
一応コンテンツを作成することはできるし、それを一般的なユーザは利用することができる。だが、Webアプリケーションのアクセシビリティなどを考え始めると全くもって十分とは言い難い事実に気づく。WAI-ARIAなどはそれを白日の下にさらしている好例だ。
WAI-ARIAが遠くのものに感じるのであれば、ユーザスタイルシートの定義を考えてみると良いかもしれない。HTML 5にはsectionやfooter、navなど、様々なSectioning Elements(セクション化要素とでも呼ぶのが良いだろう)が定義されている。セクション化要素の多くは今まで多くのページでdiv要素に適当なclass名を与えていたブロックだ。これらがはじめから用意されるようになる。これがきちんと利用されるようになれば、ユーザ側でのスタイル操作が容易になることは想像に難くないだろう。
classやidでは何も定義できないディスカッションで挙げられたul要素型とol要素型をまとめてしてしまえばいい、という提案を題材に使おう。
以下、ul要素型とol要素型をまとめた要素型をlist要素型と呼ぶことにする。list要素型としてまとめたとしても結局ul要素型(順不同リスト)やol要素型(順序付きリスト)に当たる何かを、たとえばclass名などとして、どこかに定義することとなる。
なぜならば、HTMLのボキャブラリ内でリストの扱いを判断できなくなるからだ。たとえばリストを50音順にソートし直すことが妥当かどうか、どこかで定義されていない限り判断することができない。スライドにもあるとおり、XHTMLは単なるボキャブラリ集のひとつ
だ。ボキャブラリとして活用するためにはそのボキャブラリの中にリストの扱いが定義されていなければならない。
具体的な弊害としてはユーザスタイルシートの作成ができなくなるといった事例を挙げておこう。
list要素型はスタイルシートで表現することだけできる。言い換えてみよう。list要素型はスタイルシートで表現すること以外何もできない。
結局どこかで定義するのであれば、既に色々な人が気ままに活用しているclass名より、新たな要素として定義した方が応用しやすい。class属性の値は、たとえ同じでも、他の誰かが、他の用途のために使っている場合がある。そのようなマークアップをデータとして永続的に使うのは不便この上ない。
これはmicroformatsの否定とも言えるかもしれない。microformatsは確かにおもしろい試みだし、現実的な解の一つだとは思う。が、永続的に続くとは思っていないし、そうあるべきではないと考えている。
ついでに極論も書いておこう。もし本当にclassやidで事足りるなら、本文のマークアップのための要素型としてHTMLにはdiv要素型しか定義されなかったかもしれない。何でもclassやidで示せばいいのだから。
classやidによる拡張は可能だが、それは共有することが困難な拡張だ。はじめから多くの人が似たようなものを必要とするのであれば、それははじめから定義されていた方がよい。わざわざ勝手に拡張させる必要はないのだ。(必要とされていても定義すべきでないものも存在するけれど。)
更新情報.