HTML 5のセマンティクス

大胆な予測をするつもりです。 あなたと私のずっと後に、HTMLが登場します。 私たちの時代の数十億のアーカイブページだけでなく、生きている呼吸器官としても。 多大な労力、エネルギー、投資がWebツール、プロトコル、プラットフォームの開発に費やされたため、これらはすべて簡単に放棄されます。



私たちの責任を考えるのをやめましょう。 残念ながら、歴史上、私たちは文明の重要な道具の開発に関連しており、それは何十年もの間コミュニケーションに使用されます。 そのため、HTMLの改善にむやみにまたは真剣に心を向けるとき、意思決定の結果がどれほど広範囲に及ぶかを理解する必要があります。



HTML 5、W3Cは最近、新世代のHTMLを作成するための努力を倍加し、過去1年ほどで大きな勢いを得ました。 これは、HTMLの構造だけでなく、モデルの分析、エラー処理モデル、DOM、リソースを抽出するアルゴリズム、メディアコンテンツ、2Dグラフィック、データテンプレート、セキュリティモデル、ページ読み込みモデル、クライアント側のデータストレージ、はるかに。



HTMLの構造、構文、およびセマンティクスにも変更があり、その一部はLachlan Huntの記事「 HTML 5の概要 」（ ハブでの翻訳 ）で説明されています。



しかし、この記事では、HTMLのセマンティクスのみを見てみましょう。 これは私が長年興味を持っていることであり、HTMLの将来にとって非常に重要だと思います。



BBCは最近、 abbrデザインパターンの可用性と利便性を支持して、テレビ番組でのhCalendarマイクロフォーマットの割合を減らすと発表しました。 これは、間違いなく、HTMLのセマンティック機能を、これまで意図されていた制限をはるかに超えて押し進めたことを示しており、実際にその言語で可能です。 ドキュメントのセマンティクスを強化できるHTML要素と属性がなくなるだけです。 既存のHTMLコンストラクトを引き続き使用すると、このような問題がますます発生します。 HTMLには、セマンティックマークアップ言語のような根本的な欠陥があるため、そのセマンティクスは固定されており、拡張できません。



これは単なる理論上の問題ではありません。 数十万人の開発者がクラスとIDを使用してよりセマンティックマークアップを作成します（CSSスタイルの「フック」としても使用しますが、それは別の質問です）。 ほとんどの場合、これらの開発者は、既存のスキームの値ではなく、独自の値を構成する特別な辞書を使用します。 これは疑似セマンティックマークアップです-せいぜい。



インターネットの多くのページがmicroformatsを使用してHTML要素と属性の貧弱なセットを使用するより多くの構造化されたセマンティクスを追加します 。 この場合、クラス属性に使用される値は、 vCardなどの他の標準から取得される場合もあれば、最近作成された辞書から取得される辞書と一致する場合もあります（ hReviewの場合のように）。

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

ここで解決する必要がある非常に深刻な問題があります。 開発者が疑似セマンティクスではなく、表現力豊かなセマンティクスをマークアップに追加できるようにする、明確かつ明確なメカニズムがHTMLに必要です。 これはおそらく、HTML 5プロジェクトにとって最も緊急のタスクです。



しかし、HTMLコンテンツでより多くのセマンティクスを作成するメカニズムを思い付くのはそれほど簡単ではありません。ソリューションには大きな制限があります。 おそらくこれらの最大のものは後方互換性です。 このソリューションは、現在使用されている数億台の視聴デバイスを侵害することはできません。これらは今後数年間使用されます。 互換性のない決定は、読者を失う恐れがあるため、開発者に広く受け入れられません。 つるの上ですぐに乾きます。



また、ソリューションには上位互換性が必要です。 将来のブラウザで動作するという意味ではありません-これはブラウザ開発者のタスクですが、 拡張可能である必要があります。 将来のセマンティクスの考えられる、考えられないすべてのニーズを解決するために開発する単一のソリューションを期待することはできません。 将来のニーズに応じて拡張できるソリューションを開発できます。



これらの困難は一緒になって大きな問題を引き起こします。 しかし、主要な反復が数十年にわたって行われ、通信のグローバルプラットフォームとして最も重要な言語のコンテキストでは、これは解決しなければならない問題です。



では、HTML 5はこれをどのように解決しますか？ HTML 5では、いくつかの新しい要素が導入されています。 セクション、ナビゲーション、脇、ヘッダー、フッターなどの構造的なものを呼び出しました。 タイプと内容がブロック引用に似ているダイアログ要素。 meterなどの多数のデータ要素もあります。これは、「ディスク使用量などの既知の範囲または小数値内のスカラー測定」です。 時刻要素{http://www.w3.org/html/wg/html5/#the-time}は、日付および/または時刻を表します。



これらの要素は有用である可能性があり、判明したように、実際にこの問題を解決できるかどうかにある程度の関心を寄せていますが、上位互換性と下位互換性の制限で判断します。



すべての障害を考慮する

下位互換性

セクションなどの最新のブラウザは、これらの新しい要素をどのように処理しますか？ さて、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 >



* This source code was highlighted with Source Code Highlighter .

最初は見栄えがいいです。 しかし、たとえば、セクション要素にCSSスタイルを設定しようとすると、次のようになります。

 セクション{色：赤} 

...上記のブラウザーのほとんどは成功しますが、IE7（特に6）は成功しません。



そのため、現在使用されているブラウザの75％との後方互換性の問題があります。 Internet Explorerの半減期を考えると、ほとんどのユーザーは、数年後でもIE6とIE7を使用すると予測できます。



HTML 5に新しい要素が導入された場合、大部分の開発者がそれらを使用する可能性はどれくらいですか-使用されているほとんどのブラウザーと互換性がないためです。



ボトムアップから互換性に目を向けましょう。これは次の問題です。

ボトムアップ互換性

最初に、「なぜこれらの新しい要素を発明するのか」という質問を投げかけます。 妥当な答えは、「HTMLに十分なセマンティクスがないため、これらの要素を追加することで、HTMLのセマンティクスを向上させます。



これらの要素を追加することにより、HTMLのセマンティクスの可能性を高める必要性を検討しますが、それは狭い範囲内に限られます。 導入する要素の数に関係なく、HTMLセマンティクスの追加を常に検討します。 そして、必要なだけ要素を追加しても、問題は解決しません。 特定の用語をHTML辞書に追加する必要はありません。必要に応じてドキュメントのセマンティクスを拡張するメカニズムを追加する必要があります。 技術的には、HTMLを拡張可能にする必要があります。 HTML 5は拡張メカニズムを提供しません。



したがって、HTML 5は、最新のブラウザーのかなりの割合を殺す機能を実行し、言語にセマンティクスをまったく追加することはできません。



新しい要素についていくつか質問があります。 新しい要素の名前はどこから来たのですか？ ナビゲーション要素を「nav」と呼ぶことにしましたか？ ナビゲーションでページレベル、サイトレベル、メタサイトレベルという用語が使用されるのはなぜですか？



DocBookなどの既存の辞書を採用しないのはなぜですか？ 彼の文書の語彙構造はより豊かであり、長年にわたって専門家による出版物を通じて開発されてきました。 これはDocBookを支持する議論ではありませんが、実際には、HTMLセマンティクスを提供するためのメカニズムを準備するという非常に重要なタスクは非常に重要であり、30年以上前に始まった仕事の実践にはほとんど注意を払っていません。 （GMLの最初の作業は1970年代初期に始まりました）

いくつかのソリューションのアイデア

ですから、現在の努力の極めて重要なこととして、この問題を解決する方法に関する実践的な推奨事項があります。 まあ、私は1つから始めました。



少なくともこの説明では、新しい要素の追加が説明されていない場合、属性はHTMLの別の論理的な領域であり、それに焦点を当てています。 結局、ほぼ10年間、クラスの属性とid属性をHTMLのセマンティクスを拡張するメカニズムとして使用してきました。 多くの開発者はすでにこれに精通しており、快適に感じています。 microformatsプロジェクトは、既存の属性ではHTMLのセマンティクスを拡張するメカニズムとして使用するには不十分であることを示しました。 したがって、属性を使用して問題を解決する場合は、1つ以上の新しい属性を導入する必要があります。 仕組みに移る前に、これがどのように機能するかを説明する前に、この文をHTML 5の新しい要素と同じ要件にさらしてください。新しい属性を導入する上で最も重要なことは、後方互換性がHTMLかどうかです。 もしそうなら、これはHTMLのセマンティクスを拡張するための実行可能なメカニズムを提供しますか？



新しい属性を発明しましょう。 これを「構造」と呼びますが、名前は重要ではありません。 次のように使用できます。

  <div構造= "ヘッダー"> 

ブラウザがどのように評価しているか見てみましょう。



もちろん、すべてのブラウザーが次のCSS要素を処理します。

  div {色：赤} 

これはどうですか：

  div [構造] {font-weight：太字} 

実際、IE7を含むほとんどすべてのブラウザーは、そのような属性がない場合でも、構造属性を持つdivスタイルを処理します。 残念ながら、IE6はそうではないため、私たちの幸せは消えます。 ただし、この属性はHTMLで使用でき、既存のすべてのブラウザーで認識されます。 現代のすべてのブラウザで属性を使用して、HTMLにCSSスタイルを使用することもできます。 そして、古いブラウザーを回避したい場合は、スタイル値を持つクラスを追加できます。 Internet Explorer 6または7では機能しない新しい要素を追加するHTML 5ソリューションと比較すると、これは確かに下位互換性のあるソリューションであることがわかります。

属性の拡張性

新しい要素の代わりに、HTML 5は多くの新しい属性を受け入れる必要があります。 これらの各属性は、セマンティクスのカテゴリまたはタイプに属します。 たとえば、 別の記事ですでに詳しく説明したように、HTMLには、構造セマンティクス、修辞セマンティクス、ロールベースのセマンティクス（XHTMLから採用）、およびセマンティクスの他のクラスとカテゴリーが含まれます。



これらの新しい属性は、クラス属性として使用できます。要素のセマンティクスを提供するため、要素の性質を記述するため、または要素のメタデータのために。



これは、すべてのセマンティクス要素に1つの属性があるXHTMLの属性ロールと違いはありません。さまざまなタイプの要素セマンティクスを定義し、それらを分離する必要があります。



たとえば、XHTMLロール属性は次のように機能します。

< ul role ="navigation sitemap" >

< li href ="downloads" > Downloads </ li >

< li href ="docs" > Documentation </ li >

< li href ="news" > News </ li >

</ ul >



* This source code was highlighted with Source Code Highlighter .

ロール属性の値は、 標準辞書または特定の辞書で定義された単語の分割リストスペースです。



ロール属性をそのまま受け入れないのはなぜですか？ 結局のところ、ロールの定義が適用できないセマンティクスには他のタイプがあります。 例：

  <p rhetoric = "irony">彼は素晴らしい人です。</ p> 

これは、セマンティクスの理論的なタイプ-「修辞的」を示しています。これは、修辞的性質の文書をマークアップするために使用できます。 この要素は、明らかに文書で皮肉の役割を果たしていません。 それどころか、皮肉な要素が含まれています。



別の例を示します。 HTMLには、日付など、人間が理解できる機械可読値の表現がないことがますます明らかになってきています。 これは、前に説明したhCalendarマイクロフォーマットのBBC問題の中心です。 来年のメーデーは本当に意味をなさないが、例えによれば、メーデーは来年になります。



繰り返しますが、この種のセマンティクスの属性または他の用語として「同等」という特定の用語を使用する場合、これは問題ではありません。 これは、クラスまたはロール属性を使用するほど単純ではないことに注意することが重要です。この場合、情報セマンティクス要素のセット全体が1つの要素に配置されます。 後方互換性と十分な柔軟性を提供する適切に拡張可能なソリューションについては、この方向で検討する価値があります。



真に実行可能なソリューションを作成するには、かなりの量の作業を行う必要があるため、このセクションを「いくつかのソリューションのアイデア」と呼びました。 自由回答形式の質問には次のものが含まれます。

• 異なるセマンティック属性の数。 これらのカテゴリは拡張可能ですか？
• 辞書を定義するには？
• 開発者がクラスの値を使用したのとほぼ同じ方法で、必要な用語を発明しただけなのか、それとも標準化された仕様で可能な値を定義すべきなのか？
• たとえば、2つの辞書の間に矛盾がある場合、2つの異なる辞書が2つの異なる辞書によって定義されている場合、これを解決するにはどうすればよいですか？
• 名前空間が必要ですか、それとも別のメカニズムがありますか？

急いでこれらの質問に答えるのではなく、対処する必要がある質問を提示し、対話が始まりました。 HTML 5で行われる決定の分岐点と範囲は、これらの決定を行うには大きすぎるため、言語学、セマンティクス、記号論、および関連フィールドの認識を導入する必要があります。



HTMLに新しい要素を単純に導入することは、HTMLのセマンティクスを拡張する問題の解決策ではないことは明らかです。



簡単な決定に突入しないようにしましょう-「気候」の変化により、これはすべて、孫たちに今のように問題を負わせます。 少なくとも、できるだけ良いHTMLのままにしておきましょう。