doc drawn up: 2001-11-28 .. 2014-06-08


HTML の動向

HTML をあくまでもソースコードレベルで直接記述することにこだわる素人(職業的 Web ページデザイナーではないという意味です)の僕が、気になる HTML の規格の動向について書き留めてみました。

最近の動向では、旧来の HTML4 の後継規格として、XHTML よりは HTML5 の方へと向かいつつあります。特に、Firefox が HTML5 に積極的に対応している点は心強いです。HTML5 では MathMLSVG が簡単に埋め込めるので、数式や図表の表示に大変便利です。

HTML5 については羽田野太巳氏の記事(一部有料コンテンツ)などが簡略ながら参考になります。羽田野氏のコメントとかぶりますが、僕の場合も、当時、HTML4 が規格として色々と問題があった点が指摘されていたにも関わらず、インターネットの商用面での普及が爆発的に展開していた時期であったため、標準規格としての HTML が次世代規格に更新されないまま滞っていた状況があったため、このページのようなメモを作成して、ブラウザ間の互換性など HTML に関する動向の把握に努めようと思ったのが始まりでした。10年以上にわたるその混乱した状況も、HTML5 によって、一応の収束を見ることができることになります。感慨ひとしおといった気持ちですね。

ブラウザに対する互換性

2008年以降にリリースされた各社のブラウザは段階的に HTML5 に対応しつつあるようです(Wikipedia 情報による)。すなわち、次のようになります:

JavaScript (1.5 を基準に)

URI エスケープに関する諸問題から、日本語を扱うようなケースにおいては、JavaScript 1.5(もしくは JScript 5.5)以上の対応ブラウザが要求される場合があります。この場合、IE では 5.5 以上が条件となります。Firefox では 1 において既に JavaScript 1.5 対応です。

ちなみに、Firefox 4 では JavaScript 1.9 に対応しています(IE を含めた詳細は wikipedia の情報等を参照)。ECMA-262 Ed.3 に準拠している点では JavaScript 1.5 と同じで、JavaScript 1.6-1.9 においては ECMA-262 Ed.3 に対する拡張機能部分において更新されています(cf. Versions of JavaScript)。

JavaScript は無駄に使うと、これほど嫌味なものはありませんが、料理でスパイスを少量効かせるように、適切に(特にフォーム入力等における)ユーザーインターフェースを向上させる手段として使えば、大変良い効果を発揮します。上手に使いたいものです。

非 IE ユーザーが IE での表示状態を確認する方法

IE NetRenderer というサイトで、任意の URI の Web ページが IE の各バージョンでどのような表示になるかをチェックすることができます。

XHTML

HTML4 の後継として XHTML が想定されていましたが、市場にあまり受け入れられなかったため、結局は HTML5 へと進むことになりました。しかし、HTML5 においても、XML としても有効な文書である XHTML として記述することは可能です。その場合にポイントとなる点をいくつか挙げてみます。

要素タグの大文字・小文字が区別される

XML では要素タグの大文字・小文字が区別されるので、要素タグは全て小文字で記述しなければなりません。

閉じタグは省略できない

XML 要素タグの閉じタグを省略できません。ただし、閉じタグを含んだ省略表現(ex. <br /> のような形式)を使うことはできます。

Content-Type

XHTML 1.1 においては、Content-Type に従来の text/html ではなく、application/xhtml+xml をメディアタイプとして使用することが推奨されています。この件に関する唯一最大の問題は、2012年の時点においても未だ大きなシェアを占める IE 8.0 以下がこのメディアタイプに対応していないという点です(IE 9.0 でやっと対応。Windows 自体が XP から 7 への移行期を迎えてきているので、IE 9.0 への移行が進むのも時間の問題となりました)。このため、古い IE のユーザーが application/xhtml+xml メディアタイプの XHTML 文書を閲覧しようとすると、ファイルをダウンロードするモードになってしまいます。これは実用的な意味で、今現在のところは、application/xhtml+xml を使うわけにはいかないということになってしまいます。

またさらに、application/xhtml+xml をメディアタイプ指定した文書においては、<meta http-equiv=""> を記述するべきではないともされています。これは恐らく、メディアタイプや文字コードの指定が HTTP 通信ヘッダと HTML 文書内の <meta http-equiv=""> の指定で食い違う問題が起こりやすいので、今後はすべからく HTTP 通信ヘッダで扱うことにして HTML 文書内にそれらに関する情報は記述しないことにしたのだと思います。

XHTML 1.1 の場合は原則的に application/xhtml+xml の使用が推奨されていますから、HTTP 通信ヘッダにおいて Content-Type: application/xhtml+xml の指定を行った上で、HTML 文書内の <meta http-equiv=""><meta http-equiv="Content-Type" content="application/xhtml+xml" /> はもちろんのこと、<meta http-equiv="Content-Style-Type" content="text/css" /><meta http-equiv="Content-Script-Type" content="text/javascript" /> も含めて <meta http-equiv=""> は すべて削除しておくことになります。

ともかく、HTML 文書内の <meta http-equiv=""> は すべて削除ということになります。ここまでは、すべての XHTML 1.1 文書を作成する人に共通することです。

次に HTTP 通信ヘッダの Content-Type 指定ですが、これは、.htaccess による Web サーバの設定カスタマイズが可能なサーバの利用者にしか、行うことは不可能です。しかしたとえ .htaccess が使える人であっても、現状は IE の問題があるので、XHTML 1.1 文書に対する指定としては非推奨であることを承知の上で、Content-Type 指定を text/html のまま運用する他ありません。すなわち、デフォルトの設定のままということになります。IE の対応状況を見計らって、.htaccess の使える人は、application/xhtml+xml に変更するといいでしょう。

.htaccess の記述例:

AddType "application/xhtml+xml" .xhtml

ところで、Web サーバが Apache で mod_rewrite というモジュールが組み込んである場合には、ブラウザの返す受容可能メディアタイプを判定して、それに応じた Content-Type を生成するというアイデアを知りました(情報源)。次の .htaccess 用コードはそこからヒントを得て微妙に改良したものです。

AddType "application/xhtml+xml" .xhtml
<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{HTTP_ACCEPT} !application/xhtml\+xml
    RewriteCond %{LA-F:REQUEST_FILENAME} \.xhtml
    RewriteRule .* - "[type=text/html]"
</IfModule>

これでデフォルトでは application/xhtml+xml が指定され、ブラウザの受容可能メディアタイプに application/xhtml+xml が含まれない場合のみ、text/html が指定されるようになります。

favicon

ブックマークや URI 表示に添えるアイコンとして使われるのが、16x16 ピクセルのサイズの favicon です。favicon については、IE だけが対応状況が他のブラウザと異なっている点には注意した方がいいと思います。

元々は、Windows 固有の .ico 形式のファイルをマイクロソフト社が他の OS のことを気に留めずにインターネット上で傍若無人に使用したのがそもそもの始めだったので、IE でしか意味を為さず、.ico 形式のファイルに対応している画像ソフトもあまりなかったため、それほど普及しませんでした。しかし後に Firefox が W3C の規定を反映した .png や .gif 形式のファイルによる favicon 仕様に対応するようになって、新たに息吹が吹き込まれることになりました。

そのような経緯のため、favicon は IE が発端ではあったのですが、新しく標準化された favicon の仕様には IE だけが対応していない状況でした。最新の IE 11 でようやく、IE も .png や .gif の標準規格の favicon に対応しました。

W3C の意見によると基本的に favicon を指し示す link 要素は次のような rel="icon" 属性が望ましいのです:

<link rel="icon" type="image/gif" href="/favicon.gif" />

IE はこの形式に対応しておらず、 rel="shortcut icon" 属性でないと favicon を表示しません。ところが、shortcut icon のような 2 語の属性値は W3C の規定により不適切とされています(wikipedia の情報を参照)。

なので、W3C の規定に則った HTML 文書を作成する場合には、上のコード例に加えて、IE 用にも

<link rel="shortcut icon" type="vnd.microsoft.icon" href="/favicon.ico" />

というコードを併記するというような〝場当り主義的な対処〟はするべきではないということになります。

僕が考えたこの問題に対する解決方法は、シンプルです。1) link 要素は rel="icon" のもの(1 番目のコード例)だけを記述する、2) IE 対策としてはサイトのルートディレクトリに favicon.ico を置いておく(IE は自動でルートディレクトリの /favicon.ico を探す習性がある)。つまり HTML 文書の方では、規定に反する IE の挙動については何も気にすることなく、Firefox 用の記述だけを 1 行載せておけば ok というわけです。特に Firefox の方はアニメーション GIF にも対応しているので、Windows のアイコンを流用する IE の favicon の場合と違って、とても表現の自由度が高くなります(IE 11 でもアニメーション GIF にはまだ未対応です)。

IE 11 から IE も .png / .gif に対応するようになったので、今後は IE 対策用の 2) は不要となります。

以下に、アニメーション GIF を作成するためのソフトと、.ico ファイルの変換をオンライン上で行ってくれるサイトを紹介します:

HTML、CSS 等の文法チェッカー

定番のものを紹介するだけに過ぎませんが、自分自身のブックマークも兼ねて記しておきます。HTML、CSS をハンドコーディング(手書き)する人にとっては、ほとんど必須のツールと言っていいでしょう。

  1. HTML Validator (W3C)
  2. CSS Validator (W3C)
  3. Another HTML-lint (k16 さん)

使い方としては、まずは (1) の HTML Validator で HTML の文法ミスを洗い出します。HTML が文法的に正しいものでない場合には、CSS が正常に機能することも保証されません。(1) による HTML の正当性を確認した後に、(2) の CSS の文法ミスを洗い出します。CSS を修正する段階で HTML ファイルも変更した場合は、再び (1) のチェックを行った上で、(2) のチェックを行い、エラーが出なくなるまでこの作業のループを繰り返します。

基本的には (1) (2) によるエラーの洗い出しで十分ですが、HTML をハンドコーディングするこだわりを持つ人の(恐らく)かなりの数の人は、いしの k16 さん作の (3) の Another HTML-lint による、Web ページ作成に関するさらに包括的なチェックを行います。(1) では主に HTML 自身の文法的な整合性をチェックしますが、(3) はむしろ実際の Web ブラウザにおける挙動などを視野に入れた、Web ページ作成にあたってあらかじめ考慮しておいた方がいい“作法”のようなものについて教えてくれます。こういった“作法”的なノウハウは、個人で網羅するのはなかなか難しく、(3) Another HTML-lint によって気付かされることが多く、大変有用です。

Another HTML-lint の利用方法については作者の k16 さんが FAQメーリングリストでも述べておられますが、満点を取ること自体を目標とするものではないということを念頭に置くべきです。満点を取ることを目的として、出てしまった警告をすべて出なくなるように HTML を書き直すことに血眼ちまなこになるのは、どうにかしています。もちろん、自分の配慮が足らなかったせいで出た警告に対しては、真摯に対処するべきです。一方、上述した Content-Type の問題のように、即時的に標準に適合するようにしようとすると、現状のブラウザ側の対応との問題で却って無理が生じるものもあります(かといって、このような場合に、Another HTML-lint の側の仕様変更を望むというのも、また筋違いな話です。そういう意味でも、「満点」という評価に形式的にこだわりすぎないようにするべきです)。自覚の上で出ている警告や減点に関しては、鷹揚に臨みましょう。それでも何か引っかかるものがある場合は、メーリングリストに参加するなりして発言してみるのも手でしょう。


<coding>