Internet Explorer 8 は 2009 年リリース (?) 95
ストーリー by reo
いまだに業務システムがIE7に未対応 部門より
いまだに業務システムがIE7に未対応 部門より
あるAnonymous Coward 曰く、
Microsoft の Internet Explorer 開発チームによる IEBlog によると、Internet Explorer 8 のリリースは来年の第 1 四半期以降になる模様 (→ 参考: IE8: What's After Beta 2)。
今年の 8 月下旬に IE8 Beta2 がリリースされていますが、ブログによるとまず来年の第 1 四半期に Release Candidate (RC) 版をリリースし、その後正式版を出すとのこと。以前は 2008 年中にリリース、などと言われていましたが、結局 Internet Explorer 8 のリリースにはまだまだ時間がかかるようです。
仕事の都合上、未だに IE6 がメインという人も少なくないと思いますが着実に IE8 の開発が進んでいる模様。Release Candidate から正式リリースまで 1 年かかることはないと思いますが、実は上記ブログには 2009 年にリリースする、とも書かれてはいないので、可能性としては 2010 年にずれ込む事も……いやいやまさか、そんな。
スペースを取りすぎる (スコア:2, おもしろおかしい)
←→ のためにタテどれだけ取ってるんだよとか思う。
#それがなきゃあっさりVistaに移行したかもしれないAC
Re:スペースを取りすぎる (スコア:3, すばらしい洞察)
ついでに高さも測った。
IE6 on XPで118dot（タイトルバー＋メニューバー＋ツールバー＋アドレスバー）
IE7 on Vistaで102dot（タイトルバー＋戻る進む＋アドレスバー＋検索＋お気に入り＋タブ＋ツールバー）その前に視力回復をおすすめします。
Re:スペースを取りすぎる (スコア:1, 興味深い)
＃何故か周りにそういう人が多いAC
Re:スペースを取りすぎる (スコア:1)
どうせ IE はほとんど使わないのでリボンUIの使い勝手は気にならないが、
ワイド画面全盛なのが腑に落ちない。
最近では、スクエア型(ワイド型に対して4：3の従来型をそういうことを、最近知った)の機種を見つけることが難しい。
(とうとうThinkPad X シリーズもスクエア型が無くなったし。)
みんなそんなにパソコンでハイビジョンが見たいのか、それとも横長で作業する仕事が増えたのか？
未だにコンピュータはプログラムを作成して走らせるもの、と考えている自分には、
表示行数が減ってしまう横長画面でプログラミングする気にならない。
また、プロジェクタと違う解像度でプレゼンを準備する気が知れません。
縦横比で期待通りに見えるのかとか、文字がつぶれて見にくくなったりしないかとか、
気にならないのだろうか。
学会などで、解像度のせいでプロジェクタ接続にトラブっている(プロジェクタが認識しない、グラフの線が見えない、等)のは、たいがいワイド画面のPC。
Re:スペースを取りすぎる (スコア:1, すばらしい洞察)
減りません。
×ワイド画面は縦が短い
○ワイド画面は横が長い
物は言い様ってレベルじゃねーぞ。
もともと1024*768が主流の中で、ワイド画面にして縦の解像度が減るディスプレイなんて、ミニノートやネットブックとサブディスプレイ用液晶以外に存在するのかね。
Re:スペースを取りすぎる (スコア:1)
たしかにドット数でいけば減りはしない。
でも物理サイズは減っていることが多い。
多くの場合、モデルが横長になった際、だいたい同じインチ(つまり対角線長が同じ)
になっている。
多くのスクエア型は縦にめいいっぱい液晶ハッつけていたので、縦幅をキープしたまま
横長にすると、巨大化して「モバイル」とは言いがたくなる。
ドットが細かけりゃ字も見える、といえるかもしれないが、B5モデルでXGAが出てきた段階でフォントを 10pt から 12pt にせざる得なかった自分の視力を考えると、解像度が上がっても、物理サイズを切り詰められたら、有り難みがないなぁ。
Re:スペースを取りすぎる (スコア:1)
うーむ、上の論点が良くわからん。
インチ表示は画面の対角線が一般的なので、対角線が同じ17インチなら、
ワイドの方が縦は短い。(スクエアなら縦25.9cm、ワイド型なら縦21.1cm)
ついでに、面積も小さい。
もしかして、この部分がすでに私の勘違いなのかなぁ。
「インチサイズは対角線」が間違いでないとして話を進めると、
モバイル重視のノートPCの場合、そうそう筐体を大きくできない。
例えば B5サイズで主流の12.1インチのスクエア型とおなじ縦の長さを確保するためには、14.8インチのワイド型が必要。
でも、さすがにそこまで大きくなると、ちょっとモバイルしたくない。
なので各社、そこまでの巨大化は避けている。
例えば Lenovo ThinkPad の場合、X61(12.1インチスクエア) の後継としては X200 と X300 を用意しているが、
X200 は 12.1 インチワイド、X300 は 13.3 インチワイド。
画面の縦の長さは確実に縮小してしまっている。
筐体の大きさも、X61の 268×211×20-35mmが、
X200では 295x210x20.7-32.6mm とまあまあ頑張っているが、
X300では 318x231x18.6-23.4mm と、幅がA4の長辺を上回ってしまって、
B5サイズとは言いがたい。
別のレスにあるように、液晶を切り出す際の効率という側面は分からなくもない。
ただ、人間の視覚に頼って出力(表示)や入力(マウスによるポイント)している以上、
物理的なサイズというのは重要なファクタのはず。
逆に、解像度とか「ワイド」とかいう言葉にだまされてないか？
Re:スペースを取りすぎる (スコア:1)
ところが解像度は X200 で 1280x800、X300 では 1440x900 です。
X61 シリーズは、極めて一部のモデルを除き日本向けモデルは 1024x768 だけで、より細かい文字になりますが実質的な行数は X200 であっても増加しています。
物理サイズも確かに重要ですが、1024x768 ばかりの日本向けモデルは画面サイズ的に狭すぎて辛いです。
Re:スペースを取りすぎる (スコア:1)
逆に言えば、dpiが２倍になったときに同じdot数の文字が読めますか？ってこと。
# 640x400時代を知ってればわかるんだけどなぁ。
ググったら、Windows標準の96dpiでなく120dpi設定で出荷されてるのーぱそもあるそうで。
Re:スペースを取りすぎる (スコア:1, 参考になる)
Re:スペースを取りすぎる (スコア:1, すばらしい洞察)
シンプルが身上のメモ帳でまであれをやる神経が理解できない
Re:スペースを取りすぎる (スコア:4, 参考になる)
自動最小化にすれば完全に1行になるので、マウスでしか操作できない
ツールバーがごてごて存在する従来のUIより、狭いモニタを有効に使えます。
旧来のOfficeでメニューバーまで全消ししてたような人以外は、スペース面でのデメリットはないです。
Altキーとの組み合わせで全要素にアクセスできますし。
個人的には、誰がどう設定したOfficeであっても、とりあえず見た目が統一されてるのが安心。
Re:スペースを取りすぎる (スコア:2, 参考になる)
なんと！
リボンは非常に便利に使ってたけど、これは知らなかったです。
自宅ので試してみました。目から鱗がボロボロと。
これでもっと便利に使えるようになって嬉しいな♪
週明けに会社のにも適用しておこうっと。
私の周囲は、あのリボンが慣れなくてOffice 2007は厭って人が多いのが残念。
慣れたら2003には戻れないぐらい便利なのになあ。
はじける加齢の香り！orz
Re:スペースを取りすぎる (スコア:1)
> あれだけリボンUIのデザインを宣伝していたくせに、
> 自動最小化できることさえ知らせてなかったんだもの。
目新しいから、そこを推したい気持ちは分からんでもないですけどね。
前からMSってデモンストレーションが下手だ、ってどこかで聞いたこと
あるような気がしますです、はい。
はじける加齢の香り！orz
Re:スペースを取りすぎる (スコア:1, すばらしい洞察)
Re:スペースを取りすぎる (スコア:2, おもしろおかしい)
そっかー。
Office 2007のパッケージにマニュアルってスタートガイドしか入ってなくて、
あとはヘルプかOffice Onlineを見てね、しか書いてないんだけども、ちゃんと
全部目を通してるんですね！
もちろんリボンの最小化もヘルプじゃないと書いてないわけですが、そこもちゃ
んと目を通していらっしゃると！
凄いなあ（棒
はじける加齢の香り！orz
Re:スペースを取りすぎる (スコア:1, おもしろおかしい)
Office 2007の解説書の多さを知りませんね？
Re:スペースを取りすぎる (スコア:3, 興味深い)
Word 2007 を起動して、ヘルプを開いて「リボン」で検索すると「リボンのカスタマイズについて」「リボンを最小化する」なんて極めて上位の結果に出るんですが (手元ではカスタマイズがトップ、最小化が三番目だった)、それすらやってないと胸を張って言われても困ります。
「とりあえず他人に聞いてみる」「周囲も知らなければそんな便利機能は存在しない」って決め付けちゃってるだけじゃないですか?
# Ctrl+F1 によるリボン表示 on/off なんて Office 2007 beta からヘルプに書かれてたのにね。
ついでに言うと今の標準マニュアルは紙媒体ではなくオンラインマニュアルです。ヘルプを開いてみればわかりますが、タイトルは「ヘルプと使い方」ですよ。
そこからカスタマイズの項目を開けば、やはり「リボンを最小化する」「リボンのカスタマイズについて」が存在します。
man や info はマニュアルだと認めないタイプですか?
Re:スペースを取りすぎる (スコア:1)
Re:スペースを取りすぎる (スコア:2, 参考になる)
・最小化してからタブを開くと、マウスを外した時自動で隠れる
・リボン上でホイールを回してタブが切り替えられる
・リボンのグループの右下のアイコンで従来のダイアログが呼び出せる
・クイックアクセスツールバーを「リボンの下に表示」して
カスタマイズすると従来相当のツールバーになる
・Altキーを一回押すとショートカットガイドが出てくる
見た目が変わっただけでアレルギー反応を起こしてしまった人は、この辺りの便利な動作は知らないかもしれませんね。
もしかしたらOfficeボタンがファイルメニュー相当だということすら知らない人もいるかもしれません。
慣れてさえしまえばとてもラクに使えるし、私は逆に2003やOOoを使った時など
えらくゴチャゴチャしてて使いにくいなあと思うようにすらなりました。以前はこっちで慣れてたはずなのに。
リボン含めUI要素が大きくなっているのは、高解像度のディスプレイが普及してきたり、
タブレットPCや指タッチによる操作も考慮しなければならないこのご時世では仕方ないのではないかと思います。
7の少し太くなったタスクバーもそんな流れのうちの一つでしょうね。
Re:大型化しているワケ (スコア:1, すばらしい洞察)
ワイド化のせいで、縦方向はあんまり大きくなってないような……
セキュリティホールmemoとの相性が悪いのはウチだけ? (スコア:2, 興味深い)
IE8 Beta2 でセキュリティホール memo にアクセスした後、そのタブから別のサイトに移動したりすると、なぜかコけます。周りに IE8 Beta2 を試してる人がいないので、あれこれ比較したりができないんだけど、会社の XP SP3 でも自宅の Vista SP1 でも同じ。まぁ、コけるのはそのタブだけだし、がんばって回復してきてくれるんで支障はないのですが、こんな現象おこしてるのは私ンとこの PC だけなんだろうか?
IE7 で嫌だった、PageUp, PageDown キーが効かなくなる(マウスでスクロールバーを触ると直る)現象や、突然死が起こらない(起きてもタブ限定でなおかつ甦ってくる)ので、IE7 よりは使えてます。
個人的には何故かまったく興味が沸かないのだった (スコア:1, 参考になる)
業務で必要になるならいじくりますが今の所その気配もないし……
＃やはり７からUIが大幅に変更され、それに自分が拒否反応おこしてるのかなあ？
Re:個人的には何故かまったく興味が沸かないのだった (スコア:1, 興味深い)
と云ったものが感じられなくなっています。
その典型例がＶｉｓｔａ。
しかし、それらにしがみついてプリインストールを続けている
パソコン「組み立て」メーカにも責任の一端があるのではないでしょうか？
”じゃぁ、後継は何だ？！”って聞かれそうですが、それを考えるんは私の役目ではありません。
もちろん、個人的には既に結論を出して実践していますが．．．。
＃「ＫＴとＲＯがテレビに現れると景気は悪くなる。」ほら当たったジャァン。
Re:個人的には何故かまったく興味が沸かないのだった (スコア:3, 興味深い)
しゃれぬきに、今主流のGUIのスタイルの問題点のひとつは、ここにあると思います。
つまり、機能(を呼び出すボタンなど)の位置は、
ユーザが100%自由に変更/設定できるべき、なのです。
(そして設定をImport/Exportできる機能もね。)
が、なかなかそうなっていない。
位置の移動だけなら出来る奴も多いですが、
「ボタンになってるものをメニューにしてほしい」など、
種類まで乗り換えることを許しているものは、あまり見かけません。
仮にも次世代というならば、
単に固定的に位置の変更をする(つまり変更の決定権を相変わらずメーカーが持ち続ける)
のではなく、
そのへんの自由をユーザーにいかに委譲するか、を工夫してほしいものだと思います。
脱線になりますが、
昨日「Java Expoert #03」を読んで少しだけ感心したのが、NetBeansのアーキテクチャ。
いわくGUI構造などがことごとく「ファイルシステム」のように見えるようになってるのだそうな。
ということは、GUI部品を
$ mv hoge/fugaButton foo/bar/
とするだけでGUI構成(少なくとも位置)を変更できる、ってことでしょうかね？
だとすれば画期的。
＃Eclipseは…EclipseMonkeyを使ってもDOMで事前に苦労する必要は相変わらず必要なので、かなりいまいちかも。
Re:個人的には何故かまったく興味が沸かないのだった (スコア:1)
できるのが良いか悪いかといったら良いだろうけど、それとは別に初期配置の問題と教育の問題、そして「ほとんどの人はデフォルトのまま使う」という点が挙げられます。
その結果、「変えられることよりも初期配置がどうなっているか」「再教育は不要で済むか」の二点がクローズアップされることとなります。
普通の人は鋏で紙を切りたいのであって、鋏のグリップを自分好みに改造する手間なんてどうでもいいんですよ。
より細かい言い方をするなら、普通の人は mv の現存する使い方を覚えて使うだけで、mv のコマンドラインパラメータを独自改造するのは極めてこだわりがある人だけです。
さらに言えば、教育環境/利用環境の標準化という点を考えると、逆に「変更できないようにすること」も重要になりますね。
つまり Visual Studio 位なら大満足ってことですね。
# import/export を含め、挙がってるものが全部可能ですね。
設定ファイル上にあるデータを fs 上に出しているだけですから、項目群とは別に位置、表示順序などの情報を別途管理するファイルなどが必要になりませんか? 結局全部を fs 上に置くことは難しいように思います。
ファイル名を元に項目を決定している、と考えると各 GUI 部品の位置情報をそのファイルに持たせることができるようになり、ファイル名を変更するだけで機能を変更できるようになりますが、やはり位置情報の整合性などを取るという点では問題が出そうです。また、ディレクトリによりメニューやツールバーなどの GUI 部品を表す形にすると、やはりディレクトリレベルでの位置や表示順序の情報が必要になりますね。
その辺りをまとめて、全部 XML とかに突っ込んだ方がセンスがいいように感じますが、どうでしょうか。
Re:個人的には何故かまったく興味が沸かないのだった (スコア:1, 興味深い)
IE7で、「戻る」「進む」「アドレスバー」「更新」「中止」「検索バー」の順に並んでいる段を変えたいのですが…。
具体的には「戻る」「進む」「更新」「中止」「アドレスバー」の順番にして、検索バーはコマンドバーと同じ位置に置きたいのです。
素のIE7では私のスキルでは出来ませんでしたから、現在はIEコンポーネント系のブラウザ（フリーソフト）を使用しています。
Re:個人的には何故かまったく興味が沸かないのだった (スコア:1, 参考になる)
軽くて安定していればそれでOK。
IE7に上げて要らん機能を付けてドツボにはまるだけのメリットがIE7にはない。
Re:個人的には何故かまったく興味が沸かないのだった (スコア:1)
でもMS曰く、IEはWindowsの一部で、不可分なものだそうですから。
IEを変更した副作用でOSの挙動や速度に悪影響を与えるのは、
IEの設計ミスだと私は考えます。
どっちだ (スコア:1)
と言っておきながら
「可能性としては 2010 年にずれ込む事も」
って矛盾してません?
まぁ「どちらも可能性がある」と思うのは完全に矛盾している
とまでは言いませんけど、違和感は感じます。
Re:どっちだ (スコア:3, すばらしい洞察)
by 鈴木敏夫 (スコア:2, すばらしい洞察)
本当にXP版は出るのだろうか (スコア:1, 興味深い)
RCは第一四半期ですから間に合うと思いますが、正式版はWindows DefenderのWindows 2000サポートと同様、容赦なくWindows XPでのサポートを切られたりしないのでしょうか。そうなると事実上2014年までIE7のバグとつきあう羽目に…。
Re:本当にXP版は出るのだろうか (スコア:1)
どちらにしろ・・・・ (スコア:1, 参考になる)
シェアが大きいため、対応せざる得ないけど
悲しいのでAC
IE 7, IE 8 betaと試しましたが (スコア:1)
IE 6で普通に見れていたのにIE 7だとよく行くサイトのレイアウトが崩れてしまったため、
IE 8ではどうだろうと、IE 8ベータを試したことがあります
結果は、結局崩れっぱなしでした orz
IE 6モードも欲しいなぁ。
早かろうが、メモリ少なかろうが見たいサイトの表示がちゃんとできないならしばらく使う気にならないですね。
# yes, fly. no, fry.
Re:IE 7, IE 8 betaと試しましたが (スコア:3, すばらしい洞察)
IE6の独りよがりな改竄仕様が異常なんだし。
なお、ＩＥ８のデフォルトはmozillaと同じ標準的なHTMLのモードです。
Re:IE 7, IE 8 betaと試しましたが (スコア:1)
IEを使う最大の理由は互換モードが残っていることだと思うし。
Re:IE 7, IE 8 betaと試しましたが (スコア:1, 興味深い)
そんなに大量にヤバイ表示のサイトがあるの？
Re:IE 7, IE 8 betaと試しましたが (スコア:1)
問題は特定のユーザーを対象にしたサイト、特にイントラネットのサイトですね。クライアントは Windows XP + IE6 決め打ちで問題が無い...という時期が長く続いてしまいましたから。
残念ながら IE8 に搭載される後方互換機能は、IE5 互換モードとIE7 互換モードで、IE6 を忠実に再現するモードは無いようですね。
Re:IE 7, IE 8 betaと試しましたが (スコア:3, すばらしい洞察)
結局悪いのはIE6仕様にあわせてサイトを構築している所だと思います。
そういうサイトを構築している人（デザイナ、エンジニア）が不勉強なのか、スキル不足なのか、ものぐさなのか、或いはそれ以外の要因（政治的圧力等）で表示出来ていないだけでして、本来ならどのブラウザでも正しく表示出来るようなサイト作りをすべきなんですよ。
Webサイトは、IE6で正しく表示出来るからOKなんじゃなくて、どのブラウザで見ても正しく表示出来るってのが本来系ですよね？
でもこれまでの経緯から、IE6でだけ正しく表示出来ればOKみたいなサイトは相変わらず多いんだろうなぁ。
正しいHTMLとCSSを使っていないからこーゆー結果になるんでしょうねぇ……。
＃でも、正しいHTMLとCSSを使ってもブラウザごとに微妙に違ったりするから困るんだな、全く！
Re:IE 7, IE 8 betaと試しましたが (スコア:3, 興味深い)
例えば、「IE5.5と6、Fx2と3に対応してください」といわれたら、つくる側はそのブラウザを中心に表示テストを行うというのが基本になると思います（一応OSごとの確認もとります）。
本当はその「どのブラウザでも正しく表示出来るようなサイト作り」をすべきなんでしょうけど、そこは予算や期間の都合もあるわけで。その開発に無限のリソースを割けるなら良いのだけど、現実にはそうもいきません。多くの場合、その時点（要件定義の段階）で最も利用されているブラウザが対応対象になります。
実際、IE6はWindows XPのデフォルトブラウザですから、今でもそのシェアはかなり大きいです（ライトユーザはデフォルトブラウザをわざわざ変えませんからね）。ゆえに多くの顧客はIE6への対応を求めてきます。HTMLやCSSの標準に従ってサイト構築してるのにバグ票切られるわけで、本当はWeb標準に対応したいけど、IE6などのブラウザ独自の仕様（バグ）にもあわせなきゃならないというのは、Webつくってる人が一番泣いてるところじゃないですかね。
つくる人はつくる人で、ブラウザごとにCSSハックしたりJSで無理やり対応したりと、いろいろ苦労しているのです。
ま、平和ならそれでいい...
Re:IE 7, IE 8 betaと試しましたが (スコア:2, 興味深い)
客にはもちろん客が要望したブラウザにしか対応しないと言いますが、実際にはどのブラウザでも対応するように作りますよ。客が要望してきたらテストを増やす(必要ならブラウザ別のhackを追加する)だけです。その分の金はもらうわけですし。どのブラウザでも対応するように作るのは結果的に自分が楽するためです。
そもそも世の中にブラウザは無数にあるのですから、すべての対応ブラウザでテストして動作保証するという方法論では「どのブラウザでも対応」することは不可能です。「IE7とFx3に対応」と言う場合の「対応」と同じ意味にとらえるのは発想から誤っています。
で、そういう立場から見ると他のブラウザにない動作をして個性を振りまいてくれるためわざわざ特別対応に工数を掛けなければならないのに「対応できません」と言うことのできない旧バージョンのIEはとってもウザいのです。
Re:IE 7, IE 8 betaと試しましたが (スコア:1)
って事なんですよね……orz
そーゆー現場で働いていたので良く分かります。
傾向的に社内向けWebシステムですと固有のブラウザ準拠みたいな事を言う人が多かったですね。
逆に外向けのWebシステムの場合は、クロスブラウザ対策をとれって言う人が多かったです。
本来的には社内向けだろうと外向けだろうとクロスブラウザで動くようなシステム作るのが技術屋としてのプライドなんでしょうけど、プライドではメシは喰えません。
なので、当時は泣く泣くIE専用のコード書きました。
＃一番泣いたのが、JavascriptとCSSですかね。
微妙な差異にこだわらなければいい (スコア:2, すばらしい洞察)
「微妙に違う」くらいは構わないんじゃないですか？
HTMLでは文書の要素を適切にマークアップし、スタイルシートで見え方を提示するというのがHTML/スタイルシートという枠組みで想定されているありかたです。「正しい見え方」を定義して、あらゆる環境でそれが達成されるようにする、というのは不毛なやり方に思えるし、実際不可能です。たとえば、「Firefox 2.Xで正常に表示できる」などといったところで、ブラウザの設定やユーザスタイルシートの適用によって、いくらでも違った表示状況があり得るからです。
Webアプリケーションの画面は「文書」じゃないので、これが現実的な考えでないことは分かっています。でもUI要件をこのくらいに押しとどめれば、もっとずっと楽になるのになーと考えたりします。
迷走中 (スコア:1, 参考になる)
FireFox+IE TABの構成で
基準の準じているページならFireFoxでおかしなページはIE6のレンダリングにしていますが
これに勝るものはないんじゃないですかね？
MSは結局おかしな仕様ならそのまま通すべきだし中途半端に修正するだけ無駄な気がしますけど
迷走中かどうかは知らないが、早くまともなブラウザを出してくれ (スコア:1)
IE6で開発を停止するわけにもいかないでしょう。
もちろん、MicrosoftがFirefox+IE TABなんて奇妙なことを推奨する訳にもいきませんから
IEに標準的なレンダリングエンジンを積む必要があるわけです。
しかし、そう簡単に作れなかった-というよりVistaに足並みをそろえる形で出したので中途半端な物が出来てしまったのではないでしょうか？
Microsoftなら自前でテストユーザやデバッガなども用意できそうなので、時間さえあれば完成度の高いブラウザを(中間バージョンなしで)作ることも出来るんでしょうけど
また、IE8は標準モードとIE7互換モードをユーザがスイッチで切り替えられるので
Firefox+IE TABと同じ解決策をとっているようですね。
#確かにIE7互換モードよりもIE6互換モードの方が良かったのかもしれない。
IE6専用サイトを早く追い出して欲しい (スコア:1)
できればへたに互換対応したりせず、すっぱり切り捨ててサイト側に対応を迫るように。
IE7が出てからもうずいぶんたつわけで、そろそろ切り捨てても良いんじゃないかと思うんだけど……。
しもべは投稿を求める →スッポン放送局がくいつく →バンブラの新作が発売される
やっちゃったまかふぃー？ (スコア:1, すばらしい洞察)
（事実関係は確認しておりません）
# ユーザーは移行できない原因を、MSのUI設計と、非対応サイトになすりつけ
# サイトは対応できない原因を、MSの中途半端なエンジンと、依然移行しないユーザーになすりつけ
# MSはうまくいかない原因を、ユーザーからの要望と、かつてのIEべったり仕様なサイトになすりつけ
Re:やっちゃったまかふぃー？ (スコア:1)
怖いですか？ MS的にはMFCにCHtmlViewやCDHtmlDialogというクラスを用意している程度には、普通の使い方ですが。
Norton AntiVirus 2005でもメインウィンドウにInternet Explorer_Serverな子ウィンドウが張り付いていたりしますし、オプションダイアログに至ってはほぼ丸ごとです。最近のバージョンではどうなのか知りませんが。