いわゆるHTML5対応Webブラウザの標準機能だけで、KISekae Set system (KISS)のデータを表示します。LZH書庫の展開も行います。Java VMやプラグインなどは一切必要としません。
読み取るのは純正のKISS/GS形式のデータそのものです。ブラウザからアクセスしやすくするための事前変換などは一切必要ありません。
実用的な意味はあまりありません。ぶっちゃけ、新規にWeb着せ替えを自作するならsioriでも使ったほうがよほど高速で古いブラウザとの互換性も高いでしょう。KISSデータをWeb上で遊ばせるにはきすちょこやJavaアプレット版KISSなどの選択肢もありましたが、最近のブラウザやJava実行環境では困難になりました:
(2018-03-20追記)Java 10 (18.3)から、Javaプラグインは廃止されました。Java 10のリリースに伴いJava 9のサポートは終了したため、現在サポートされていて、アプレットを使うことができるJavaバージョンは8のみです。
(2016-11-25追記)Oracleは、JDK 9からJavaプラグインを非推奨にすると発表しました。(2018-02-03追記)Java 6u171とJava 7u161からJavaプラグインが削除されました。
(2015-11-05追記、2018-02-03更新)Mozilla Firefoxはバージョン52以降、Flash以外のNPAPIプラグインのサポートを終了したため、Javaアプレットは動作しなくなりました。またWindows用64bit版はそれ以前からFlashとSilverlight以外のNPAPIプラグインのサポートを廃止していたので、Javaアプレットは動作しません。
(2015-09-02追記)Google Chromeは、バージョン45以降(Linux版はバージョン35以降)NPAPIプラグインのサポートを廃止したので、Javaアプレットは動作しません。
(2015-04-17追記)Windows 10のMicrosoft EdgeはカスタムActiveXコントロールをサポートしないので、Javaアプレットは動作しません。
Linux版のGoogle Chromeでは、バージョン35以降Javaアプレットの実行がサポートされなくなりました(参照: Issue 363053: IcedTea Java Plugin not recognized with 35.0.1916.27 beta aura)。)(2015-04-17追記)また、全プラットフォームのChromeでバージョン42以降、Java Plug-inを含めNPAPIプラグインが既定で無効化されました。
Java SE 7u11以降、既定で無署名のJavaアプレットの実行前に警告が表示されるようになりました。(2014-01-29追記)またJava SE 7u51以降、無署名のJavaアプレットの実行は既定でブロックされるようになりました。
Windows 8では、MetroスタイルのIEはプラグインをサポートしないので、Javaアプレットは動作しません。(2013-07-28追記、2014-04-22更新) 現時点でJava Plug-inはIE10以降の拡張保護モードに対応していないので、デスクトップ版のIEでも拡張保護モードを有効にするとJavaアプレットは動作しなくなります。JRE 7 Update 51以降、Windows 8.1のIE 11では拡張保護モードに対応したようです。IE9以降のActiveXフィルターが有効だとJavaアプレットの実行はブロックされます。またGoogle Chrome 11 (Chromium Revision 72766)やFirefox 26以降ではデフォルトでJavaアプレットがブロックされ、実行にはユーザーの許可が必要になっています。
これに対して、HTML5版をデフォルトでブロックするブラウザは今のところありません(ブラウザが古くて動かないことはありえますが)。
そのほか、次のような点についてはJavaアプレット版よりメリットがあります。
いっぽう次のような点はJavaアプレット版に劣ります。
Webブラウザの性能が許す限り、いくらでも多くのセルと大きな表示領域を使えます(とはいえちょっと大きいデータになるとあまり実用的ではありません)。コメント機能、追加セットには今のところ未対応です。
ckissにはいちおう対応していますが、データが大きくなるのでロードが非常に遅いです。
今のところ並列実行を全く考慮していないので、同じページで複数データを同時に開いたり、ロード中にセットを切り替えたりすると動作がおかしくなります。
現在、LZH圧縮していないデータの読み込みではXMLHttpRequestを同期的に使っているので、データの読み込み中ブラウザが固まります。遅い通信回線や巨大なデータでは顕著な問題になります。
プラグインなどは必要ありませんが、WebブラウザはいわゆるHTML5対応と呼ばれる、比較的新しいものでなければなりません。
具体的には以下の機能をサポートしている必要があります。また、任意のバイナリファイルからの読み取りを実現するためにunlzh.jsのシステム要件も満たす必要があります。
canvasはピクセルデータの読み書きをサポートしている必要があります。具体的にはCanvasRenderingContext2DインターフェースにgetImageDataメソッドとputImageDataメソッドが必要です。古い(たとえばWeb Application 1.0の時代の)canvas要素の実装はこれらのメソッドをサポートしていない場合があります。putImageDataをサポートしていない場合にはdata URLスキームによるシミュレートを行います。createImageDataメソッドはサポートされていれば使いますが、必ずしもサポートされている必要はありません。
セルを任意の座標に表示するための絶対配置(position: absoluteなど)、セットに存在しないセルを隠したりするために可視性(visibilityプロパティ)などの機能を使っています。ckissのセル全体透明度(%t)を実現するためにopacityプロパティを使っています。
マウス操作を検知するためにaddEventListenerメソッドやMouseEventインターフェースなどを使用しています。
ポインタの要素に対する相対位置を求めるために、getBoundingClientRect()メソッドを使用しています。offsetX/offsetYのほうが直接的なのですが、ブラウザにより実装されていなかったり実装がCSSOM Viewの仕様通りでなかったりするので使用していません(参考)。仕様ではgetBoundingClientRect()により得られる値はfloatなので、セルの当たり判定で誤差を生じないようにMath.roundで丸めを行っています(ただし実際には、IEやWebKitは丸めを行なった値を返すようです)。
またページの幅を取得するのにinnerWidthプロパティを、CSSのfloatプロパティを変更するためにcssFloatプロパティを、CSSプロパティの計算値を取得するためにgetComputedStyle()メソッドを使用しています。一部のブラウザではバグ対策のためにCSSOM Viewで定義されている他のプロパティやブラウザの独自拡張を使っている場合があります。
Internet Explorerはバージョン8でもかなり厳しいです。あくまで私の環境での参考ですが、Chrome 2はFirefox 3.5の2〜3倍、Safari 4は10倍近くも速いです。Internet Explorer 8はFirefox 3.5の10倍以上遅いですが。Minefield 3.7a3preではJavaScriptがさらに高速化されてCanvasPixelArrayがサポートされたため、Chrome/Safari/Opera 10.50並みに速くなっているようです(これらの機能の導入前後のビルドではっきり体感できるほど速度が違う)。技術的な解説
IE9 Platform Preview 3では大幅に速くなっていますが、Microsoftの宣伝から受けるイメージほどではありませんでした(ハードウェアが貧弱でアクセラレーションが効いていないのかもしれませんが)。
また最低でもECMA-262 第3版の機能が必要です。たとえば、第3版で初めて定義されたtry...catchを使用しています。もっともいわゆるHTML5対応ブラウザのJavaScript実装が第3版の機能すらサポートしていないほど古いということはありえないので、事実上この条件は問題になりません。
今のところdata URLのcanvasシミュレートはtoDataURLをサポートしていないため、canvasのネイティブサポートが必要です(img.srcを返すだけなので画像のスライスが必要なIE8以外なら対応は簡単そうですが)。もっともcanvasすらサポートしていないブラウザーが以下の他の必要条件を満たしている可能性はほとんどないと思います。
画面キャプチャー用SVGを作成するとき内部でSVG DOMを使用しているため、SVGサポートが必要です。
SVG文書断片をシリアライズ(文字列化)するためにXMLSerializerを使用しています。
一部のBlobコンストラクターをサポートしていない旧ブラウザーがサポートするBlobBuilderは考慮していません。
一部のURLオブジェクトをサポートしていない旧ブラウザーがサポートするwebkitURLは考慮していません。
ダウンロード時のファイル名指定と、強制的にダウンロード動作を発生させるために必要です。download属性をサポートしていないブラウザーでも画面遷移が発生してSVG画像が表示されるかもしれません。その場合は「名前を付けて保存」で画像をダウンロードできます。
リンクのクリック動作を発生させるために必要です。一部の旧ブラウザーのためにdispatchEventによるpolyfillなどは行っていません。
canvasをサポートしていない環境やcanvasにputImageDataがない環境(Safari 3.2など)では、data URLスキームによりputImageDataをシミュレートしています。ただしそういう環境は概してJavaScriptも低速なので、あまり実用的ではないでしょう。
Safari 3.2.2/3.2.3/Chrome 1.0はgetBoundingClientRectに未対応なので、CSSOM View Moduleの他の機能を使ってシミュレートしています。
Firefox 2はgetBoundingClientRectをサポートしていないので、Gecko独自のgetBoxObjectForによりシミュレートしています。またCSSの固定配置の実装バグにより、ときどき着せ替えウィンドウがシェードの背後に回って操作不能になることがあったので、この対策として(またブラウザのバグとは関係なくページのフッタが固定配置要素であるような場合を考慮して)z-indexを指定しています。さらにCSSのfloatの実装バグにより、着せ替えウィンドウの幅が正しく計算されないので(またブラウザのバグとは関係なく固定配置を使わないモードを考慮して)、幅を明示的に指定しています。
各種シミュレートは原則としてKISSを動かすのに必要な最低限の実装しか行っていないので、そのまま他のページで使い回せるとは限りません。また同様のシミュレーションを行っている他のライブラリと衝突するおそれがあります。ご注意ください。
Opera 10.50〜12.18 (Presto Opera)ではバイナリファイルのダウンロードに対応して動作可能になりましたが、細かな不具合があります:
Opera 15以降(Blink Opera)はChromeと同様です。
IE9では、開発者ツールを開くとwindow.consoleが再定義されるため、動作しなくなります。
IE9はBlobが未サポートなので、画面キャプチャー機能は動作しません。
Firefox 70/ESR68未満では文書に挿入されていないa要素でclickメソッドが動作しないため、clickを呼び出す瞬間だけ文書に挿入しています。clickの代わりにdispatchEventでclickイベントを発火しても回避できるようですが、今のところ採用していません。
画面キャプチャーのSVGはシリアライズをブラウザーに丸投げしているので、出力はブラウザー依存です(xmlns:xlinkがIEでは個々のimage要素につくのに対してEdgeHTML/Firefox 108/Chrome 109ではsvg要素に1つだけつくなど)。
Internet Explorer 7以前は、ブラウザの標準機能のみではピクセル単位で任意の絵を描くことがほとんど不可能に近いので、対応していません。絶対配置のspanをたくさん並べてシミュレートするという手もいちおう試してみましたが、案の定まるで使いものにならなかったので(私のスキル不足の可能性もありますが)あきらめました。
Opera 10.10以前のバージョンはバイナリファイルをJavaScriptから読み取る手段がなかったので、(KISS/GSのファイルをそのまま読めるという要件を満たす限り)対応できませんでした。
(2011-05-14) Firefox for mobile 4.0.1は(少なくともWindows用のエミュレータ上では)マウスイベントが取れないため、服を移動させることができない(ページ全体がスクロールしてしまう)ようです。
現在は他者が設置することを想定していませんが、勝手に解析して設置する分にはかまいません。
という不親切さにもかかわらず、設置していただいたページがあるようです。
kisekae.org - kisekae set viewer and gallery ローカルの.lzhファイルをドロップすることでブラウザー上でKISSデータを開けるようです。FKiSS2対応
smooch KISS/GS仕様の.lzhファイルを独自形式に変換するHaskellプログラムと、独自形式のビューアーから成ります。