  |
はてなキーワード: ie8とは
> 「IE8は別料金！」って張り紙しておいてもダメなの？
テキストエディタが秀丸推奨。というかエディタに金を出してくれない。
OSSのエディタが増えてきたにも関わらず、意識低いので秀丸メインが多い。
前述の通りようやくSVNが導入されたけれども、Githubの提案は「英語で使いづらい」という理由で却下。
総務だろうと何だろうと全社員がrootで見ようと思えば見られる状態。
性善説に頼りすぎだろ。
ReactやAngularJSといったモダンなものは難しいという理由で俎上にすら乗らない。
既に開発が打ち切られたjQueryプラグインなんかを当たり前のように使う。
当然開発が打ち切られてるもんだから最新版のjQueryでは動かない。
結果、特定プラグインを動かすためだけに複数バージョンのjQueryを読み込ませたりする。
にも関わらず「何で遅いのか」と問題になったりする。
コード見ろよ。
Slackやチャットワークはおろか、Skypeなども使われていない。
受信するメールの量が多いため当然取りこぼしも増える。
当たり前のようにIE8対応が仕様書の必須要件に含まれている。
最新ブラウザ以外の対応に別料金でも取ればむしろ工数と金になるものを、無知なので最低要件に含めてしまう。
何度言っても理解しない。
もちろん、別にこれがダメってわけじゃない。いやダメなのもあるけど。
「これ使えてるだけまし」って人もいるかもしれない。
ただ、数え役満っていうのかな、技術力の低さがインクリメントされていって、現状の「技術に明るくない我が社」を作ってるように思う。
自分が少しずつ会社を変えていけばいいのはわかるけど、決定権持ってる人間が技術に明るくないと、枯れた技術がいよいよ朽ち果てる寸前まで現状をよしとする。
それが、うちの会社。
気がついたら「まともな技術持った人」が全員辞めていた。
里見へ
この手紙をもって僕のHMTLコーダーとしての最後の仕事とする。
まず、僕のHTMLソースを解明するために、Another HTML-lint 5に構文チェックをお願いしたい。
以下に、html5についての愚見を述べる。
html5対応を考える際、第一選択はあくまでIE8非対応であるという考えは今も変わらない。
その場合には、html5shiv.jsを含むIE8対応が必要となるが、
残念ながら未だ満足のいく成果には至っていない。
これからのhtml5の飛躍は、IE8非対応以外の対処法の発展にかかっている。
僕は、君がその一翼を担える数少ないHTMLコーダーであると信じている。
君にはhtml5の発展に挑んでもらいたい。
遠くない未来に、IE8対応による死がこの世からなくなることを信じている。
ひいては、僕の屍を構文チェッの後、君の研究材料の一石として役立てて欲しい。
屍は活ける師なり。
もうPC向けWebブラウザは、進化する余地がないのか、停滞しているように思えてしょうがない。
IEはともかく、FirefoxはデザインをChromeにしちゃったし(あれのどこがいいのやら)、Chromeに至っては、停滞どころか悪化しているとさえ感じる。
IE8になってようやくWeb標準に従うようになって、IE9でJavaScriptが劇的に速くなり、IE11でかなりWeb標準の準拠度が改善された。
また、Windows XPのサポート終了により、IE6というWebデザイナーの多数を地獄送りにしたブラウザから完全に脱走できるようになった。
しかも、サポートポリシーが変わって、2016年1月以降は各OSで最新のバージョンしかサポートしないと決まったため、思ったよりも早くWebデザイナーの苦痛が取れるようだ。IE6で懲りたんだろうか。
しかし、IEコンポーネントブラウザの互換性を軽視する傾向にある。
IE10では、Windows7の必須アップデートのせいで画面描画が乱れる場合があったり、特定のWebサイトでIEコンポーネントブラウザをフリーズさせるという必殺技を披露した。
IE11では、一部環境でDOMストレージが原因でブラウザコンポーネントを十数個開くとフリーズする新必殺技を披露した。(現在、バグ修正済)
次のIEでは、どんな技を披露してくれるのだろうか。
Chromeをパクってと同様、高速リリースサイクルになって3年目。
アドオンの互換性に悩み、自ら失敗といいつつも、高速リリースサイクルを何とかやっていけてるようだ。
シングルプロセス/マルチスレッドながら省メモリとJavaScriptの速度チューニングを着実に行っている。
つい先日、australisというChromeのパクリに非常によく似たUIを強制適用し、一部ユーザーから顰蹙を買う。
高速リリースサイクル、強制アップデートを流行らせた元凶。
Chromeは初期設計のポリシーがよく、HTML5の準拠度とブラウジングスピードは今でもよい。
登場からあっという間にシェアを獲得し、主要ブラウザと呼べるほど有名に。
しかし、バージョンが上がるたびに肥大化し、メモリ消費量がますます増え続け、低スペックマシンでは重くなる一方である。
レンダリングエンジンがWebKitから独立してBlinkになったが、さらに迷走していく。
ユーザーが阿鼻叫喚した、ウィンドウシステム共通化プロジェクト。
理想は、各種コントロール(スクロールバーやボタン、エディットボックスといったもの)を全プラットフォームで共通化した上で、GPUによる描画で高速化する・・・ということだった。
Windows版ではバージョン32から適用された。しかし、安定版になってもスクロールバーの矢印が消えた、汎用マウスジェスチャが使えない、
縦/横スクロールがまともに動かない、Webフォントが描画されないなどなど、多数のバグが残存していた。
今でも、バージョンが上がるにつれて改善されたものもあれば、一度改善していたのに不具合が再発するなど、安定版といいつつ安定しない日々が続いている。
いったい、「安定版」とは何なのだろうか。
最近、ChromeはGoogleのものであることをユーザーにしらしめる努力ばかりやっているのではないか。
Google Nowなど、自社のサービスを便利に使うために機能追加するのは別にかまわないが、新しいタブページの異常にでかいGoogleロゴはどうだろう。
よく開くページのサムネイルを小さくし、下に追いやってまでGoogleロゴを目立たせる必要はあったのだろうか。
今年中にNPAPI廃止を目論んでいるが、それは現実的なのだろうか。
Chrome独自に持っているPPAPIは、セキュリティが厳格なゆえにNPAPIの代替手段には決してなりえない。少なくとも、PPAPI上で動くFlashがNPAPIのそれと同等の速度で動かない限り、廃止はありえないと思う。
Firefoxが高速リリースサイクルを採用した初期の時のように、高速リリースサイクルを優先するあまり、品質を犠牲にしているケースが目立っている。
最近出た37では、DirectWrite周りの実装がお粗末で、安定版が最初に出たころはズームイン/ズームアウトするだけで文字が表示されなかった(翌日に修正)。今でも、ビットマップフォントの表示品質がGDIよりも悪い。
高速リリースサイクルの弊害が現れているのではないだろうか。このことに、Chromiumの中の人たちは、気づいているのだろうか。
去年、姉が結婚したついでにPCを新調してたんだけれど、「旦那がIEは遅いからって別のソフトを入れてくれたんだけど、使ってみた感じ全然違いが分からないからIEそのまま使い続けてる」と言ってたな。
以前何かの記事で読んだが、2chを見てる人は圧倒的に三十代以降の男性が多いらしい。
この層がPCを購入した時期的に、XP率が高く、ウェブブラウザを選ぶ程度のリテラシーがある(ので他のブラウザと比較してIE8が相対的に"遅い"のを理解してる)けど、IE9～10(11)を知らない(IE8と同程度だと勘違いしてる)、という条件に合致してるように思う。
IE9はIEセントリックからスタンダードセントリックへのブリッジリリース。新しい(Windows)APIを積極的に利用するようコアは一新された。JSエンジンを分離して新規開発した初のバージョンでもある。
（代わりに後方互換性を失った）
IE8はIE神話最後の鬼子。地獄の袋小路。互換表示でも使われないまさに袋小路。
IE7はIE6の成功を拡張しようとした外面優先アップデートリリース。内部的には順当な更新。
IE6はIE5のラインを引き継いでコアとなるTridentエンジンが当時（12年前！）としてはモダンは32bit APIだけで動く決定版。
IE11でとうとうQuirksモードを捨てて、デフォルトでEdgeモードでレンダリングするようになったため、
ヘンなDOCTYPE指定でいままでQuirksモードでレンダリングされてたたくさんのいいかげんなサイトに細かい不具合がでてる。
どこ相手にしてるかで違うけれど、モバイル向けで怖いのはiOS4.x（まだいる！）とAndroid 2.x。WindowsPhone7.5の方がまだ楽。
通常サイトで一番怖くて面倒なのはIE5.2 for Mac。今年になっても利用者の存在を確認して愕然とした。Safari 3も怖いけど。
6まで対応なら2倍
としたい
あとクライアント側には「新しいものに対応するほうがコストかかる」と思ってる人がいるのも問題
IE6に対応するのは、同じもの作るのに原始時代と現代の道具で作るような差があるってことなんだけど
古いほうが簡単なんでしょ？って思ってる人が結構いる
開発側です。
IE10 はさほど問題ないんです。IE10 でやっと標準に追い付いてきたという感じ。問題は、IE 使ってるようなユーザーはアップデートしないという事実です。
スクリプトなどの実行の早さは、IE8 位までは数倍のオーダーで遅く、マップ上にたくさんのオブジェクトを表示するようなものを作ると、IE の速度面対応だけで大変でした。
それよりも問題なのが、Web の標準に対応していないことです。
CSS3 や HTML5 への対応は、他のブラウザに比べて数年単位で遅れてました。Chrome か Firefox で開発しているとします。そのままテストすると Chrome Firefox Safari では問題ありません。IE だけ問題が、というのが普通でした。IE 対応だけで工程かかるのです。IE7 や 8 を視野に入れると、諦めざるを得ない技術もあります。たいていは擬似的に対応できるのですが (Canvas にライブラリで対応するなど)、そのために余計な工程がかかるのが問題なのです。ぶっちゃけ IE 切り捨てて、その時間を他に当てたほうがより良いものを安く早く作れるということです。
という感じになるので、IE8 以前を切り捨て OK になるだけで段違いですね。
しかし、最初に言ったように IE ユーザーはアップデートしないんですよ。Chrome Firefox Safari が優れているというより、これらのユーザーはほぼ間違いなく最新版使っているのが一番のアドバンテージなんです。IE10 は IE 史上ではやっと他に並びかけるほどまともな標準対応になったので、IE 使ってる人が全員 IE10 ならこれほどネタにされることもなかったと思います。
開発側はこうした IE によるストレスを日々受けているので、擬人化や IE 死亡のようなネタになると祭りになりやすいのではと思います。
http://linux.ohwada.jp/modules/smartsection/item.php?itemid=515
http://0xcc.net/pub/webdb/bk-05.html
などのまとめが素晴らしいね
最近のブラウザはほとんどRFC2231に対応しているみたいだ
IEは，8になってもまだ対応してなかったのかよ！ とか Safariは未対応かよ！ という突っ込みはあるけどね
それと，自分の環境で確かめられる範囲でさきほどの投稿の表をもう少し充実させてみたよ
| 生utf8 | 生sjis | url_encode(utf8) | url_encode(sjis) | RFC2231 | |
| chrome24 (win7-64bit) | ok | x | ok | x | ok |
| firefox18 (win7-64bit) | ok | x | x | x | ok |
| IE9 (win7-64bit) | x | ok | ok | x | ok |
| firefox18 (MacOS X) | ok | x | x | x | ok |
| Opera | ok | x | x | x | ok |
| Safari5.1.7 (MacOS X) | ok | ok | x | x | x |
| IE8,7,6 | x | ok | okだけど長いファイル名× | ? | x |
RFC2231対応状況全般と，IEの8,7,6とOperaについては参考ページからの情報を使っているよ
それと，参考ページと私の調査でSafariの生SJIS対応の結果が矛盾しているんだけどどうしよう・・・バージョンの違い？
案は２つあるよね
案１）
案２）
Rails3でRFC2231準拠のやり方がよくわからないので，Rails3のsend_file関数で日本語ファイル名を使うなら案２が無難かな
何が凄いかって、荒らすエネルギーが半端じゃない。IE8を画面一杯に格子状に10個くらい並べて開いて、書き込み終わったら速攻で×ボタン押して閉じて、またIEのアイコンダブルクリックしてブックマークから別の荒らし対象サイト開いて書き込み開始。
これを数時間、下手すれば一晩中ぶっ続けでやったりしてる。キーボードを叩く音が、数秒と途切れる事なく延々と続く。そして「電池が切れる」と、24時間ぶっ続けで眠り続けたりしてる。ブックマークの数は三桁オーバー。勿論、本人には荒らしている自覚は微塵も無い。
