ここ暫くの間、当ページをWin版IEで表示する際にIE自体が動作不能となる原因不明の不具合に悩まされていた。しかし、その原因が今日になってようやく解決。
DIVタグにfirst-letterを適用するとIEがクラッシュするみたいですな。
つーか何なんだこの仕様は。CSS自体は表示出来ない属性を無視するという規格に沿って設計されている筈なのだが、よりによってCSSの仕様にきちんと従っている場合であってもクラッシュしてしまうとは何事か。それ以外にも実装の甘いプロパティが随分存在するようで、コンテンツの一部が表示不良に陥ったりしている。…以上の理由から、本Doblogを閲覧される際にはNetscapeないしはSafari【Mac】を熱烈推奨します。

しかし、DoblogはWin版IEでしか動作しない機能が多くてどうしようもないですな。その最たる例はホームページへのリンク。Win版IE専用のツールバーがインストールされていない環境においてはスクリーンキャプチャ付きで他サイトへのリンクを張ることが出来ず、私の場合は渋々研究室のマシンからURLリンクを行っている。この件に関しては直接機能改善要望を出したこともあるのだが、数ヶ月経った今となっても改善される気配が無いのでもう諦めました。この程度の機能であれば、別にブラウザに依存することなく実装可能な気もするんだが…。

iPod強化計画も一段落し、研究室に戻った所で長野上司から召集令状。というのも上司曰く「俺明日から実家（※長野）に帰るから、その間ネットワークのことヨロシク」ってこんな新米部下に突然ネットワークの管理を任されても困りますですのよハイ。
とは言うものの、当の長野上司も現状を把握出来ていないらしく、某OBに現在問い合わせている最中とのこと。しかし頼みの綱であるOBともマトモに連絡が取れず、結局問題は解決されずじまい。…なーんだ、結局放っておけって結論に達する訳ですな。（←違）

それはさておき、長野上司とあれこれ話していたらふとこんな話題に。
上司「俺のサイト広告バナーが邪魔で、フレームで区切ると全フレームに広告入っちゃうんだよ。」
井戸「え? 僕が前使ってた『ジオ』はページ毎にON/OFF出来たんですけど、そういう機能無いんですか?」
上司「アップした段階で勝手に埋め込まれてるみたい。あー、広告ナシのCGI使える安いスペースって無いかなぁ…?」
井戸「広告消すだけだったら、スタイルシート使えば簡単に出来ますよ。」
上司「…へ?!」

と言う訳で、日頃培ったCSSテクニックをここで披露することに。
上司のサイトを覗いてみると、確かにページ上部に自動で埋め込まれたと思われるテーブルタグが。詰まる所、今回のミッションは‘ページ最上部にある広告のテーブルを非表示にして、なおかつ位置属性をキャンセルせよ’ということになるのでありんす。つーか、こんなのCSS使えば一瞬です。伊達に週20時間もCSSいじってる訳じゃありません。

ということで、早速井戸中蛙の3分クッキング開始ー。
本当に消えました。
つーか、こんな簡単に消せてしまうとかえって拍子抜けである。CSSを全く知らなかった長野上司は殊の外驚いており、遂には「俺もスタイルシートやろっかなー…」等と口にし出す始末。そう、CSSとはWebページのレイアウトを行う上で最強のツールとなるのである。ただブラウザによって実装状況がまちまちなんですがな。

暫くお見苦しい状況が続きますが気にせんといて下さい。
つーか、久々にDoblogのHTMLソースを本気で覗いたんですがとことんカスタマイズしづらいですな。重要な部分に限ってclass指定がされていなかったり、階層構造がやたら複雑だったり。おまけに各社ブラウザのCSS実装結果が全然仕様に沿っていなかったりと、詰まる所思った通りにレイアウトが再現されません。
ということで、早いトコ何とかせんとなー。

という訳で、昨日初めて触れたCGIシステムが早くも実験段階へと突入。
…それにしてもPerlとはとんでもねぇ言語である。それっぽく打っただけのソースコードがそれなりに動作してしまう為、コーディングが進むにつれてどんどん手応えが無くなっていく。こんな現象はC++でもObjective-CでもJavaScriptでもTclでもAppleScriptでも味わったことが無く、何とも気持ち悪く感じられる。
そして困ったことに、職場で使用しているレンタルサーバはUTF-8で保存したCGIソースを認識してくれず、多言語化が期待されていたシステムであるにも関わらず実験段階で頓挫。まぁ、これに関しては致し方ない問題なので、英語版と日本語版の2本立てで運営していくことで決着。

お仕事の時間はあっという間に過ぎ去ってしまい（※結構楽しんでいる証拠）、真っ直ぐ研究室に戻って情報処理。これまで研究用のデータや講義資料の類を全てUSBメモリに保存していたのだが、USBメモリ自体の信頼性が著しく悪いのでMOへ移植。
その際に研究室内でとんでもない議論が交わされていたのだが、その内容に関しては追ってHTML化することに決定。

帰宅後は絵無捨てを観つつ食事を済ませ、晩酌しつつ雑用。そろそろ期末レポートも仕上げていかねばならないのだが、諸事情によりモチベーションが下がりまくっている。

【カラーマネージメント対応ブラウザ】
・Safari v1.2.2
・OmniWeb5.0 RC1

なお、Win環境下でプロファイルの埋め込まれたJPEGファイルを閲覧する際は、一旦デスクトップにダウンロード後MSフォトビューアで開けば期待する色調が得られる。
また、Win環境のフォントは名称に半角カナが使われている場合があり、これらのフォントをCSSのフォントスタイルに指定するとCSSファイルそのものが読み込み不能となるので注意。何なんだこの仕様は…??

そして、Win版IEではmargin:auto使用時にバグが出る。やってらんねー。

ということで、早速ダウンロード&動作チェック。従来バージョンと比較するとCSSの表示能力がかなり改善されているが、相変わらずJavaScriptはダメダメ。まぁ、全く使い物にならなかったCSSがここまで改善されただけでも良しとするか…。

言うまでも無く、私はアウトロー志向である。パソコンと言われれば真っ先に思い付くのはMacだし、そこで使用するブラウザと言えば当然のことながらNetscapeであった。
…ほんの数年前までは。

ご存知の通りNetscapeはver.5の開発に失敗し、その後リリースされたver.6もベータ版からスタートする有様だった。OS9時代からのMacユーザは好んでNetscapeを使用していた訳であるが、CSSの実装に大きな問題のあったNetscape Communicator 4.7.xが時代遅れであったことは当時の我々にも明らかであり、その後リリースされたver.6も余りに動作が鈍かったことから、ユーザは次第にIEへと傾いていった。特に、Mac版のIEはWin版に実装されていない『アーカイブ形式での保存』にも対応しており、それは単一ファイルで全ての埋め込まれた要素を保存出来るという大変優れたものであった。当時のIEには、それだけでも「使いたい」と思わせる程の説得力を持っていたのである。
かく言う私自身も、OSXに乗り換えて暫くの間はIEを使用していたが、Apple純正ブラウザ『Safari』がベータリリースされてからはずっとSafariをメインに使用しており、フォトギャラリーを保存したり重要なフォームに入力したりする際のみIEを併用するようになった。一方、ver.6のベータリリース時にダイヤルアップ回線で全コンポーネントをダウンロードした位愛着のあったNetscapeは、最早CSSの表示チェック用にしか使わなくなっている。その理由は明らかであり、スクロールバーにせよ何にせよ独自仕様のインタフェースがどうも馴染まないのである。日本語表示もフォントの設定が甘いようで、何となくぎこちなさを感じてしまう。CSSの実装という面ではSafariに並んで洗練されているNSであるが、最早積極的に使用する気は全く起きない。

しかし、この期に及んでようやくNetscapeの最新版が公開されるとの噂である。どうやらマイナーアップデートに留まるようなので私自身余り期待はしていないのだが、果たして一般ユーザーに今回のバージョンアップが受け入れられるのであろうか? 特に今日のNetscapeのようなオンラインウェアの場合、ダウンロードして貰えない限りユーザー数の拡大は期待出来ない。我々のようなWebデザイナーはもとより、新バージョンがどれだけIE志向のエンドユーザーの心を捉えることが出来るか、是非注目していきたいものだ。

昨晩から今日の午前中に掛けて、以前から気になっていたJavaScriptの最適化作業を行った。HTMLに直接埋め込まれていたコードを外部ファイルに移しただけであるが、ページによってはファイルサイズがが8割以上削減された。少なくとも、Safariのようなキャッシュが積極的に働くブラウザにおいては、読み込み速度が劇的に改善されている。
しかし、依然としてJavaScriptの冗長部分が気になってしまう。外部JavaScriptファイルだけでも156kBというのは如何ともし難い。だが、これ以上ソースコードを簡略化するのは事実上困難であるため、暫くの間はこのまま様子を見たい。

それと同時に、DoblogのCSSも若干いじった。これまではfont-familyがきちんと動作していなかったのだが、若干修正を加えてデフォルトのフォントをヒラギノに変更。Mac OS X環境での見やすさはかなり改善された（と思う）。

ついさっきメールチェックしたら、迷惑メールが15通も届いていた。
従来のウィルス系メールであれば、ヘッダを展開して‘Return-Path’をチェックすれば大方の送信元は特定出来た。しかし、今回の迷惑メールはその辺の偽装がかなり巧妙に行われているようで、送信元アドレスとリターンパスが同一のもので指定されている。ひとまずYahooとBIGLOBEが集中的に狙われていることは突き止めたのだが、これでは何の対策にもならない。中には私のアドレスで偽装送信されたメールもあったようで、それに対して御丁寧に返信までして下さった方も居たようだ。
…偽装迷惑メールに返信する奴があるか、アフォ。

何はともあれ、私からインターネット経由でメールを発信する場合は必ず『.Mac』アドレスを使用しているので、個人的に面識のない方に対してもしSo-netアドレスでメールが届いた場合は、ほぼ確実に迷惑メールであると言える。私自身何も悪いことはしていないので「開封しないよう気を付けて下さい」としか言い様が無いのが現状だ。

個人サイトのJavaScriptが余りにも冗長だった為、少々スリム化を図った。ソース自体がImageReadyの吐き出したものを統合しただけという代物で、一部にはバグに相当する冗長部分まで存在する有り様だったからだ。
回避方法は以前から検討していたのだが、その結果switch構文の‘ようなもの’を使用することで回避出来ると判断。つーかJavaScriptにもswitch構文使えるんじゃーん! ということに今更気付き（←遅ぇよ…）、実際に試してみた所あっさりと解決。何て幸せなんだ。

こうして、残るJavaScript関連の懸案事項はHTMLソースにベタ打ちされているコードのスリム化だけとなった。ページによってはテキストだけで60kBを越える代物となっているので、早急に何とかしたい。これさえ解決出来れば、本当に携帯電話でも閲覧出来るページに仕上がるのだが…。