browser

文字の左1px分が欠ける現象

overflow:hidden;が指定された領域内で、文章の先頭文字が欠けてしまう現象が発生しました。
windowsのIEのみではなく、今回はFireFoxでも同様の現象が見られたため、この問題が解決するまでに結構な時間を・・・。

OSの問題?
フォントの問題?
フォントサイズの問題?
overflow:hidden;の指定領域の問題?

複数の観点から調べてみました。

まず、OSの問題かということについてですが、今回はwindowsのみで発生していてmacでは発生しなかったのでOSに何かヒントがないかということで、Windows XP での全角固定ピッチフォントの仕様変更を確認しましたが、今回使用しているフォントがプロポーショナルフォントであるMS Pゴシックであることからも、ここに問題があるとは思えません。

次にフォントの問題?かという点についてですが、たしかに問題が発生しているのはMS Pゴシックのときでそれを使用するwindows側ブラウザのみに発生している問題でした。
macはデフォルトのフォントが異なるためこの現象は発生しません。
フォントの表示領域に問題があるかもしれないが、確かではない感じです。

フォントサイズの問題?という点ですが、こちらも特定の大きさの場合のみ今回の現象が発生しました。
14px相当前後の場合に発生した問題です。
しかしこれを原因としてしまうと、14pxがダメなのか!?ということにもなり納得がいきません。

最後にテキストの表示領域自体に何らかの問題がないかについてです。
テキストが表示されるエリアに指定しているCSSをすべて細かく見ていくと、overflow:hidden;が影響していることわかりました。
まずはhtmlをみてみます。

<div class=”contents”>
<p>ぐぐぐぐぐぐぐぐぐぐぐぐぐぐぐ</p>
<p>aaaaaaaaaaaaaaaaaa</p>
</div>

これに対してcssは、

.contents{
width:640px;
padding:20px;
}

.contents p{
width:600px;
overflow:hidden;
}

としていました。
ここでpに指定したoverflow:hidden;が無いと、文字は欠けずに表示できました。

ただし、ここでの疑問は領域(ボックス横幅)についてはきちんと確保しているにも関わらず、overflowを指定しているとその計算が狂ってしまい先頭文字の開始位置が左にずれてしまうことです。

ここで、pに対してoverflow:hidden;が無ければ文字が欠けない訳ですが、それでは困るので代替手段としてoverflowの指定場所を変えました。

.contents{
width:640px;
overflow:hidden;
padding:20px;
}

.contents p{
width:600px;
}

pを内包する親要素に対してoverflow:hidden;を指定することにしました。
こうすると若干文字のはみ出し方に違いは出ますが、とりあえずは解決です。

Tags: , ,

IEでoutlineの領域が広がる

IE6,7でword-wrap:break-word;を適用したところ、とある問題(バグ?)に遭遇しました。

横幅指定のあるボックス内にテキストが入るような状況で、半角英数記号が連続する場合に、これまでは

word-break:break-all;

でIEには折り返しの対応をしていましたが、今回は

word-wrap:break-word;

で対応してみることにしました。

すると、折り返す半角英数記号がリンクの場合、outlineだけ右にはみ出てしまうのです。
かといって、クリッカブル領域もその分広がるのかというと、そうではないようです。

screenshot

残念な表示をしてくれるIEのために、結局これまでどおりの
word-break:break-all;
をIEのみに適用することにしました。残念。

ちなみにFireFoxなどのモダンブラウザではoverflow:hiddenないしはword-wrap:break-word;でこれまで対応してきました。

FireFoxで半角英数の折り返し処理を適用できるようになっただけでもまだマシということで…

Tags: , , , , ,

overflow:auto;にしたtextareaでスクロールバーが出ない

overflow:auto;を設定し、入力エリアより長く文章が入った場合に自動的にスクロールバーが出るように設定したtextareaで、こんな問題に遭遇した。

FireFoxで見たとき、文章が多くてもスクロールバーが出ないといわれた。

調べてみたところ、どうやらtextareaの高さが足らなかったため、スクロールバーの▲▼の描画エリアを確保できなかっただけっぽい。

なので高さを追加した、解決。。。。
最低でもwindowsでは高さ34pxくらい必要だった。
ちなみにmacはというと56pxくらい必要になります。

Tags: ,

ブラウザシェアと画面解像度のランキング 2010年1月期

現在管理している4サイトでのブラウザシェア及び画面解像度

期間:2010/01/01-2010/01/31

前回計測からすでに8ヶ月程度経って、ブラウザシェアと解像度にも変化が出てきました。
以下のデータの中からはグルメ検索サイトがUU,PVともにトップで統計としてはそこが一番役に立つのではないでしょうか。
傾向としては、IE7からIE8への移行が多く、IE7よりもIE6を使用している人の方が多くなっているという現象や、横長のディスプレイを使用している人が増えてきたこと、そしてやはりスーマートフォンユーザーが少しずつ増加しているということでしょうか。

■ブログ(プライベート・アメブロ)
1. Internet Explorer—–70.78%    前回78.18%
—7.0 60.55%   前回79.73%
—6.0  22.02%   前回19.93%
—8.0  17.43%   前回0.33%
2. Safari—–12.34%    前回6.75%
3. Firefox—–7.14%   前回11.95%
4. Lunascape—–7.14%
5. Chrome—–2.60%    前回0.52%

1. 1280×800 —–27.92%    前回29.87%
2. 1024×768 —–24.68%   前回34.81%
3. 1680×1050 —–12.99%   前回5.19%
4. 1093×614 —–9.09%   前回5.19%
5. 1280×768 —–7.14%   前回3.64%
6. 320×396 —–5.84%   前回5.19%
7. 1400×1050 —–3.25%    前回3.38%
8. 1280×1024 —–1.95%   前回4.16%
9. 1366×768 —–1.30%   前回6.49%
10. 1440×900 —–1.30%   前回2.60%

■地方のシネコン
1. Internet Explorer—–86.47%   前回89.80%
—8.0   47.48%   前回2.88%
—7.0 26.60%   前回58.45%
—6.0   25.47%   前回37.61%
—5.5   0.29%   前回0.69%
—5.0  0.12%    前回0.10%
2. Firefox—–4.17%   前回3.82%
3. Safari—–3.97%   前回2.25%
4. NetFront —–2.28%   前回2.37%
5. Chrome—–1.22%   前回0.59%
6. Opera—–0.89%   前回0.86%
7. Lunascape—–0.45%   前回0.86%
8. Mozilla Compatible Agent —–0.34%   前回0.86%
9. Playstation 3—–0.09%   前回0.86%
10. Playstation Portable —–0.03%   前回0.86%

1. 1024×768 —–30.45%   前回37.44%
2. 1280×800 —–20.46%    前回20.03%
3. 1280×1024 —–16.70%   前回19.98%
4. 1440×900 —–4.91%   前回4.64%
5. 1366×768 —–4.72%   前回1.31%
6. 1680×1050 —–4.66%   前回4.05%
7. 1920×1080 —–2.08%
8. 1280×768 —–1.82%   前回2.32%
9. 320×396 —– 1.57%
10. 1920×1200 —–1.10%   前回0.95%

■地域グルメ検索サイト
1. Internet Explorer—–88.75%    前回91.14%
—8.0   42.31%   前回2.36%
—6.0  32.19%   前回42.84%
—7.0   25.08%    前回53.76%
—5.5   0.40%   前回0.62%
—5.01  0.01%
2. Firefox—–5.19%    前回4.38%
3. Safari—–3.62%   前回2.81%
4. Chrome—–1.26%   前回0.57%
5. Opera—–0.58%   前回0.83%
6. Lunascape—–0.21%

1. 1024×768 —–32.71%    前回40.66%
2. 1280×800 —–21.93%   前回20.45%
3. 1280×1024 —– 18.59%   前回20.69%
4. 1366×768 —–4.32%   前回0.82%
5. 1440×900 —–4.24%   前回4.01%
6. 1680×1050 —–4.17%   前回3.91%
7. 1280×768 —–1.72%   前回2.30%
8. 1920×1080 —–1.69%
9. 1920×1200 —–1.19%   前回0.79%
10. 320×396 —–1.03%

■Yahoo!ショッピング 寝具ショップ
1. Internet Explorer—–84.85%   前回86.37%
—8.0  52.69%    前回3.93%
—6.0  24.85%   前回37.70%
—7.0  22.21%   前回57.87%
—5.01  0.10%
—5.0  0.05%   前回0.18%
2. Firefox—–7.27%   前回7.89%
3. Safari—–4.65%   前回4.10%
4. Chrome—–1.27%   前回0.90%
5. Lunascape—–1.15%
6. Opera—–0.35%   前回0.47%

1. 1024×768 —–26.45%   前回36.90%
2. 1280×800 —– 21.75%   前回19.68%
3. 1280×1024 —–15.97%   前回17.69%
4. 1440×900 —–5.20%   前回5.47%
5. 1680×1050 —–5.16%   前回5.54%
6. 1366×768 —–4.37%   前回1.17%
7. 1280×720 —–3.67%   前回2.07%
8. 1920×1200 —–2.31%   前回2.34%
9. 1920×1080 —–2.23%
10. 1280×768 —–2.06%   前回2.23%

Tags: ,

overflow:auto;を指定した要素の背景画像が固定できない件

ある特定のボックスであるdivの高さと横幅を固定とし、テキストがその領域からはみ出る場合にスクロールバーが出る設定を以下のようにした。

div#messageArea{
width:600px;
height:150px;
overflow:auto;
padding:12px 10px;
border:1px solid #CCC;
background:#FCFCFC url(http://xxxx.jp/img/sampleaimage.gif) no-repeat 0 0;
}

まずこれでIE以外のブラウザでは背景画像をdivの領域内で固定できた。
このままだと、IEで背景画像はスクロールで消えてしまうため、
ここにさらにbackground-attachment:fixed;を追加。

div#messageArea{
width:600px;
height:150px;
overflow:auto;
padding:12px 10px;
border:1px solid #CCC;
background:#FCFCFC url(http://xxxx.jp/img/sampleaimage.gif) no-repeat 0 0;
background-attachment:fixed;
}

こうした場合、IE6以外のブラウザで背景画像の開始位置の解釈が変わり、ウインドウの左上が開始点となってしまった。
そのため、IE6専用にハックをつける。

div#messageArea{
width:600px;
height:150px;
overflow:auto;
padding:12px 10px;
border:1px solid #CCC;
background:#FCFCFC url(http://xxxx.jp/img/sampleaimage.gif) no-repeat 0 0;
_background-attachment:fixed;
}

ここまでで、FireFox3.6,Safari4,IE6には対応できた。
が、IE7では背景画像は出るが、固定はできていない状態。

ここまでが限界だったため、いろいろ調べてみたところ、
ここの一番下に探し求めていた情報がありました。

背景画像を固定しない場合
・背景画像を設定したボックス内の左上が0%位置となる。
・IEも同様。

背景画像を固定した場合
・背景画像の0%位置は閲覧領域(自分の場合はウインドウの左上)となる。
・IEの場合、body要素とhtml要素に背景画像を指定した場合は上と同様。
・IE6でそれ以外の場合は背景画像を設定したボックス内の左上が0%位置となる。
・IE7でそれ以外の場合は閲覧領域(ウインドウ)の左上が0%位置となる。

ただ、自分の場合についてはdiv要素の位置が常にウインドウの左右中心で、上から200pxの位置にあったため、以下のように無理やり背景位置を固定とした。

div#messageArea{
width:600px;
height:150px;
overflow:auto;
padding:12px 10px;
border:1px solid #CCC;
background:#FCFCFC url(http://xxxx.jp/img/sampleaimage.gif) no-repeat 0 0;
*background-attachment:fixed;
*background-position:50% 200px;
_background-position:0 0;
}

IE以外のブラウザでは背景固定を設定しない(fixedにしなくても背景が固定されるから)で背景位置を00ポジションに設定。
IE6,IE7は背景画像を固定し、ウインドウの左上を始点として背景画像の位置を設定。
IE6は背景画像を固定にしても、背景画像の開始位置がdiv要素の左上になるためウインドウではなく、divボックスの左上を背景画像開始点とする。

Tags: , , ,

ブラウザシェアと画面解像度のランキング 2009年4月期

現在管理している4サイトでのブラウザシェア及び画面解像度

期間:2009/04/01-2009/04/30

■ブログ(プライベート)
1. Internet Explorer—–78.18%
—7.0     79.73%
—6.0  19.93%
—8.0   0.33%
2.  Firefox—–11.95%
3.  Safari—–6.75%
4.  Netscape—–2.08%
5.  Chrome—–0.52%
6.  Opera—–0.52%

1.   1024×768 —–34.81%
2.   1280×800 —– 29.87%
3.   1366×768 —–6.49%
4.   1680×1050 —–5.19%
5.   1280×1024 —–4.16%
6.   1280×768 —–3.64%
7.   1400×1050 —–3.38%
8.   1920×1200 —–2.86%
9.   1440×900 —–2.60%
10.   800×600 —–1.82%

■地方のシネコン
1. Internet Explorer—–89.80%
—7.0     58.45%
—6.0   37.61%
—8.0   2.88%
—5.5   0.69%
—5.0  0.10%
2.  Firefox—–3.82%
3. NetFront —–2.37%
4.  Safari—–2.25%
5 Opera—–0.86%
6. Chrome—–0.59%

1.   1024×768 —–37.44%
2.   1280×800 —– 20.03%
3.   1280×1024 —–19.98%
4.   1440×900 —–4.64%
5.   1680×1050 —–4.05%
6.   1280×768 —–2.32%
7.   1366×768 —–1.31%
8.   240×400 —–1.07%
9.   1400×1050 —–1.02%
10.  1920×1200 —–0.95%

■地域グルメ検索サイト
1. Internet Explorer—–91.14%
—7.0   53.76%
—6.0  42.84%
—8.0   2.36%
—5.5   0.62%
—5.0   0.19%
2. Firefox—–4.38%
3. Safari—–2.81%
4. Opera—–0.83%
5. Chrome—–0.57%
6. Netscape—–0.05%

1. 1024×768 —–40.66%
2. 1280×1024 —– 20.69%
3. 1280×800 —–20.45%
4. 1440×900 —–4.01%
5. 1680×1050 —–3.91%
6. 1280×768 —–2.30%
7. 1152×864 —–1.10%
8. 1400×1050 —–1.02%
9. 1366×768 —–0.82%
10. 1920×1200 —–0.79%

■Yahoo!ショッピング 寝具ショップ
1. Internet Explorer—–86.37%
—7.0  57.87%
—6.0  37.70%
—8.0  3.93%
—5.0  0.18%
—5.5  0.18%
2. Firefox—–7.89%
3. Safari—–4.10%
5. Chrome—–0.90%
6. Opera—–0.47%
4. Netscape—–0.04%

1. 1024×768 —–36.90%
2. 1280×800 —– 19.68%
3. 1280×1024 —–17.69%
4. 1680×1050 —–5.54%
5. 1440×900 —–5.47%
6. 1920×1200 —–2.34%
7. 1280×768 —–2.23%
8. 1280×720 —–2.07%
9. 1366×768 —–1.17%
10. 1400×1050 —–0.86%

Tags: ,

火曜日, 5月 19th, 2009 browser, Fire Fox, Internet Explorer 1件のコメント

border-collapse:collapse;を指定したtableが左にズレるバグ

FireFoxでサイトを確認したとき、border-collapse:collapse; が指定されたtableが親要素から左に1pxずれるバグがありました。

原因がイマイチ分かりませんが、おそらくmozillaのバグなんでしょうね。

ここにも載ってました。

http://bugzilla.mozilla.gr.jp/show_bug.cgi?id=4246

しかも解決済みだということですが、いまだに直らないってことは解決していないのでしょうか??

それともこちらのマークアップにミスが!?

こんな構造になっていようが、

にしようが、ずれるもんはずれるんです。

結局、ボーダーをtableに指定しないで、tableをdivで囲ってあげてそのdivにボーダー指定するか、

FireFoxだけ、border-collapse:collapse; を指定しないかで解決したんですけどね。

うーん。。

Tags: , , ,

FireFoxで画像置換したリンクのアウトラインが画面左に伸びる

overflow:hidden;の指定。

また、macIE5のバグ回避のため、
/*\*//*/
li.a{overflow:visible;}
/**/
とする。

Tags: , ,

liをdisplay:block;で扱う場合のIEのバグ

ナビゲーション、メニューなどのリストの作成を、liをブロック要素として並べて使う場合に、IEでは個別のliブロックの下に変な隙間が入ってしまう件について。

単純にそのブロックに横幅を指定してあげれば解決する。

htmlの書き方でliごとに改行しないなどの方法がネット上でいくつか見られたが解決に至らなかった。
別の方法として、ulに対してline-height:0;とし、liにline-height:auto;とする方法も見つかったがコレも解決にいたらず。

というわけで、今回のIEのバグは横幅指定で解決しました。

Tags: , ,

FireFox3のフルページズームに関するバグ?

親ボックス内3カラムの子ボックスをフロートで配置したレイアウトの場合に、FireFox3のフルページズームの縮小を行うと3カラム目のボックスが落ちる現象を確認。

原因をネットで探してみた中で、解決に一番近い情報が確認できたサイトが、Firefox 3 のフルページズーム使用時はスクリーン上でのピクセル量とCSS上でのピクセル量 なのだが・・・・

・親ボックスの横幅に対して、3つの子ボックスそれぞれにも横幅が指定され、合計で親ボックスの全幅となる。
・float:left; float:left; float:right; で配置。
・フルページズーム機能の縮小の場合のみ、3カラム目が下に落ちる。

とりあえず、ボックスのカラム落ちを回避した方法は・・・

子ボックスの幅をどれかひとつ数ピクセル縮める。

カラム落ちする場合の縮小したイメージをよく見ると、どうやら余白やコンテンツ幅のpx指定がうまく効いていないっぽいことでレイアウトが崩れている。
フロートの解除に関するスタイル指定のミスではなかったので・・・・

これでいいのだろうか??

Tags: , ,

2024年12月
1234567
891011121314
15161718192021
22232425262728
293031