スタイルシート、JavaScript、DOM、ブラウザ判別、PHP 等ウェブ制作関連の各種情報
当方、通常制作環境は MacOSX なので、MacOSX 環境の方はそこでウェブ制作をするための環境構築について、ウインドウズで制作している方には Mac だとこう違いますよ、みたいな参考情報をあわせて書いてみます。
IE6 でしかチェックしていないようなウェブページは、他のユーザーエージェント利用者が悲しい思いをしていることが多いので要注意です。逆もしかりですが、もともとマックユーザーなんかは少数派を自認しているから結構一生懸命他の環境チェックしてたりするんじゃないでしょうか？自分はそうです。
いろんな方にちゃんと見てもらえているデータを作っているのかどうかは、きちんとした HTMLソースを書くのは重要ですが、結果をその環境で見てみない限りはわからない面が多々あります。個人でやっているからどうでもいいとかということではなくて、ことウェブに関しては自分が通常使っている以外でどんなふうに見られているのかを知りたいのは制作者自身でしょう。場合によっては「同じマシン、同じOS」でもユーザーの設定によって全く違う見栄えになっていることもあります。制作者が意図していない状況になることはいくらでもあります。
最近ならブログの普及とともにスタイルシートを使ってレイアウトしているページが増えています。ただしそのこと自体でヨシヨシとはなりません。結果として「レイアウトが崩れて内容が読み取れない」ページがあります。サービスやサポートサイトで「見れない」のは非常に困ります。「CSS を使うことが重要。だから崩れても仕方がない」って訳にはいきません。JavaScript や CSS 非反映設定に自分で変更することもあります。こう書いている自分が作ったサイトでもすべて完璧ではなくてユーザーからメールを貰うこともあります。制作者として恥ずかしいことなので、なるべくそういうようなページにならないようにしているのは当然ですが、ユーザー側の環境は現実的にいくらでもあるので常に注意をはらっていなければならない状況です。そのような問題をなるべく防ぐには制作者側ができる限り様々な環境での表示（動作）チェック環境を用意するしかありません。「○○には対応していません」「○○でご覧ください」とホームやアバウトページに注意書きをいれたりもしますが、自分はその注意書き自体が恥ずかしいことだと思いますし、恥ずかしい恥ずかしいでは済まない。プロだから、アマだからも関係ありません。「（自分が作ったものを）多くの人に見てもらいたい」そう思うなら対処をしたくなるのが当然のこと。その上で。
あなたがプロの制作者だとするとクライアントの要求に答えることは最重要かもしれません。しかし、そのクライアントからたとえ口頭で要求されなくてもクライアント以外にも、サイトに訪れるユーザーの要求に答えるサイトの構築をするのがプロです。このまた当然の事がどれだけ大切でどれだけ大変なことなのかは、きっと本当のプロにしか理解できないでしょう。
Windows では PC 1台で OSふたつははいっちゃう（なんビットだとかの話はよくわかりまセン）ようなので、自分トコでは Windows2000 と Windows98 がはいっているマシンと WindowsXP マシン 2台で Windows 環境はほぼやりくりしてます。一応 FTP 程度は Windows でも可能にしてますけど制作自体は 99% が MacOSX の PowerBookG4。他に MacOS9 マシンと Windows95 マシン。通常は Windows95 （立ち上げる時は勇気がいる）を除いた 4台で、IE の 5.01 以降、Netscape4 以降、Opera5 以降、ドレかのマシンで動いています。MacOSX で Apache サーバー上で制作したウェブデータは、ローカルネットワーク上にはいっているそれらのどのマシンでもみることが可能です。このような環境は以前だとかなり苦労しました。今はそうでもない。
実際のドメインを使った絶対パス指定による制作以外にローカルネットワーク上での動作チェックでできないことは殆どありません。昔から Perl 等での CGI 制作者だったらそういう環境が絶対必要だった筈で、現在だったらブラウザ毎の「見栄え」の違いを見る為だけに各種ブラウザ閲覧環境を用意するということではなく、サーバーサイド処理に関しても手元で記述して、自分の周りの PC 上のブラウザでリロードすると全部チェックするということまでできます。自分の場合だと MacOSX を手にしてからとその前までが雲泥の差。ドメイン名称までは無理でも公開サーバーと殆ど同環境の別制作環境を手元で用意して動作チェック、表示チェック等をやれるだけやりつくしてからサーバーにアップが可能。まぁここまでいっちゃえばやりたい方は自宅に公開ウェブサーバーを用意するまでいっちゃうんですが、自分の場合はそれが目的ではなくて、多数のウェブサイトを構築してそれとなるべく同じ環境を手元に置きたいということです。
現在の最新機種はわかりませんが、Classic 環境同梱の Macintosh にはいまだに Netscape4.7 がプリインストールされてきます。使う使わないはユーザーの自由ですし、ウェブ制作者関係はチェック用に便利ですが、普通の方ならもういらないと思います。ネスケ4 ってもう 5年以上も前の製品なんですね。
アップデートは可能ですからそうそう問題にはなりませんが、ついに完全サポートレスになってしまった MacOS9 についている IE5.0 は、バグだらけでもう大変なシロモノです。5.17 （これ以降のバージョンアップはありません）をユーザーに勧める以外に手はありません。（手に入れるのも難しいですが）それ以前に MacOSX 環境であれば、普通は Safari を使う筈で、よっぽどのことがなければ一度 Safari を使っておいて「こんなん IEのほうがイイ」って方はいないとは思うんですが、当面は対処を常に考えなければならないブラウザでしょう。何故かというと OSX にアップグレードしていない OS9 ユーザーはまだまだ多いこと、OS9 ユーザーのメインブラウザが IE5 であることというのが大きな理由。自分はもう MacIE5 対策はやりたくない気が満々なのですが（笑）
制作自体はほとんどコレだけでできるんですけどね。OSX のUNIX環境は、ウェブ制作者でもともとマック使いだったら、他の環境には戻れないくらい最高です。便利になりました。ただ、やれること増えたら、もっと忙しくなりました。
2005年2月20日更新
メインマシンのハードディスクがぶっとんで、ゼロから環境構築をしたので簡単に書いとくことにしました。自分も面倒なことは避けたいので、おそらくちょっと MacOSX に慣れていて、ウェブ制作している方なら誰でも可能なことくらいしかやってません。MacOSX は UNIX サーバーと殆ど同じ環境にするのが他と比べれば楽です。UNIX 知識はあるにこしたことないけれど、自分は殆ど知りません。今だったらそれに必要なら専門家も周りにいるし、オシエテ攻撃もできたりするので。だけど、そこまでやらないでもだいたい自分の希望する環境にはできます。
ウインドウズでもできるみたいですが、余り知りません。Apache はいれてみたけど内部処理的に専用記述をすることになるので公開環境が UNIX 系である場合と同じという訳にはいかないみたいだし、なにしろ慣れてなくてディレクトリ構成とかよう分からんので。なので情報はいっぱいあるので他をあたってください。
サーバーサイドのスクリプトなんかを自作したいならローカルでなんぼでもチェックできる環境があるに越したことはありません。
とりあえず、現時点で（2005年2月）マッサラな OSX 上にて PHP、CGIが動いて、ついでに MySQL と PostgreSQL も使える状況になるべくややこしいことせずに（ターミナルとか使わない（笑）ようにと思ったけどやっぱり使う）やる方法。ちなみに OS は MacOSX10.3.9 です。
「自分のために」毎度この構築は結構な手間なのでメモしとこと思ったけど、自分でかいといたもとネタのメモ自体がさっぱりよく分からない（爆）。書くならちゃんと書け、といいたいトコロなんですけど、ごめんなさい。必要なリンク先等くらいは近日整備します。
てことで手元の MacOSX マシンでいろいろやりたい方は
こうやってキレイにまとめてくれている方がいて助かりますね。
ここにもある。こんなに情報あるから自分は書かない（笑）
なにに必要なのかよく分かってませんがいれました。ハードディスク食います。OSX のパッケージ買ったらついてきます。または Apple のサイトにいってダウンロードできます。会員にならなきゃダメかもです。自分はなんかよくしらなけどなってたりする。
MySQL のサイトいってダウンロードします。MacOSX 版のパッケージでてます。OSX マシンは最初からはいってるんですが、バージョンが新しくなってたり、パッケージのインストールは簡単だからやっちゃいます（笑）。
PHP ももともとはいってますが MySQL と同様。自分は GD 使いたくて以前は単品ダウンロードしてコンパイルしてってやってみましたが冷や汗タラタラだったので「そういうチャンとしたやり方を覚えてやる」という根性ある方はそうしてください。なにしろ便利な必要なライブラリがタンマリはいってるパッケージが普通にインストーラ使っていれちゃえるので、それ使っちゃう。
PostgreSQL に関しては業務上使うのでいれた。だけどチョッピリ難しかった。最近 MySQL のほうが増えてきてますが。
パッケージに関しては以下のリンクにあるやつをインストールするのが一番簡単。
必要なモジュール付きの PHP の最新版が簡単にインストールできます。戸惑ったのは error_reporting が変わっちゃったことくらい。まぁいっつも .htaccsess にかいとけばいいか。php.ini 書き換えても勿論いいですけど。
ターミナル使ってやるのが普通ですが、それが不安なら TinkerTools いれて見えないファイル見えるようにして、いぢくりたいファイル（やディレクトリ）のユーザー権限変えて、テキストエディタ（自分は JeditX 利用）で開いて書き換えます。シロウトのやり方ですいません。でも手慣れたやり方で記述間違えないほうが重要。バックアップとったりするのは勿論。
プログラム絡みだとか DB とかを利用したウェブサイト構築やるんだったら .htaccess 等の設定記述を覚えることになります。ソッチからはいって、その .htaccess を動作させるにはどうやればいいんだ？と考えれば調べて httpd.conf の書き換えに至ります。失敗してわけわからなくなったら OS 入れ替えを覚悟しつつ、そうしたくないから慎重にやることになります。
MacOSX 環境で上記をなんとか動作させて、それだけでも以前とは雲泥の差でいろいろ作れちゃうのですが、どんどんもっと楽したいと思うんで。例えばブログを使いたくなって試したいと思うと MacOSX 上にインストールするんですが、そのローカル上で構築して「こりゃあええわ」と思ってそれをレンタルサーバー等に設置する時は設定ファイルやパス情報が違うわけです。その設定情報もなるべくなら揃えたいと思いませんか？そういう場合、レンタルサーバー側は変更は難しいのでその設定状況と同じディレクトリ構成を MacOSX 上に用意してそこでウェブアプリが動作できればパス情報なりでローカルで作ったものをそのままアップしちゃえばいいわけです。ドメイン情報とかはできないけど、ディレクトリ構成上データのアップロード等には絶対パスが使われますからそれくらい揃えとこうという。
で考えてみたんですが、そんなトキはシンボリックリンク使えばいいわけですね。以下はこの www.ichiro.to の場合。ローカルでは ichiro ってユーザー作って http://127.0.0.1/%7Eichiro/ ってブラウザでアクセスすると公開しているこのサーバーのやつと同じものがはいっています。Nucleus 等で記述してある公開サーバーの絶対パスとは違うので、そのディレクトリを作っちゃう。
ln -s /Users/ichiro/Sites/ 実際のサーバーのウェブルートまでのパスプラスそのディレクトリ名称
制作時は Sites/ 以下でいぢくって、その中で実際にアップするサーバーのパス情報が使われた時も該当ファイルをちゃんと呼びます。これでヨシ。
細部をいえばもっと楽するのに必要な部分もあるんですけど今回のところはこのへんで。
MacOSX を使っていて自分のサイトも持ってるけど、html ファイルはみれるけど CGI とかはサーバーにいれて試す、というような方はここまでできちゃうだけで感激でしょう。自分はこの環境のおかげで CMS やブログやフリーCGI なんかを気になるもんはどんどんいれて動かしてみていぢくって遊んでます。そう、これができるようになったからやっと自分で PHP とかのスクリプトプログラム書くようになった。誰にも迷惑かけないでのんびりできる。（仕事になるとのんびりできなくなったけど）以前は CGI の HTML箇所書き換えとかしてアップして、サーバーエラー何度も見て（おかげで Perl は嫌いになった）大変だった訳で。
それにしてもこれ簡単に書き過ぎじゃないか？とは思うけど詳細知りたい方は今や情報収集簡単だし。すいません。
と、いちお中身は随時更新するつもりはあります。だって全然不親切スギルし、自分でもまた再構築するときになんにも参考にならん！2005年 4月13日
※ユーザーエージェント名は、PHP で取得したものです。JavaScript で取得する内容と異なる場合があります。
※同じOS内のユーザーエージェントが同じマシンで動作させているとは限りません。
※チェック環境があるからといって、毎度毎度全てにわたってチェックしているとは限りません。
※Opera の送出ユーザーエージェント切り替えに関しては本物と同等と判断してはいけません。Opera は Opera。詐称してもサーバーサイドでのブラウザ判別で Opera と認識可能なため、処理によってはユーザーエージェント側での切り替えが効かないようにしてしまえる程度です。このへんは制作者側もユーザーの期待する動作を邪魔しないよう考えなければならない事もあります。サーバーサイドでの判別処理は制作サイド側からの押しつけがあえて必要な箇所で行い、JavaScript 等でも処理するプロパティ等によって詐称受け入れを有効にしておくべきこともあります。
※各種HTML、CSSコーディング、JS等の動作を作者の期待する動作にさせるための互換対策を可能な限りやるようにはしていますが、全ての環境で同じ見栄えや動作をさせるということとは違います。同じにすることが困難な場合に、どういう代替え処置をさせるか、を考えて実装することが重要だと思います。
※なによりも大切なのは判別切り替え手法や制作手法それ自体ではありません。コンテンツそのものです。その表現をウェブという環境の中でいかにユーザーに伝えるのか、よりよい表現手法はないのか、というために必要なことであると思うだけです。
2005年11月29日 00:24
フリーのウェブサイトディレクター。音響オペレーター。北海道札幌にて活動中。
Web Site designed by Studio Susto