What's new in IE5

〜 Internet Explorer 5 の食えない事情

ここでは、'99年3月に正式リリースを迎えた Internet Explorer 5.0 の 素晴らしい機能の一端を紹介します。 ← ウソ f(^^;

IE5.0 は今まで重かったレンダリング機能が軽くなったとか、 「ラジオ」などの新機能が面白いとかいわれますが、 DHTML 作成の上での機能や性能はどう影響するか興味のあるところです。

現実問題として、軽く触ってみたところかなり大きな影響がありそうなので、 「Style Sheet の落し穴」や「怪談! Cross Browser」で追記することはやめて、 「What's new in IE 5」として独立させることにしました。

とは言っても、自分のマシンに IE5 をインストールする危険は 当分冒さないように考えているので、網羅的に確認することはできません。


目 次

IE5.0 のバージョン
えっ?そりゃ 5.0 でしょ?
JavaScript1.3
そうなんです。 IE5.0 は JavaScript1.3 と自称しています。
キャッシュ制御
IE5 のキャッシュ制御は IE4 と違うような気が...
ウィンドウ制御のセキュリティ強化?
サブウィンドウの制御が変わったけど、これ、セキュリティ強化の一環?
DIV のサイズ
IE5.0 で作成されるレイアは IE4.0 でも NN4.5 でもない、独自ルールです。
位置を指定しない absolute なレイアの位置
IE5.0 で作成されるレイアのデフォルト値は一味違う。
style オブジェクトのプロパティ
IE5.0 の style オブジェクトのプロパティはヘン
不可視のレイア
あれ?ヘンだなぁ。不可視のレイアを作ってるつもりなんだけど...
DIVタグの怪・2
たまには、良くなっていることもある。
insertAdjacentHTMLの怪
IE4 でな〜も言われへんのに、 IE5 だとエラーだとのたまう、ヘンなヤツ
レイアの表示制御手法
IE5.0 上の DHTML は速いか遅いか?
zIndex の陰謀
IE5.0 の z order 制御は人工知能付き?
マウスイベント
なんたること! IE5.0 で動作がおかしくなった。
内部コードの苦悩
外部ソース参照のスクリプトを書き出すと苦悩の日々が始まる...


IE5 のバージョン

IE5.0 のバージョンは 5.0 ですが、 JavaScript から見るバージョンは( Windows95 の場合 ) このようになります。

appVersion : 4.0 (compatible; MSIE 5.0; Windows 95)
userAgent  : Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)

つまり、 IE4.0 とはブラウザのバージョン( MSIE 5.0 )が異なるだけです。

※ まあ、これは今に始まったことではないですが、 いつまで「Mozilla ... compatible」なんでしょうかね。(^^;

それに、appVersion が 4.0 のままと言うのは、IE5 が IE4 のマイナーチェンジと 言っているのでしょうか(笑)。

あ、ここで言いたいことは IE4.0 と IE5.0 の差は appVersion,userAgent に関する限り「MSIE 4」か「MSIE 5」 しかないことです。

また、JavaScript 自体は 1.3( IE4.0 は 1.2 ) になっています。 然し、IE における JavaScript のバージョンはいったい何を意味するんでしょうか?

NN における JavaScript1.3 は明示している項目を除いて ECMA-262 準拠なんですが、 IE5.0 では ECMA-262 に準拠していない項目も多々ありますし、 準拠しないと提示しているドキュメントやアナウンスも 見たことも聞いたこともありません。

一応、IE5.0 の判定方法を蛇足で例示しておきます。

ie5=(navigator.appVersion.indexOf('MSIE 5')>=0);

現在のところは 「MSIE 5」で判定できるようです。 もし、不安ならこのようにすると良いかもしれません。

navigator.appVersion.toLowerCase().indexOf('msie5.0')>=0;

JavaScript1.3

IE5.0 で SCRIPT タグでバージョンを指定した場合、JavaScript1.3 でもマッチします。

そこで、Netscape社で言うところの JavaScript1.3 の新機能について確認してみました。

※ 全てではありません。 簡単に確認できる項目に対して簡単なテストをしただけです。
ですから、間違いがあるかもしれませんので、鵜呑みにせず 各自確認して下さい。

NN の JavaScript1.3 に対する IE5.0 の動作
機能名IE4.0IE5.0備考
Unicode IE は以前から実装している
NaN  
Infinity  
undefined ××これが×は実にイタイ
isFinite()  
toSource() ××殆ど使わないと思うけど...
getFullYear() これも以前からある
function.call() ×× 
function.apply() ×× 
strict equal  
Array constructor  
Array.push() ××IE4.0 からメソッドすらない
Array.splice() ××IE4.0 からメソッドすらない
string.replace() ×× 
Boolean constructor  
object.toString()  

※ この表で、「新」はJavaScript1.3で追加、「修」はJavaScript1.3で仕様変更で、 「IE4.0」「IE5.0」欄の「○」印は動作することを、「×」印はエラーになることを、 「未」印は未だ確認していないことを 意味します。

表を見る限りでは IE4 と IE5 の言語仕様上の差は殆どなさそうです。 どうやら、DOM - Document Object Model - の変更だけでしょうか?

※ NN では JavaScript1.3 でインターフェイスが変更された関数は、 SCRIPTタグで language="JavaScript1.2" と指定した場合と language="JavaScript1.3" と指定した場合で動作が異なりますから注意して下さい。
また、この表の「IE5.0」欄に×がついている項目はたとえ

<script language="JavaScript1.3"><!--
// --></script>


としても、ブラウザチェックをしなければならいことを意味しています。 ( 実質上、別の手段があるなら使用せずに済ます方が得策かもしれません )


キャッシュ制御

IE4 では特に no-cache を指定していないのに、 何度もイメージを出力する CGI が呼び出される傾向がありました。

IE5 はこの点を改善したようで、 no-cache を指定しているにもかかわらず、 メモリキャッシュ上のデータを使用してしまいます(笑)

※ でも、これは十分な調査はしていないので、少しマユツバものです。 f(^^;


ウィンドウのセキュリティ強化?

JavaScript の最初の頃、作成したサブウィンドウがユーザにより閉じられたことが認識できず、 window.close をやってエラーになりました。

そこで、次のバージョンでは window.closed プロパティを追加して認識できるようになった のですが、 IE5 で挙動が変わったようです。

つまり、 window.open したサブウィンドウを onUnload イベントで window.closed プロパティを調べても正しく反映されていないようです。

また、closed プロパティのない古いバージョンに対してよく使われる手法で window オブジェクトにスクリプトが windowclosed 変数を追加して対処する方法も、 サブウィンドウが閉じられると window オブジェクトのプロパティを参照できないので役に立ちません。
対処方法としては簡単で、 IE5 なら無条件に window.close を呼出せば良さそうです。 f(^^;;

if(ie5 || !subwindow.closed) subwindow.close();

上のサンプルは closed プロパティのない古いバージョンではエラーとなります。
古いバージョンにも対応するなら、つぎのようにします。 ( といっても未確認です f(^^;;;


// open 時に設定する
subwindow.opened = true;

// close 時の処理
if(ie5 || subwindow.opened) subwindow.close();

まさか、相次ぐセキュリティホールに嫌気がさして、 十把ひとからげにガードしたんじゃぁ... f(^^;

【その後】
と思っていたら、少なくともバージョン 5.00.2614.3500 では直っていました。
#> ん〜、いつから... それとも、勘違いかなぁ... f(^^;;


DIVのサイズ

「StyleSheet の落し穴」の「DIVのサイズ」でも 記述した通り、DIVの生成されるサイズは明示的に指定しない限り、 ブラウザ依存です。

然し、IE5.0 の登場により、ブラウザばかりではなくバージョン依存にもなったようです。
IE5.0 では作成するレイアのスタイルシートでの記述により以下のようになります。

ウィンドウ( またはフレーム )

★position:relative 指定
IE4.0に同じ

★折り返しが発生しない position:absolute 指定
NN4 に同じ

★折り返しが発生する position:absolute 指定
ウィンドウ幅まで伸長される

※ 正直いって、これはバグだと思います。
#> しかし、直さないだろうなぁ > MS!

【その後】
と思っていたら、IE5.01 では修正されていました。


位置を指定しない absolute なレイアの位置

<div class="sample">...</div>
<center><table .../table></center>

とした場合、レイアの位置( left,top )を指定しないと、 その部分で普通に文字等を記述したのと同じ位置( left )になりますが、 IE5 では違います。

次に記述したものと同じ配置になるようです。 つまり、上の例では左右の中心に配置されます。

◆IE4,NN4 の場合
DIV



◆IE5 の場合
DIV



left,top を指定しない場合の配置は特に規定がないので、明らかなバグとは呼べないかも...

※ この仕様をよく利用する私としては「バグ」と呼びたい... (T_T)
でも、M$社はせいぜい「HTMLとの相性」としか言わないだろ〜な〜ぁ

【その後】
と思っていたら、IE5.01 では修正されていました。


style オブジェクトのプロパティ

IE5 での最も大きな変更は currentStyle と runtimeStyle オブジェクトの追加でしょう。

今まで、style オブジェクトに対して参照・設定などを行っていましたが、 style オブジェクトはインラインスタイル専用になり、 従来の style オブジェクトは currentStyle オブジェクトに、 そして、新たに runtimeStyle オブジェクトを設けたようです。

このために、IE4 で動作していた DHTML が IE5 でうまく動作しない現象が発生しています。

※ これは W3C DOM の仕様に合わせるための作業の一部と捉えることができますが、 それ以外に、パフォーマンス対策の一環との見方もできます。 f(^^;

以前と異なる部分を列挙すると大体以下の様になります。

  1. pixelLeft などスタイルシートにない属性のプロパティは廃止された

  2. 従来の style オブジェクトはインライン指定のスタイルが反映され、 このオブジェクトに対する設定はインライン指定の変更として位置づけられた。

  3. インラインスタイルより優先するスタイルして runtimeStyle が新設された。
    このオブジェクトは HTML では指定できない、 いわば JScript のためのオブジェクトのようだ。

  4. ブラウザのデフォルト、STYLEタグ、インラインスタイルなど全てを考慮して、 実際に適用されているスタイルとして currentStyle が新設された。
    これは、IE4 の style オブジェクトに相当する。

結局、この変更により、以下の差が出てきます。

IE4/IE5 でのクロスバージョンの動作をさせるためには、次のようにすればよいようです。


// 位置の取得
function getDivLeft(div){
  return ie5?div.offsetLeft:div.style.pixelLeft;
}

// サイズの取得
function getDivWidth(div){
  return ie5?div.offsetWidth:div.style.pixelWidth;
}

※ ie5 の変数の設定については 「IE5.0 のバージョン」( 前述 )を参照して下さい。


不可視のレイア

Style Sheet で visibility:hidden; と指定しても、 初回の読込み時に一瞬表示されることがあるようです。

調べてみたところ、レイアを表示する際に該当のレイアが client領域にない場合 ( つまり、ブラウザのウィンドウ外にある場合 )、 client領域からある程度以上離れていると、原点座標に表示された後 指定された座標に移動している結果のようです。

※ ただ、それだけ。 f(^^;
IE5.0 の中身が透けて見えるような気がする...

そういえば、NN でも「戻る」操作のとき、ページの途中に戻る場合は ページの先頭付近にあるレイアが一瞬表示されますね〜


DIVタグの怪・2

「StyleSheet の落し穴」の「DIVタグの怪・2」で 採り挙げた項目が直っているようです。

※ たまには MS もバグを修正するんだ... f(^^;
互換性のない仕様変更するヒマがあるなら、もっとバグも直してくれよ〜っ。


insertAdjacentHTMLの怪

レイアにHTMLを追加する場合、通常 insertAdjacentHTML を使用しますが、

'<p><hr>'

で始まる HTML を指定してみて下さい。何故か JavaScript エラーになります。

※ 理由がワカラン。
ってことは、これ以外にも食い合わせがあると思うゾ
因みに、'<p></p><hr>' なら問題ない。


レイアの表示制御手法

IE5.0 は軽くなったという噂が結構ありますが、 DHTML に関してはどうでしょうか?

「怪談! CrossBrowser」の「レイアの表示制御手法」で 採り挙げたレイアの move と visibility 制御の処理時間を計測してみました。

処理時間の計測結果
ブラウザ種類通常子レイア親レイアレイアの重なり
IE5.0 move2.312.202.532.20
visibility1.431.428.081.54

これは、結構驚きの結果です。 NN4 と比較すると未だに遅いのですが、 IE4.0 では子レイアを持つ多少複雑なレイアの移動処理が遅かったのに対して、 IE5.0 では表示制御をした方が遅くなっています。

IE5 と NN4 を対象にする限りは visibility で制御するより move で表示制御する方がはるかに安定した性能が出せそうです。

※ 測定したマシンは前回とは異なるマシンなので、両者を絶対値で比較しないで下さい。
単に、傾向として捉えて下さい。

類推すると、IE5 では move 処理の結果を各レイアの DIV や style オブジェクトの 関連するプロパティの更新処理が少なくなったためでしょうか。

反対に visibility の制御は IE4 より極端に遅くなっています。 これも DIV のオブジェクト構成が変わり、プロパティの更新タイミングなどが 変わってきたせいかもしれません。

【その後】
「NewGameWeb」の ML で投稿記事のために再度測定し直して見たら、 処理時間は IE4 の半分で傾向は同じ結果が出ました。

測定した環境や IE5 のバージョンが違うのでどちらの結果が正しいとは言えないです。 f(^^;

IE5: Ver. 5.00.2614.3500


zIndex の陰謀

IE5.0 では z order( レイアの重なり )制御に関して何かの変更がなされたようです。

つまり、100個程のレイアを生成( 少なくとも onLoad イベント以降 )に生成した場合 zIndex を変更しても反映されない場合があるようです。

※ 現象が今一つ掴めないのでまわりくどい表現ですけど... f(^^;;

もう少し詳しく現象を説明すると、レイアを97個以上生成し、 レイアの zIndex を変更しても z order が変わらない現象で、 以下の特徴があります。

※ 96( 16進で 60 )以下かそれより多いかで発生するなんて いかにもプログラミング上のバグらしい f(^^;

これを考慮すると以前からある 描画抜けではないようです。
( 未だに、IE5 はインストールしていないので、充分な試験ができません )


マウスイベント

event オブジェクトの x,y プロパティが変更(?)されたようです。
説明は変わっているわりに、内容的には同じように見えますが、 現実は BODY の座標系での位置ではなく clientX/Y の値が返ってくるようです(*1)。

*1 clientLeft/Top ではイベントに同じメンバがあるので意味ありません。 従って、バグではないかと考えています。

<a href=... onMouseOver="..." ...><img src=...></a>

のように使用した場合イメージ内の座標で clientLeft/Top が返ってくるようです。 この Tips集でも NN4 の pageX,pageY の代わりに使用していたのですが、 期待する動作にはなりませんでした。

いろいろと考えた結果、マウスイベントからページ上の座標を得るには

pageX=document.body.scrollLeft+window.event.clientX;
pageY=document.body.scrollTop +window.event.clientY;

で取得できそうです。

また、ウィンドウ外にマウスが移動した時も通知されるように変更されたようですが、 グラブ制御をしているわけではなさそうなので、 この変更が役に立つかどうかはしばらく研究してみないとなんとも言えません。


内部コードの苦悩

SCRIPTタグで外部ファイルに JavaScript のソースを置く場合、 指定もとの HTML と同じ文字コードで記述しなければなりません。

※ HTML4.0 の仕様には charset で外部ファイルの文字コードの指定が できることになっていますが、IE, NN 共にサポートしていません。

また、 IE4 から( だっけ? )内部コードとして UNICODE になったお蔭で、 色々な問題が発生しています。

例えば、window.open でウィンドウを作成し、document.write で生成した FORM から 出力したデータが UTF-8 になるとか...

そんな、いただけない IE ですが、 IE5.01, IE5.5 は確実に磨きをかけたようです(笑)。

これは、高橋さんの JS-ML での話題ですが、 これと同様にして外部ファイル参照のスクリプトを document.write で書き出すと 外部ファイル( XXX.js )もまた UTF-8 だと解釈されるようになっています。

このため、外部ファイルに日本語が埋め込まれていると全て文字化けしちゃいます。

※ ところで IE5 の変更の大きな項目に DOM の変更があり、 W3C の HTML4.0 仕様と共に DOM に対応しようという動きが見えます。
そこで、 W3C HTML4.0 の仕様にある SCRIPT タグを見ると charset などの設定がありますが Microsoft にある Online Reference を見ると該当する項目もなく、HTML4.0 準拠じゃ なかったんだぁ、と認識を新たにすることにもなります(笑)。

全く、対応方法がないか、というとそうでもなく behavior として #default#download を 指定したレイア( これは W3C DOM にはない )経由でスクリプトファイルを読込み、 DOM で規定されている appendChild でスクリプトを登録すると動作する、 という情報があります( 実際に動作を確認しました )。
この件の詳細は JS-ML のアーカイブ( js-ml:02532 )を参照して下さい。

【その後】
...しかし、この話は IE5.01 の初期の時点での話で、 知らないうちに修正( バージョンは同じ )されているようです(笑)。

現在では IE4.01 IE5.01 共に外部ファイルは HTML と同じコードではなく、 必ず Win版の場合は Shift JIS、 Mac版 IE4.5 では UTF-8 でなければならないようです。

例えば HTML が EUC である場合でも UTF-8 である場合でも外部ファイルを Shift JIS コード にしないと文字化けしたり表示時にエラーが発生したりします。

ところが、 NN では HTML と外部ファイルは同じ文字コードでないとやはり文字化けしますから、 結局 IE, NN 共に正常に表示できるようにするためには全ての文字コードを Shift JIS に することになります
#> 弱りましたね〜 ^^;


Copyright(c) 1999 - 2000 ShinSoft. All rights reserved.