"IE" Search Results 62 件

最大化だって!?

コンテンツ側でブラウザサイズを変えるなんてとんでもない!と思っておりますが、
希に、ブラウザサイズを変える仕様を求められる事があります。
個人的な信念がどうあれ、仕様がないケースも(ノ∀`) ダジャレ

タグブラウザ時代

window.resizeTo(screen.width,screen.height);
window.moveTo(0,0)
コードとしては↑な感じですが、これが近頃鬼門。ブラウザのタブ化と共に、挙動が結構変わってます。

Firefox

タブが2つ以上ある状態でブラウザサイズが変わるのはFirefoxくらいです。

IE8,Safari

IE8やSafariは、タブが1つの状態もしくはスクリプトから開いた新窓ならリサイズされます。
ただし、IE8の場合はリサイズ結果は必ずしもフルスクリーンとは限らず、その挙動の差異もいまいち原因不明。

その他

Chromeは、スクリプトから開いた新窓ならリサイズされますが、手動で開いた窓はリサイズ無効。
Operaに至っては、MDI(ノ∀`)

結論

全画面化が強く求められるコンテンツはflash化が良さそうです。
その他はほどほどの対応が現実的でしょうか。

コメントは受け付けていません。

position:relative;やabsoluteで位置を調整するケースがありますが、
微調整に向いているrelativeに意外な落とし穴を発見。

落とし穴1:パーセント値の扱いが違う

サンプルHTMLを用意しました。
これの、黄色のボックスの位置がブラウザによって結構変わります。
px指定の場合は大差無いんですけどね(・ω・)パーセント指定だと途端に癖が出まくります。
まとめると以下の通り。

自ボックスを基準にした指定値(ほぼ)を取る

IE6
IE7

ブラウザのinnerHeight?を基準にした指定値をとる

Chrome(2.0.172.30)
safari(4.0)

指定が無効

IE8
FireFox(3.0.10)
Opera(9.64)
macのSafari(3.2.3)

落とし穴2:webkitの挙動がwindowsとmacで異なる

微妙なバージョンの違いかも知れませんが、何れにせよ、
本件に限らず、windowsのChromeやSafariでレンダリングが意図通りだからと言って、
macのSafariでも大丈夫とは限らない訳です((((;゚Д゚))))
ちゃんと、macチェックもしましょう俺(ノ∀`)
※追記:safari4で挙動がそろいました

コメントは受け付けていません。

サンプルHTMLの表示に於いて、
IE8、Firefox3、Safari3(chromeも)では、
sampleimg
この画像のように、ボックス間に隙間が空いてしまいます。
IE6,7、Opera9ではボックスAとボックスBは密接します。
ボックスAは、marginもpaddingも(borderも)なし。
Aの子ボックスのbottomにmarginが入っています。

名だたるモダンブラウザがほぼ全滅

本来?なら、ボックスAとBの隙間はボックスAの背景色で埋められるのが直感的なレンダリングです。
ところが、モダンブラウザと名高いIE8、gecko、webkitがボックスAの背景をキャンセルしてしまいます。
うーむ。ここまで、そろいもそろってですと、流石にバグではなく仕様なんでしょうね(´・ω・`)

親ボックスのpaddingにダミー値をいれて対策

良くある実例では、ボックスAが id=”main” ボックスBは id=”footer” で共にダミー的コンテナボックスだったりで、余白系の値は0にされていることでしょう。
大抵の場合は無調整で問題ないのですが、
(無駄に)複雑な多重背景で、うかつなズレが許されない場合がままあります。
そんな際の、margin、padding、時にはborderで、ごまかす調整するでは、キャンセルされるボックスAのbottomにpaddingの値を与えてやるのが良さそうです。

コメントは受け付けていません。

「固定幅+中央寄せ」時の背景ズレ対策を半年以上前に書きました。
背景画像がブラウザをリサイズすると1pxうねりますよね?
その補整に関する記録です。その際は、偶数幅のものをセンタリングするからうねるのだと思っていたのですが、よくよく考えてみると、奇数でもうねるんですよね。他にも色々と気になり、もう少し突っ込んで検証してみました。

検証用素材HTMLをご覧ください。

奇数幅でもうねります

センタリングでは、
ブラウザ幅が偶数幅の時は奇数幅画像がずれ、
ブラウザ幅が奇数幅の時は偶数幅画像がずれます。
1px違いますので当然です(ノ∀`)

ずれ方が違う……

msieもgeckoもoperaもwebkitも……リサイズで黒と赤の線がチラチラしますね(・ω・)
よくよく考えてみました。

余ったマージンを左へ送る場合

余ったマージンを左へ送る場合
ブラウザ幅が偶数の時に右に黒線が出ます。

余ったマージンを右へ送る場合

余ったマージンを右へ送る場合
ブラウザ幅が偶数の時に左に黒線が出ます。

つまり、ブラウザ幅が偶数の時と奇数時で、余分マージンを送る側を変えるレンダリングエンジン以外は、リサイズで黒と赤の線がちらつくことになります。
幸か不幸か、現状のメジャーなレンダリングエンジンは全てちらつきます。

各ブラウザの特徴

IE6,7だけ(6未満は無視)が左に余分マージンを送るようです。他は皆右へ。
IE6.7以外は、偶数と奇数の画像を混在させない限り、ずれな……ん?
いや、それって偶数と奇数がずれるのであって、バックグラウンドとフォアグラウンドがずれる原理とは関係ありませんよね\(^o^)/

フォアグラウンドのずれ方を見る

ブラウザ幅に限らず線と画像が合う、operaとwebkitは、問題ありません。
これらは、偶数と奇数の画像を混在させない限りずれないと言うことです。
問題は、msie6,7とgecko。
マージン送り方向という考え方では、どうも、バックグラウンドとフォアグラウンドで逆にマージンを送っているようです。

msie(6,7)

バック 余分マージン左送り
フォア 余分マージン右送り

gecko

バック 余分マージン右送り
フォア 余分マージン左送り

msie8,opera,webkit

バック 余分マージン右送り
フォア 余分マージン右送り

対策

結局、前と大差ありませんorz

  • IE6.7は背景画像の右端に1ピクセル足す
  • FireFoxは背景画像の左端に1ピクセル足す
  • 奇数幅でそろえても無駄\(^o^)/

動的にjQueryで内幅を変えるのも面白いかなと考えていたのですが、
ブラウザ間の「ずれ方」の差異は幅いじりだけでは無理のようです。

具体的に

標準モード

#main {
	background:url(main-bg.gif) repeat-y center 0;
	_background:url(main-bgie.gif) repeat-y center 0;/* IE6 センタリング補正 */
	*background:url(main-bgie.gif) repeat-y center 0;/* IE7 センタリング補正 */
}
#maincontainer:-moz-read-only {
	background:url(main-bgff.gif) repeat-y center 0;/* Mozilla センタリング補正 */
}

互換モード




#main {
	background:url(main-bg.gif) repeat-y center 0;
	_background:url(main-bgie.gif) repeat-y center 0;/* IE6,7 センタリング補正 */
}
#maincontainer:-moz-read-only {
	background:url(main-bgff.gif) repeat-y center 0;/* Mozilla センタリング補正 */
}

で動くっぽいです。
どうもIE8がくせ者です。
互換モードでは新セレクタが機能しない((((;゚Д゚))))
互換モード時にはヘッダに、

を追加したら上手くいきました。
アンダースコアハックやらスターハックが無効化されるようです。

コメントは受け付けていません。

単純なリキッドレイアウトは画面が狭かった時代の遺物だと思っています。
もちろん、リキッドを全否定する意味ではございません。

アマゾン風リキッドを知る

jQueryで作るAmazon流リキッドレイアウトを読んで、始めて最近のアマゾンのリキッドレイアウトを知りました(ノ∀`) ブラウザの横幅に応じて、表示点数を変える(ずらすのではなく)レイアウト。
なるほど。これはある。あるぞぉーーー
記事はどうやら、jQueryを使うことに主眼があるようで、jQueryを使わない実装には触れられていませんでした。

とりあえず作ってみる

さらっと作れるじゃんね。一応プロだし(ノ∀`)
ん。。。むむ……案外手強いwwww
アマゾンどうのこうのの部分は問題ないのですが、それ以前のリキッドレイアウトが手強いぞーー
というか、リキッドの案件なんてほとんど縁が無かったな俺(・ω・)ダメじゃん

練習じゃぁ!

危機感を感じ、とりあえず練習に。
目指すは、本文部のみがリキッドの3カラムレイアウト。

1つ目。まずは、ネガティブマージン(とやら)でを作る。

  1. IE6でウィンドウ幅を縮めると左サイドが散歩に出かける
  2. ウィンドウリサイズ時等々、挙動がおかしい((((;゚Д゚))))(IE,Opera)

なんじゃこりゃ。・゚・(ノ∀`)・゚・。
IE6がどうのこうの以前にIE7でどうにもならん((((;゚Д゚))))
ふぅおちつけ。良くある事じゃないか。
どうせ、ブロックモデルの解釈がおかしいに違いないさ……

2つ目。リキッド部を無駄タグで入れ子にしてみた

なーんだ、あっさり動いたじゃん……IE6のアレ以外は。
アレ
ちょっとネガティブマージンから離れてみましょうか……

3つ目。左カラムをアブソリュートしてみた

お!IE6でも大丈夫じゃん!
って、フッタを突き抜けてます。当然です。それがアブソリュートです。

4つ目。もっと大胆にアブソリュートしてみた

本文部と、サイド部を別レイヤーにして、サイド部を丸ごとアブソリュート。
フッタを突き抜けないように、JavaScriptで高さをリアルタイムで調整(゚Д゚)食らえっ!
やけくそだったのに、リサイズ時の値取得が上手くいかず放心。
まて、リアルタイムにサイズを変えるなら、リキッド部の横幅を弄ればいいじゃないか……

5つ目。JavaScriptでリキッドさせるタイプ

もうね、素直にリキッド部の幅をJSで弄っちゃいますよ。ええ。
ええ、普通に動きます。柔軟性も結構ありますよ。ええ。
なのになんでしょう。この敗北感は(´-`)
そうだ!jQueryで作るAmazon流リキッドレイアウトを読んで、いやCSSでいいじゃん?と思ったのが発端だったのです。
まぁ、該当箇所こそあっさりCSSで動いてますが、ソレより基本とも言える部分でjQueryを必須にしてしまう訳には参りません。

6つ目。ネガティブマージンのものを基本に、IE6だけJS補正してみた

挙動のおかしなIE6だけをJavaScriptでねじ伏せれば良いのです(゚Д゚)
世に出回ってるサンプルも結構眺めました。
上手く動いている物は、大抵、サイドも可変となるパーセンテイジ指定でして、本文部のみリキッドというタイプは、どれも、IE6のこの挙動に関しては放置しているようでした。
テーブルよりはJSかな(´・ω・`)IE6(正確には7未満)だけに適用もできるし。

と言う訳で、今回の修行はここまで(゚Д゚)今日のところは勘弁したらぁ

コメントは受け付けていません。

ページトップへ

背景伸縮

[技術メモ] 2009年4月7日(火曜日) 23:45

女子美術大学みたいなことできる?と聞かれサンプルを製作。

実は、その昔に挑戦してクロスブラウザの面で失敗したことがあり(ノ∀`)
いやぁ、jQueryは便利ですね(・ω・)表示すべき「幅」の取得も楽にできてしまいました……
スクロールバーの幅とかは考えずに、windth:100% のブロック要素の幅を取るのが吉なのかもしれません。
CSSだけで動くのはIE位でしたが、背景ストレッチくらいは標準機能であっても良さそうなものです。

追記

flash背景のが軽いっぽい(・ω・) flash背景サンプル
ランダム背景やら伸縮の微妙な具合やらも調整の幅が広そうだし、縦幅を固定しようとすると、jQuery+私の技術では厳しかった(ノ∀`)overflow:hiddenも効かず。
なにより、flashのが軽い((((;゚Д゚))))

コメントは受け付けていません。

ページトップへ

メディアの重心

[自分ルール] 2009年3月11日(水曜日) 22:53

メディアがもつ意志の重心

「コンテンツが利用者に支持される事で、スポンサーの利益を上げる」というスタイルにあるメディアのほとんどはおそらく、

  • スポンサー
  • 利用者
  • 制作者
  • 社会

の意図、意志によって構成され、またこれらの重心は、成り立ちや経済によって媒体毎に異なります。

利用者至上主義は簡単ではない

利用者の利便性を追求する行為は、それが的を射ていれば、利用者の増加に直結します。
視聴率、アクセス数、そしてコンバージョン。
スポンサーの利益が優先されて利用者が不利益を被る事もあるでしょうが、NHKの様な広告スポンサーを持たない有料モデルであっても「不満」が消えない現状をみられる様、「利用者の利便性を追求する」行為そのものが、とても難しい事だと言えるでしょう。

何故難しいか

  1. 利用者の望みがバラバラだったり、そもそも望みがなかったりする事
  2. 機械的に大多数の望みを把握する仕組構築の難しさ
  3. 望まれている提案を生み出す難しさ
  4. 望みを叶える事が、利用者の不利益に直結する可能性
  5. 望まれていない啓蒙の難しさ

1、2、3、はマーケティングやマーチャンダイジング的手法を用いるのが王道でしょうが、データを中心にフィルタリングやパーソナライズを自動化できるのはネットの強みでしょうか。

4、は「欲しい物しか見ない」事で成極化的な凝り固まりを起こしてしまう可能性です。視野を極めて狭くするものであったり、大量な時間を浪費させるものであったりします。

5、は4を緩和する為にも望まれる要素ですが、啓蒙自体の難しさはもちろん、広告・実益との境界が曖昧になりがちな問題もあります。特にマスメディアによる啓蒙は弊害も反発も多く、マスメディア自体が嫌われる原因の一つにもなっています。技術的には、やはりネット向きでしょうか。「お勧め」を自動抽出する仕組みに近いとも考えられますし。

ネットメディアの重心

「ネット」が持てはやされ「テレビ」が飽きられてつつある現状の根幹には、メディアの重心が深く関係していそうです。
ネットには、利用者の利便性を追求しやすい性質があり、そここそが「ウケ」ていると。それはもちろんイノベーションでしょう。

検索エンジンは利用者至上主義を通しやすい

検索エンジンの場合、

  • 利用者の望みが、最初にかなり明確に示される
  • 望みを叶える事に提案自体が含まれている
  • コンピュータシステムで処理している

利用者に重心を持って行きやすい本質を持っています。
もちろん、利用者至上主義で運営する必要はありません。
しかし、他メディアではしたくてもできない事が、簡単に行えるメディアなのです。

googleの重心

近頃のgoogleは、無茶のしすぎで悪名さえ轟いています(笑)。
利用者寄りの重心をもつメディアという点では、googleが最右翼と言えるでしょう。利用者(あくまで利用者)としては、googleは案外誠実なんです。
例えば、リスティング広告の在り方。
ヤフー VS グーグル–見られるリスティング広告はどっち?」では、ヤフーの表示形式の方が効果が高いと持ち上げていますが、これ所詮は「騙しリンク」の手法なんですよね……
一方、googleは広告のクリックレートが落ちようとも、不誠実な表現を避け利用者の利便性を優先しています。

google的重心の怖さ

ストビュや、ブック検索等々、これら線上には様々な問題があり、利便性追求が同時に社会を激しく削りたてています。
これが、イノベーションに伴う新旧価値観のつばぜり合いなのか、「社会」の利益と「利用者」の利益に発生している構造的なラグなのか、単なるやり過ぎなのかは正直、よく分かりません。
ただ、そこにある問題が単純な摩擦を超えている感覚はあります。

マスメディアの重心

ネットの無料モデルに“マスメディア”の未来はない」 では、重心がスポンサーに偏ることの弊害が語られていますが、ネットを持ち出すまでもなく、国内マスメディアの多くは既に利用者寄りの重心ではありません。
マスメディアによって特権のように自称されるジャーナリズムが信頼を取り戻すのは、確かに至難の業でしょう。

広告的提案は不信を買いすぎたか

広告優先な提案は「ついつい」な結果を招きがちです。そもそも騙す気満々のものでさえ存在します。

もっと自分にあった商品が他にあったのに、それどころか不要だったのに、ついつい買ってしまった……
クライマックスをCM明けに引っ張るのでついつい見たがイライラしか残らなかった……
褒めてばかりの記事を信じて買ったが、誰でもすぐに感じる不満がレビューされていなかった……

積もり積もったこれら不信が「広告的提案=スパム」と判断する下地を作ってしまったのかもしれません。
逆に、テレビドラマがスパムと認識されていないのは、作品中の提案がまだ不信を買っていない証左とも言えそうです。

ネットメディアの可能性

利用者の要求に対して、「適した提案」を返す事は、素晴らしい事です(怖くもありますが)。
また、その内容に広告が含まれるかどうかも、提案される側にとっては本質ではありません。

優れた提案には誠実さ

望まれた以上の物を提案する行為は、スポンサーの事情を無視できたとしても難しい事です。
データマイニングシステムと同時に、騙す気のない誠実さとその裏付けが不可欠でしょう。
しかし、技術的にそれらを克服できたとしても、少なからず誤解は発生します。
なぜその提案に至ったかの誠実さを伝えるには、おそらく表面的な「理由」だけでは足りません。
多少角が立とうとも実態に近い立場を明示できるメディアが信用を勝ち取ることでしょう。

ネットでは嫌われる事さえ好かれる以上の結果を生める

嫌いな雑誌を買う人は奇特ですが、嫌いなウェブ記事はそれなりに使われます。
無料モデルが一般的だからでしょうか、「嫌い」な対象を嫌いと、間違っている対象に間違っていると言える文化がネットには存在します。「炎上」や「釣り・煽り」もその性質が目だ立たせた現象と言えるでしょう。
この性質の芯には「信用さえ得られるなら嫌われる事を恐れる必要はない」という意義がありそうです。
※もちろん炎上を目指すべきではありません。その多くは誠実さを欠いてしまったが故に起こる不幸な現象です。

嫌われても信用を取るべきか

「信用」は「好き嫌い」に対抗しうる数少ない基準です。
「好かれているが信用されない存在」
「嫌われても信用はされる存在」
の二択を迫られた際、特にネットの場合はそろそろ後者を選択すべきなのかも知れません。

コメントは受け付けていません。

互換モードじゃありませんか

DOCTYPE宣言によってはIEの挙動がバグだらけになります。
いわゆる「互換モードと標準モード」における、互換モードの問題です。
そうならない様に「標準モード」になるDOCTYPE宣言を使用するのがセオリーなのですが、今日行ったコーディングではレギュレーションで互換モードが指定されており、久々に汗をかく事に。

ズームでずれる

IEの互換モードではblockのmarginがマトモに解釈されません。一見上手くいっていても、ズームしてみるとずれたり(zoom:1;でも無理)。
私の場合、これはpaddingを主に書き換え必要ならばblockを入れ子にして対応します。
まぁ、ここまでは、HTMLコーディングではよくある事です(ノ∀`)

印刷でずれる

position を使用していると、何故か印刷でずれまくります(ノ∀`) もちろんIE互換モード。
小一時間悩みました。どうやら、印刷の場合はpaddingがマトモに解釈されないようです。

つまり

IE互換モードの(特にpositionを使う)場合、

  • ブラウザ上では特にズーム時にmarginの解釈がおかしい
  • 印刷上では特にpaddingの解釈がおかしい

状態になってしまいます。

今回は、IEのみに印刷用CSSを当てる事で対応しました。

コメントは受け付けていません。