とっぷぺーじ
ねこめしにっき
2005/11/前半
2005/12/前半
まぁあんまり Safari をけなしてばかりではアレなので。
このエントリによると、 Safari は ICC プロファイル埋め込み画像に対応している模様。つまりブラウザとして ColorSync 対応。いやぁ Apple 純正ブラウザであればこうでなければいかん。
同機能はその昔、 MacIE にも搭載されていた。こういう Mac プラットフォームに対する適合努力を抜かり無くキッチリやりつつ、今もいろんなブラウザがマネのネタモトにしているようなアイデアをたくさん持っていたから、 MacIE は賞賛に値したのですよ。
カラーマッチングの話にもどりますが、多勢に無勢、というか Web のデフォルト色空間は sRGB であり、もはや Mac 環境でもディスプレイ環境のデフォルトは sRGB 色空間でありますから。 Web で公開する用の画像を伝統的 Apple RGB や Adobe RGB で作成するのはちと微妙な感のする最近。ていうかもうね、そもそもディスプレイをきっかりキャリブレーションしているユーザなんて (グラフィック系デザイナ以外) いるわけが無いんですから、色の再現性を Web に求めるのはかなわぬ夢なんすよ。
でもしかし、遠い将来に Gecko や WinIE も 色空間補正に対応するやもしれないので、プロファイルを埋め込んでおく事自体はやっておいて損はないかもしれないなー、とか思ったり。デファクトである sRGB 環境向けの画像作っておいて、 sRGB 環境向けである旨のプロファイルを埋め込んでおけば、閲覧者が自分のディスプレイをキャリブレーションしている事が前提とはいえ、色空間補正されない sRGB 環境下のブラウザでも、伝統的 Apple/Adobe RGB 環境あるいは sRGB 下の Safari でも、本来の色味をだいたい再現できるかもしれないわけだし。
ちなみに CSS3 Color Module によれば、 CSS3 では ICC Color Profile: the 'color-profile' property なるものが準備されていたり。プロファイル埋め込み画像のみならず、ページすべての色をプロファイル補正できるという。イイヨイイヨー。
ぴろたんのスタイル切り替えスクリプトを使っている場合にはUAFuncメソッドに以下の変更が必要でした。
t.Moz=(uaStr.match(/Gecko/) && !uaStr.match(/Safari/));
like GeckoでMozと判別されてしまうのでよろしくなかった模様。まぁ、like Geckoとかいう文字列は死ぬべきですね(てけとう)
[ ぷろじぇくと、みすじら。 より ]
実際、like Gecko
とかいう文字列は死ぬべきですね (ぼうよみ)。
さて、参考までに、Web標準普及プロジェクト の Web標準化Tips には以下のようなくだりがあります。
Mac用のブラウザである"safari"(Konqueror)がGeckoブラウザと誤認されるように偽装していることが、先日公開されたベータ版から判明しました。
対応策として調べる文字列を"Gecko"から"Gecko/"に変更しています。詳細は次のバグをご覧ください。 [Bug 2917]
[ ブラウザ判別では"Gecko"を調べてください - Web標準普及プロジェクト より ]
真・ Gecko 系ブラウザを判別する際、現在ぼくもこの方法でウソ Gecko (= Safari を始めとする AppleWebKit 系ブラウザの事)を除外しています。しかし今後、 "Gecko/ほげほげ" の文字列を持つ新たなウソ Gecko が現れない保証なぞ無いあたりで、 UA 文字列によるブラウザ判別の限界を改めて思い知らされるわけですわ。
さて、上記のまゆにゃんのコードは、 UA 名文字列 (navigator.userAgent) に "Gecko" の文字列がありつつ、 "Safari" の文字列の無いものを真・ Gecko 系ブラウザと判別しているようですね。さてここで、 Safari を始めとする代表的な AppleWebKit 系ブラウザいくつかの UA 名文字列を羅列してみます。
Mozilla/5.0 (Macintosh; U; PPC Mac OS X; ja-jp) AppleWebKit/416.11 (KHTML, like Gecko) Safari/416.12
Mozilla/5.0 (Macintosh; U; PPC Mac OS X; ja-jp) AppleWebKit/416.11 (KHTML, like Gecko, Safari) Shiira/1.1
Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US) AppleWebKit/125.4 (KHTML, like Gecko, Safari) OmniWeb/v563.62
というように、どれも "Safari" の文字列が入っているというか、Safari 以外は Gecko を偽装しつつ Safari であることも偽装してんのよね。おもしろいですね。
これら AppleWebKit 系ブラウザたちをひとまとめに判別する際、ぼくは "AppleWebKit" の文字列を見てます。ブラウザ判別の主用途は、レンダリングエンジンもしくは JavaScript エンジンの差異に前もって気付くためであり、その差異を生んでいるもの・包括するものは、やっぱり "AppleWebKit" だと思うので。 "Safari" の文字列ではなく(OmniWeb や Shiira は Safari ではない)。もちろん "KHTML" でもなく (例のゴタゴタにより KHTML 本家からは遠ざる一方でわ / 憶測) 。
まぁフツーはこういうワケのワカラン事情は考えないで、Safari を判別するためには素直に "Safari" の文字列を見るのがフツーの営み。よってそれがフツーの慣習となっていくのは自然の摂理であり。イニシエの "Mozilla" 文字列の故事をたずねるまでもなく、 Shiira や OmniWeb や他 AppleWebKit 系ブラウザはもはや、 "Safari" の文字列を外す事・ Safari の偽装を解く事は不可能。だから、まゆにゃんの判別コードでなんも問題ないっつーか。
なんで俺が電信八号なんてメーラを使つてゐるかと言ふと、個別のメールがそれぞれテキストデータで保存されるから。他の多くのメーラが個々のメールを別々に保存しないでメールボックスなるデータベースに一纏めにして保存する――これが何か怖くて。（略）
[ 闇黒日記 (平成十七年十一月二十五日) より ]
まったく同意。そういう系統のメーラーに限らず。単体ではアプリケーション非依存だったはずのデータを、特殊な方式 (それがバイナリデータだと最悪) で溜め込むだけ溜め込み、潰しの効かないデータに変えてしまっておきながらエクスポート機能無し、自分亡き後の世界の事なぞ知らんヨ、みたいなデータ的ブラックホールアプリケーションは恐怖。
というか、これはコンピタライフを始めた頃からの永遠のテーマなんですが、コンピタライフを営む上で収集したり自作したいろんなデータを、 10 年 20 年、あるいは棺桶同行的なスパンで保持したいと考える時、どのフォーマットを選択したらよいのか。すなわち、現時点で将来的にもっとも潰しが効くと目されるフォーマットはどれなのか、というやつ。
たとえば十数年前に集めたヲタイラスト CG とか。往事の事だから 16 色 MAG やら X68000 の PIC やらが結構多くて。 11 年前 (1994年8月頃) 、エロ線画に X68k で彩色してもらって作ったヤッツケ CG 集 (たしか地元イベントオンリーで頒布した) は PIC 形式だったなー。 懐かしいネ！ (w ……ってそんな話じゃないんだ。
今となっては、 MAG だの X68k PIC だのは、少なくとも Mac プラットフォームにおいては読むのが相当難儀になってきている。元々国産の画像フォーマットって事もあって、 Mac 界的には元々外様仕様だったという事情や、 OSX 移行の際に「ソフトウェア的断絶」が少なからずあった事情により。そして近々 Intel Mac 移行というイベントがある。ふたたび「ソフトウェア的断絶」の時期が迫っている。さすがに OSX 移行の時よりは穏やかだろうけれども、その事をマカーは頭の隅に置かねばならない。ドザーにしても、Win9x から NT 系への移行のときとか、次の Windows Vista でも多少は「ソフトウェア的断絶」が起きたり起きなかったりしたりするんじゃないのかしら。
MAG なら GraphicConverter で今でも読めるので、 OSX ネイティブ環境下でもさほど問題ないとも言える。 X68k PIC も、 Classic MacOS (あるいは OSX Classic 環境上) の PixelCat (Classic 版) を使えば一応読める。しかし Intel Mac ではもはや Classic MacOS も Classic 環境も動作しないのですよ。ともあれ、これらイニシエのフォーマットで記録されている手持ちの画像データは、読める手段のある今のうちに、潰しの効く、将来に対する担保ある他の形式へ変換しておかないとヤバイ。まぁ今なら PNG にしとけば今後 10 年程度はだいたい安心でしょう。というわけで昨今はせっせとフォーマット変換してまわっている次第。
動画とかがやばい。5 年 10 年先の未来を託せるこれだ！というものが無い。そもそも動画は変換エンコードがかなり手間というのがいちばんガン。劣化の問題もある。アニヲタ系の動画世界は、わずか 6 〜 7 年前は Intel Indeo の AVI が主流だった。 Classic MacOS の時代はそれを再生する術があったけど、 OSX ネイティブ環境下ではもはや術が無い。これも OSX 移行による「ソフトウェア的断絶」による。んで、ここ数年は DivX (または DivX 互換) の AVI とか WMV コーデックの AVI とかが主流な感じ。前者なら OSX ネイティブ環境下でも余裕で再生できている。しかしこれとて 5 年後にどうなってるのかワカラン。フォーマットとして依然主流であることは考えにくいし、それよりやっぱり「ソフトウェア的断絶」が最大の心配点。この観点だと、もはや OGM とか MKV とかそういう泡沫モノは選択肢としてあり得ないっしょ。H.264 にしてもしかりで。なんとかならんもんかな。
音声は、とりあえず無圧縮は WAV で圧縮モノは依然として MP3 でいいんじゃなかろか。ヘタに OGG とか TTA とか FLAC とかそういう泡沫系は動画と一緒でやばいでしょ。「ソフトウェア的断絶」の可能性がやたら高リスク。
圧縮ファイルもしかり。長らく Mac プラットフォームの標準的圧縮フォーマットであったはずの SIT なんて、 OSX10.4 から OS 標準バンドルじゃなくなった件により、今後の存続に暗雲がたれ込めまくっている。つまり「ソフトウェア的断絶」危惧種。これも今のうちにどうにかしとくべきかもしれない。あと、あの超絶便利だった、MacIE5 のスクラップブックファイル ( Web アーカイブファイル / WAFF) も、 MacIE 自体あるいは WAFF 展開ツール Waffle が正常動作している今のうちに何とかしておかないと、相当やばい。
というわけで、 10 年単位のスパンで「データフォーマットの潰し」なるものを考慮すると、ポッと出のものとか、プラットフォーム非互換的・何らかの標準仕様的裏打ちの無いものは、なかなか怖くて選択できんわけです。
HTMLなんてものは、ネットワーク越しにデータを交換する際にだけ用ゐられれば良いファイル形式で、ローカルの環境ではアプリケーション依存のデータで持つてゐても全然問題はない。
全然問題はない
とは思ってなくって、ローカル環境上のアプリケーションのデータであっても、なるべく潰しの効くものであってほしい。「ソフトウェア的断絶」がとにかく怖いので。Painter で今日描いて保存した RIFF 形式ファイルが、10 年後も問題なく読める気なぞまるでしない、とか。例が微妙すぎ。つか、もはや Painter は使ってなくて今の環境にはインストさえしてないから、昔描いた RIFF ファイルを見る術が既に失われているという…。
HTML だの XML だのは、結局ただのテキストデータでしかないのが最強。50 年先には、 HTML や XML はその本来の便宜そのままを扱えないかもしれないけれども、テキストデータがテキストデータとして読めないという事はまず無かろうというあたりが、壮絶に潰しが効いている。まずその担保を安心して享受しつつ、その上で可能な限りの長期間、本来の便宜を享受していきたい場合の潰しの効き度は、 HTML と XML とでとっちが勝るだろうかと考えるに、 XML なんじゃなかろうかと。
「使ひ捨てるデータ」としてのXML
のくだりについては、 XML を貶める目的のために使ひ捨て
の事例をわざわざ持ち出している感が漂いました。
Mac プラットフォームにおいては、両方ともゴミ以下。 Opera に至っては選択肢として考慮の余地さえない。
Firefox がシンプルブラウザだという評がある。笑わかさないでよ。本当のシンプリシティにはエレガンスが漂うものですよ。
一般に、意味も無く闇雲に多機能だとか、本筋から外れた拡張性だとか、無闇にカスタマイズ性があるとか、そういうソフトウェアはつまり、制作者の自信と確信のなさの発露の結果だと考える次第。それはエレガンスから遠いアティチュード。
関係ないけど、 Windows のオンラインソフトに、多機能をウリに本筋から外れた機能をテンコ盛りにしてるソフトが多いのは、なぜですか。たかがランチャーがどういうわけか圧縮書庫を解凍する機能を持ってるとか、タスクトレイ用の時計がデスクトップアイコン整列機能をもってるとか。バカじゃないの？ Firefox の拡張にも似た傾向があるよね。シンプルに行こうよ。シンプルに。女の子はエレガントに。（謎）
[ 武蔵流プログラマへの道 経由 ]
「早起き生活」で早起き体質に！
早起き生活のメインサービス「早起き日記」を使えば、自分の状態を把握しながら少しずつ生活を改善してゆくことができます。
起き上がってパソコンに向かい、Webサイトにアクセスするので、二度寝防止にも効果的です。
さらに、記録した起床時刻は、グラフとしてブログに貼り付けることもできます。
さあ、さっそく使ってみましょう！
漏れも使い始めてみてる！
でも早起きグラフは貼らないよー。目標起床時刻がすでにちっとも早起きさんじゃないわ、しかもその目標が実現不可能にさえ感じるわで恥ずかしすぎ。（えー
[ La mocha rouge 経由 ]
FLASH のかわいい系ミニゲームたくさん。しかしプレイして面白いかっていうと、どれもちと微妙。
温故知新系 JavaScript ノミゲー。ベーマガ世代的に懐かしすぎ。これは文句無く楽しいー。面データのロードとかあたりで Ajax 使ってたりして。
正直、XML は使えば使うほど、仕様のぐずぐずさ加減に、怒りが込み上げてくる。XML 1.0 でやめておけばよかったのに。そこに namespace だの XSLT だの XPath だの付け加えて、みんなそれぞれ好き勝手な方向を向いているから、収集がつかない。なら、それらを使わなければいいって？その通りです。でも、便利そうだから、思わず使っちゃって、でもやっぱり使い物にならねーよ、うぉぉー、となるわけです。
[ HAPPY Macintosh Developing TIME! より ]
たしかに、 XML 応用系の世界はその包容力と応用力により膨張する一方だから、その先端領域や辺境領域ではぐずぐず
や好き勝手
になっているグダグダな事例には事欠かなかったりするけれども (RSS フィードにまつわる仕様的混乱と騒動もその一例)。しかし上記引用に挙げられた XML 名前空間も XSLT も XPath も、 XML 応用系の中心に位置し互いを補完しつつ応用系の根幹インフラを形作っているものであるから、好き勝手な方向を向いている
などと言われる筋合いは無いと思った。
OSX も、ぐずぐずさ加減
や好き勝手な方向を向いている
事例に事欠かない「XML 応用系の辺境領域」を多く抱えこんだ舞台だと常々感じている次第。
好き勝手感を強く覚える。(そうならないために、 Dashboard Widget の (X)HTML は、最低限、 Konfabulator のように XML であるべきだった。)
ぐずぐずさ加減が強い。
ぐずぐず。
つまり XML 応用系の末端に位置するものの一つである OSX アプリケーション自体、ぐずぐず
や好き勝手
の舞台となりがちであって、そこに関わる人にはなるべく「ぐずぐずを排する態度」なるものを尊重していただきたいところです。具体的にどうしろとかは分かりませんが、便利そうだから、思わず使っちゃって、でもやっぱり使い物にならねーよ、うぉぉー
とかならないような。幸運というかなんというか、 Mac は伝統的に GUI の整合性や一貫性を尊び、それが生産性を育む事を体感的に知っているユーザの根城であり、ゆえにぐずぐず
や好き勝手
を嫌う風潮があるので、技術仕様に対してもそういうアティチュードを持ちやすい環境だとか何とか、思っていたりします。
そういう観点で：
http://homepage.mac.com/mkino2/index.html を HTML4.01 Transitional としてチェックしました。
355個のエラーがありました。このHTMLは -92点です。タグが 20種類 531組使われています。文字コードは Shift JIS のようです。
[ Check result of Another HTML-lint より ]
マークアップ言語として仕様のぐずぐずさ加減
に定評のある HTML 4.01 Transitional にさえマトモに準拠できず、それをはるかに上回るグダグダなマークアップしかできてないとわいったい何事。…とかまぁ、こういう HTML 的だらしなさを指摘すると、世のプログラマと言われる人々 (Web プログラマ含む) の多くは、どういうわけか見下したかのような反応をする事が多いんだけども。いわく、たかが HTML ごとにで大げさな云々。
(mkino 氏もそうだとは言ってません。そうでない事を祈りつつ、過去の経験則からの傾向論。)
たしかに HTML や XML といったマークアップ言語仕様なんてもんは、各種のプログラム言語仕様に比べれば、難易度の観点で遥かに安易で容易な仕様だけど（テキトーに作ってもそこそこ動作するだけの仕掛けが世の中に蔓延してる事もあり）。しかしその容易な HTML ごときでさえグダグダでマトモな実装を施せない者に、他の技術領域においてグダグダをしない確証なぞ持てないというか。ある体系における整合性や一貫性の尊重、つまり「ぐずぐずを極力排する態度」を本当に重要なアティチュードとしているのか疑わしいというか。「神はディテールに宿る」っていうヤツかしらん。
ねこめしにっきヘッドライン
Mail to Alimika Satomi
Site search
About copyrights