JavaScript StyleSheet

以前のネタ帳でもちょこっと触れたんだけど、Netscape 4.xが採用しているスタイルシートにJavaScript StyleSheet（JSS）なるものがある。既に過去のものとなったブラウザー向けの技術だけあってすっかり忘れさられているのだけど、例えば商用サイトなどでNetscape 4.xがスタイルシート採用に対する障害になるのであれば、こいつを使って凌ぐのもいいかな、と思った次第。

とは妄想したものの、実際どうなのか。おいらのサイトでも試してみようと思った。記述法はZSPCのスーパースタイルシートリファレンスを参照した。

このページ用にJavaScript StyleSheetで簡単なスタイルを組んでみたんだが、いくつか表現力が弱いなぁと思った点がある。まず背景画像が繰り返ししか指定できない点。これはNetscape用にサイズの大きな画像を用意するかほかの表現を考える必要がある。また、文脈セレクタがおいらの環境では動かない（もっともこれはおいらの指定が間違っているのかもしれないが）。

また、幅が1行未満のブロック要素でスタイルが適用される範囲が要素そのものの幅に制限されてしまうのも気になる。hn要素のような幅に短かい要素に適用するときは、その幅を明示しておいたほうがいいのかもしれない。これらはCSSを使っているときにも同じ現象が発生していたので、CSSとJSSで同じロジックが働いているんだろうなぁ。

では、結局何のためにこれを使うのかというと、CSSでNetscape用のものをわざわざ作ってその限界にヘキヘキするなら、あらかじめ仕様が限定されているJSSを使ったほうがいいかなぁと（￣△￣；。ブラウザーの振り分けを特に設定しないでも、CSSのメディア属性に「not-netscape」とでも書いておけば、Netscape 4.xにはCSSが使われずJSSを見にいってくれる。

問題はJSSの表現能力なんだけど、マージンや色、背景といった基本的な成形をする分には必要十分。今でもWinIEで表示に問題のあるプロパティは無理に使わないようにしているし。要はCSSの表現能力に頼ったコンテンツ作りをしないように気を付ける、ということで。だらっと文字が流れている、いわゆる何も整形されていない状態を避けることが今回の発想の根本なのだから。

何年経ってもウェブ製作ちゅーのは、どこまでをひとつのスタイルに集約するか、どこまでを個別の環境のために対応させるか、そのターゲット設定のせめぎ合いだったりするものように思う。

application/xhtml+xml

先月13件のレスをもらいながら、どうするかを検討したapplication/xhtml+xml移行の件。ようやく今月から採用と。ここまで時間がかかったのは、要はおいらがウェブを取り巻く技術に対してまったくズブのド素人だったということ。あとは2ちゃんで油を売り過ぎた、というとこでしょうか（￣△￣；。

今回は、application/xhtml+xmlを吐き出すブラウザーをPHPで判別し、対象となるブラウザーに対してこのコンテントタイプでデータを送信する方式を取った。ヘッダの書き方やらエスケープの方法やら基本文法でつまづきながらだったので、結局時間ばかりが過ぎていく。テスト用に作りあげたコードはえらくシンプルだったため、自分のヘタレっぷりに余計にショックを受けていたり。

なにはともあれ、XHTML用のMIMEタイプを備えたコンテンツを吐き出せるようになった。ところが今度はPHPをページ初頭に埋め込むと、どういうわけだがXML宣言をエラーとして認識してしまう現象が発生。そこで、echo命令を使って<?php echo ("<?xml version=\"1.0\" encoding=\"utf-8\"?>") ?>と記述して、XML宣言を生成することに。

こうなるとローカルに置かれているファイルはもはやXMLでもHTMLでもない不思議なマークアップファイルに。Apacheを通して吐き出されることによって、ようやくXMLやHTMLとして生を得るわけですな。こういう考えに対しては「静的な状態でHTMLとして成立すべき」と異を唱える人も出てくることでしょう。

何はともあれ製作側としては、ApacheとMozillaの組み合わせで最低限の整数式状態の確認ができるので、それはそれでありがたい限りかと。こうしてコードを書いている最中でもタグの閉じ忘れをバシバシ指摘されているし。また今後、サイトのセマンティック化を進めていく中で、今回の変更の恩恵をじわりじわりと受けていくことになるんだろうなぁ。

今使っているXREAだと、無料サービス状態で適用されているApacheのmod_layoutモジュールがブラウザ判別後のhttpヘッダ挿入を邪魔してしまう。これも初めは何がなんだかわからなくて、View HTTP and HTML Sourceツールを使いながらようやく原因を突き止めた次第。何も知らないといらんことで苦労するねぇ（￣△￣；。

それから、せっかくPHPが使えるなら（というより、静的な状態でHTMLになっていないのを逆手にとって）、各ページで共通のパーツを外部に置いてしまうのはどうだろうと考えた。共通のパーツは「.inc」という拡張子を付けた外部ファイルに記述し、<?php require ("hogehoge.inc");?>というPHP命令文で読み込む。これらの外部ファイルの書き替えが発生すると、この命令が書き込まれているすべてのファイルで反映されるのがポイント。JavaScriptを使った読み込みとは異なり、どんな環境からのアクセスでもこの方法が使えるのもメリットのひとつ。

パフォーマンスがデメリットにならないか心配なんだけど、1日500アクセスが上限のうちのサイトでは微々たるものかもしれない。あとは.htmlの拡張子のままでPHPをパースさせる方法がわからなかったので、やむを得ず.phpのファイル名を使っていることもデメリットかなぁ。

いろいろ試してようやくXHTMLの文書らしくなってきた。ただし、w3cのバリデーターからはいくつか警告を食らってしまった。これは、DOCTYPE宣言でルート要素の指定を間違えていたのが原因とのこと。大文字でHTMLと書いていたのをhtmlを書き直したらValidになった。この辺、しっかり勉強しないとね（￣△￣；。

あとはDOM経由で、ファイル内のh3の内容とその上位要素divのid属性の値を使って、コンテンツリストを作る方法を探しているところ。XSLTを使えれば楽勝なんだけど、PHPもしくはその他の方法でこのファイル内に抜き出した結果を表示させるにはどうしたものかと。

同じ道

自分の記憶がどこまで確かかは、はっきり言って自信がないんだけど、あれは1年半前のMozilla Party 2.0の会場でのこと。セミナーの最後を締めくくるべく、全体セッションというのが行なわれた。

そこでテーマに取りあげられたのが、今後モジラが何を目指していくべきなのか、ということだった。むろんmozilla.orgやNetscapeの人間もその場にはいたが、ユーザーグループとしてボランティアとして、モジラをどう捉えていくべきなのか、どうmozilla.orgに意見していこうかを確認しようという前提があったように思う。当時、モジラはバージョン0.6の時代だったかなぁ＜＜記憶が不確か（￣△￣； 。

そこではリファレンスブラウザーとなるべく孤高の道を歩むのか、それともより多くのソフトでGeckoを採用してもらえるようにIEや旧Netscapeの仕様に併せて非標準のHTMLをサポートしていくべきなのかが話題の中心となった。そのセッションでは答は出されなかったが、その後の流れを見ていくと、「インターネットのソフトウェアとしての技術を提供する」という流れで落ち付いたように思える。世間に迎合するかしないかで悩むのとは別の方向性をモジラは見つけたようだ。

「Geckoを多くのソフトで採用してもらえるように」という話の中で提案されたのが、のちに話題となった「Web標準普及プロジェクト」だ。すでにベースとなる動きは始まっていて、それを本格的に行なってはどうだ、といったものだったように思う。

このセッションに参加していた職業デザイナーの人からは「Gecko採用のブラウザーが増えるか、もしくはそれに影響されてIEが標準準拠を真剣に考えてくれるようにならなければ、自分達の苦労はなくならない」という発言が出された。

またある人からは「標準対応してくださいと言っても、普通のWeb管理者はわからないかもしれない。わかりやすく伝えるためにGecko搭載のブラウザーで見えるページを作ってくださいと提案するのも手かもしれない」という提案もあり、それに対し「それではGeckoで見れればいいのか、と誤解される可能性もある」「ならばどうしたらいいのだ」といった議論に1時間以上もの時間が費やされた。

その後始まったWeb標準普及プロジェクトは、いろんな問題を指摘されつつも一定の成果を収めたように思う。このプロジェクトによって問題の修正に応じたサイトは、Operaに代表される標準へのコミットメントを謳う他のプラウザからでも利用できるようになったからだ。

「IEで見られればいい」という常識に風穴を開け「開かれたWebによるサイト構築」の実例を築きあげたという点、またいろんな批判を浴びながら自分たちが本当は何をしたかったのかを問い直し続けてきた点で、彼らのプロジェクトは評価されていいはずだと思う。

こうした前例がある中、moonstoneで始まった「MoonStone'S Laboratory OPERA Open The Web!!」はまだそのスタートラインに付いたばかり。「なぜもじら組という前例があるのに、それに学んだり、彼らと協調したりしないの？」といった疑問点はある(実際、もじら組の人たちはOperaを敵視していない)んだけど、もじら組と同じような道を歩きつつある「オープンソースでないブラウザを支援する人たち」のプロジェクトから、どんな答が出てくるのか実は少し楽しみだったりするのだ。

More inteligent

当ページは12月分より、XHTML用のMIMEタイプapplication/xhtml+xmlを使ってコンテンツを送出するようにしている。だだし、このタイプのMIMEタイプをサポートしていないUA用にブラウザの送信要求によっては従来のtext/htmlでも送信できるような仕掛けを施しているのだ。

この送信要求の判断にはHTTP_ACCEPTと呼ばれているHTTPヘッダを利用している。ここにApplication/xhtml+xmlがあれば、このMIMEタイプで送信するというのは以前ここに書いた通りだ。

ただ、中にはこのXHTML用のMIMEタイプをサポートしているにも関わらず、それを明かな候補として送ってこないUAもある。これはある意味もったいない話だと思い、この手の話に詳しい人にこの話題を振ったことがある。

その人によると、こういったブラウザは「*/*」という形式でどんなメディアのどんな形式でもいいから送ってよ、と要求することが多いようだ。この形式ならプラグインでのサポートなど対応が流動的なメディアの存在を曖昧にしておけるという利点があるからなのだそうだ。

また、「*/*」と書くことによってapplication/xhtml+xmlで送ることを許可していることになるので、仕様的には問題がないと考えることは可能。ただし解釈としては問題なくても、実際これでは不便だというのは納得できるということだった。

まあ、ターゲットのUAが判っているのだから、こちらが機転を利かせてターゲットブラウザーをUserAgentの値で判別・追加するという手もあるだろう。

普段、ページを記述したあと整数式になっているかをモジラでチェックするようにしているのだが、タグが閉じていない、文字参照に問題があるなどが一瞬でわかるのが作り手としては非常にありがたい。ただし閲覧側にとってこのMIMEタイプがメリットになるのは、XML機能をページに追加してからということになるのだろう。まずは一歩を踏み出すことからかな、と思っている。

HTMLとプレゼンテーション

Webブラウザーを使ってプレゼンという提案はたまに耳にする話だし、自分も以前一度それと似た提案をこのサイトでしたことがある。でも実際にはおいら自信、今年5月にmozilla.party 3.0でmozilla.orgの人が基調講演で使っていたのを見たのが初めてというていたらく。

Webブラウザーでのプレゼンをあまり見ない原因のひとつは、紙に打ち出すことを考えれば結局PowerPointで作ったほうが早いというのがあったりする。また、オーサリングツールの不足も原因として挙げられると思う。

ただ、もしも前者の前提が紙への出力でなくWebへの打ち出しであったらどうだろう。

PowerPointからのHTMLエクスポートはプレゼンが複数のファイルに分割され、管理や分りやすさの面で少々問題がある。「少々」と言ったのは自分で難癖くさい匂いを感じたからだ。が、その一方で検索エンジンの結果から飛んで来たときにそこがスライドの一部だったりすると全体の見通しの悪さに面喰ってしまうことが度々あるのは事実だ（OpenOfficeのプレゼンツールのHTMLエクスポート機能を見ていないので、こう言い切ってしまうのは引っかかるんだが）。

これが分割されたファイルではなく、単一のHTMLファイルで実現できれば見通しの悪さはだいぶ改善される。これを実現するには、各スライドをdivもしくはhn要素の直前で改ページさせる方法が一般的に使われている。ただし改ページの仕方には現在2通りの方法があるようだ。

ひとつはJustArksに含まれる「PrezArk」で採られている方法。これはPrezArk上でめ予約されたクラス名が指定された匿名ブロックを1スライドと見做すようにし、通常のWebブラウザー上で表示させた場合は各スライドを縦に並べて表示させている。各スライドにはページ内リンクを使って移動できるようになっている。

もう1つはOperaのプロジェクションモード（いわゆるOperaShow）で採られている、CSS2のpage-brake-beforeを使う方法。1スライドを括った匿名ブロックに改ページの指定を入れるものだ。こちらは、F11キーによるスクリーンモードとプロジェクションモードの切り替えで、Webページらしいレイアウトとプレゼンらしいレイアウトを切り替えられる利点がある。前者と違い、コードベースの記述が必要なのが難点。OperaShowは作成ツールが存在するらしいのだが、おいらは見つけられなかった＜＜あってもどうぜWindows用だろうし（￣△￣； 。

どちらも作成後のHTMLソースを見るといろいろ言いたくなるような構造だったりするのだが、これはWebページとしての構造よりプレゼンとしての構造を意識した結果なのかもしれない。そういう意味ではHTMLで記述されるよりもXMLで記述されるべきものなのかもしれないが、すぐにWebに持っていけるという点ではXHTMLを使うということに意味があるのかもしれない。

オーサリングの問題だが、簡単に済ますならPrezArkの<div class="navi">に改ページを指定するか、ゴーライブなんかで同じようなことを試みるのも手かもしれない。OperaShowで表示させるなら、作成したスタイルシートファイルの指定に<link media="projection">を書き加えるのを忘れずにといったところかな。

妄想インターネット

今日も朝からテストの連続でクタクタ。冷たい雨がみぞれ混じりに変わるなか、おいらは帰途についた。いいかげんな実装のブラウザーと不思議マークアップさえ消えてくれれば、こんなことにはならないのに……、とようやく席の空いた電車のシートに座り、おいらは日々の苦労を思い返していた。

回りを見るとデート中のカップルやパーティ帰りの若いグループが楽しげに話をしている。そうですか、きょうはクリスマスイブですか。去年も「来年こそはゆっくりクリスマスを」なんて思っていたわけなんだが、脆くもその夢は崩れさってしまったわけなんだな。誰ですか「クリスマス出荷にしちゃいましょ」なんて言い出したオバカさんは（￣△￣；。

何はともあれ自宅に着いたおいらは、メールのチェックを済ますと早々に床に就いた。最近ずっと続いている睡眠不足のおかげで、帰宅しても、もはやこれくらいしかできないのだ。せめてクリスマスイブらしいいい夢でも見ることにしよう。

夢の中でおいらは、ひどく怪しいサンタが部屋をうろついているのを見たような気がした。そのサンタは、おいらの机のほうで何かごぞごそやっている。おいらはその気配を感じつつ、再び深い眠りに引きずりこまれていった。おいらが目を覚ましたのは窓の外が明るくなったころ。どうやら外は雪が積っているようだ。

ふと机の上を見ると、ノートパソコンのフタが開いている。不審に思い画面をのぞきこむと、デスクトップに見慣れないアイコンが。そしてiChatに残されたメッセージ「やあ、見慣れないアイコンに驚いたかい? これは毎日大変な君のために用意した、ぐっと来るブラウザーだよ（￣△￣；」。あのサンタは夢ではなかったのか……、人のパソコンに何しやがった（￣△￣；。

一応お約束のウィルスチェックを済ませたあと、見慣れないアイコンのブラウザーをダブルクリックして起動。さとみかんのサイトを巡回したところ、そのブラウザーは非常に軽快に動作し、レンダリングも綺麗。操作性もオペラのマウスジェスチャーなんて比較にならないほど良い、とても素敵なブラウザーとして振る舞ってくれた。

ところがだ、コミューンの外のサイトに移動した途端、そのブラウザーは態度を大きく変えたのだ。なんとページが表示されない。それどころか、「この"ほーむぺーじ"は正しくないHTMLで記述されています。ページを表示させたい場合は、エラー補正エンジンを搭載した有償版をご購入ください。」と購入をおいらにせまってくる。

うーん、とてもぐっと来るブラウザーだ。だけど一般のページを見るためだけに、ブラウザーに金を払うべきなのだろうか、と考えながらあることに気が付いた。ハードディスクからブラウザーというブラウザーが削除されている（￣△￣；。

金を払いたくなくば、正しいHTMLで記述されたサイト以外見るなということなのか!? うーん、こんなテロのような横暴が許されるものなのだろうか。うーんでも、最近は標準準拠のページが多いからこれでも困らないような困るような……。

おいらは結局、お金は払わないことにした。その代り、自分のサイトを正しいHTMLで書き、正しいHTMLで書かれるウェブサイトが増えることを楽しみに毎日を過すことにした。あの怪しいサンタが、この怪しいブラウザーをインストールして回るたびに、昨日まで見えなかったサイトが今日からは見えるようになっていくのだ。

はた、と目が覚めた。またおいらは職場にいる。目の前にはやりかけのテスト仕様書。単純なルーチンワークの最中に疲れて眠ってしまったようだ。それにしても夢に出てきたあのブラウザー、実は標準以外のマークアップの処理がまともにできないヘタレなレンダリングエンジン積んでいるだけなんじゃ（￣△￣；……、と。でも、世界中のサイトが正しいマークアップをするようになれば、エラー訂正なんていらなくなるんだよな、と思い直し、再びテストに取りかかることにした。

Opera移行

3年以上の長きにわたって使い続けたMac IEから、Opera 6 for Macへと移行すました。

本当は日本語版の登場を待とうかなぁと思ったのだが、何をごちゃごちゃやってんのか、一向に出ないまま年を越しそうな気配。そういうこともあって、とりあえず移行だけでもしてしまえ、と今日の作業に至ったわけ。

Opera for Macというのは非常に中途半端なルック＆フィールを持っていて、Mac用ソフトらしくもなければ、Operaらしくもない。

Operaつーのは使い勝手や操作性の良さとかが売りのソフトだけあって、本当はどのプラットフォームのバージョンでもそれがルックスからにじみ出てきているはずなんだが、どうもMac版のOperaからはそのオーラが強く出ていないような気がする。

たとえばそれはマウスジェスチャーであったり、Linux／FreeBSD版にでさえ実装されているマルチプルドキュメントインターフェースであったりするわけなのだが、どうしてMac版にはそーゆー機能がないのですか（￣△￣；。シンプル・イズ・ベストというなら、キメラたんがすでにあるでしょうに。

まー、それでも先日ネタ帳に書いたような、キーショートカットによるエレメント＆リンクナビゲーションや表示の拡大縮小機能、製作者スタイルシートの取り外しボタンや、Control+ドラッグでページを行き来できる機能とか、モジラでもできるようなできないような機能なんだけど、Operaならより少い手順で実行できる、という利便性は、やはりOperaだなと。

以前にも書いたけど、Opera 6のレンダリングエンジンつーのはモザイク時代のものを改修しつづけたものなので、正直あまり解釈の正確さは期待してない。今までだって製作やテストにはパワフルなツールを満載したモジラを使っていたし、それはこれからも変らない。Operaはどちらかというと使い勝手の良さが普段のブラウジングには最適という理由で選んだわけだし。

解釈に関しては今開発途上版が出ているOpera 7 for Windowsでしっかり叩いていくべきでしょう。CSS1の勧告書を執筆した人間がOperaのCTOとして開発陣を率いている点から考えても、叩けば叩いただけ（そしてそれを伝えれば）変るんじゃないかと。モジラと違って日本では今まではマイナーなブラウザーだったから、叩く人間とそれを伝える人間がが少なすぎたんじゃないかな。

話が横道に逸れたけど、えーっとまずそのショボいルックスをなんとかしようと見た目をいじったわけ。以前どこかで紹介されていた日本語化の方法と、Opera 7っぽいスキンの導入で見ためはだいぶ洗練されますた。

それから文字なんだけど、ATSUIフォント描画エンジンの美しさを実感するには太めのタイポグラフィーのほうがいいかなぁ、とフォントの指定を初期設定の「Times New Roman」から「Heveletica」に変更。

本当はヒラギノ系を指定したいところだけど、標準設定のフォントにマルチバイト名のフォントを指定してしまうと、せっかく個別要素ごとに指定されているフォントの設定を上書きしてしまうバグがある。Mac OS Xのヒラギノはボールド用の字体を持っていないので、結果非常にノッペリとした画面になってしまう（￣△￣；。それだけは耐えられん。

あとは「ミニさとみかん」をホットパネル上に配置したわけだが、ウィンドウのUIがMDIでないこともあってか、ミニさとみかん上のリンクをクリックすると新規のウィンドウが立ちあがってしまう。

いろいろ実験した結果、最初のクリックは「cmd」+「option」キーを押しながらすることで、リンク先が「ミニさとみかん」パネルと関連付けられた新規ページ（タブ）として開くことがわかった。最初だけ気を付ければ、あとはOpera for Windowsのような使い勝手が実現する。

ブックマークに関しては、Mac IEからそのまま取り込むと、おばかなオペラたんはそれがLatain-1コードで記述されていると勘違いしてしまうようだ。ひどい文字化けで手がつけられない（￣△￣；。なので、いったんモジラに取り込み、そこからインポートした。モジラからでも多少ブックマーク名にゴミが付くのだが、個人的には実用上問題がなさそうなので、これで放置。

この1ヶ月、UIに関してはいくつかのマックユーザーのサイトで言及があったわけだけど、Macらしいルック＆フィールとOperaらしいルック＆フィールというのは上手く天秤にかけていく必要があるのかな、という気もした。ソフトのアイデンティティを左右する問題でもあるから、おいらたちユーザーはどこまでOS固有のUIとインテグレートされていれば満足なのか、よーく考える必要がありそうだ。