ダリの雑記：WEBプログラム版

サーバとドメインを移転したお客さんのサイトが、全然インデックスされないとの連絡をいただきました。

ドメインも変わってるのだから、それはそうだろうとも思ってたんですが、移転したのは3か月くらい前だし、おかしいってことで調べてみました。

あやしいところでは、robots.txtやHTMLのmetaタグでクロール禁止設定しているあたりですが、robots.txtはそもそもないし、HTMLのmetaタグもほぼ無いに等しいほどシンプル。

リダイレクトも旧サーバ・旧ドメインから３０１できっちり転送しているので問題ない。

仕方ないので、Search Consoleを設定して調べてみたところ、下図のエラーが出てました。

（Search Consoleの左メニュー＞クロール＞robots.txtテスターを開くと出てきたエラー）

現在 Google で取得できない robots.txt ファイルがあります。この場合、Google が robots.txt を取得するまでサイトのクロールが停止されるか、前回取得した robots.txt ファイルが使用されます。

robots.txtなんてファイルは作ってないし、実際サーバ上にも無いし、おかしいなと思ってrobots.txtにブラウザからアクセスしてみたら、htaccessのリライトルールのせいで、404エラーでもない変なエラーページが開いてしまいました。

そして下の記事を発見。

robots.txtがこんなに重要だったとは。。。身をもって知りました

なんとまあ、robots.txtは存在してちゃんと設定されているか、または無いなら404エラーで返さないと、Googleはインデックスしてくれなくなるらしい。

正直、インデックスされないように設定することのほうが少ないため、robots.txtなんてあんまり気にしたことありませんでした。（通常は無いなら無いで404になるし）

気をつけねば。

とあるサイトをhttps接続に変えたところ、下図のような警告が出るようになってしまいました。

この接続は安全ではありません
このページの一部（画像など）は安全ではありません。

ブラウザはFirefoxで、Google Chromeでも同じようなエラーになっていましました。

ソースを確認したところ、リンクURLでhttpになっているところはありましたが、画像やCSS、JSの読み込みパスはすべてhttps、もしくはスラッシュから始まる絶対パスになっています。

JS、CSS内のパスにhttp接続があるかとも思いましたが、これも違う。

特に読み込みに失敗しているようなファイルはなさそうなので、見た目上は正常なのですが、警告が出っぱなしというのは気持ち悪いし、ユーザーに不安を与えかねません。

CSS・JSを消したり戻したりして、とあるCSSが原因だと判明しました。

そのCSS内では画像が読み込まれていたのですが、そのパス自体は相対パスで問題ありません。

では、何が原因か？とよくよく見てみたところ、そのCSSで読み込もうとしている画像が存在していない・・・

これか！と思い、必要な画像をアップロードしたところ、警告が消えました。

リンク切れが起きても、この現象起こるんですね・・・

Google Chromeで、なぜがチェックボックスが表示されない現象発生したのでメモ。

原因はスタイルに

-webkit-appearance: none;

が記述されていたから。

これを消したら、表示されました。

参考サイト

chromeでチェックボックスが表示されない :: concrete5 Japan 日本語公式サイト

table内に記述しているaタグに、角丸とドロップシャドウをかけてボタンっぽくしたのですが、なぜかIE9でドロップシャドウが効かない状態になりました。

スタイルの記述はこんな感じ

table a{
position:relative;
z-index:1;

background-color:#FFF;
display:inline-block;
text-decoration:none;
padding:3px 8px;
margin:5px 5px 5px 0px;

-moz-border-radius: 5px; /*FireFox*/
-webkit-border-radius: 5px; /* Safari and Chrome */
border-radius: 5px; /* Opera 10.5+, IE */

-moz-box-shadow: 1px 1px 3px #777; /* Firefox */
-webkit-box-shadow: 1px 1px 3px #777; /* Safari and Chrome */
box-shadow: 1px 1px 3px #777; /* Opera 10.5+, IE */

behavior: url("/PIE.htc");

}

「position:relative」も「z-index」もちゃんと記述しているのに効かない。

というか角丸はちゃんと効いてるのに、なぜドロップシャドウだけ効かない？

他の場所で使っているドロップシャドウはちゃんと効いてるのに。

・・・もしや、と思い該当のaタグをtableから出してみたところ、

・・・効いた！

tableタグ内に記述したタグにはドロップシャドウをかけられないのかな？と思い調べてみると、こちらのサイトを発見しました。

IE9でborder-collapse: collapse指定要素内でbox-shadowが表示されない！ | ブログデザイン

どうも、tableのスタイルを「border-collapse:collapse;」にしているとダメみたい。

なんでやねん・・・

その部分のtableのみスタイルを「border-collapse: separate;」とし、解決しました。

【追記】　というかtable自体にではなく、ドロップシャドウをかけるタグのスタイル（この場合aタグ）に「border-collapse: separate;」と書けばよいみたい。

この記事は2012年に作成されたものです。内容が古くなっている可能性があります。

【2013/06/17追記】こちらの記事もあわせてどうぞ。
target-densitydpi=device-dpi　に注意【viewport】

スマホサイトを作る際は、viewportの設定を行なわないと、デフォルトの横幅980pxで設定してしまうので注意、とのことだったので、いろんなサイトが良く設定している

<meta name="viewport" content="width=device-width,initial-scale=1.0,minimum-scale=1.0,maximum-scale=1.0,user-scalable=no" />

を設定してみました。

しかし、FirefoxのFireMobileSimulatorで一通り整えて、実記テストしてみたところ、おかしな点が出てくる出てくる。

まず、ズーム（ピンチイン・ピンチアウト）が効かない。

これは「minimum-scale」と「maximum-scale」と「user-scalable」をしっかり設定しないとダメみたいです。

「minimum-scale」はデフォルトのスケールである「initial-scale」にあわせればいいとして、「maximum-scale」は「minimum-scale」よりも大きい値にし、「user-scalable」は「yes」にします。

<meta name="viewport" content="width=device-width,initial-scale=1.0,minimum-scale=1.0,maximum-scale=2.0,user-scalable=yes" />

そもそも「minimum-scale」「maximum-scale」「user-scalable」は設定しない（記述しない）と言うのもありです。ちなみにこの設定は一部機種には全く効かない（つまりuser-scalableがnoでもズームできてしまう）場合があります。機種に依存してしまうので深く考えないほうがいいかもですね。

続いて、「device-width」の値。

iphone3Gは幅320pxですが、iphone4からは640pxになるはず。

しかし、「width=device-width」の設定ではiphone4だろうが4Sだろうが、第４世代のipod touchだろうが幅のサイズは320pxになります。（こう書くと誤解を生みそうな感じですが、もちろん画面の半分しか表示されないわけではなく、320pxのサイズのものが640pxに引き伸ばされて表示されるという感じになります。）

しかも、幅480あるはずのXperiaでさえ320pxになってしまう・・・

よくよく調べてみると、幅320pxでサイトを作れば、大体の機種に合うようにできているそうです（例外はもちろんありますが）

Androidケータイの場合は、１つの機種で解像度が３種類に分かれており、通常はミドルの解像度で表示されているとのこと。

参考サイト：

• Androidの「target-densitydpi」でviewportの調整[to-R]
• 解像度 - Jimdoでマルチ・デバイス対応のホームページ

幅のサイズをきっちり、機種の解像度に合わせたい場合は（ただしiphone除く）、さらに「target-densitydpi=high-dpi」を足しましょう。

【８月16日追記】「target-densitydpi=high-dpi」の場合、Andoroid タブレットなどで表示がおかしくなる可能性があります（※１）。「target-densitydpi=device-dpi」としたほうが良いようです。

<meta name="viewport" content="width=device-width,target-densitydpi=device-dpi,initial-scale=1.0,minimum-scale=1.0,maximum-scale=1.0,user-scalable=no" />

通常はこの「target-densitydpi」は「medium-dpi」となっています。

（）書きでも触れましたが、これはAndroid向けなので、iphoneでは効きませんので注意！

「initial-scale」を0.5にしたりすると、640pxで表示されるようになるので、iphone4・4Sの場合は

<meta name="viewport" content="width=device-width,initial-scale=0.5,minimum-scale=0.5,maximum-scale=0.5,user-scalable=no" />

を記述する、というように振り分けられれば良いのですが、3Gとの振り分け方がイマイチよくわからない・・・

というわけで、現在まだまだ模索中です。

※１：具体的には短辺800pxのタブレットで表示した際、画面の３分の２くらいのサイズでしか表示されませんでした。（機種や設定などによるかもしれませんが。）

【2013/06/17追記】こちらの記事もあわせてどうぞ。
target-densitydpi=device-dpi　に注意【viewport】

参考サイト

• Android対応スマートフォンサイトのレイアウト（viewport・コンテナ編）
• iPhone 4 (Retina) での device-width は320 - [ぴ](2010-08-30)
• Androidの「target-densitydpi」でviewportの調整[to-R]
• 解像度 - Jimdoでマルチ・デバイス対応のホームページ
• スマートフォン用に最適化サイトを作る最小マークアップ | 風俗店サイト構築用CMS「CASTPRO4」

５月15日、ついにbetaの文字が取り除かれた、CSS3 PIE 1.0.0が公開されました。（自分が気づいたのは今日ですが。）

ダウンロードはこちら

最終的には、

1. box-shadowレンダリングのdivide-by-zeroエラー
2. ホバリング後にエレメントを削除した時にでるエラー
3. IE9の印刷時エラー
4. IE7およびIE8でブラウザズームを使用した時のレンダリングなどの問題

の問題が解決されたそうです。（IE6～IE8でCSS3が使える「CSS3 PIE 1.0.0」登場 | エンタープライズ | マイナビニュースより）

印刷時にPIEによるCSS3が効かないというのは、これまで通りですが、スクリプトエラーウィンドウがやたら立ち上がる問題は解決されてうれしい限りです。（beta4で一度直ったと思われていたのですが、beta5でこの問題が復活していた。）

まだまだバージョンアップするかもしれませんが、まずは製作者の方へ、

ありがとう

そしてお疲れ様でした。

ブラウザによってレイアウトに誤差が出てしまうことは多々有ります（特にIE vs それ以外）

が、同じFirefox6.0を使用しているのに、自分が使っているパソコンと先輩の使っているパソコンでレイアウトに誤差が出てしまいました。

floatして並べているボタンが１つずれるという程度のものでしたが、同じブラウザしかも同じバージョンなのになぜ誤差が？

アドオンのせい？

単に以前のキャッシュが残っているだけでは？

など、いろいろ原因を探ってみたところ、１つ重大な違いが有りました。

それは自分が使っているOSは「Windows 7」であるのに対し、先輩が使っているのは「Windows XP」ということ。

ためしに他のXPマシンでも見てみたところ、やっぱりずれが発生していました。

ブラウザのみならずOSでまで誤差が発生するのかよ・・・orz

なんだかんだでXPは未だシェアNo1ですからね～。

このOSチェックまでしなきゃならんのかと思うとうんざりした気分になりますが、誤差が発生する以上、チェックしとかなならんよな～・・・

ある意味XPでIE9を出さないというマイクロソフトの判断は正しかったのかも・・・

トラバをくださった方のブログで気づいたんですが、PIEのバージョンが４月にアップしたみたいです。

前バージョンのbeta3で発生していた、印刷プレビューでスクリプトエラーのウィンドウが立ち上がる問題が解決していました。（.htcで実行させたとき）

印刷でCSS3が実行されないという点は変わらずですが、とりあえず支障なく使えるようになりました。

他は何か変わったのかなぁ・・・

PIEダウンロードサイトへ

【追記】

beta5使ってたら、スクリプトエラーが復活しとる・・・。

とりあえず解決方法はありますので、こちらのサイトをご参照ください。

PIE.htc 使用時のIEでの印刷プレビュー【(x)html】

いつくらいに更新されたのか正確にはわからないんですが、去年の年末あたりにPIEが更新されていたようです。

具体的な変更点はまだ調べてませんが、レイアウトの崩れがなくなった代わりに、印刷ではCSS3が表現されなくなりました。

というか、印刷プレビューを開くとスクリプトエラーが・・・（でも出ない場合もある、この差がわからない・・・）※beta4でこの問題点は改善されました。

それでもレイアウトが崩れない分、beta3の方が使えそうなので、当ブログのPIEはこちらに差し替えました。

ついでにbeta2の印刷時のレイアウト崩れがどれくらいひどかったかというと、こちら

• PIE version1.0 beta2の場合のサンプル
• PIE version1.0 beta3の場合のサンプル

上記のサンプル画面で印刷プレビューを見てみてください。

PIEのダウンロードはこちらから

※PIE version1.0 beta3以降はレイアウトの崩れという最大のバグはなくなりました。

以下はPIE version1.0 beta2以下の場合、起きるバグです。

最近まで気づかなかったのですが、PIEを利用したサイトをIEにて印刷しようとすると、とんでもなくレイアウト崩れがおきます。

当サイトはPIEを使用しているので、IEにて印刷プレビューを見てみるとわかりますが、もはや使い物になりません。（※PIE version1.0 beta4にしたので、レイアウトの崩れはなくなりました）

記述方法が悪いのかなぁ？

とりあえず印刷用のスタイルと分けて、印刷ではCSS3を使用しないようにするとかしたほうがよさそうですね。

スタイル内にて印刷スタイルとスクリーン用スタイルをわける方法については以下のサイトを参照

印刷時専用のスタイルシートを作る（All Abouさんのサイト）

■追記

と思ったら、上記のサイトに載っているスタイルシート分けでは対処不可能のようです。

@media printのスタイルにはPIEの記述は外しているのになぜか反映されない・・・なぜ？

PIE、まだ早すぎる技術なのか・・・

<link rel="stylesheet" href="screen.css" type="text/css" media="screen" />
<link rel="stylesheet" href="print.css" type="text/css" media="print" />

で分ける方法だったらさすがにうまくいくと思うのだけど、まだ未検証。

■追記２

と思ったけど、やっぱりダメでした・・・

PIE version1.0 beta3から、この問題点はかなり解消されましたので、バージョンをあげましょう。

PIEダウンロードはこちら。