アカウント名:
パスワード:
globalCompositeOperationの動作にFirefox/OperaとWebKit系で 違うところがあって [hatena.ne.jp]、仕様に忠実なのはFirefox/OperaのほうなのですがWebKitが修正を拒否している [webkit.org]ので、現時点でIEは採用しかねていると思われます。IEが採用するとその仕様に事実上決まってしまうのはほとんど間違いないので、動作にある程度ベンダ間で合意が取れている状態でなくてはそりゃ採用しづらいでしょう。ちなみにglobalCompositeOperationはオペレータをサポートしていない場合の挙動もちゃんと規定されているので、スクリプト側でサポートされていない可能性を想定するなら、IE9判別ではなくfeature detectionをすべきです。たとえばcopyオペレータを使
globalCompositeOperationの動作にFirefox/OperaとWebKit系で違うところがあって、仕様に忠実なのはFirefox/OperaのほうなのですがWebKitが修正を拒否しているので、現時点でIEは採用しかねていると思われます。
これはW3CからWebKit側にちゃんと対応するように、MSにはFirefoxやOperaに合わせる様にと口出しできないのかな?それが出来ないと結局は力が有るところは独自に実装しちゃうという状況は改善しないって事ですよね。
FirefoxやOperaは Canvas 2D Context [w3.org]の仕様に従っているだけで、それを独自の実装と言われても困るのですが。
WebKitのサイトには、FirefoxやOperaの実装は間違っていると書いてある
捏造はやめていただけませんか。
We believe the spec is wrong in its definition of these behaviours.
(現在の)Canvas 2D Contextの仕様は間違っていると主張しているだけです。もちろんCanvas 2D Contextはまだ草案ですから仕様が更新されるのは一向に構いませんが、実際に更新されるまでは正しいのはFirefoxやOperaの実装です。独自の実装よばわりされる筋合いはありません。WebKit陣営であるはずのIan Hickson氏が現行の仕様を更新するつもりが
> 捏造はやめてもう少し穏やかな言葉を使われた方が...
Canvas 2DのcompositはPorter-Duffの論文 [keithp.com]に基づくのは仕様で言及されている点でもあり誰もが異論のない点だとは思います。
現在の仕様はPorter-Duffの論文で分類されているコンポジット状態をより視覚的に反映しやすい(=論文を見た人および仕様を見た人がイメージしやすい)という点で優れていると思いますし、仕様を作る側のIan Hicksonが現状の仕様をより元論文のイメージに近いように明確化しようという側に立つのも理解できる気もします。
とはいえ、"周りをクリアする"タイプのコンポジットは最終的な可視部分の描画範囲が小さくても描画範囲全体に影響を及ぼすので、現行の仕様のまま描画領域をclipping regionとするとオプティマイズしにくいパフォーマンス劣化がおき易くなりそうですね。また、MSのJatinder Mannが指摘した [w3.org]ように、描画の影響が現在描こうとするものとなるのが多いCanvas2Dにおいて違和感があるというのも納得できます。
Webkitが実装を修正するのはさほど難しくないと思われますし、Opera/Firefoxも同様なのでうまく解決をしてほしいところです。
この件に関しては実用度が高いにもかかわらずブラウザの実装の差異によって使いにくくなっていた問題で解決されると幸せになる人が多くなると思うのですが、Ian氏・WebKit陣営に歩み寄りの気配が見られないのが気がかりです。
こうしたテストケースの作成によってブラウザ間の実装の差異が明確化され、仮実装の修正や草案仕様の修正の必要性がより広く認識される意義は大きいと思います。
個人的にはどちらの方向でも良いんですが、Webkit陣営が実装を修正しないならより強く仕様の修正を働きかけるべきだと思うので、現状では現草案を応援という感じです。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人は巨人ファンでA型で眼鏡をかけている -- あるハッカー
IE9のcanvasサポートが100%じゃないのは多分意図的 (スコア:5, すばらしい洞察)
globalCompositeOperationの動作にFirefox/OperaとWebKit系で 違うところがあって [hatena.ne.jp]、仕様に忠実なのはFirefox/OperaのほうなのですがWebKitが修正を拒否している [webkit.org]ので、現時点でIEは採用しかねていると思われます。IEが採用するとその仕様に事実上決まってしまうのはほとんど間違いないので、動作にある程度ベンダ間で合意が取れている状態でなくてはそりゃ採用しづらいでしょう。
ちなみにglobalCompositeOperationはオペレータをサポートしていない場合の挙動もちゃんと規定されているので、スクリプト側でサポートされていない可能性を想定するなら、IE9判別ではなくfeature detectionをすべきです。たとえばcopyオペレータを使
Re: (スコア:0)
これはW3CからWebKit側にちゃんと対応するように、MSにはFirefoxやOperaに合わせる様にと口出しできないのかな?
それが出来ないと結局は力が有るところは独自に実装しちゃうという状況は改善しないって事ですよね。
Re: (スコア:0, 興味深い)
元々WebKit側から出たアイディアですし、むしろ独自の実装をしているのは、FirefoxやOperaの方な訳で。
Re: (スコア:1, 参考になる)
FirefoxやOperaは Canvas 2D Context [w3.org]の仕様に従っているだけで、それを独自の実装と言われても困るのですが。
捏造はやめていただけませんか。
(現在の)Canvas 2D Contextの仕様は間違っていると主張しているだけです。もちろんCanvas 2D Contextはまだ草案ですから仕様が更新されるのは一向に構いませんが、実際に更新されるまでは正しいのはFirefoxやOperaの実装です。独自の実装よばわりされる筋合いはありません。
WebKit陣営であるはずのIan Hickson氏が現行の仕様を更新するつもりが
Re:IE9のcanvasサポートが100%じゃないのは多分意図的 (スコア:2, 参考になる)
> 捏造はやめて
もう少し穏やかな言葉を使われた方が...
Canvas 2DのcompositはPorter-Duffの論文 [keithp.com]に基づくのは仕様で言及されている点でもあり誰もが異論のない点だとは思います。
現在の仕様はPorter-Duffの論文で分類されているコンポジット状態をより視覚的に反映しやすい(=論文を見た人および仕様を見た人がイメージしやすい)という点で優れていると思いますし、仕様を作る側のIan Hicksonが現状の仕様をより元論文のイメージに近いように明確化しようという側に立つのも理解できる気もします。
とはいえ、"周りをクリアする"タイプのコンポジットは最終的な可視部分の描画範囲が小さくても描画範囲全体に影響を及ぼすので、現行の仕様のまま描画領域をclipping regionとするとオプティマイズしにくいパフォーマンス劣化がおき易くなりそうですね。
また、MSのJatinder Mannが指摘した [w3.org]ように、描画の影響が現在描こうとするものとなるのが多いCanvas2Dにおいて違和感があるというのも納得できます。
Webkitが実装を修正するのはさほど難しくないと思われますし、Opera/Firefoxも同様なのでうまく解決をしてほしいところです。
この件に関しては実用度が高いにもかかわらずブラウザの実装の差異によって使いにくくなっていた問題で解決されると幸せになる人が多くなると思うのですが、Ian氏・WebKit陣営に歩み寄りの気配が見られないのが気がかりです。
こうしたテストケースの作成によってブラウザ間の実装の差異が明確化され、仮実装の修正や草案仕様の修正の必要性がより広く認識される意義は大きいと思います。
個人的にはどちらの方向でも良いんですが、Webkit陣営が実装を修正しないならより強く仕様の修正を働きかけるべきだと思うので、現状では現草案を応援という感じです。