Information

-- 2007-03-31

色々とテストした結果、結局 display:blank は、使わないことにした。

百害あってではないが、プログラム的には非常にスマートなんだけれど、できるだけ多くのブラウザで表示できるべきだという大前提にそぐわない。結局、使い古された Javascript で表示をコントロールすることにした。それでも css と Javascript ファイルでデザインを決定し、html は意味ベースで構成というコンセプトは外せない。とりあえず、満足のいくソースが作れたので、これでまたテストを重ねてみる。

だんだんとXデーが、近づいてちょっと焦ってきた。でも妥協すると結局後が面倒なので、ワイフには悪いと思っているが、夜遅くまでコンピュータの前にいることが多くなってきた。

-- 2007-03-30

新しいサイトのトップページのデザインを調整している。

新しいサイトはデザインはもちろん、ソースコードも丁寧に作成してみた。XHTML は意味ベースで組んで、css と Javascript でデザインを与えている。css でも色や形などの属性を動的に変更できるが、それはあくまでも自分の属している構造体に対してだけ。全く別のオブジェクトの属性を動的に変更するためには Javascript の出番となる。

色々と試していたら Safari が落ちた。何度やっても落ちる。どうやら Safari のバグらしい。回避策を講じるためには、原因が不明ではどうしようもない。調べていくと、どうやらオブジェクトの display 属性を変更する時に落ちる事が判明。つまり・・・

obj.style.display=none;

　こいつを実行した後で、ページを再読み込みすると落ちる。少なくとも Safari/419.3 では再現性がある。ということで、Safari だけ、この命令を実行しないようにした。将来は特定のバージョンだけ封印するように変更しないと、Safari ユーザだけ、永遠に見る事の出来ない動作となってしまう。とりあえず Apple には報告済み。

-- 2007-03-27

サイトデザインの見直し作業が続いている。

ネット上に沢山ある情報は、非常に参考になる。しかし解せないのは、css の解説や html の解説をしているサイトのページが時として文字化けする事だ。そして、文字化けの原因を追及しているサイトもあるけれど、的外れなことを書いているサイトも多い。一番解せないのは、特定の文字を HTML 文に埋め込んで文字化けを回避するを今だ得意げに解説しているところがあることだ。

文字化けの原因は、HTTPプロトコルヘッダにあるキャラクターセットと、実際のページのキャラクターセットが異なる事にある。これが原因のサイトがほぼ100%を占める。

HTML でもキャラクターセットを指定できるが、それは HTTP でキャラクターセットを指定しない時に使えるテクニック。もし HTTP でキャラクターセットが明示的に指定されている時には、それが優先されるし異なるキャラクターセットを HTML に使うべきではない。

HTTP と HTML は全く違う。当然キャラクターセットに対する考え方も違う。HTTP は、通信環境やサーバのモジュールやモジュールを動作させるためのプログラムの関係からキャラクターセットを決める。HTML はデザイン上の問題でキャラクターセットを決める。 HTTP のキャラクターセットと相容れないキャラクターセットを HTML で採用する理由は全くといっていいほど根拠が無い事がほとんどだ。確かにデザイン上 Unicode が使えれば、使える言語の幅も広がるし使える文字も多くなるので、使いたいとデザイナーが思うことはあるだろう。しかしそれを支えるシステムが無ければ、デザイン以前の問題だ。

ちなみに G-ZONE では、過去の悪習から Shift JIS を HTTP のキャラクターセットとして送っている。XHTML でもキャラクターセットを指定するときには当然これに従う。唯一違うのは、Google bot 向けの xml。Google bot が Unicode を要求しているので、送信するファイルは UTF-8、もちろん HTTP のキャラクターセットも UTF-8 をセットして送信している。

と、かっこいいことを言ったが、現在の G-ZONE での HTML キャラクターセット指定は酷い。x-jis となっているところがほとんど。shift_jis に改めなければいけないが、どうせ新しいデザインで一新されるからほったらかし。

新しいサイトは、できる限り w3c の仕様通りのフォーマットにするつもりだ。これで、問題が出るとするとブラウザの問題。しかし w3c の仕様通りに送出している限り、少なくともブラウザで文字化けが起きて読めない事はないと断言しても良いだろう。まあ、IE はこの辺を上手く処理できるので、大抵文字化けを起こす事は無い。

しかし、IE でしかテストしないサイトの場合、所詮 IE でしか見る事は出来ない。もし、IE がバグを修正し、正しい css の解釈ができるようになったとたん、それまで美しかったデザインは地に落ちた醜いものに変身。ウェブデザイナーは慌てて対応することになりかねない。

間違った情報は、全て勉強不足からくる。情報収集能力も必要かもしれない。自分も気をつけなければならない。改めて G-ZONE にある記事を読み返すと、勉強不足のところが目につく。精進あるのみ。

-- 2007-03-22

自慢じゃないがHTMLの記述について知らない事はいっぱいある。なんだ、そんなことも知らないのか！　と言われてしまいそうだけれど、ハートマークは ♥ と書けることを最近知った。XHTMLでも同様だ。

こうした仕組みは文字実体参照というが、よくお世話になっている ⁢ や > はHTMLを使い始めた頃から知っていた。こうした文字実体参照は通常コードを記述するもので、意味をもつように記述できる文字は限られたものしかないと思い込んでいた。が、実は沢山ある。

参考：特殊文字実体参照

ハートマークについていえば、♥ も ♥ 同じに見えるかもしれないが、最初のは ♥ で ♥ とHTMLの記述は違う。どちらが良いかは、どのブラウザ表示ができないとならないと考えるのかで異なることになるだろうし、HTMLソースを直接見た時のことも考えるだろうから一概に言う事はできないだろう。でも知っていて損は無いので、ここにメモとして残しておくことにした。

余談だが、某有名アニメで話題になった文字 ∀ は ∀ と書く。

-- 2007-03-20

なんとか、MacOS IE でも似たような表示になるようになった。色々とあきらめなければならない動作もあったけれど、まあ満足。今回の実験で、試したブラウザの中で一番 w3c の css に近い形でレンダリングできたのはFireFoxとい結果になった。Safari もいい線いくけど、フォントの大きさがおかしい。MacOS だけ使っていると、フォントの大きさの違いには気がつきにくいが、各プラットフォームの画面解像度と関係している。というか、Safari だけが、72ppi での表示にこだわっている感じだ。

例えば、12ポイントの文字を表示すると、それは12ピクセルの高さになる。けれど MacOS で12ポイントの指定をしたとき、Windows で同じデザインのページを見ると文字が小さく見える。逆に Windows で12ポイントの指定をしたとき、MacOS で同じデザインのページを見ると文字が大きく見える。これは次のように計算できる。

MacOS の12ポイントデザインを Windows で見た時：
　12pt×72ppi÷96ppi＝9pt

Windows の12ポイントデザインを MacOS で見た時：
　12pt×96ppi÷72ppi＝16pt

実際比べてみると、随分と違った印象だ。

これは MacOS、Macintosh が誕生した1984年頃（開発プロジェクト開始は1979年と言われている）での技術力と関係している。ブラウン管の解像度を高くすればコストが嵩む。プリンタとの絡みもあるが、当時の技術力でコストを考えての決断といえよう。Windows が登場したのは、このずっと後のことだから、96ppiでも安い供給が可能だった。

この誤差は、これまでのG-ZONEのデザインでは無視してきた。無視しても気にならないようにデザインしたということだ。ちゃんとデザインする時には、この画面解像度の差は気になる。css ではポイント指定でなく、文字の大きさをピクセルで指定する事も可能なので、css でのデザインだと解像度の問題もクリアできるのは魅力だ。

-- 2007-03-19

いつのまにか Google で ３Dモデルリングツールの無料配布をしている。SketchUp というツールがそれ。すでにおなじみの Google Earth と連携して建物を配置できるらしい。実際使ってみると他のツールとは違った癖があってなじみにくいところもある。しかし単純なインターフェースは、むしろ他のツールより慣れるのには時間がかからないかもしれない。

他のツールとファイル交換をするためには、Pro を購入する必要があるらしい。ちょっと面白いので、息抜きに何か作れるかもしれない。

-- 2007-03-19

ああ、こんなところに落とし穴が・・・

新しいサイトのおおよそのデザインが出来上がった。インターネット関係における開発は Unix コマンドが豊富でLinuxとは比べ物にならない使い勝手が良い事から MacOS で行っている。基本動作は、Safari と FireFox で確認。他にも Mozilla を使ってみたが、問題無し。もちろん一番多く利用されている Windows の IE6 でも確認。これはちょっと不満が残るもののおおむね良好。良し！

と、思ったが念のために起動した MacOS IE（intel-macでは動作しないアレです）を試したら、ガーン！　全然違うものが表示された。どうやら MacOS IE は、css の解釈が問題ありのようです。Safari も G4 上と intel 上では動作が微妙に違うけれど、そんなレベルじゃない。これじゃあきっと、MacOS 9 のユーザにはガッカリな状況だろう。ここを参考に、最大公約数的なデザインに再挑戦することにした。

-- 2007-03-16

寒いと思ったら、窓の外に白いものが舞っている。

今、全面的にG-ZONEのデザインを見直しているところ。G-ZONEはサイト構築のためのノウハウを蓄積するための色々な実験場でもある。技術面ということではなく、バランスのとれたサイトの作り方というかコンセプトの実験場だ。

G-ZONEのデザインは単純に見栄えを良くするだけでなく、コンテンツの内容に沿ったバランスと、できるだけ多くのブラウザで同じに見えるよう工夫している。G-ZONEのデザインは、使い古されたテクニックだけで作ってある。それは、古いブラウザやマシン環境のことを考えての事だ。これまで JavaScript や css はもちろん、あまり多くの画像を積極的に使わないようにしていた。しかしインターネットを取り巻く技術が進歩し、ここ数年の動向を見て安定期に入っているように思える。

世は ajax とかに浮かれているようだが、G-ZONEのユーザインターフェースとしては今回は見送る。理由は簡単だ。まだ ajax は安定期に入っておらず、ブラウザ毎の対応が異なるところがいまいちだからだ。しかし css は違う。とはいえ、相変わらずマイクロソフト社のIEは、css の解釈に問題がある。そのために csshack なる奇妙な技術もある。

G-ZONEに csshack を持ち込む気にはならない。そこまでしなければならないようなデザインというのは、デザインじゃないような気がする。挑戦的に行う事はデザインではないだろう。利用者がいてデザイン。観客に挑戦したらアートだと思う。G-ZONEはアート作品じゃないので、使い勝手の良いデザインがあれば良いと思っている。でも実用本意ということでもない。そのあたりがデザインできればいいなあ。

-- 2007-03-08

　Gs Mall に更新情報っぽいものを取り付けた。ちょっとした思いつきだったが、それっぽいので、そのまま公開。

　Gs Mall のページは、ちょっとショップっぽい雰囲気にするため、わざとニギニギと並べ立てて賑やかにしたつもり。広告を載せてるのも、そうした賑やかさの演出。ショップにするにはカートシステムを置べきだろうけど、それではやりすぎ。個別のお気に入りリストを作成出来るようにしたいと思うが、そのためには認証システムが必要になる。それもちょっとやりすぎか。程よく賑やかな雰囲気と使い勝手があると良いな。

-- 2007-03-02

Googlebot にちょっと興味が出たので、昨日に続いて G-ZONE のアクセスログの話。

ログを見ると２種類のロボットがクロールしている様子が伺える。ここで Google で Googlebot を検索すると、大別すると２種類、全部で３種類に分類されてそれぞれ役割があるらしい。大きくは、ＰＣ向けのコンテンツを探す Googlebot。それと携帯サイト向けコンテンツを作成する Googlebot-mobile。Googlebot-mobile は、さらに chtml コンテンツ用と xhtml コンテンツ用があるという。

G-ZONE ログにある Googlebot-mobile は、Nokia6820/2.0 と入っているので xhtml コンテンツ用ということになる。Nokia の公開されているブラウザの仕様に従ってクロールしているということだろう。問題は、Googlebot-mobile のクロールが 27日11時頃から28日18時頃までの間に、異常なまでに集中してきていることだ。この間にクロールした総ベージ数は、G-ZONE のサイトだけで5000ページ以上になる。特に27日の昼頃は、１秒に１度の間隔でクロールされた。Google からのアクセスじゃなかったら、拒否したくなる頻度だ。これが、先日のプログラム修正をする原因の一旦を担っているのかもしれない。良い勉強になった。

Googlebot-mobile は、その後アクセスしてくる気配がない。満足したらしい（笑。一方 Googlebot は、数十秒に１度の頻度でクロールしている。ところでクロールと書いたけれど、Google の言うところのクロールは「サイトをアクセスして読み込む」ことではないらしい。その後、コンテンツとして整理されて初めて「クロール」と言うようだ。どうもこの辺の用語が、自分の中では消化されていない。さらに興味がわいてきた。