という人におすすめ。
これは「ツカエル」と思ったCSSは、ブログでも紹介するんですが、こういうリファレンスがあると、便利かも。
あ、なんか人任せでスミマセン。
あと、最近のサイト制作でのコダワリといえば、最初に YUI.css を読み込ませて、要素をリセットするという事。
やじまの雑記ブログ。特にテーマは決めてません。
という人におすすめ。
これは「ツカエル」と思ったCSSは、ブログでも紹介するんですが、こういうリファレンスがあると、便利かも。
あ、なんか人任せでスミマセン。
あと、最近のサイト制作でのコダワリといえば、最初に YUI.css を読み込ませて、要素をリセットするという事。
IE8のパブリックベータが公開されていますが、いまだにIE6がIE全体の半数を占めています。
サイト制作の立場から言えば、IE6からのアクセスもまだまだ無視できないですね。
ところがIE6は、CSSの実装に致命的とも思えるバグがあって、表示結果がIE7やFirefoxのそれとは、かなり異なる場合があります。
特に注意したいのがマージンをとったブロック要素をフロートした場合。
IE6では、フロートした側と反対側にマージンを2倍取ってしまうバグがあります。
<style>
.block {
display: block;
float: left;
margin: 5px;
}
</style>
といったCSSを記述した場合に<li class=”block”>~~</li>を2つ並べたとすると、「左側のマージンは、0になり、右端のマージンが10pxになってしまいます。
そこで、IE6では、display:block を display:inline にすることで IE7 や Firefox と同じ表示にします。
<style>
.block {
display: block;
float: left;
margin: 5px;
_display: inline;
}
</style>
2番目に指定している display に _ (アンダースコア、アンバーバー)が付いているのが分かりますでしょうか。
この _display というのは、正確にはCSSの記述としては正しくないのですが、ここもIE6のバグで、「_」のみを無視してそれに続いて記述されているスタイルシートを有効にしてしまうんですね。
IE7 や Firefox の場合は、_で始まる要素は、それ全体を無視するので、上記のスタイルシートの場合、IE7 と Firefox では、display: block。IE6 では、display: inline が適用されます。
IE6 で display: inline にも関わらず height が使えるのもなんだか釈然としないんですが、まあ、実際にブラウザでそうなるんだからよしとします。
他にもIE6に対応させるテクニックは、さまざまなサイトで検証されています。
例えば、ブラウザ毎に読み込ませるスタイルシートを替えたりするのが王道でしょうか。
<link rel=”stylesheet” type=”text/css” href=”style.css” />
<!–[if lt IE 7]>
<link rel=”stylesheet” type=”text/css” href=”ie6.css” />
<![endif]–>
上記の記述では、IEのバージョンが「7未満の場合」に ie6.css を読み込むようになります。
他の IE7 や Firefox の場合、<!–[if lt IE 7]>から<![endif]–>までがコメントとして無視されます。
サイト全体を IE7 と Firefox の環境でコーディングし終えた後で、IE6でチェックして、おかしい部分を ie6.css でスタイルシートを上書きするというやり方。
非常に多彩なモジュールが公開されている Zen Cart なんですが。
公式が1.3.0.2なので、公開モジュールのほとんどがEUC-JPであったり、PHP5に対応していなかったりします。
ま、ようは文字コードとPHPのバージョンの問題だったりするので、ソースを見て修正すれば、そのほとんどが使用できちゃうんですね。
あと、最近ハマりかけたのが、「有料モジュール」だからと安心していたら、単純なPHPの記述ミスがあったりした事です。
KAGOYAサーバー(専用サーバー50)で、Zen Cart のテストサイトをアップしているんですが、しばらく何ともなかったのに、突然アクセスしづらくなってしまったんですね。
何か新しいモジュールを入れて、それが原因であれば、そこを取り除くのですが、今回の場合、セットアップ済みの複数サイトが同時に同じ現象に見舞われてしまい、標準インストールのままのサイト(zc_installすら削除してない)までアクセスしづらい状況になってしまったんですね。
アクセスしづらいというのは、更新ボタンを押せば、なんとか表示するけど、次のページへリンクするとまたエラーが出るといった感じです。
Zen Cart ではないんですが、同様のPHPを使ったCMSで同じ現象に悩んでいた方がいたみたいです。
自分は SAKURA なんですが、相棒が KAGOYA でして、OpenPNE の設定でかなり長期間悩んでいました。一緒になってネット検索などをしているとここに当たりました。
酔生夢死: KAGOYAでOPENPNEその後
http://blogs.dion.ne.jp/php/archives/6159089.html
ここによると、ちゃんと「OpenPNE セットアップガイド」通りにやっても管理画面でエラーが出るとのこと。
たしかに、Syntax error が出ました。このエラーから文字コードか OpenPNE のバグかといろいろ探っていたのですが、KAGOYA そのものの問題でした。
ちなみに環境としてはカゴヤの共用プランに独自ドメインという仕様。
インストールというかセットアップに関しては前回述べた通り、session.auto_startとmbstring.encoding_translationのデフォルト設定によりうまくいかないので、こいつをhtaccessでポチッとな、とするだけ。
結果、KAGOYAのデフォルトPHP設定で「mbstring.encoding_translation」と「session.auto_start」がONになっているのが、問題だったというわけ。
しばらく、自分開発のコンパクトなPHPカートを作っていたのですが、最近またZen Cart を弄ってます。
コンパクトなPHPカート(名前はまだない)は、それはそれで、既存のブログに追加したり、HTMLで既に出来上がっているサイトに簡単に追加できるので、便利なんですが。
(個人的には、MODxでサイト構築して、SnippetsでPHPカートに飛ばしたりする方法がいい感じになってきている)
ところが、最近の受注案件では、一からの構築と、高機能を求められるのでそういった部分には、「高機能ショッピングカート」としてZen Cart が必要になってくるわけです。
OsCommerce やEC-CUBE といった選択肢もあるのですが。
取引先の業種にもよるのですが、ちょっと特殊なことをやろうとするとZen Cart でないと“小回り”が利かなかったりするんですね。