安請け合いするんじゃなかった、と後悔するくらい面倒だった。
ある要素に対してhover時にマウスカーソルの形を変えたい。
デフォルトで用意されているカーソルの画像を使う事が出来るが、ここには気の利いた画像はあまり無い。
urlを指定して画像ファイルを読み込む事も出来る。
IE8は、Windowsカーソル形式(.cur)のファイルを認識する事が出来る。
他のOSではこの形式のファイルが使えない可能性があるが、pngやgif形式の画像が使える可能性がある。
Firefoxは以前はpngやgifのみ対応だったという記述を見かけだが、3.6時点ではcurファイルに対応している。
curファイルはWindowsアイコン形式(.ico)に類似しており、このファイルはIcoFXというフリーソフトで作成できる。
マウスポインタに使うアイコンファイルは32x32の4bit(16色)形式である。他の形式も大丈夫かも知れない。
作った画像をそのまま指定すると、カーソルの矢印の先にあたる位置が画像によって異なるため、
カーソルの画像が変わった途端に指している場所がずれてしまうように見える現象が起きてしまう。
この「指している位置」のことをホットスポットと言う。ホットポイントという誤用がいくつか見受けられたが誤りである。
ホットスポットはx座標の値とy座標の値で表現され、デフォルトは左上の0,0である。
css3においては、このホットスポットを指定する事が出来るが、IE8はこの指定に対応していない。無視される。
そこでやむを得ずcurファイルの中にホットスポットの情報を埋め込むことにする。
まず、IcoFXでico形式のファイルを作成した場合は、拡張子をcurに変える。
レンタルサーバやらブログやらの都合でcurファイルがアップロード出来ない人はicoのままでもいいらしい。
次にバイナリエディタでおもむろにファイルを開く。
一番上00000000の02列が02になってなかったら02にする。
0A列にX座標を16進数で入れて、0C列にY座標を16進数で入れて保存すればおｋ。
目視でチェックしながらホットスポットを見定めたい時は、Firefoxでcss3で調整すれば良い。
最後にcssの書き方の一例を示す。
これで互換性が確保されるのかはわからない。古いブラウザでは文法エラーになるかも知れない。
div { cursor: url(hoge.cur), url(hoge.png) 1 2, auto; }
カンマ区切りで左から順に解釈してくれる。urlのあとにスペース区切りでホットスポットのxとyを数字で指定できる。
urlだけの指定では不足で、最後に必ずurl以外の形を指定しなければいけない。特になければautoでもいい。
血筋を書いて家系図を作ろうかと思っていたが、そんな事は無かったぜ。
「類似性を把握する」という観点から、ブラウザをレンダリングエンジン別に整理する。
実際のところは、レンダリングエンジンの血筋の違いよりも、バージョンの違いのほうが影響が大きいため、
「Geckoだからどれも一緒」とか「FirefoxがOKだからNetscapeもOK」みたいな事にはなり得ないので注意は必要。
複数のエンジンを使い分けが出来るブラウザもあるが、古いバージョンが組み込まれている可能性も高いため、テストに便利かどうかは微妙である。
- Trident
- Microsoft Internet Explorer
- Gecko
- KHTML
- Konqueror(Linuxのデスクトップ環境 KDE のウェブブラウザ)
- AppleWebKit
- Apple Safari
- Google Chrome
- iPhone
- Presto
- Opera
- ケータイのフルブラウザなどにたまに使われる
- Netfront
AppleWebKitはKHTMLからforkしたものなので血筋は一緒だが別物。
KHTMLは軽量でGeckoは高機能という違いがある。血筋は不明。少なくとも今あるものは別物。
KHTMLのUser-Agentには like Gecko の表記があるが、これは眉唾である。
Mozilla/4.0(Compatible みたいな、いかがわしい主張に近いものがあると思う。
でも、（ブラウザ判別の役に立たないくらいの粗さで）すごーく大きい括りをすると、どれもGecko系であるとは言える。
ちなみにNetscape Browserというブラウザがあるが、日本語版は出ておらず、開発も2年半前から更新がないので、
いま「Netscapeに対応する」という作業が発生する可能性は、恐らく無い。
参考までに、「安全な」ブラウザの互換性に関する考察。
- Microsoft Internet Explorer
- バージョン8のみ対応するのが適切。
- バージョン8未満でサポート対象のOSでは、Windows Updateでバージョン8を勧められる。
- 「わざと」アップデートを拒否しないと、バージョン8未満になる事が無い。
- Windows 2000などのサポート対象外のOSでは、バージョン8にする事が出来ない。
- Mozilla Firefox
- 最新バージョンに対応するのが適切。
- アップデートチェックが行われて、最新バージョンのインストールを勧められる。
- Windows Updateが禁止されていたり、サポート対象外のWindowsでもインストールが出来る。
- クロスプラットフォーム対応が最も進んでいる。
- AppleWebKit
- Appleの推奨するバージョンに対応するのが適切。
- Chromeは独自カスタマイズされているので、対応したいなら相応の覚悟が必要。
- クロスプラットフォーム対応が現在進行形で進んでいる。
- が、Windows版SafariとMacOSX版Safariの時点で描画が全然違う。
- 個別対応しないブラウザへの措置
- マイナーである事を理由に迫害されるブラウザに対しては救済措置をとるべきである。
- が、互換性確保のために製作コストをかけるべきではない。
- cssやjsや画像が動かなくても必要な情報におおむねアクセス出来る事を心がけていれば良い。
- 携帯電話、スマートフォン、PDAなど
- 結局バージョン等が一々違うので、機種ごとに個別対応するしか無いと考えたほうが無難。
結局、手抜きする事は出来なさそうだな。
全体を通じて
- DoCoMoが最もブラウザの実装水準が劣っている。
- そのため、各種実装をDoCoMoにあわせながら、いかにして合理化するかが課題になる。
やりたいこと
- PCでケータイサイトを製作する。
- 実機確認はしなくて済むようにする。シミュレータかPCブラウザで表示を確認できるようにする。
- 製作時点ではキャリアごとの複数対応は極力避ける。
- PHPによる変換処理を踏まえてリリースする。動的でも静的でも構わない。
できてること
- 画像フォーマットの統一
- jpeg形式であれば新しい機種のすべてで対応している。
- gif形式はSoftBank 2Gで非対応。
- 2009年10月現在発売中の端末は1機種だけ。2011年に廃止予定。
- よって、おおむね使って良いと言えるのではないか。
- png形式はDoCoMoで対応していない。
- 文字コードの統一
- XHTML対応機種ではおおむねUTF-8が使えるようになった。
- Shift_JISも使える。
できてないこと
- 絵文字の表記方法の統一
- 似たような絵文字が3キャリア共に存在するものだけ使うのがひとつの手。
- HTML内への記述方法はすべて異なるため変換処理が必要。
- 画像ファイルにしてしまえば表示は確約されるが本末転倒と言える。
- DTDの統一
- 各キャリアで規格を揃える気は無いだろうから一生無理そう。
- だとすると結局キャリア毎にHTMLを生成するしか無いという事になる。
- XHTML basicという規格はあるがDoCoMoではcssが欠落するという問題がある。
- XHTML Mobile Profileという規格はDoCoMoのインラインcssにも一応対応する。
- XHTMLへの切り替え
- DoCoMoだけがCHTMLという旧来の形式をいまだに推進している。
- CHTMLではcssが使えないなど製作上の制限が多い。
- ただし、DoCoMoのXHTMLは、外部cssを解釈出来ないという致命的な欠陥を孕んでいる。
- Content-typeの統一
- DoCoMoのXHTMLでは application/xhtml+xml が必要。
- DoCoMo以外は text/html にも両対応。
- MSIEは application/xhtml+xmlに非対応。
- これはDoCoMoの実装が誤っているわけではないので、MSIEで動作確認出来ないという制約として捉えるしかない。
- Flash対応
- 新しいバージョンへの移行がちぐはぐなため、Flash Lite 1.1という古い形式を使うしかない。
- 同じFlash Lite 1.1でも機種ごとに機能制限があるため、Flashなら互換性問題から解放されるというわけではない。
ここまでの情報から考えられる作戦
- CHTMLで書いて、DoCoMo以外にはゲートウェイ変換で表示される事を期待する。（だめだめ）
- XHTMLで書いて、キャリアごとに違う部分は変換処理をかます（本稿の選択）
- Flash Lite 1.1で書く。それはそれで試行錯誤すると思われる。SEOとか謎だし。
動的に実装する事が望ましいもの
- ある単一のURLにアクセスされた際に、キャリアを判別して自動的に振り分ける処理
静的に実装する事が望ましいもの（動的でもサーバ負荷さえ許容できればOK）
- PHPでやる処理
- DTD生成処理
- 絵文字変換処理
- 外部cssをインライン展開する処理
- 手でやったほうが良いかも知れない処理
- HTTPDでやる処理
