ほほほ！ 休日が来ます！ 常にcoca-co ... HTML5！

雪が降り、なんとなく陽気になったお正月気分。 どうにかしてお祝いの精神を維持するために、出版社から少し驚いたことにし、Mark Pilgrimの無料の電子書籍「 HTML5 」で読者を喜ばせることにしました。 開発者ガイド 」（HTML5に潜る）。 オリジナルの本はインターネットでも無料で入手できます。



本全体をダウンロードする前に、最初の章に慣れることをお勧めします。

第1章どうやってここに来たの？

さあ始めましょう

私は最近、Mozillaプラットフォームの開発者による声明を読みました。この声明では、標準の開発に常に伴う緊張について述べています。

仕様とソフトウェアの実装は、慎重な共同開発の方法で進めなければなりません。 実際、一方では、標準の最終バージョンがリリースされる前に実装を表示したくありません。そうしないと、開発者は特定のプログラムの機能を考慮します。つまり、仕様の一部のみがビジネスになります。 一方、少なくとも1つの実装がリリースされるまで、完全な標準を承認したくありません。そうしないと、フィードバックなしで行う必要があります。特に、プログラムの作成者の意見は考慮されません。 矛盾は避けられません。 試行錯誤によって問題を解決することは私たちに残っています。

HTML5がどのように表示されたかを説明しますが、これらの言葉を覚えておいてください。

MIMEタイプ

あなたが持っている本はHTML5に捧げられており、以前のバージョンのHTML標準、特にXHTMLに捧げられていません。 ただし、HTML5の履歴を明確に追跡し、HTML5の登場前の理由を確認するには、まず、特にMIMEタイプの概念を理解するために、いくつかの技術的な詳細を習得する必要があります。



ブラウザーがページを読み込もうとするたびに、サーバーは、ページ自体のコードをクライアントプログラムに送信する前に、一連のヘッダーを送信します。 通常、ユーザーにはこれらのヘッダーは表示されませんが、Web開発者向けの一部のプログラムではヘッダーを表示できます。 見出しは、送信されたページのコードをブラウザに認識させる方法を指示する限り重要です。 最も有益なタイトルはContent-Type



と呼ばれ、次のようになります。



Content-Type: text/html







text/html



値は、コンテンツタイプ、または読み込まれたページのMIMEタイプと呼ばれます。 この見出しによってのみ、個々のリソースのコンテンツが何であるか、したがって、このリソースの表示方法が決まります。 画像には独自のMIMEタイプがあります（ image/jpeg



-JPEG形式の写真の場合、 image/png



-PNG形式の場合など）。 JavaScriptファイル、CSSスタイルシート、および一般に、Web上のすべてのものには独自のMIMEタイプが装備されています。



実際、すべては上記の説明よりも少し複雑です。 最も初期のWebサーバー、つまり1993年以降のWebサーバーは、1994年に発明されただけなのでContent-Type



ヘッダーを送信しませんでした。 ちなみに、1993年から今日までの間に多くのことが行われ、現在行われている互換性のために、いくつかの一般的なブラウザは、特定の条件下でContent-Type



ヘッダーを無視します。 これはコンテンツスニッフィングと呼ばれます。 ただし、一般的なルールは、HTMLページ、画像、スクリプト、ビデオ、PDFドキュメント、または独自のURLの下にある他のWebコンテンツが、 Content-Type



ヘッダーにMIMEタイプの事前通知とともにクライアントプログラムに送信されることです。 Content-Type



この情報は役に立つので、よく覚えておいてください。

標準がどのように生まれるかについての大きな余談

タグはどこから来たのですか？ 私は少なくともあなたが時々同様の質問をしたとは思わない。 明らかに誰かが作成しました。 そのようなことはどこからも来ません。 さまざまな時に使用したHTMLのすべての要素と属性のうち、絶対に誰もが誰かによって作成されました。 この誰かが、要素または属性がどのように機能するかを思いつき、彼の考えを文書でまとめました。 この種の人々は間違いなく私たちより賢いですが、彼らは普通の人々でもあります。



標準がオープンに開発された場合、過去に戻って、仕様の1つまたは別の段落のアイデアがどのように生まれたかを見ることができます。 ディスカッションはメーリングリストで行われ、そのアーカイブには通常、検索インターフェイスがあります。 タグについての質問に答えるために、私は少し「電子考古学」を行うことにし、World Wide Web Consortium（W3C）がまだ存在せず、世界のすべてのWebサーバーを指で数えることができる時代の深みに突入しました。 インターネットの初期の頃です。



1993年2月25日、マーク・アンドリーセンは次のように書いています。

新しいオプションのHTMLタグを提案します。



IMG







それを使用して、引数SRC = "url"を指定する必要があります。 タグはビットマップファイル（ビットマップまたはピックスマップ）を参照します。 ブラウザはWebでこのファイルを要求し、画像として認識し、場所に応じてテキストに貼り付けます

ページコード内のタグ。

使用例：









（終了タグは必要ありません。）



他のコンテンツと同様に、このタグはアンカー内にネストできます。 そうすると、画像は、通常のテキストリンクのように、アクティベーションの影響を受けやすくなります。 ブラウザには、サポートするグラフィック形式を自由に選択できるようにする必要があります。 XbmやXpmなど、適切な選択肢が私には思えます。 ブラウザが

この形式の表示方法がわからないため、開発者がこの場合に提供したいことをさせてください（たとえば、X Mosaicでは、目的の画像を置き換えるビットマップ画像が表示されます）。



この機能はX Mosaicで実装されます。 私たちはそれに取り組んでおり、少なくとも開発チーム内で使用する予定です。 もちろん、HTMLで画像をサポートするためのメカニズムはどうあるべきかについてのあなたの提案は嬉しいです。 あなたが私のものよりも良いアイデアを持っている場合は、共有してください。 さまざまなグラフィック形式が状況を非常に曖昧にしていることは知っていますが、代替手段はありません。 「ブラウザをできる限り最適に動作させます」と言うだけで、理想的なソリューションが提供されるまで待ちます（MIMEタイプを使用することもあります）。

この引用を明確にする必要があります。 XbmとXpmは、UNIXシステムで一般的なグラフィック形式です。 Mosaicは最初のブラウザーの1つです。 UNIXシステムで動作するバージョンは、Xモザイクと呼ばれていました。 マークが1993年初頭にこの手紙をディスカッションリストに送信したとき、彼はまだMosaic Communications Corporationという会社を設立しておらず、その後彼に名声をもたらしました。それぞれNetscape CorporationとNetscape Navigator）。



「多分いつか」MIMEタイプといえば、MarkはHTTPプロトコルで提供されるコンテンツネゴシエーションメカニズムを指します。 このメカニズムのおかげで、クライアントブラウザープログラムはサーバー（この場合はWebサーバー）に、処理可能なリソースの種類（たとえば、 image/jpeg



）を通知し、サーバーはクライアントにとって便利な形式でコンテンツを送り返すことができます。 1993年2月の時点で、HTTPプロトコルの最初のバージョン（1991）のみがソフトウェアに実装されており、クライアントはサポートされている画像タイプに関する情報をサーバーに送信できませんでした。 したがって、マークが直面した問題。 数時間後、トニー・ジョンソンは答えました：

私はMidas 2.0にいます（プログラムはまだSLACによって内部で使用されていますが、オープンリリースの準備ができています）同様のソリューションが使用されています。 タグには別の名前が付けられ、別の引数NAME = "name"がありますが、機能は提案したIMGタグとまったく同じです。 例：







NAME , «» . , , , , . , , .



( , ) . , -, , IMG SRC, IMAGE SOURCE . ICON — , , . ,

, ICON .





Midasはもう1つの初期のブラウザーであり、X Mosaicの現代版です。 クロスプラットフォームであり、UNIXとVMSの両方で機能しました。 SLACの頭字語は、スタンフォードリニアアクセラレータセンター（Stanford Linear Accelerator（Electron）Research Center）の略です。 現在、このセンターは国立研究所のステータスを取得しています。 SLACのエンジニアは、アメリカで最初のWebサーバーを立ち上げました。これは実際にはヨーロッパ以外では初めてのサーバーです。 1993年2月、SLACはネットワーク上の100世紀の人と見なされました（1年3か月働いた！）。



トニーの手紙の続きです。

新しいタグについて話しているので、Midas 2 .0で実装する予定の別の同様のタグについて説明します。 彼のスキームは次のとおりです。







, . , — -. HTTP2, .





HTTP2という名前で、1992年版の基本的なHTTPバージョンがここに表示されます。 1993年の初めには、その大部分にソフトウェアの実装がありませんでした。 ドラフトはHTTP2として知られ、いくつかの改良がHTTP 1.0として標準化されました。 HTTP 1.0には既にコンテンツネゴシエーション用のリクエストヘッダーが含まれています。つまり、「多分いつか」が間もなく登場します。



トニーはこ​​の手紙を終了します。

次の代替案を検討しました。



<A HREF="..." INCLUDE>.

タグに新しい機能を追加したくありません. , INCLUDE . , INCLUDE, (« . » ) , INCLUDE.



. , INCLUDE . , INCLUDE, (« . » ) , INCLUDE.





この提案は実装されていませんが、画像が欠落している場合の置換テキストのアイデアは非常に魅力的であり、マークが提案したタグ設計には言及されていません。 数年後、このアイデアは属性に実装されました（その後Netscapeはすべてを台無しにし、ツールチップとして代替テキストを誤って表示しました）。



ティムバーナーズリーは、メッセージの数時間後に彼とマークに返信しました。

写真は次のように表現できると思いました







。 参照関係の意味は次のとおりです。



EMBED-表示するドキュメントの特定の場所にコンテンツを埋め込みます。

PRESENT-ソースドキュメントが利用可能な場合にコンテンツを表示します。



属性のさまざまな組み合わせが可能であることに注意してください。 ブラウザがそれらのいずれもサポートしていない場合、エラーは発生しません。 この方法でユーザーの選択に敏感なアイコンを作成するには、アンカーを別のアンカーにネストする必要があることは明らかです。 しかし、正直なところ、特別なタグを紹介したくありません。

この提案は実装されていませんが、rel属性はまだ存在しています（第3章の「HEAD要素」セクションを参照）。

ジム・デイビスが追加しました：

たとえば次のように、コンテンツのタイプを指定できると便利です。







ただし、コンテンツの種類がファイル拡張子によって厳密に決定されるまでは、確実に対応したいと考えています。

この提案も実装されていませんが、後にNetscapeはtagを使用した任意のマルチメディアオブジェクトの埋め込みをサポートし始めました.



(Jay C. Weber) :









.



(Jay C. Weber) :







ブラウザでグラフィックを表示することは、私の古い夢です。 しかし、マルチメディア情報の種類ごとに個人タグを作成することは本当に必要ですか？ 最近まで、誰もがMIMEタイプのメカニズムの出現を喜んで見ていました。 今何が起こったの？

マーク・アンドレスデンは答えた：

これは、今後の標準的なドキュメント処理エンジンとしてのMIMEタイプの使用に代わるものではありません。 これは、MIMEとは独立して必要な機能の単純な実装です。

ジェイ・ウェーバーは反対しました：

しばらくの間、MIMEタイプを忘れて、本質から気をそらします。 実際、来週誰かがサウンドファイル用の新しいタグを提供することを期待できるので、埋め込み画像をサポートするあなたのアプローチには同意しません。 一方、すべてのメディアタイプに単一の埋め込み方法を使用する場合は、それほど高価ではないコインを支払う必要があります。



経験から、Jayの懸念は十分に根拠があったことが示唆されています。 確かに、1週間以上が経過しましたが、HTML5にタグが表示されました