HTMLのセマンティック機能の強化は必須の課題だが、果たしてHTML5が理想的な解決策と言えるのか?HTML5の黎明期であった2009年、著者は特に後方互換性と前方互換性に注目して、より良いHTMLとは何かの考察を加えている。

# 275

HTML 5におけるセマンティクス

大胆な予測を立てようと思う。私達がこの世を去った後も、HTMLはずっと存在しているだろう。しかも、単に我々の時代からの遺産としての何十億ページだけでなく、生きて呼吸をしている存在として。私達はWebツールやプロトコール、プラットフォームの開発にあまりにも多くの努力とエネルギー、投資とをつぎ込み過ぎていて、もはやそう簡単にはHTMLを見かぎることができなくなっている。

まずは立ち止まって、私達の責任を考えてみよう。私達は歴史の偶然から、我々の文明が今後何十年も使うことになるであろう重要なコミュニケーションツールの開発に関わった。よって、もし私達が何となく、もしくは真剣に、HTMLの改良を検討する場合には、今日の決断が一体どれだけ大きな波及効果を及ぼすのかを理解していなければならない。

W3Cは最近、次世代HTMLを形成する努力を倍増させたが、HTML5はここ1年位で、非常に勢いを増してきている。これは巨大なプロジェクトで、単にHTMLの構造だけではなく、パース・モデルやエラー・ハンドリング・モデル、DOM、リソース・フェッチのアルゴリズム、メディア・コンテンツ、2Dドローイング、データのテンプレート化、セキュリティ・モデル、ページ・ローディング・モデル、クライアントサイド・データ・ストレージ等々をカバーしている。

また、HTMLの構造や構文、セマンティックについても改訂がある。この中の何点かは、Lachlan Hunt氏が「A Preview of HTML5 」という記事の中で言及している。

しかし、当記事においては、あくまでHTMLのセマンティックに限定して注目しよう。これは私が何年も関心を持っていたことで、またHTMLの未来にとっても本質的に重要なことだと思っている。

英BBCは最近、abbr design patternのアクセシビリティとユーザビリティについての懸念から、BBCのプログラムリストでのhCalendar microformatの使用を打ち切ると発表した。これは明らかに、HTMLセマンティックの機能を元々意図されていたところから、いやそれどころかHTML言語の合理的に可能な範疇からも、大きく逸脱させてしまったことを示すものだ。私達は、よりセマンティックに富んだドキュメントをマークアップするために必要なHTML要素と属性を単に使い果たしてしまったのだ。HTMLの既存の構造に対して小手先の知恵を駆使することを続けていたら、このような問題はもっと持ち上がってくるだろう。しかしHTMLは、セマンティックなマークアップ言語として根本的な欠陥に苦しめられている − なぜならそのセマンティックは固定されていて、拡張可能ではないからだ。

これは単に理論上の問題ではない。何百何千ものディベロッパーが、よりセマンティックに富んだマークアップを作成するために、HTML属性のclassやidを使っている。(彼らはまたこれらの属性を、CSSでスタイルを設定する時の「フック」としても使用しているが、それはまた別の事案だ。)ほぼ常に、これらディベロッパー達はその場かぎりのボキャブラリーを使う。それは、既存のスキームから持ってこられた値というよりも、彼らが自由に作った値だ。良く言ってもせいぜい、偽のセマンティックマークアップだ。

Web上の多くのページで、HTMLの要素と属性の貧弱な組み合わせでは実現できない、より構造化されたセマンティックを追加するためにmicroformatsが使われている。この場合、class属性に使われる値は、例えばvCardのような他の基準から流用したり、もしくはまだしっかりした既存の基準が存在しない新規のボキャブラリーから流用(hReviewの場合のように。)したりして形成された、合意済みのボキャブラリーの中から取ってこられる。

拡張可能なセマンティック

ここに解決しなくてはいけない真の問題がある。ディベロッパーがマークアップに、偽のセマンティックなどではなく、よりリッチで意味のあるセマンティックをはっきり明確に加えられるような、HTMLのメカニズムが必要とされている。これはおそらくHTML5プロジェクトにとって、正にもっとも緊急の目標と言えるだろう。

しかしこれは単にHTMLコンテンツの中でリッチなセマンティックを創出するためのメカニズムを作ればいい、というほど簡単な問題ではない。いずれの解決法にも、それなりに大きな制約が付いて回る。おそらく一番大きな制約は、後方互換性だ。解決策は、今日使用中で、また今後も何年も使われるであろう何百何万ものブラウザ閲覧用デバイスを除外するものであってはならない。後方互換性を持たない解決策では、ユーザー排除に繋がるとの危惧を抱くディベロッパーからの幅広い支持を受けるのは難しいだろうし、ほどなく頓挫するだろう。

解決策はまた、前方互換性もなくてはならない。それは未来のブラウザの中でも機能しなくてはならないという意味ではないが(それはブラウザ・ディベロッパーの役目だ)、しかしそれは拡張可能でなければならない。私達が現時点で提唱可能ないかなる解決策も、未来のセマンティックの想定範囲内もしくは範囲外の、すべてのニーズを満たすことができるとは思い難い。しかしながら、将来ニーズが生じた時にそれに対応できるような拡張の可能性を持った解決策を作成することはできる。

これら2つの制約は切り離し難く、厄介な問題となっている。しかし、10年毎には大きな変革を繰り返す言語であり、且つ、地球規模のコミュニケーション・プラットフォームとして最重要な言語でもある点を考慮すると、この問題を解決しない訳にはいかない。

では、HTML5はこの問題にどう対処しているのだろう?HTML5では、いくつかの新しい要素が導入された。新要素のうち、sectionnavasideheaderfooterについては、私は「構造的」と呼んでいる。dialog要素は、コンテンツ要素の一つで、blockquote要素と似ている。また、データ要素と言われるものもあり、例えばmeter要素は「分かる範囲でのスカラー測定、もしくは分数値(例:ディスクの使用状況)を表す」ものだし、time要素は、日付と時刻両方、もしくはそのどちらか片方、を表す。

これらの要素は便利そうだし、またある程度世間の関心を集めもしたが、しかしこれらは私達が提唱した問題点を本当に解決してくれるのだろうか?特に、前方互換性と後方互換性という2つの制約に縛られた中で。

ではそれぞれの制約について考えてみよう。

後方互換性

現在のブラウザは、これらの新要素、例えばsectionをどう処理するだろうか?まず、Safari、Opera、Mozilla、そしてIE7でさえも、最新バージョンであればどれも、下記のようなページをレンダリングすることができる。

<h1>Top Level Heading</h1>
<section>
   <h1>Second Level Heading</h1>
   <p>this is text in a section element</p>
   <section>
    <h1>Third Level Heading</h1>
   </section>
 </section>

これは素晴らしいスタートに見える。しかし、例えば下記のようなCSSでsection要素にスタイルを設定しようとすると…

section {color: red}

上記で挙げたブラウザのほとんどがきちんとスタイルを適用する中、IE7(とおそらくIE6も)ではスタイルが効かない。

よって、現在使用されているブラウザの75%で、深刻な後方互換性の問題が生じていると言える。Internet Explorerのシェア減少のペースを考えると、ほとんどのユーザーが今後も数年間はIE6もしくはIE7を使い続けると予測できる。

HTML5がこれらの新要素を導入したとして、これら新要素が現在使用中のブラウザのほとんどと基本的に互換性がないと知った上で、それでもディベロッパーの大多数がそれを使う可能性はどの位あるだろう?

もしあなたがCSSの問題へ別の解決の糸口を探しているとしたら、残念なことだが、section要素にclass属性を付けて、その上でclassの値を使ってスタイルを設定するという方法はIEではうまくいかない。探してみればおそらく何らかの回避策もあるかもしれないが、実際にそれが見つからない限り、暗礁に乗り上げたも同然だ。

では、次は2つ目の制約、前方互換性について考えてみよう。

前方互換性

まず、「なぜ私達はこれらの新要素を考案しているのだろうか?」という問いから始めよう。合理的な答えは、「なぜならHTMLはセマンティックが十分リッチではないし、これらの要素を追加することによって私達はHTMLのセマンティックをよりリッチにすることができる。悪いことじゃないでしょう?」だ。

これらの要素を追加することにより私達は、HTMLのセマンティック機能をより強化する必要性を提唱しているのだ。しかしそれはあくまで限定的だ。いくつ要素を追加しようとも、私達はますます更にHTMLに追加したいセマンティックを思いつくだろう。ということはつまり、私達が好きなだけ新しい要素を追加したとしても、問題解決には到達できないということだ。私達はHTMLのボキャブラリーに特定の語彙を追加する必要はない。そうではなく、必要に応じてよりリッチなセマンティックをドキュメントに足すことができるメカニズムを追加することが必要なのだ。専門用語で言うところの、HTMLを拡張可能にすることが必要だ。HTML5ではしかし、拡張性のメカニズムは何も提案されていない。

HTML5はそれゆえ、現在使われているブラウザの多くでうまくいかない機能を導入した一方で、その言語によりリッチなセマンティックを追加するという役には全く立っていない。

新要素についてはまだいくつか疑問がある。新要素の名前は一体どこから来たのか?ナビゲーション要素が必要だとはどうやって決められて、それが「nav」と呼ばれることになった経緯は?なぜ同じ用語が、ページレベル、サイトレベル、そしてメタサイトレベルのナビゲーションに使われるべきなのか?

なぜ、Docbookのような既存のボキャブラリーの流用ではだめなのか?Docbookのドキュメント構造ボキャブラリーはずっと豊富だし、何年もかけて出版の専門家達によって開発されてきた。私は別にここでDocbookを持ち上げるための議論をしている訳ではない。肝心なのは、HTMLにおけるリッチなセマンティックに向けたメカニズムの提供、という極めて重要な課題が場当たり的に対処されていて、30年かそれ以上前(GMLの初期開発は1970年代初めに開始)に遡る関連分野の成功事例についてはどうもほとんど鑑みられていない、ということだ。

解決策についての考察

さて、現在の努力について批判的に論じてきた後で、じゃあ私にこの問題を解決する何か実用的な提案があるかって?まあ、提案の序章くらいならある。

もしHTMLに要素を追加することが論外だとしたら、少なくともこの議論の枠内では、HTMLの中の属性に着目するのが理にかなっているだろう。結局のところ、ほぼ10年間に渡って、私達はclass属性とid属性とを、HTMLのセマンティックを拡張するためのメカニズムとして使ってきた。多くのディベロッパーがこのやり方に慣れているし違和感がない。microformatsプロジェクトにおいて、HTMLの既存の属性では、HTMLのセマンティックを拡張するための汎用メカニズムとしては十分ではない、ということがはっきりした。よって、もし私達がこの問題解決のために属性を使おうと思ったら、ひとつかそれ以上多くの新しい属性を生み出す必要がある。これがどう機能するかの詳細に入る前に、この提案を、HTML5の新要素に要求したのと同じ条件でもって比較検討してみるのが公平というものだろう。まず最も重要なことだが、HTMLに新しい属性を導入することは、後方互換性があるだろうか?もしあるのなら、それはHTMLのセマンティック拡張のための使えるメカニズムを提供してくれるだろうか?

試しに新しい属性を作ってみよう。それを仮に「structure」と呼ぶことにするが、ここで名前は重要ではない。この新しい属性は下記のように使うことができる。

<div structure=“header”>

私達のブラウザがこれをうまく扱えるかどうか見てみよう。

もちろんどのブラウザでも、下記のCSSスタイルは適用される。

div {color: red}

しかし、次はどうだろう?

div[structure] {font-weight: bold}

実際のところ、structure属性なんてものは存在しないにもかかわらず(!)、IE7も含んだほぼすべてのブラウザで、structure属性の付いたdivにスタイルを適用することができる。残念なことに、IE6ではこれは効かないので、私達の幸運はここまでだ。しかし、私達はこの属性をHTMLで使って、既存のブラウザすべてにそれを認識させることはできる。さらに、すべてのモダンブラウザにおいてはこの属性を使って、CSSでHTMLにスタイルを適用することすらできる。そして、もし古いブラウザにも対応したいのであれば、スタイル適用のために、その要素にclassを追加することができる。これをIE6でも7でもスタイルが効かない新要素を追加するというHTML5の解決策と比較してみると、このやり方の方がずっと後方互換性に優れた解決法だというのが分かるだろう。

属性を通じての拡張性

新要素の代わりに、HTML5はいくつかの新しい属性を取り入れるべきだ。これらの新しい属性は、セマンティックのカテゴリーもしくはタイプに紐付けられる。例えば、私が別の記事にて詳しく述べているように、HTMLには、構造的セマンティック、修辞的セマンティック、(XHTMLから流用された)役割セマンティック、その他のセマンティックのクラスやカテゴリー、が含まれる。

これらの新たな属性は、class属性とほぼ同じ使い方ができる。つまり、ある要素にその要素の性質を表すセマンティックを付与するためか、もしくはその要素にメタデータを付与するために使うのだ。

これはXHTMLの役割属性と変わらないが、すべての要素セマンティックにたった一つの属性の「バケツ」しか持たないのではなく、むしろその要素が持つ様々なセマンティックのタイプを見分け、それらを分別していくべきだ。

例えば、XHTMLのrole(役割)属性は下記のように働く。

<ul role="navigation sitemap">
    <li href="downloads">Downloads</li>
    <li href="docs">Documentation</li>
    <li href="news">News</li></ul>

role属性の値は、スペースで区切られた、デフォルト・ボキャブラリー、もしくは定義されたボキャブラリーからの用語の羅列だ。

なぜ、role属性をそのまま取り入れないのかって?それは、「役割」という用語が当てはまらない、他の様々なセマンティックが存在するからだ。例えば下記のような。

<p rhetoric="irony">He's a fantastic person.</p>

これはセマンティックの論理的タイプの一つ、「修辞」を表しているが、「修辞」はドキュメントの修辞的性質をマークアップするために使うことができる。この要素が、このドキュメントの中で皮肉という役割を果たしていないのは明白だ。むしろ、要素のコンテンツが皮肉なのだ。

次にもう一つ例を。日付などの人間が読むことが出来る情報の、コンピュータも読めるバージョンの添付について、HTMLがその機能を欠くことはますます明白になっている。これが、前述のBBCがhCalendar microformatについて抱えていた問題の核心だ。<span role=“2009-05-01”>May Day next yearが意味をなさない一方でしかし、<span equivalent=“2009-05-01”>May Day next yearの方は理にかなっているかもしれない。

繰り返すが、私達がこの種のセマンティック属性のために、「equivalent」という特定の用語、もしくは何か他の用語を使うかどうかは重要ではない。特筆すべき大事な点は、セマンティック情報の格納場所として、どんなサイズにも合うワンサイズのバケツとして、class属性やrole属性を使えばいいというほど事は単純ではない、ということだ。後方互換性と十分な柔軟性を備えた、適切な拡張が可能な解決策に向けて、こっちの方の解決案を更に詳しく調べることは有意義に見える。

私はこのセクションを「解決策についての考察」と名づけたが、それは使える解決策を本当に作り上げるには相当な量の作業が必要になるからだ。まだ結論の出ていない疑問点は下記のとおりだ。

  • 別個のセマンティック属性がいくつ必要だろうか?これらのカテゴリーは拡張可能であるべきだろうか?もしそうなら、どうやって?
  • ボキャブラリーはどうやって決定されるべきか?
  • 私達は、ディベロッパー達がclassの値を使っていたやり方とほぼ同じように、私達が欲する用語を自由に作り出すべきか?もしくは、可能な値はすべて、標準化された仕様によって決定されるべきか?または、何らかの統計データを使った、ボキャブラリーの作成(と願わくば共有)のメカニズムがあるべきか?
  • もし、2つの異なるボキャブラリーによって定義された2つの同じ用語といった場合のように、2つのボキャブラリーの間で葛藤が生じたとしたら、これはどうやって解決されるべきか?
  • 名前空間の形式が必要か?もしくは何か他のメカニズムが存在するのか?

これらの疑問に性急に答えようとするよりも、私はこの疑問を提示することで取り組むべき課題に光を当て、対話を始めたいと思っている。HTML5に関する決定事項の影響と波及範囲は甚大で、せめて少なくとも言語学やセマンティック、記号学やその他関連分野に精通した人たちからのインプットが必要だ。

そうすれば、他のことはともかく、単なる「新要素の作成」ではHTMLのセマンティック機能向上のための解決策にはならない事ははっきりするだろう。

軽々しく慌てて決断を下さないようにしよう。結局のところ、私達は自分の孫世代に、気候変動によって既に十分な重荷を背負わせてしまっている。せめて彼らに、私達にできる最良のHTMLを残そうじゃないか。