【WHATWG】HTML5 Part3【W3C HTML WG】

1 ：11/01/24 〜 最終レス ：12/01/08

訪れるのは輝ける未来か、はたまたHTML3.2の悪夢再来か。
次世代HTML規格HTML5について語るスレその3
大いに語ろうず。
W3C - HTML 5 differences from HTML 4 日本語訳
ttp://www.html5.jp/trans/w3c_differences.html
前スレ
http://hibari.2ch.net/test/read.cgi/hp/1254235548/l50
個人的にはdl要素会話文が不適切になったことが気に食わない。

2 ：

個人サイトならどうでもいいけど、企業サイトはコーディングルール
しっかり決めとかないと面倒くさいことになりそうだな。

3 ：

まだ企業関係は4.01が多いけどやっぱこれからは、5やね。

4 ：

　　　　 　＿＿＿_∩＿∩
　　〜／　　　　　 　 ・　・＼
　　　（　　 　　　　　　 ∀ 　 ）　　＜ぼく、４ゲット君
　　　　＼／＼／＼／＼／

5 ：

WHATWG、HTML標準規格を「随時アップデートする」方針へ変更 - SourceForge.JP Magazine : オープンソースの話題満載
http://sourceforge.jp/magazine/11/01/24/0259219
めんどくさそう

6 ：

ビデオとかの派手な部分は別として、
headerとかsectionとかそういうのはもう使ってもOKなのかい？
CSSでスタイル作ったら各ブラウザは対応してくれてるのかな。

7 ：

おせーよ乙

8 ：

　＼　　　　　　　　　　　　　　　　　　　　/
　　 ＼　　丶　　　　 　 i.　　 |　　　　　 /　　 　 ./　　　　 　 ／
　　　　＼　　ヽ　　　　　i. 　 .|　　　　　/　　　 /　　　　　 ／
　　　　　 ＼　　ヽ　　　　i　　|　　　　 /　　　/　　　　　／
　　　＼
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　-‐
　　ー
　_＿　　　　　　　　　　わ　た　し　で　す　　　　　　　　　　　　--
　　　　　二　　　　　　　 　　／￣＼　　　　　　　　　　　＝　二
　　￣　　　　　　　　　　　　|　＾o＾　|　　　　　　　　　　　　　　　　￣
　　　　-‐　　　　　　　　　　 ＼＿／ 　　　　　　　　　　　　　　　‐-
　　　　／
　　　　　　　　　　　　/　　　　　　　　　　　　　　　ヽ　　　　　 ＼
　　　　／　　　　　　　　　　　　　　　　　　　　丶　　　　 ＼
　　 ／　　　/　　　 /　　　　　　|　　　i,　　　 　 丶　　　　　＼
　／　　　 /　　　　/　　　　　　 |　　　 i,　　　　　　丶　　　　　＼　

9 ：

dtdもないんだろ？
カオスだよな

10 ：

そのかわりDOMによるインターフェイスがしっかり定義されてるんだけどね
あとパースの仕様も

11 ：

なるほど

12 ：

>>5
W3Cはどうすんだこれ。勧告行ってもすぐWHATWGが「それは最新仕様じゃない」って言ってくるってこと？
WHATWG側も以前は勧告するって言ってたけど、その方針は取り下げたってこと？

13 ：

グラフィック（描画）に限定してHTML5の質問。
Flash（AS3.0）と比べたときのCanvas（JavaScript）の優位性って何ですか？
CanvasはFlashよりも負荷が軽いとは言われるものの、これは明らかにコンテンツ
次第だし、どっちもベクターグラフィックだし、今のところ有利な点が見つかりません。
（と言うか、JavaScriptはAS2.0の兄弟だし）
強いて挙げれば、Canvasはブラウザとテキストエディターがあれば手軽に出来る
というくらい？
宜しくお願い致します。

14 ：

将来性

15 ：

プラグイン不要
プラグインの脆弱性心配なし

16 ：

>>15
それって諸刃の刃だよな。
プラグインが無いということは、100％ブラウザ依存な訳だから、各ブラウザ
によって同じJavaScriptでも微妙に見え方が変る。
特に、手の込んだ精細な描画を再現するとき致命的だと思う。

17 ：

描写の問題だったら簡単に解決できるよ。videoからcanvasに引っ張ってくるとか、いくらでも手はある

18 ：

>>16
フレームバッファに直接アクセスできるHTML5（canvas）の場合は、その問題はない
最終手段として「すべて自分でレンダリング」という大技があるから

19 ：

レスさんきゅう
>>17
これってvideoタグを無理やりcanvasにするってこと？　詳しく。
質問としてはJavaScript（コーディング）による数学的な描画を前提にしているのだけど。
例えば円：　x = Rcosθ　y = Rsinθ とか。
>>18
「すべて自分でレンダリング」というのは毎回全部beginPath()で描き直すってこと？

20 ：

>>19
videoの中身をcanvasにコピーするってことだけど数学的な描画には使えない。
けど「数学的な描画」で「精細な描画を再現する」とき「微妙に見え方が変って困る」ことってなんだ？ｗ
数学的な描画ならcanvas使えばクロスブラウザ問題なんてないはずだけど

21 ：

>>16
例えばどう言う時？

22 ：

>>20-21
精細な描画に対するHTML5のデメリットとしては
ttp://d.hatena.ne.jp/mindcat/20100815/1281877127
ttp://itpro.nikkeibp.co.jp/article/Interview/20100831/351574/
の記事が発端となっています。
たとえばFlashのこんな（静止画では無い）描画です。
http://wonderfl.net/c/2PWX
http://wonderfl.net/c/kkOn
http://wonderfl.net/c/ueZ6

23 ：

まだ草案なんだし、徐々にブラウザごとの差異も無くなっていくと期待しよう

24 ：

実装確認してから仕様を策定するっていうプロセスからしておかしい

25 ：

仕様を策定してから実装にして討ち死にした例：XHTML

26 ：

結局、数学的な描画に限定してFlashと比べたときのCanvasの優位性って何だろ？
今のところ、タダで簡単に始められる点しか見つからない。

27 ：

>>26
相変わらず何が聞きたいのか意味不明だな
「数学的な描画に限定」すりゃ「同じ」としか言いようがないんだが
ただ、HTML5なら開発者・利用者ともにずっと使いやすくて簡単に作れる、ということ

28 ：

プラグインを使わない＝使用プロセスが減る、ってことは確実に長所。
あとは全部一長一短。

29 ：

>>27-28
うん。言いたいことは分かるけど、プラグインを使わない反面>>22のような微細な
描画では見え方が変るから携帯サイトでキャリア毎に修正するのと同様にブラウザ毎
の微調整が必要なのでは？
たかが1ピクセル、されど1ピクセル。

30 ：

全部自前でやればって言われてる意味分かってないだろ

31 ：

あと、FlashをActionScript2.0にして「数学的な描画に限定」にすれば
CanvasのJavaScriptとほとんど同じだけど、現在主流のAS3は（描画の設定ほかで）
全く別ものだから。
考え得る範囲で書くと、
・工期（制作時間）：　AS2ではほぼ同じ。AS3ならJavaScriptが有利。
・細かい描画設定：　AS3（反面パラメーターが多く複雑＆要厳密な型指定）
・ブラウザ間の再現性：　AS（Flash）が有利
・初期投資：　JavaScriptが有利
・初心者向け：　JavaScriptもAS2もほぼ同じ
・3Dや物理ライブラリ：　不明（JavaScriptの現状が分からないので）
まとめると
「簡単な描画や入門用，短納期にはCanvas（JavaScript）。精細で高度な（3Dなど）描画はFlash」
と思われる。

32 ：

>>31
まとめはその結論でいいと思うよ。現状では。
細かい部分を言うと
・細かい描写設定：
　実装間の違いがあるためAS3が現状有利
　今後規格策定が進むにしたがって改善される余地はある。
・仕様
　Adobeが一社だけで策定しているFlashと、ブラウザベンダが合同で策定しているHTML5
　ECMAScript規格を無視したAS、ECMAScript規格を基にしたJS
・脆弱性
　層をひとつ増やす分、Flashの方が脆弱性は生まれやすくなる
・ソースコード
　Flashはそのままだとソースコードを読めない。JSなら読める。

33 ：

>>32
こういう項目毎の返答だと嬉しい。
レス有難う。

34 ：

ちなみに俺は「Flashクリエーター」と呼ばれる連中が　大　嫌　い　です。
特に激重単純タレ流しムービーを作る連中。

35 ：

こういうバカがFlashの嫌われる所以だなぁ

36 ：

canvasの優位性はブラウザとの統合(右クリックメニューがちゃんと出るとか)だと思ってるから、そういうのが要らなくて数学的な描画をしたいだけならcanvasに優位性は無いと思う。

37 ：

>>36
Flashの右クリックは簡単にカスタマイズ可能。
　ActionScript 3.0　ContextMenu　コンテキストメニュー
でググると吉。
例：　ttp://ojigotts-app.zono.cc/tag/contextmenu/

38 ：

>>37
ブラウザの機能は使えないし、バージョンとかいらないメニューは消せない

39 ：

>>38
それを言い出したらキリ無いじゃん。
普通のHPでもGIFやJPG部分の右クリックとそれ以外の箇所の右クリックは違う。
すごく簡単な例ならhttp://tsushima.2ch.at/s/news2ch125601.jpgとか。

40 ：

>>39
アホか。
コンテクスト(context, 文脈)に応じてメニューが変化するのが
右クリックのコンテクストメニューというもの。
マウスの選択先が画像かそれ以外かで変化するのは当然の振る舞い。
その振る舞いは、HTMLを使った普通のHPならブラウザと自然に統合される。
Flashの場合は、わざわざASでスクリプトを組んで、ブラウザと同じ振る舞いを
模倣する動きを作り込まなければならない。
自然に(スクリプト無しに)可能なHTMLとは大違いだ。

41 ：

>>40
なるほど、勉強になった。
「コンテクスト(context, 文脈)に応じてメニューが自然に（自動的に）振舞うようになる」と。
でもその説明なら、同じコード（context）で同じ画像に対してブラウザ毎にメニューが変るのは
解消できるの？

42 ：

>>41
ブラウザ毎どころか、同じブラウザでもプラットフォーム毎にメニューの
内容は異なるよ。でもユーザは迷うことはない。なぜなら、それが
いつも使っているブラウザの自然な振る舞い(メニュー内容)だから。

43 ：

>>42
なんか、それってよそ者を受け入れないアメリカ中西部の田舎町みたい。
昔から変らぬ仲間，知っている顔が同じ教会に集まる。
つまりは、ブラウザというコミュニティにFlashという異端者（異物）を入れるなと。

44 ：

ユーザーの立場からすれば普段の挙動と同じ方がストレスが少ない。
FLASHはフォーカス外さないとブラウザのショートカット効かなくなったりするしな。

45 ：

>>43
ユーザビリティに興味ないならそう思ってればいいんじゃない？
htmlで書ける部分をflashで置き換えたらウザがられるだけ。
flashなんて技術屋のーなんだし。

46 ：

重要な要素としてはアクセシビリティもあるよ
Flashで作るとほとんど不可能だけど
読めるHTMLを後からJSで動かせば親切な設計も十分可能って話
まあこれはHTML5+WAI-ARIAで実現するんで、Canvasでは使わないし
HTML5使わず現行の仕様だけで可能な部分も大きいんだけど
FlashをHTML5で置き換えるメリットではある

47 ：

flashはflash毎にコンテキストメニューがバラバラであり、ブラウザのコンテキストメニューとの共通部分もない。
一方ブラウザのコンテキストメニューはたかだか数種類だし、コンテキストによって変化しない共通部分もある。さらにブラウザの拡張機能もきちんと動作する。
コンテキストメニュー以外では中ボタンの扱い等もブラウザとflashで一貫しない。

48 ：

flasher(笑)

49 ：

>>48
確かに、垂れ流しFlashを作って悦に入ってる自称クリエーターは笑えるが、
HTML5も安心できないぞ。
今は製作者の数が少ないから良いけど、簡単なGUIツールが普及して素人でも
容易に複雑なサイトが作れるようになるとFlash以上に酷い状態になる。
・・・ブラウザに直接書くから、ブラウザを閉じる以外に無視することができなくなる。
ちなみに、FlashはPlayer（無料でDLできる）が有ればブラウザが無くても問題なく
利用できる。

50 ：

何が言いたいかサッパリだな。

51 ：

CanvasはHTMLの要素の一つなので他の要素にオーバーレイ描画できる。
JPEG画像を自動的に解析したり加工するJavascirpt/Canvasライブラリができたりするんじゃないかな。
グロ画像ぽかったら勝手にモザイクかけてくれるとかさ。

52 ：

File API使えばブラウザの上にドラッグ＆ドロップでファイル読み込ませたりできるんだろうけど
こういうのもFlashだとできない気がする

53 ：

ドロップ→アッーのトラウマ

54 ：

Flashは結局プラグインである事が一番悪い

55 ：

昔はそれが一番良かったんだけどねｗ時代は変わった、と

56 ：

>>43
お行儀の悪い奴、無作法な奴はどこへ行っても嫌われる。

57 ：

HTML5終了　Flashより圧倒的に遅いことが判明
ttp://macsuki.blog133.fc2.com/blog-entry-1810.html
ちなみにこの蝶の動画は4ヶ月くらい前に作られたもの。
当時は主にGPUで描画させるFlashPlayer10.2の正式版は未だでした。
>>56
HTML5（Canvas）でも性根の腐った重いサイトは作れるよ。
要は製作者と発注者の問題。

58 ：

>>57
真面目な話、比較としてはエンターテインメント的な価値しか無いでしょ？それ

59 ：

Flashがクソと言われるのはクラッシュしまくるからだ
SEOだとかデザイン性の問題は二の次
重い軽いかでいうとFlashは十分軽い

60 ：

>>58
だってttp://macsuki.blog133.fc2.com/blog-entry-1810.html の検証箇所はそれじゃん。
GUIのためにカスタムボタンとかカスタムスライダーの作成を必要とするなら、HTML5は
もっと劣るじゃん。
>>59
そんなもんFlashでもHTML5でもコンテンツ次第ですよ。
10ｔトラックに20ｔの荷物を載せたらノロくなるし、5ｔの荷物でも高さ10mの土管なら（重心が高すぎて）
不安定になる。

61 ：

BOTと話してる気分だ

62 ：

まあインタプリタ言語（JS）がコンパイル言語（AS）より速いのは当然だ
問題は差があることではなく、その差がどの程度なのか、どこまで詰められるのかってことで
あとJSは書き方次第でだいぶ負荷かわったりするし
生のJSソースから高速版ソース吐くようなツールもあるし、実用レベルまで差は詰められると思うよ
っていうかその見通しが立ってないのに業界がHTML5にこんなに注力するわけない

63 ：

>>62
要は案件毎の棲み分けだと思う。
表現力＆操作性を重視　→　AS3
表現力＆操作性よりも納期とコストを重視　→　AS2
試験的なサンプルやGUI入門　→　Canvas（JSまたはAS2）

64 ：

>>62
＞まあインタプリタ言語（JS）がコンパイル言語（AS）より速いのは当然だ
いや逆だから

65 ：

オープンな議論で仕様が決まり、ブラウザベンダーが競争で実装を磨き合うcanvasやjavascript
Adobe一社の胸先三寸で仕様からスピードからセキュリティまで決まってしまうFlash

66 ：

>>64
今気づいたｗもちろんその通りだｗ
速いじゃなくて遅いだったな。

67 ：

というか、今時コンパイルしないJavaScriptの実装ってあるのか？
JavaScriptもコンパイル言語だよ

68 ：

>>65
作る側としては結構辛いのよw
やる事多くて。

69 ：

>>68
現状では同じことをCanvasでやると納期が（どう少なく見積もっても）Flashの
3倍以上かかる（案件によっては5倍以上）。
※初期投資がほぼ0円なのは魅力だが、「手の込んだもの」では目茶工期を要する。
開発ツールが充実すれば工期は短縮できるだろうけど、現状ではHTML5はシナや
インドに発注した方が人件費の面でお得。

70 ：

簡単な描画をプログラム的に行なった物をスマホで動かして絶望した
HTML5だめじゃん

71 ：

>>70
環境プリーズ

72 ：

>>69
適材適所だろ

73 ：

>>67
コンパイル済みのバイナリを読むかテキストを読むかの違いだろ
JITコンパイルとAOTコンパイルじゃ全然ちがう
お前の言だとPerlもRubyもPythonもコンパイル言語になるぞ

74 ：

HTML5終了　Flashより圧倒的に遅いことが判明
http://macsuki.blog133.fc2.com/blog-entry-1810.html
まぁ、HTML5なんてこんなもんだろ。

75 ：

ブラウザ自体html5とゆうかCanvasが速くなるように開発されてないだけじゃないの？
実装してるだけで

76 ：

videoもaudioもcanvasも使わないサイトだってあるだろうになんで"HTML5"なんだよｗ

77 ：

htmlをデータとするには、html5はいいと思う。
div id="hoge"ばっかだったソースが、headerやfooterやnavやsectionとかでロボットも人間も見やすくなる。
対応していない古いブラウザで同じに見えるようにするのは手間だけど・・・

78 ：

>>75
それなら益々ブラウザ間の差異が出てくるな。
ユーザーは馴染んだブラウザを捨てて「Canvasが速い」ものを探さないといけなくなる。
IE8は嫌だ。

79 ：

IE8、そもそもCanvasには対応してないからｗ
IE9のcanavsは、ハード支援の効果で最速だけど

80 ：

HTML5より遥かに貧弱なHTML4が大繁栄してるのに、HTML5が終わる訳無いだろ

81 ：

Windows XPが消えてくれないと、本格的にhtml5に移行する気になれない

82 ：

なんか頭悪いのがきたぞ

83 ：

HTML5は、終わるというよりも、始まらない気がしてきた

84 ：

んな訳ねーだろ
お前、canvasとvideoしか知らないんじゃないの？

85 ：

xhtmlよりrubyサポートがショボくなるんだよね

86 ：

AppleがHTML5に注力する理由：
Flashだとプラグインを外せば広告は見れなくなるが、HTML5ではブラウザ
に直接描画するので見ないといけない。
※見たくない広告でも最後まで再生しなければ次に行けない。

87 ：

現に今、全ての広告がFlashだって訳じゃないし、それでもブロック出来てるだろ？

88 ：

広告を見ないためにプラグインを外す…その発想はなかった

89 ：

>>86みたいな仕組みはFlashでも可能なわけだが
広告を見ないと次が再生されない
そもそもプラグインを外せば見たいものも見れないわけで本末転倒では

90 ：

キャプション付き画像のマークアップが普通に可能になったのが嬉しい。
ただfigure要素などに未対応のUAにはbody直下のインライン要素として扱われる場合もあるな
後方互換性を考慮するとスタイルの適用は結局divだったり、二度手間な感じ

91 ：

/* CSS・スタイルシート質問スレ 上級者用【71th】
http://hibari.2ch.net/test/read.cgi/hp/1205680031/854-
このへんでも関連する話題が出ているが
bodyに見出しが必要、ていうhtml5の仕様にはムズムズさせられる。
article以下にのみ見出しを置いていくということができない（できるけどよろしくない）。
仕様とhtml5doctor読んだけどまだarticleの位置付けがいまいちよくわからん。

92 ：

これってHTML5のvideoの比較対象になる？
Molehill を搭載した Flash Player Incubator プレビュー版が公開
ttp://clockmaker.jp/blog/2011/02/incubator/
次の世代のFlash Playerは凄いことに！GPUにより数十万ポリゴンが60FPSで動く
ttp://clockmaker.jp/blog/2010/10/molehill/

93 ：

Firefox4のバーチャルパークってどうなってんのあれ？
とりあえずCSS Transform使ってるのかなと思ったけど
どうでもいいけど吐き気がしたわ

94 ：

Webビデオの63%がHTML5対応になった
http://jp.techcrunch.com/archives/20110301mefeedia-63-percent-video-html5/

95 ：

articleは、題と文からなるくくりだ。
題がないときは使わない。

96 ：

企業レベルでは対応できても
個人レベルじゃ2種類以上も用意してられないし（共有レンタルのサーバリソース的にも手間的にも）
まぁ普通は個人サイトでも外部リソース借りてYouTubeなんかにアップロードするのが主流だが
全部自分で管理したい個人サイトではFLVがまだまだ当分現役

97 ：

いや、個人サイトはHTML5だろ
動画ファイル置いて単純なタグ入れるだけなんだから
修正・差し替えもすぐできるし、簡単なJavaScriptで制御できるから自分で管理できる部分がずっと多い
すべてお任せ式のFLVプレイヤーに頼らざるを得ないFLVだと、どうしても制約が多いからね

98 ：

>>95
見出しが要求されるのはsectionも同じだが、articleは入れ子になっている場合を除き
親との意味的連続的が切れた独立した記事というマークアップになる。
一つの文書（ファイル）内に新着ニュースの要約を並べるような場合に使うものだろう。
単一内容のHTML文書で従来の<div class="main"></div>などを置き換えるようなものではない。
HTML5doctorでも「メインの部分をマークアップする要素がなぜ無いのか不思議だが、
headerでもnavでもasideでもfooterでもない部分がそれにあたる」
という趣旨の記述がある。要は素の状態のbodyのことだわな。

99 ：

>>98
でもそのページのメインコンテンツが1つの独立した記事ならば、article要素としてマークアップできますよね？

100read 1read

1read 100read

TOP カテ一覧 スレ一覧 削除依頼 ▲
・　次のスレ
【Overture】PPC広告7【AdWords】
[Google・Yahoo!等]■ロボット型検索エンジン44■
【SEO】Google対策 パート10【Google】
趣味でアンケートサイトを作ってみました。