W3CによるHTML5テスト、次世代WebブラウザではIE9がもっとも好成績 55
ストーリー by hylom
切磋琢磨 部門より
切磋琢磨 部門より
あるAnonymous Coward 曰く、
W3Cが「HTML5 Test Suite Conformance Results」を発表した。これは各ブラウザがHTML5をどれだけサポートしているかを調査したもので、232のテストから構成されている。Internet Explorer 9 Platform Preview 6とChromium 9.0.571.0、Firefox 4.0b8pre、Opera 11.00 alpha、WebKit Nightly Build r70732を対象としてテストが行われ、全体としてはIE9がもっとも好成績を残す結果となった。
テスト結果を見ると、IE9はattributeやaudio、video、xhtml5といったテストを100％パスしている。いっぽう、canvasやgetElemetnsByClassNameについてはほかのブラウザよりも劣る結果となっている。
IE9のcanvasサポートが100%じゃないのは多分意図的 (スコア:5, すばらしい洞察)
globalCompositeOperationの動作にFirefox/OperaとWebKit系で違うところがあって [hatena.ne.jp]、仕様に忠実なのはFirefox/OperaのほうなのですがWebKitが修正を拒否している [webkit.org]ので、現時点でIEは採用しかねていると思われます。IEが採用するとその仕様に事実上決まってしまうのはほとんど間違いないので、動作にある程度ベンダ間で合意が取れている状態でなくてはそりゃ採用しづらいでしょう。
ちなみにglobalCompositeOperationはオペレータをサポートしていない場合の挙動もちゃんと規定されているので、スクリプト側でサポートされていない可能性を想定するなら、IE9判別ではなくfeature detectionをすべきです。たとえばcopyオペレータを使いたいなら
みたいな。もっともcopyオペレータはまさに現時点でブラウザによって動作が異なるオペレータでサポート判定だけでは不十分な可能性があるので、例としてはあまり適切じゃないかも。
Re: (スコア:0)
これはW3CからWebKit側にちゃんと対応するように、MSにはFirefoxやOperaに合わせる様にと口出しできないのかな？
それが出来ないと結局は力が有るところは独自に実装しちゃうという状況は改善しないって事ですよね。
Re:IE9のcanvasサポートが100%じゃないのは多分意図的 (スコア:3, 参考になる)
2010年5月下旬にMSの中の人から「globalCompositeOperationの動作がブラウザによって違うんだけどこれってどうよ? WebKitの動作のほうが合理的だと思うから仕様を更新したほうがよくね?」質問がある [w3.org]。
↓
「既出。リストの過去ログをググれ」と返事がある [w3.org]けど、議論はここでおしまい。
↓
2010年6月下旬にIE9 Platform Preview 3がcanvas 2D contextをサポートするけど、globalCompositeOperationは未サポート。
↓
桶屋(Adobe)が儲かる ←今ここ
Re: (スコア:0, 興味深い)
元々WebKit側から出たアイディアですし、むしろ独自の実装をしているのは、FirefoxやOperaの方な訳で。
Re:IE9のcanvasサポートが100%じゃないのは多分意図的 (スコア:1, 参考になる)
FirefoxやOperaはCanvas 2D Context [w3.org]の仕様に従っているだけで、それを独自の実装と言われても困るのですが。
捏造はやめていただけませんか。
(現在の)Canvas 2D Contextの仕様は間違っていると主張しているだけです。もちろんCanvas 2D Contextはまだ草案ですから仕様が更新されるのは一向に構いませんが、実際に更新されるまでは正しいのはFirefoxやOperaの実装です。独自の実装よばわりされる筋合いはありません。
WebKit陣営であるはずのIan Hickson氏が現行の仕様を更新するつもりがないっぽい [whatwg.org]のがどうも妙なのですが。
別ストーリーで「IE6はCSS2に対応しているとは一言も言っていないのだから、CSS2のプロパティと同名の独自拡張をサポートしているにすぎない」と主張している人がいました。CSS2のpositioningなどの仕様がIEの実装を元に作られたからと言って、IEの実装と違う点はすべてIEのほうが正しいわけではありません。
同様の論法に従うなら、WebKitはCanvas 2D Contextと同名のプロパティを使った独自拡張をサポートしているにすぎません。
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陣営が実装を修正しないならより強く仕様の修正を働きかけるべきだと思うので、現状では現草案を応援という感じです。
互換性のために (スコア:1, すばらしい洞察)
かつてIE6が巻き起こした様々な混乱を考えれば、それくらい厳しくすべきだ。たとえ対象がマイクロソフト以外であっても。
このテストスイートは開発中だから余り厳密に信用するな (スコア:2)
Re: (スコア:0)
Re: (スコア:0)
Re: (スコア:0)
そもそもサブジェクトまで全部読まないといけないってプレッシャーがあって困る。
まあ読んで欲しいのかもしれんが…
Re:互換性のために (スコア:1, すばらしい洞察)
その前にさっさとHTML5の仕様固めろよ……
Re:互換性のために (スコア:3, すばらしい洞察)
Re:互換性のために (スコア:2, おもしろおかしい)
では、HTML5に対する（webアプリ開発者等を含む）ユーザー側の統一した要望を……
Re:互換性のために (スコア:1)
それなりならいいけど (スコア:0)
実際には1pxたりとも表示の違いが許されないので死にます。
この馬鹿げた要求さえなくなるなら古いブラウザのサポートもやぶさかではないのですが。
Re: (スコア:0)
何してはるんですか一休さん？
Re: (スコア:0)
# CSS3も含めてどんどん分かりにくくなってるしぃ
Re: (スコア:0)
Re: (スコア:0)
これまでのHTMLって
「仕様が完全に固まってからブラウザが実装を行う」
ってやり方だったんだ。へぇー。
Re: (スコア:0)
ブラウザ間の互換性を十分に高めるために、手法を変えることも必要だと思いますけどね。
Re: (スコア:0)
今までのやり方だとまたブラウザごとに実装が変わるだろ。学習能力無いんかいな。
Re: (スコア:0)
いや、固まらないと
＞テストに100%パスしないと
の100%をどうやって判断するの？って凄く大きな問題が有る訳だが。
Re: (スコア:0)
＞テストに100%パスしないと
それが何か問題あるのか？
iTunesはHTMLでコンテンツが記述されているのか？違うだろ。
オンラインビジネスをするのにHTMLに従う必要がないことは、HTML5容認派のApple
でさえ、かような形で否定している。オンラインビジネスをするための、専用のHTML
もどきであるXMLを解釈するブラウザがこの世に出てなにか問題でもあるの？
＞一般向けにリリースできない or HTML5対応を名乗れない、などのペナルティが必要だと思う。
さらに、一般向けとは何を意味するの？XMLブラウザと名乗ってきてもリリースできないの？
浅はかな、ばかばかしい話ですね。
Re:互換性のために (スコア:2, 参考になる)
> iTunesはHTMLでコンテンツが記述されているのか？違うだろ。
iTunesは9から描画がWebKitベースに変更されていて、特殊な機能ボタンの実現以外は通常のHTML5で実装されるようになりました。
c.f. http://willnorris.com/2009/09/itunes-9-now-with-more-webkit [willnorris.com]
ここのコメントの中でiTune Storeへのプロキシを作って、通常のWebブラウザからアクセスできるようにした方もいるので
気軽にソースと結果を眺められるようになっていますよ。
http://itunes-proxy.jgate.de/ax.itunes.apple.com/WebObjects/MZStore.wo... [jgate.de]
Re: (スコア:0)
>> iTunesはHTMLでコンテンツが記述されているのか？違うだろ。
>iTunesは9から描画がWebKitベースに変更されていて、特殊な機能ボタンの実現以外は通常のHTML5で実装されるようになりました。
元コメです。
なるほど、これは知りませんでした。ありがとうございます。
「特殊な機能ボタンの実現」の箇所で、IE6の特殊仕様や、HTMLでできないことは、
Flashを使えばよい、といった過去の潮流を思い出させる箇所はあるのですが、ね。
Re: (スコア:0)
親コメは「HTML5対応ブラウザを名乗るなら、テスト100%パスを義務化しよう」と言っているだけで、
全てのブラウザ的要素のあるソフトウェアに、100%のHTML5対応を求めているわけでは無いのでは。
難しいと思いますが、互換で苦労したので気持ちはわかります。
IE9の成績がいいのは・・・・・・ (スコア:1, 興味深い)
Microsoftは、IE9のテスト用に作成したテストケースを、せっせとW3Cに提供している。今回のTest Suiteに採用されたテストケースにしても、Microsoftが提案したものや、その発展系が含まれている。
Windows Internet Explorer Testing Center:
http://samples.msdn.microsoft.com/ietestcenter/
Canvas、WebSocks API関連について特にいえることですが、いつのDraft案に準拠したかで、互換性が損なわれるような大きな変更は、やめていただきたいものです。
Re:IE9の成績がいいのは・・・・・・ (スコア:1, すばらしい洞察)
問題はrubyだと思う。
HTMLでルビが振れるようになるのは結構なことだが、ruby要素だけは死んで欲しい。せっかくXHTMLがうまい具合に廃れてきたのに、台無しだ。
Re:IE9の成績がいいのは・・・・・・ (スコア:1, オフトピック)
Re: (スコア:0)
Re: (スコア:0)
ルビはいいけどruby要素は駄目ってどういうこと？ 気になるので詳しく
Re:IE9の成績がいいのは・・・・・・ (スコア:3, 参考になる)
例えば、abbrって要素があるけど、これのマークアップは
で行う。
つまり、"WWW"と"わーるどわいどうぇぶ"の2つの文字列の関係を示すために、この要素が使われているわけ。で、表現方法として"WWW"の上にポインタを持っていくと、"わーるどわいどうぇぶ"っていうツールチップが出る。デフォルトではね。
しかし、よく考えて欲しいんだけど、abbreviationをルビで表現したい場合もあるよね。すると、abbrとrubyを両方マークアップしなければならない、という、ちょっとおかしなシチュエーションが生まれる。これは、文章構造のマークアップという観点からは下策もいいところ。なぜ、こうなったか、そもそもルビとはなんなのか、という点に議論が尽くされていなかった。今までね。
ぶっちゃけ、ルビってスタイルでしょ？ もちろん、「読み仮名」と「漢字」の間には文章構造が成立している点は否定しないけど、それは、あんな複雑怪奇なルールでしか記述できないものじゃない。spanみたいな汎用要素でも表現可能だ。ルビの重要な点はどういう風にレンダリングされるか、なんだから、これはスタイルシートがルビに対応していれば、それでいい。
すでに、CSSには:afterと:beforeという擬似要素がある。
と書いておけば、上記の
は
とレンダリングされる。
もし、前後だけじゃなくて、インライン要素の両サイドに擬似要素が配置できたら、それこそが定義から考えてもルビそのものだろう。仮に:upper-side擬似要素とでも名づけておくけど(実際には縦書きのことも考えて、違う名前にすべきだけど)、CSSに
って書いておいた時に、
が
とレンダリングされたら、みんなが幸せになれるはず。
もちろん、abbribiationでもacronymでもなんでもなくて、ただ読み仮名なんだ、ってこともあるだろうから、<ruby title="わーるどわいどうぇぶ">WWW</ruby>っていう要素があってもいいし、その場合はいちいちスタイルシートを指定しなくても標準で上記のように表示されるべきだと思う。あるいは、<span ruby="わーるどわいどうぇぶ">WWW</span>とかでもいい。
しかし、少なくとも、現行のruby要素のように、rbとかrtとかそういった子要素でルビを表現するのはマゾの振る舞いであって、常人の為すところじゃない。もちろん、これは対応していないブラウザである程度納得がいくようにこういったギミックが仕込まれたわけだけど、この対価は重すぎて話にならない。筋の悪い技術でも広まると宗教戦争が一層激しくなるので、やめるなら今のうち、だと思うんだけれど、どうかな？
Re: (スコア:0)
Re:IE9の成績がいいのは・・・・・・ (スコア:2, おもしろおかしい)
ちょっとまって。
じゃあ、「香具師（やし）」とか「強敵（とも）」とか、
「小鳥遊（たかなし）」とか「一方通行（アクセラレータ）」とかは、
どの漢字の上にどの仮名をいれればよいのですか？
Re:IE9の成績がいいのは・・・・・・ (スコア:1)
>「白長須鯨」にルビ打ったときに「く」が須の上に出るようでは、話にならないのですよ。
白と長と須と鯨に、しろ なが す くじらと独立してルビふれば？
Re: (スコア:0)
Re:IE9の成績がいいのは・・・・・・ (スコア:1)
>そんなことしたら、白長須鯨ではなく白 長 須 鯨になってしまう
問題ないよ
Re: (スコア:0)
漢字はつながることで意味や読み方が変わるんだから一文字ずつじゃ駄目でしょ。
あなたはそれでも構わんと思うかもしれないけど、日本語的には駄目。
Re:IE9の成績がいいのは・・・・・・ (スコア:1)
>漢字はつながることで意味や読み方が変わるんだから一文字ずつじゃ駄目でしょ。
漢 字はつながらなくても意 味や 読 み 方 が通りますよ。一 文 字 ずつでも駄 目ではありません。
>日 本 語 的には駄 目。
ね、 問 題 ないよ。
Re:IE9の成績がいいのは・・・・・・ (スコア:1)
うーん、それもやや日本語を独自の枠に当てはめすぎているように思うのですが……。
ルビってもっと柔軟な使われ方をしていますよ、特に当て字の場合に。
例えば、夏目漱石氏の『吾輩ハ猫デアル』では、「金剛石」という言葉に「ダイヤモンド」という読みを振っているようです。当て字ですから、漢字一文字ずつには分割することができません。あくまで単語に対しての読みになるはずです。
これが「正しい日本語ではない」と否定されるならそうなのかもしれませんが、実態に即していないという意味では全く実用的ではありません。
結局日本語のルビは、愚直にその箇所の発音だけを示唆する場合もあれば、単語に対しての属性を付け加えている場合もあり、更には全く違う言葉を振って多義的な文章を作るようなお遊び（秋津透氏が好んだ(笑)）さえあるという、きわめて野放図に用いられてきたものなわけです。
以前Web上のどこかで読んだだけなのでソースは示せませんが、rbとrtの醜さも「言語学的には親字ではなくルビの方こそが主」という主張に対してのものだそうです。（記憶違いがあったらごめんなさい）
「現状の仕様が美しくない」という点には同意ですが、元々言語なんていい加減なものですから、仕方ないんじゃないでしょうか。
--
余談になりますが、昔私がルビの簡易レイアウトプログラムを作った際は、「親字と振り仮名が同じ仮名のときは省略（ひらがな／カタカナ同一視）」というルールにしました。
「取っ手」の読み仮名はあくまで「とって」、「シロナガス鯨」は「しろながすくじら」としておき、表示時に「っ」や「しろながす」を省略というイメージですね。
機械的に判別できないケースもありそうですが、自分の必要とした範囲では支障なかったので(^^;)
Re:IE9の成績がいいのは・・・・・・ (スコア:1)
考 えているけどね。で、 反 論 になっていないよ。もうちょっと 内 容 を 考 えておくとよいだろうな。
あ、ACだから、 無 理 かな？
Re: (スコア:0)
Re:IE9の成績がいいのは・・・・・・ (スコア:1, 参考になる)
CSS Ruby Moduleでは属性と要素を互換するのは難しい。
例えば、
とできれば、面白いとは思うけど、おそらくこれを意図どおりにレンダリングしてくれるブラウザは将来的にも現れないだろう。ruby-baseをきちんと指定できないので。
余の部分のように、細かい制御方法の取り決めはどの道必要だけど、
http://www.w3.org/TR/css3-ruby/#display [w3.org]
で指定されているように*要素*とその周りの親子関係を期待するような決め方は悪手だし、そうしていまうと、この先の発展はないと思う。ただ、スクリプトを使えばなんとかなる、という点だけはかろうじて評価できる。
> #1853173
か、もしくは、
http://www.w3.org/TR/html-markup/datatypes.html#data-token-def [w3.org]に従って、
になるかな。
Re: (スコア:0)
HTMLの問題ではなく日本語の問題でしょ。
「白長須鯨」はそれで一つの成語じゃないの？
だったら分割するのは間違い。
仮に、「白長須」と「鯨」に日本語として分けられるとしたら、表現もそうするだけの話。
Re:IE9の成績がいいのは・・・・・・ (スコア:1, 興味深い)
その通りでIE9はテストをどんどんW3Cに提供しており、それをアピールしてますね。
まあ、地道に開発者のために網羅性の高いテストケースを提供しつづけているというのは、とても良い態度だと思いますけど。他のグループもテストを提供できるわけだし。
特定の「ナントカベンチマーク1.0」とか「Acid3」みたいな華々しいものこそ、特定の団体が適当に機能を固定して作ったものであり、特定のブラウザへの有利不利が出やすいと思います。
Re: (スコア:0)
HTML5については先行実装だけ突っ走るWebKitの方がやり方えげつないなあと思う。
先行実装が存在しないと規格に含めない方針で策定を進めているという事情があるとはいえ。
第二次大戦 (スコア:0)
何度でもやるんだろうね
Re: (スコア:0)
それはIEじゃなくてHTMLのバージョンの話？
Microsoftは昔は自身の規格をW3Cでゴリ押しな印象が強かったけど（XMLSchemaとか）、
HTML5に関してはやりすぎでもなくやらなすぎでもなくって感じで至極妥当な対応を
しているように思う。
Typo (スコア:0)