汎用埋め込みタグOBJECT要素に関する覚書き

はじめに

WEB画面にさまざまなマルチメディア情報を埋め込むことができる汎用タグとして<OBJECT>タグがある。画像、動画、音声、各種プラグインデータ、JAVAアプレット、他のHTML文書等の、様々なデータ形式をWEB文書に埋め込むことができる。しかし、現状では、データ形式ごとに<IMG>、<EMBED>、<BGSOUND>、<APPLET>、<IFRAME>などのタグを使い分けている。それはなぜか？

<OBJECT>タグは、ブラウザ側の対応が完全ではないようで、限られた状況でしか利用されていない。マルチメディアに限らず、テキストだってなんだって埋め込むことができるものの、自由度が高い反面、その挙動は、WEB製作者の意図したようにならないことがある。思わぬ落とし穴が、そこここにあるのだね。

ここでは、マルチメディア情報の活用の観点とW3Cヴァリッドの観点から極力<OBJECT>タグを使用する方向性について、自分なりにまとめてみたい。（覚書き）

<OBJECT>タグが使いづらい理由

まず、WEB製作者側にたって、OBJECTタグを使いづらい理由を自分なりに考えてみた。

第１の理由は、汎用性を確保するために<OBJECT>タグの属性には「必須属性」がないということではないだろうか。

W3Cの勧告書を英語で読んでもよくわからないので（ちなみに翻訳した日本語だとよけいわからない）、わかりやすく解説しているページを眺めていると、どうもそういうことがひとつの原因らしい。属性を何も書かなくても機能することからインライン要素にOBJECTタグを使ってブロックレベル要素を埋め込む（<p><OBJECT><blockquote></blockquote></OBJECT></p>）みたいな記述が可能になるなど、ちょっととっつきにくいイメージがあるし、どうやって使うのか、持て余している感がある。とりあえず表示できてるから、ま、いっか的な使われ方のようだ。

これを要するに、<OBJECT>タグは、<EMBED>タグに比べて、はるかにたくさんのパラメータが用意されていることから、自由度が高い。自由度が高いがゆえに、逆に使いにくいのである。しかし、使いにくいといっても、W3Cにおいて、<OBJECT>タグへの統一という大方針があるわけで、<EMBED>タグは排除される方向にあることから、今後どうしても<OBJECT>タグの活用について考えていかなければならない。

第２の理由は、処理プラグインを強要しているところにあるのではないか。どういうことかというと、現在いろいろなWEBのソースを見ても、さらには「?HTMLタグ辞典」などの刊行物を読んでも、<OBJECT>タグの使用には、必ずといっていいほどclassid属性に引き続く、暗号のような英数字の文字列が使用されている。

ここからちょっと推測が入るけれども、このclassid属性によって、埋め込まれるデータを処理するためのプラグインを指定しているふうなのだ。これはちょっと考えるとおかしいと思う。（おかしいなら笑えという突っ込みはなしよ。）というのは、音声再生ソフトや動画再生ソフトは、今ではいろいろなファイル形式に対応していて、このデータ形式はこのプレーヤーでなければ！というものは少ない。「midi」や「mp3」ファイルはそのいい例だと思う。

ユーザの環境によって、Microsoft Media Playerで再生したり、RealPlayerだったり、QuickTimeだったりといろいろあるのに、例えば、MIMEタイプがtype="audio/mp3"で、classidにRealPlayerの”暗号文字列”を記述することにより、プラグインとしてRealPlayerを明示的に指定するとしよう。

この場合ユーザ側にとっては、いつもはQuickTimeをmp3の再生プレーヤーとして関連付けしていて、再生できる環境にあるのに、わざわざRealPlayerをインストールしなければならない羽目になる。ユーザはプラグインのインストールを強要されるため、はなはだ面倒であり、かつ、不愉快だ。

したがって、WEB製作者は、この辺のことを考えてコーディングする必要があるため、面倒くさくて、やなタグやな?（笑）となるのではないかしら。（あくまで想像だが）

そして、３つ目の理由は、ブラウザの対応状況。実はこれが一番大きな理由だと思うのだが、ブラウザによってずいぶん挙動が違うということだ。表示できたりできなかったり、また、パラメータの解釈が異なるため、コンピュータそのものが、とんでもなく動作不安定になったりと、ワールド・ワイド・ウェブ・コンソーシアムで勧告されているにもかかわらず、各ブラウザの対応がまちまちというのが、まったくもってお粗末であるな。EMBEDタグの歴史的なこととか、OBJECTタグのとっつきにくさとか、古いバージョンへはそうするとか、OSの違いはこうするとかは別にして、早く対応してちょーよってのが結論（おい！）各ブラウザに対応するために、いまだにOBJECTタグとEMBEDタグを併記している現状は、どう見ても勧告無視の姿勢でよろしくないのではないでっしゃろか？（勧告はあくまで勧告なのだが…）

プラグインに対する配慮

ユーザ側のプラグインの有無のことまで考えていたら、前に進まない。これはまったくのユーザの都合であることから、考察を加えるほどのこともないが、WEB製作者として、若干、考慮しておかなければならないことがあるので、触れておくことにする。

まず、画像、動画、音声などのマルチメディア情報のファイル形式は、一般的にインターネットの世界で使用されている形式のものを使用するということである。当たり前といえば当たり前であるが、さまざまなユーザ環境に対する最大公約数的な表現に心がけるとともに、インターネットの世界で、より一般的に使用されているファイル形式で”保険”をかけておくというやり方が必要である。どういうことかというと、例として、画像の埋め込みに関するひとつの例を挙げることにする。

ある写真家が、高精細な写真を配布するWEBを運営しているとしよう。WEB製作者は、できるだけそのままの画質を保持したまま写真を配布したいという意図から、.PNGや.TIFFなどを選びたいと考えるだろう。（.jpgは画質が劣化するし、.gifは色数に制限がある。）しかし、ユーザ側では、一般的でない（？）.PNGや.TIFFなどのファイル形式を処理できない環境である可能性が、.jpgや.gifなどに比較すると高いと思われる。そこで、OBJECTタグが、幾段にも入れ子処理が可能であることを利用して、次のようにコーディングするといいかと思う。上記の例は、現実的にあるかどうかは別にして、
（１）.TIFFが処理できない場合は、.PNGを処理
（２）.PNGが処理できない場合は、.jpgを処理
（３）.jpgも処理できない場合は、「配布用画像がご覧いただけない方は、お問い合わせください。」というテキストが表示されるという3段構えのコーディングの例である。

つまり、マルチメディア情報を配布する際、いくつか一般的なファイル形式を”保険”として用意しておき、ユーザ側で取捨選択できる仕組みをWEB製作者側が配慮するということである。すなわち、ユーザ側にインストールされているプラグインに対してある程度配慮しておく必要がある場合は、OBJECTタグは、それを実現できるコーディングが可能であるということである。