ラベル ie の投稿を表示しています。 すべての投稿を表示
ラベル ie の投稿を表示しています。 すべての投稿を表示

2013年12月14日土曜日

IEのバージョン別の X-Content-Type-Options: nosniffの対応状況

IE8以下は内容がHTMLっぽいとHTTPレスポンスヘッダ‐のContent-typeに関わらず、HTMLとしてレンダリングしてしまう。
IE8はnosniffをつければ、Content-typeに従う。

参考: X-Content-Type-Options: nosniffの効果を確認してみる | UCWD-Studio.【ホームページ制作 / 京都】


PHPの実験用コード

<?php header('Content-type: text/plain') ?>
<script>alert(1)</script>


IE9以降およびChrome・Firefoxなどは、nosniffがある場合はJavaScriptやCSSの外部ファイルのContent-typeが妥当でないと、その外部ファイルは読み込まない。

参考:
X-Content-Type-Options: nosniff の効果 : swdyh
MIME タイプのセキュリティ リスクの軽減 (Windows)

2013年12月10日火曜日

今どきのHTTPヘッダーによるセキュリティ向上の調査メモ

今夜つける HTTPレスポンスヘッダー (セキュリティ編) - うさぎ文学日記の中で、よく知らなかったヘッダーについて調べたメモ。

いくつかのヘッダーについてのブラウザ別のサポート状況はこちら。
(ちょっと古いが、少なくともこれ以降のバージョンではサポートしているということは分かる。)
↓
IPA ISEC セキュア・プログラミング講座:Webアプリケーション編 第8章 マッシュアップ:クライアントサイドマッシュアップ: #4 対策に利用できる技術


X-XSS-Protection

IE8以降のXSSフィルターはデフォルトで有効になっている(ブロッキングモードではない)。
↓
Security through HTTP response headers

[IEInternals] XSS フィルターを制御する | Hebikuzure's Tech Memo

Internet Explorer 8 には、XSS フィルターとして知られている、反射型クロスサイト スクリプティング攻撃を防止するのに有効な画期的新機能があります。このフィルターは既定ではインターネット ゾーン、信頼済みサイト ゾーン、制限付きサイト ゾーンで動作します。

オフにしている人や、XSS on XSS Filterに備えて、ブロッキングモードで有効にさせるのが無難?
X-XSS-Protection: 1; mode=block


Content-Security-Policy

(参考)Content Security PolicyでXSSを断ち切る | monoの開発ブログ

インラインリソースは'unsafe-inline'で許可できる。
dataスキームURIには"data:"で許可できる。
↓
An Introduction to Content Security Policy - HTML5 Rocks

IEがほぼサポートしていないようなので、効果は限定的か。
↓
CSP policy directives - Security | MDN
CSP is quite usable in Chrome 16+, Safari 6+, and Firefox 4+, and has (very) limited support in IE 10.

セキュリティとしては非常に強力だが、ホワイトリストのメンテが面倒なので外部リソースを気軽に使うようなサイトでは使うのは難しい?

あるいは、こんな風に思いっきり緩くしておくか?(これだと意味がないか...)
Content-Security-Policy:
default-src 'self';
script-src 'unsafe-inline' *;
img-src data: *;
frame-src *;
font-src *;
style-src 'unsafe-inline' *;
report-uri /csp-report.php

見やすくするために改行している。未検証なので取扱注意。
faviconはimg-srcに含まれる。
違反が見つかったら、report-uriにJSONでPOSTされる。
eval()が必要なら'unsafe-inline'も追加する。

Content-Security-Policy-Report-Onlyでチェックのみに使うのが良いかもしれない。


Strict-Transport-Security

IEが10でもサポートしていないことを考えると、これが効かない場合のリダイレクト等の処理も必要。
↓
HTTP Strict Transport Security - OWASP

2011年9月15日木曜日

画面をキャプチャするブラウザのプラグインいろいろ

ブラウザで表示している画面のスクリーンショットを撮るプラグインのメモ。



いずれも、Flashの領域もキャプチャできたし、画面全体をスクロールしてキャプチャする機能もあった。

画像形式は「キャプチャー イット!ツールバー」はJPEG、それ以外はJPEGかPNGから選べる。

Google Chromeの2つは、キャプチャ直後に新しいタブが開き、そこでキャプチャした画像の編集ができる。そのまま1クリックで印刷もできるので、画面イメージを印刷する用途には便利。
でも逆に、ファイルとしてどんどん溜めていきたい場合には毎回タブで開くより「キャプチャー イット!ツールバー」のように黙々とフォルダに画像ファイルを保存して行ってくれた方が便利かも。(「Screen Capture」の方は、設定でそうすることもできる。)

Chromeの「Screen Capture」以外は日本語化されていた。


ブラウザのプラグインではないけど、JTrimは画面キャプチャから画像の加工までできて便利。

2011年9月9日金曜日

IEのバージョンと互換モードによる @_jscript_versionの値の違い

IEのJavaScript(正確にはJScript)でのみ使える、「条件付きコンパイル変数」の1つであるJScriptのバージョンを表す@_jscript_versionについて、IEの各バージョン、各モードでどんな値になるか調べたのでメモ。


  • IE10 PP2
    • 通常モード:10
    • 互換モード:10
      • IE5~10の全ての"Force IExx Document Mode"で試したが、全て10だった
  • IE9
    • 通常モード:9
    • 互換モード:9
      • 開発者ツールでブラウザーモード、ドキュメントモードを変えても、全て9だった
  • IE8
    • 通常モード:5.8
    • 互換モード:5.8
      • 開発者ツールでブラウザーモード、ドキュメントモードを変えても、全て5.8だった
  • IE7
    • 5.7らしい(未検証)
  • IE6
    • WinXP SP3以降:5.7
    • WinXP SP2以前:5.6らしい(未検証)


@_jscript_versionは互換モードかどうかに関係なく、JScriptのバージョンになる。


参考

2011年8月23日火曜日

各ブラウザのconsole.log()実装状況


Firefox以外のモダンブラウザは、標準で装備していた。

ブラウザ調査した
バージョン
ログの表示方法その他
IE8ツール
↓
開発者ツール
↓
「スクリプト」タブ
IE8以降で搭載。
String型にCASTされて出力される。
(Objectの中身は見られない。)
Firefox6.0アドオンのFirebugを使う


Chrome11.0ツール
↓
JavaScript コンソール
↓
「Scripts」タブ

Safari5.1ページのメニューボタン
↓
開発
↓
JavaScriptのデバッグを開始
↓
「コンソール」タブ
Windows版で確認。
Opera11.50Operaボタン
↓
ページ
↓
開発者用ツール
↓
Opera Dragonfly
バージョン11から搭載。
ObjectやArrayの中身は見られない。
CSS等のエラーとごっちゃに出るので見辛い...


所感
  • SafariやOperaはコンソールの表示方法が分かり辛い。
  • IEやOperaはObjectの中身を見られない(Operaは配列の中身も見られない)ので使い辛い。
  • Operaは他のエラー(CSS等)と一緒に出力されるので見辛い。


参考

2011年5月2日月曜日

IEの互換表示は印刷プレビューにも適用される

IEでアドレス(URL)欄と更新ボタンの間にある互換表示ボタンをクリックすると、下位バージョンのIEでの表示モードになる。(IE8の場合、IE7での表示になる。ただし厳密に言うと同じではないらしい。ほぼ同じだが。)

で、互換表示にした時に印刷プレビューについても互換表示が適用されるかどうか調べた。


調査に使ったHTML
IE8モード(以上)の場合「IE8」、IE7モード(以下)の場合「IE7」と表示される。

<!DOCTYPE html>
<html lang="ja">
<head>
<meta charset="UTF-8" />
<title>Which are you?</title>
<!--[if lte IE 7.0]><style> #ie8 { display: none} </style><![endif]-->
<!--[if gte IE 8.0]><style> #ie7 { display: none} </style><![endif]-->

</head>
<body>
<div id="ie7">IE7</div>
<div id="ie8">IE8</div>

</body>
</html>

結果
画面表示と同様に、印刷プレビューにも互換表示が適用された。

また、印刷プレビューと印刷で異なることは少ないので、おそらく印刷についても互換表示が適用されると思う。
細かいCSSの適用とかはどうなのかな。

2011年4月19日火曜日

Google Font APIはどうやってマルチブラウザ対応しているのか

WebFontsを読み込む場合のCSSの書き方はブラウザごとに異なるため、こんなsyntaxを使う必要がある。
しかし、Google Font APIで読み込むCSSをではそんな書き方はしていない。
そこで、試しにTangerineのCSSを各ブラウザで読み込んでみて、Google Font APIがどのようにマルチブラウザ対応をしているのか調べてみた。


IE 8

@font-face {
  font-family: 'Tangerine';
  font-style: normal;
  font-weight: normal;
  src: url('http://themes.googleusercontent.com/font?kit=HGfsyCL5WASpHOFnouG-RPY6323mHUZFJMgTvxaG2iE');
  src: local('Tangerine'), url('http://themes.googleusercontent.com/font?kit=HGfsyCL5WASpHOFnouG-RD8E0i7KZn-EPnyo3HZu7kw') format('woff');
}
URLはIE専用。
2行目のsrcはIE9用?


Firefox 4
@font-face {
  font-family: 'Tangerine';
  font-style: normal;
  font-weight: normal;
  src: local('Tangerine'), url('http://themes.googleusercontent.com/font?kit=HGfsyCL5WASpHOFnouG-RD8E0i7KZn-EPnyo3HZu7kw') format('woff');
}
URLはChromeと同じ。


Chrome 10
@media screen {
@font-face {
  font-family: 'Tangerine';
  font-style: normal;
  font-weight: normal;
  src: local('Tangerine'), url('http://themes.googleusercontent.com/font?kit=HGfsyCL5WASpHOFnouG-RD8E0i7KZn-EPnyo3HZu7kw') format('woff');
}
}
URLはFirefoxと同じ。
@mediaでscreenだけにしているのはAndroid対策か何かか?


Safari 5 (for Windows)
@font-face {
  font-family: 'Tangerine';
  font-style: normal;
  font-weight: normal;
  src: local('Tangerine'), url('http://themes.googleusercontent.com/font?kit=HGfsyCL5WASpHOFnouG-RKCWcynf_cDxXwCLxiixG1c') format('truetype');
}
URLはSafari用(Operaと共通)。アンダーバーで区切ってるのはiPhone用(iOS用?)が別にあったりするためか?


Opera 11

@font-face {
  font-family: 'Tangerine';
  font-style: normal;
  font-weight: normal;
  src: local('Tangerine'), url('http://themes.googleusercontent.com/font?kit=HGfsyCL5WASpHOFnouG-RKCWcynf_cDxXwCLxiixG1c') format('truetype');
}
URLはSafariと同じ。OperaもTrueType組。


まとめ
おそらくUser-Agentで判断して振り分けているだけのようだ。
フォントファイルは大きく分けると下記の3つに分かれるようだ。
  • IE8-
  • IE9+、Firefox、Chrome
  • Safari、Opera


参考:Webフォント (Webfonts)を使う際の最新記述方法 Fontspring Syntax (The New Bulletproof@Font-Face Syntax) - フォントブログ

2010年11月21日日曜日

PHPで 「Webページの有効期限が切れてます」となる時の傾向と対策

PHPでフォーム等を作った場合、Webブラウザの戻るボタンやJavaScriptのhistory.back()で前のページに戻った時に「Webページの有効期限が切れてます」と表示されることがある。

上記はIEの場合で、ブラウザによって少し挙動が違う(下記)。
いずれもページを更新(リロード)するとサーバにPOSTが再送信され、ページが表示される。
  • IE
    • 上記(IE8の例)のような画面が表示される。
  • Firefox
    • 「このページを表示するにはフォームデータを再度送信する必要があります。フォームデータを再送信すると以前実行した検索、投稿や注文などの処理が繰り返されます。」という確認ダイアログが表示され、「再送信」ボタンと「キャンセル」ボタンが表示される。「再送信ボタン」をクリックするとページが表示される。
  • Chrome
    • 「フォーム再送信の確認
      このウェブページを正しく表示するには、先ほど入力したデータが必要です。データをもう一度送信することは可能ですが、このページで行った操作をすべて繰り返すことになります。データを再送信してこのページを表示する場合は [再読み込み] をクリックしてください。」というメッセージのみの画面が表示される。
  • Safari
    • このようなダイアログが表示される。(Windows版で確認。Mac版は分からない。)



犯人はだれだ?


原因は、PHPでSESSIONを使うと(デフォルト設定では)自動でキャッシュ制御用のHTTPヘッダーが送出され、それによりクライアント側のキャッシュが使用不可にされるため。(参考:floatingdays: PHPでブラウザキャッシュを有効にする)

つまり、下記条件を全て満たした場合にこの現象が発生する。
  1. HTTP POSTで遷移してきた。
  2. SESSIONを使っている。(session_start()してるか、php.ini等でsession.auto_start=1に設定している。)
  3. 次のページに行ってから、ブラウザの履歴機能(JavaScriptのhistory.back()を含む)で戻ってきた。



じゃあどうすればいいの?

対策として有名なのは、session_start()する前に、session_cache_limiter('none')とすること。
session_cache_limiter('none');
session_start();
これにより、SESSIONを使っても余計なHTTPヘッダーが送出されなくなる。

または、php.ini等でsession.cache_limiterに"none"を設定しても同じことになる。(おそらく元ネタはこのあたりだろう → PHP: session_cache_limiter - Manual )

実際にこれで問題は解決する。



異論反論オブジェクション! [shut very bad!]

しかし、「PHP/「ページの有効期限切れ」対策 - Glamenv-Septzen.net」によると、これはPHPが想定しているパラメータではなく、お行儀のよいやり方ではないらしい。

'none'というパラメータは正しいパラメータではなく、それゆえに何もHTTPヘッダーを送出しないという挙動になるらしい。
(ただし、もし「規定外のパラメータはスルーする」というのが意図した仕様だとしたら、'none'でも何でも「正しいパラメータ」だけど。)

上記の記事ではsession_cache_limiter('none')ではなくsession_cache_limiter('private_no_expire')を推奨している。
「「ページの有効期限切れ」をsession_cache_limiter()で解決 - shinyanakaoのよすがブログ」でも同様にprivate_no_expireを推奨している。

しかし、実際にsession_cache_limiter('private_no_expire')を使うと、やはり余分なHTTPヘッダーが送出される。

private_no_expireの場合、(privateに比べて)Expiresが送出されなくなるが、「Cache-Control: max-age=(session.cache_expire ぶんだけ未来)」が送出されるため、やはりブラウザに影響が出てしまう。(参考:現在のキャッシュリミッタを取得または設定する - PHP 5.3 日本語マニュアル)
Firefoxでは問題ないが、IEだとリロード時にもキャッシュを使ってしまい、サーバからのリロードができなくなるようだ。(参考:Webアプリケーション開発ラボ by NPO情報活用センター - PHP:キャッシュ問題について。、PHP Tips|ワークスポット・ジェーピー)
おそらくsession.cache_expireで設定されている期間はキャッシュが有効になるのだろう。(Expiresでそう指定しているのだから、IEは悪くない。)

なので、お行儀が悪くてもsession_cache_limiter('none')を使うしかないのでは?('none'じゃなくて'hoge'でも'hage'でも「正しい」パラメータ以外なら何でもいいけど。)



新たな選択肢

しかし、こういう手もあるよ。
session_start();
header('Expires:'); //下記「余談」の追記も参照
header('Cache-Control:');
header('Pragma:');

header()でセミコロンの右に何も書かないと、PHPは何も送出しないようだ。
これにより、session_start()のHTTPヘッダー送出を上書きし、結果的に何も送出しない。

session_cache_limiter('none')より冗長だが、明示的という意味ではいいかもしれないと思っている。
(キャッシュを有効にしたい場合にも応用が効く。)



余談

上記のようにブラウザキャッシュの無効化を無効化すると、当然ながらSESSIONの最新情報が反映されていないブラウザキャッシュをブラウザが表示してしまうので注意。

(2011/1/7 追記)
IEはキャッシュがあり、かつ、そのキャッシュがExpiresを何も指定されていないと、アドレスバーにURLを直接入力された場合やリダイレクトした場合などにサーバにアクセスせずにキャッシュの方を使ってしまう。(Firefoxはその場合もサーバにアクセスしてくれる。)
ブラウザの履歴機能を使うためにキャッシュはさせたいが、上記の場合にはサーバにアクセスさせたい場合は、Expiresで-1を指定すると良いようだ。
header('Expires: -1');
ログイン管理をする場合などはこれをやっておいた方が良さそう。
(追記終わり)

また、POSTのパラメータに「チケット」(=ワンタイムトークン)を入れることによる二重POST防止を推奨するのは正しい。というか二重POSTを確実に防ぎたいと思ったらこれしかない。


2010年6月7日月曜日

CSSによる背景色グラデーションのブラウザごとの書き方

例えば、上から下に白から青のグラデーションを表示したい場合はこう書く。(省略可能なパラメータは省略した。)

/* IE */
filter: progid:DXImageTransform.Microsoft.Gradient(StartColorStr=#ffffffff, EndColorStr=#ff0000ff);

/* IE8 */
-ms-filter: "progid:DXImageTransform.Microsoft.Gradient(StartColorStr=#ffffffff, EndColorStr=#ff0000ff)";

/* Firefox */
background: -moz-linear-gradient(white, blue);

/* Chrome, Safari */
background: -webkit-gradient(linear, left top, left bottom, from(white), to(blue));

IE8は右辺をクォートで囲う必要があるので注意。

IE以外は、詳細な指定をすれば複数の濃淡を指定できたり球状の効果を表現できたりと色々できる。

Operaは未対応らしい。


参考
IE:Gradient - filter,フィルタ
Firefox:-moz-linear-gradient - MDC
Chrome, Safari:CSSでグラデーションを表現する - builder by ZDNet Japan

2010年5月28日金曜日

JavaScriptによって動的に CSSを追加する場合のブラウザごとの挙動の違い


(2011/3/29追記:Firefox4とChrome10の実験結果を追加。)


JavaScriptに続いて、動的にCSS(またはstyle要素)を追加する場合の、追加方法の違いによるブラウザごとの挙動も調べた。


調査に使ったJavaScript(HTML5なのでtype属性は省略してある。)

window.onload = function() {
    // divのinnerHTMLに外部CSSの読み込みを突っ込む
    try {
        var div1 = document.createElement("div");
        div1.innerHTML = '<link rel="stylesheet" href="test1.css" />';
        document.body.appendChild(div1);
    } catch(e) {
    }
    
    // createElementでlink要素を生成して外部CSSを読み込む
    try {
        var link2 = document.createElement("link");
        link2.rel = "stylesheet";
        link2.href = "test2.css";
        document.getElementsByTagName("head")[0].appendChild(link2);
    } catch(e) {
    }
    
    // divのinnerHTMLに生のstyleを突っ込む
    try {
        var div3 = document.createElement("div");
        div3.innerHTML = '<style>#test3{ color: red }</style>';
        document.body.appendChild(div3);
    } catch(e) {
    }
    
    // createElementで生のstyleを追加する
    try {
        var style4 = document.createElement("style");
        style4.innerHTML = "#test4{ color: red }";
        document.getElementsByTagName("head")[0].appendChild(style4);
    } catch(e) {
    }
};

test1.css
#test1{ color: red }

test2.css
#test2{ color: red }


結果は下記の通り。

ブラウザ
1
2
3
4
IE 8
X
O
X
X
Firefox 3.6
O
O
O
O
Firefox 4.0
O
O
O
O
Chrome 4
O
O
O
X
Chrome 10
O
O
O
O
Safari 4
O
O
O
X
Opera 10.53
O
O
O
O


やはりIEではcreateElementで外部ファイルを読み込む方法しか動かない。
(ちなみに外部ファイルはhead要素でなくbody要素にappendChild()してもOKだった。)

でもChrome、SafariやOperaでほぼ動いたのが意外だった。


(2011/3/29 追記)
style 要素を動的に生成する - m2の方法を使えば、innerHTMLに生のstyleを突っ込むことができる。IE8、Firefox4、Chrome10、Opera11で動作することを確認した。

JavaScriptによって動的に script要素を追加する場合のブラウザごとの挙動の違い


(2011/3/29追記:Firefox4の実行結果を追加)


JavaScriptによって動的にscript要素を追加する場合の、追加方法の違いによるブラウザごとの挙動を調べた。


調査に使ったJavaScript(HTML5なのでtype属性は省略してある。)

<script>
function test(value) {
    document.getElementById("test").value += value + ",";
}

window.onload = function() {
    // innerHTMLに外部JSの読み込みを突っ込む
    try {
        var div1 = document.createElement("div");
        div1.innerHTML = '<script src="test1.js"><' + '/script>';
        document.body.appendChild(div1);
    } catch(e) {
    }
    
    // createElementでscript要素を生成して外部JSを読み込む
    try {
        var script2 = document.createElement("script");
        script2.src = "test2.js";
        document.body.appendChild(script2);
    } catch(e) {
    }
    
    // innerHTMLに生のJSを突っ込む
    try {
        var div3 = document.createElement("div");
        div3.innerHTML = '<script>test(3);<' + '/script>';
        document.body.appendChild(div3);
    } catch(e) {
    }
    
    // createElementで生のJSを追加する
    try {
        var script4 = document.createElement("script");
        script4.innerHTML = "test(4);";
        document.body.appendChild(script4);
    } catch(e) {
    }
};
</script>


test1.js
test(1);

test2.js
test(2);

処理が実行されたら、表示用のテキストボックス(id="test")に番号が表示される。

結果は下記の通り。

ブラウザ
1
2
3
4
表示順
IE 6/8
X
O
X
X
2
Firefox 3.6
O
O
O
O
1→2→3→4
Firefox 4.0
X
O
X
O
4→2
Chrome 4
X
O
X
O
4→2
Safari 4
X
O
X
O
4→2
Opera 10.53
X
O
X
O
2→4


innerHTMLにscript要素を入れるのはFirefox3.6以外では動かない。(セキュリティ的な施策?)
Firefoxでしか動作確認していないと嵌りそうだ。(というか嵌った。)

IEのことを考えると、生のcreateElementで生成したscript要素に生のJavaScriptを書くやり方も使えない。
(そんなことが必要になるケースは無いかもしれないが。)

素直にcreateElementで外部JSを読み込むのが良いようだ。


(2011/3/29 追記)
innerHTMLに生のJavaScriptを入れる方法としてinnerHTMLでscriptする - Thousand Yearsの方法があったようだ。
しかし現在のブラウザでは、IE8では動作したが、Firefox4、Chrome10、Safari5、Opera11では動作しなかった。

2010年5月8日土曜日

dataスキームによる画像を手軽に作れるジェネレータ

dataスキームはIE6・7は未対応。IE8から対応した。


グラデーション画像は、cyokodogさんが作った生成ツールが便利そう。
IEはfilterにより表現されるのでIEでも表示できる。



画像ファイルからdataスキームを生成したい場合は[JavaScript] dataスキームURI生成(画像データのBase64変換)が便利そう。


その他の場合でかつHTML5のcanvasで描けるような図形の場合、toDataURL() メソッド - Canvasリファレンス - HTML5.JPを参考にしならが自分で作る。

2009年11月6日金曜日

CSSフレームワーク YAMLと Highslide JSは相性が悪い

CSSフレームワークのYAMLとページ内ポップアップライブラリのHighslide JSを併用したら、IEで見た場合のみHighslideの表示がおかしくなった。

参考情報を探したが、ドイツ語しか見つからない...


結局解決していない?


具体的には、2カラムの右側(div#col3)にあるリンクをクリックしたらHighslideがポップアップするようにしたら、IEの場合だけ"Loading"の表示が画面の右の方にずれてしまう。
場合によっては画面の外にまでずれてしまい、その時だけ横スクロールバーが出るような状況に。

Firebug Liteなどを使って調べていたら、どうやらLoadingのCSSプロパティleftの値がおかしいらしい。
Highslideは、Loadingの位置を計算で求めている。
その際に、offsetLeftを積み上げてleftを計算する。積み上げるというのはリンクからoffsetParentをたどっていき、そのoffsetLeftの合計を求める。(scrollLeftの考慮もしている。)
で、このoffset系のプロパティは、ブラウザによって挙動が違うらしい。

実際にlinkのleftの計算に使われるoffsetParentとoffsetLeftを表示させてみると、Firefox(3.5)とIE(7)ではかなり内容が違う。
まずFirefoxの方はたどるoffsetParentが少ない。すぐにBodyにたどりつく。offsetに関連しない要素は無視するようだ。
対してIEはoffsetに関連しない要素も全部拾う。何が関連するかの判断もFirefoxとはかなり違う。
さらに、IEではdiv#col3の子要素のoffsetLeftの値がおかしい。
具体的には、div#col3の子要素は、正しいoffsetLeftの値に加えて、なぜかdiv#col3のoffsetLeftの値が加算されている。
これにより、LoadingのLeftがdiv#col3のoffsetLeft分だけ右にずれてしまうようだ。

ここで、上記の参考サイトを見て、div#col3のpositionプロパティを変えたらなんとなかるかなあと思い実験。
FirefoxのFirebugで調べたところ、div#col3はpositionを指定していないので、デフォルトのstaticのはず。
が、IEでFirebug Liteで調べたところ、なぜかrelativeになっている。IE用のパッチのCSSの影響?
そこで、div#col3のpositionにstaticを指定したら、Loadingがリンクと同じ位置に表示されるようになった。
(たぶん)position:staticの場合、offsetParentの対象でなくなるようだ。これにより、div#col3のoffsetLeftが重複して加算されることを回避できた。

2009年9月24日木曜日

PNGの画像を IE6で透過にするライブラリ調査メモ

IE6では透過PNGが透過しない。それを無理やり透過させてしまうJavaScriptライブラリを調べたメモ。





DD_belatedPNGが一番良さそうかな?


参考:
ITキヲスク | IE6で透過pngを表示させるオススメscript、「DD_belatedPNG.js」

Highslide JSでimage mapのリンクを扱う場合の注意点

Highslide JSは普通のリンクだけでなく、Image Mapのリンクでもページ内ポップアップができる。

しかし、IEで表示した場合、Image Mapのリンクをクリックすると下記の現象が起きる場合がある。

  • リンク(Image Map)の場所に関わらず、「Loading」の表示がページの左上に表示される
  • ポップアップ表示も、ページの左上を基点として拡大・縮小する

Image Mapがページを下にスクロールした位置にある場合、Loadingの表示が無いように見える。


解決策はここに書いてあった。
Highslide JS • View topic - Headline HTML problems with IE while fine in Firefox
Try using highslide-full.js instead of highslide-with-html.js.

highslide-full.jsを使えとのこと。
やってみたら、見事に解決した。


下手にHighslide Configuratorを使わずに、FULLを使った方が無難かも。

2009年3月5日木曜日

Whatever:hoverの version 3 (csshover3.htc)がリリースされていた

Whatever:hoverのversion 3がリリースされていた。

詳細はれぶろぐ - [JavaScript] Whatever:hover の :focus 擬似クラスへの対応についてが詳しい。

でも:hoverをたくさん使っているページでのIEの挙動は相変わらずもっさりカクカク。

参考:» onmouseout IE flickering problem (Blog Archive) Alex Mauzon

2009年2月11日水曜日

IEと Firefoxと grayと grey

色として灰色を指定する場合、Firefoxではアメリカ流の"gray"でもイギリス流の"grey"でも、どちらでも表示できる。
しかし、IEでは"gray"しか対応していないので注意。

もっと注意なのが。薄灰色。IEではgrayへの対応とは反対に、なぜか"lightgrey"の方しか対応していない。



Firefoxの場合





IE7の場合(IE6も同様だった)

参考:
 Remember grey!=gray in IE CSS! - Democratic Underground
 灰色 - Wikipedia

2009年1月22日木曜日

Google ChromeでなぜかQueryStringを含むURLを見られないと思ったら

ChromeでQueryStringを含むURLを見ようとするとしばしば「404 Bad Request」になってしまうことがあり、調べたらIEと同じ現象らしい。

/~sugano/ » Google ChromeのDigest認証

IEへの対応は、Apacheいじり始めてすぐに入れたのでそういうものだと思ってたけど、まさかこんなところで再開するとは。

2008年3月15日土曜日

「はてな」で見る、IEバージョン別のスクリーンショットの比較

IE7バージョンをさかのぼっていって、IEの変遷を見つつ、はてなのトップページがどのバージョンまで見られるか試してみる。
(最初はYahoo! Japanでスクリーンショットを撮ってみたが、あまりにも無難に対応しているのでやめた。)

実験に使ったIE7は、インストールしてからほとんど設定等を変更していないものを使っている。
IE6以前についてはMultipleIEsのものを使っている。


IE7
以前のIEと比べると上部のUIが大幅に変わった。メニューバーが隠れるのでWindowが広く使える。検索窓が標準で付いている。フィードに対応している。


IE6
上部メニューのアイコンがソフト。

IE5.5
シンプル。はてなではここまで対応しているようだ。

IE5.0
はてなではJavaScriptのエラーが発生。(左下の黄色い三角マーク。)また、「注目のキーワード」のところが表示されていない。

IE4
上部メニューにMailがある。もはやはてなは見られない。

IE3
手元のWindowsXPで起動すると、すぐ異常終了してしまうので確認できなかった。

IEでも faviconを表示するためにサーバ側で必要なこと

IEではfaviconがURL入力欄の左側に(IE7ではタブの左側にも)表示される。

(例)



しかし、サイトによってはfaviconの代わりにIEアイコンが表示される。というよりfaviconが表示されないサイトの方が多い。

(例)
Yahoo!でさえも。Firefoxでは表示されるので、faviconが無いわけではない。( http://www.yahoo.co.jp/favicon.ico にある。)


原因は、faviconのファイル形式か、あるいはfaviconの置いてあるドメインらしい。
IEのFaviconに関する仕様は非常に厳格です。
まずWindows icon形式(bmp形式ではないよって拡張子を変えただけではだめ)でなければなりません。
(中略)
またIEはサイト(=ドメイン)のルートにあるfavicon.ico以外は読み込みません。

上記引用元で紹介されている、@icon変換をダウンロードしてfaviconを作成したところ、無事にIEでもfaviconを表示できた。
(@icon変換に読み込ませるために、既存のfaviconをいったんWindowsのbmp形式に変換したが。)

ブログ アーカイブ

tags