HTML5

訪れるのは輝ける未来か、はたまたHTML3.2の悪夢再来か。
次世代HTML規格HTML5について語りましょう。

W3C - HTML 5 differences from HTML 4 日本語訳
ttp://www.html5.jp/trans/w3c_differences.html

2 Gets！

で、何で今更 HTML なの？
XHTML でいいじゃない

XHTML2.0の策定にモタモタ何年もかけすぎなんだよ

objectがあるのにembed復活、mediaにaudio、svgがあるのにcanvas...

一方IEは対応する気なし

IEが君臨する限りHTML4.01は王座に居座る

結局今までdivで区分けしてたのに要素用意しましたよってことだろ

進化じゃなくて変更しただけ
開発者の自己満足、付き合う義理は無い

HTML5ｲﾗﾈ
とっととxhtml2勧告してくれよ

何十年かかっても勧告されそうもない空論よりは現実的かと

IEが対応しない時点で大同小異。
どちらも空論。

その点ではXHTML1.1のほうが3cmくらい有利かもしれない

>>11
まだIEが対応しないと決まったわけでもないでしょ。しない可能性は高そうだが。

いつになることやら
てかなくても特に困らないしなｗ

xHTML2はどのブラウザも対応表明してないのにこっちは我先にって感じだな
あそこ以外は

ていうかHTML5はOperaやSafariの独自実装を標準規格にまとめようとしたやつだからな。

とりあえず表示だけは全部揃えてくれたら何に準拠しようが気にしないぜ

tes

<br>タグと<p>タグの違いってなに？どう違うの？

全く違うぜ坊や
ここは質問スレじゃないが今おっさん気分がいいから教えちゃう♪
<p>タグってのは文章の段落ごとに使うタグで
<br>タグってのは無理やり改行させるために使うんだ
でも正しい使い方をしてれば<br>タグはほとんど使う必要はないんだ
だから二つの区別がつかないお前さんは正しい使い方をしてるか全くの無知かのどっちかだ
あとはググレば基礎を解説してるとこあるからそこ見やがれってんだい
ここのテンプレでも見とけばパーペキっすよ
http://pc11.2ch.net/test/read.cgi/hp/1188989641/

>>19
Webサイト制作初心者用質問スレ Part 187
http://pc11.2ch.net/test/read.cgi/hp/1188989641/


つか、スレタイを素朴に見るとHTMLの５スレ目みたいに見える

>>19
Word で言うなら
<p> = return
<br> = Shift + return

ってとこじゃね？

HTML5はかなりストリクトな仕様になっているが、ウェブページをつくって
る大半の人は>>19みたいなレベルで、HTML5の意図をくみ取れないんじゃない
か、って気がする。

そもそもタグなんて知らないやつが多いんじゃないか？

みんなが標準標準言い出したのは、
XMLならソフトでも処理しやすいから、XHTMLに移っただけで、
タグ付けに意味を求めたわけじゃないだろう。
HTMLに戻られても・・・

hxタグを使うとその下の行と行間が開いてしまうのですがこれを詰める方法はないでしょうか？

事故解決しました

>>26
>ID:KV6aCqyZ

氏ねよクズ

HTML5ってStrictか？
適当な理由を無理矢理こじつけて文章構造とデザインの分離を騙った、
Webで金を稼いでいる連中にとって都合のいい、商売臭に満ちたHTMLにしか見えんのだが。

head, body といつものように記述した後ろに
foot (or leg? or tail? or hip?) 要素で
後注エリアを確保できるようになりますか？

どこか物好きな開発チームからHTML5を実装したブラウザ
出してくんないだろうか。

WebKitがそろそろやるんじゃね？

>>30
そのぐらい自分で調べろ
footer 要素は提案されているが、2022年以降とかだから、
今後どうなるかは不明

HTML5って本当に2022年までかかるの？　平成22年じゃなくて？

HTML５ｵﾜﾀな

HTML 5 ってルビ使えるの？

使えないと思うよ。

ルビ使えないんじゃHTML5にする価値ないね。

使えないというか、CSS3 Ruby Moduleが実装されればspan要素とclass属性の
組み合わせでルビ表示はできるはず。

ブラウザの独自実装の寄せ集めの癖に規格策定まで15年かかるなんて阿呆か。
単なる様子見のための観測気球なんじゃないのか？

>>33の「2022年以降」ってソースどこ？

先進性のアピールのためにXHTMLを使うんですか?
99パーセントのWebサイトはHTML 4.01 Trantionalで十分ですが。
古いブラウザに対応させるのに、いったい何年かかるの????
W3Cは解散して

>古いブラウザに対応させるのに、いったい何年かかるの????
いみふ

> 先進性のアピールのためにXHTMLを使うんですか?

あなたの想像する ｢先進性のアピール｣ とは､ いったい誰に対するアピールなのですか｡

すみません。たとえばの話で恐縮なんですが、HTMLのタグの属性値内（ダブルクォーテーションで囲まれた値内）で
ダブルクォーテーションを使いたくなったりしたときどうすればいいんですか？必要に迫られているわけでなく
興味本位での質問です。

たとえば、<input type="text" name="-"-">とname属性の値を-"-としたいときどうするんでしょう？

おしえてくださいm(_ _)m

HTML1.0
↓
HTML2.0
↓
HTML3.0
↓
HTML4.0　→　XHTML1.0
↓　　　　　　　↓
HTML5.0　　　 XHTML1.1

ネタスレになったのか。

>>45
仕様書読めよ

ダブルクオーテーションを属性値に入れたいなら
括りをシングルクオーテーション「'」にするか
属性値の「"」を「&quot;」か「&#34;」にすればいいんじゃないの。

ハトムルファイブ

videoとかaudioとか意味わかんね
何のためのobject？
HTML5.1ではflash要素を入れるとか言ってくるだろうな

>>50
特許が正式に認められたobject方式をオープンな標準仕様に含めるわけにはいかなくなったから。

MSがobjectを採用してるというだけで、陪審たちもMSが悪いに違いないと思い込んで、
特許無効の予測を裏切り、特許成立の判決。w3cとかいう陪審たちが聞いたことのない組織も特許無効を
証言したけど、MSの味方は陪審の敵＝国家国民の敵なので聞く耳を持たれなかった。

というわけでobjectの類似機能は、特許の有効期限が切れるまでHTMLには二度と含まれない。

xHTMLでアンカーのtargetが消えたのは痛かった。

<a href="hoge.html" onClick="window.open( this.href , '_blank' ) ; return false ;">

WD出たね。
http://www.w3.org/TR/2008/WD-html5-20080122/

>>52
XHTML 1.1 SEやXHTML Basic 1.1で復活するっぽい。

今 XHTML 1.1 でサイト運営しているんだけど、HTML 5 が勧告になったら使ってみようかな、と思う。

WD 出たのは大きな前進だな。

WDならXHTML2だって出てますが。

ついでにこっちも。

HTML 5 differences from HTML 4
http://www.w3.org/TR/2008/WD-html5-diff-20080122/

なになに

XHTML2は学術論文、詩、・・・etc.向けで
現在Web上に存在するサイト、ショッピング、オークション、掲示板、・・・etc.はカバーしていない
ゆえにHTML5は策定される

・・・か。
論文や詩ならDocBookがデファクトだから、XHTML2は産まれる前から要らない子ってことかよ。

DocBookよりTeXのほうが多いっしょ

align や width はいらないけど
semantics な属性まで削りすぎ。

WDの1.4.1. HTML vs XHTMLというところなんだけど、

ちょっとでも間違っていたらXHTMLはうまく解釈されないがHTML5なら
なんとかなるって・・・・

そんなに融通の利かないブラウザあるの？

パーサ通らないだろ

XMLはミスってたら即アウトでしょ

そもそもXMLは人間が書くものじゃない
ちょっとでもミスると即アウトとか，
そんなシビアな作業を人間にやらせて間違わないわけがない

そんな糞エディタつかう人間が書くものじゃないな

ホームページビルダーみたいなエディタ屋に都合のいいHTMLだろ。
そんなに商売に使いたいならHTML Moneyとでも名乗ればいいのに。

これ、文書が(X)HTML5かどうかってどうやって判別するの?
ネームスペースもXHTML1.xと同じだし、DOCTYPEにもバージョン情報無いし、html要素のversion属性もないし。

判別する必要なんてないじゃん、どうせ誰も（ｒｙ

>>50
ブラウザがネイティブにvideoやaudioを再生できるようになるから、
プラグインがいらなくなるんだよ。今のところ、動画再生するなら
ユーザーがFlashプラグインをインストールしてブラウザがそれを
読み込むのが標準的で、AVIを再生となるとまた別個にプラグインが
必要だったりするからね。

>>58
>XHTML2は学術論文、詩、・・・etc.向けで
>現在Web上に存在するサイト、ショッピング、オークション、掲示板、・・・etc.はカバーしていない
>ゆえにHTML5は策定される

「Extensible HyperText Markup Language」の「Extensible」を声に出して100回読め、と
言いたくなるような理屈だな

XHTMLが難しいって…どんだけ頭が悪いんだ

HTMLの方が難しいよな…
>>1にもあるけど、
<em/content/
だなんてなかなか書けないしそもそもSGMLパーサでもないとパースしてくれないし。

XML と HTML の比較で HTML のほうが難しいなんていってるようなやつは XML まともに勉強してないだろ

いや、>>1にそういう比較があるからでしょ

HTMLの(SGMLの)一部の記法が難しいっても
まったく書かなくてもすむんだし
難しいって言いたいから持ち出してきてるような感じがして
いらっとくるな

プログラミング言語なら一文字間違えただけでエラーが常識なのに
HTMLでは何でも通るようにしろってのも無茶な話だ。

まったくだな
HTMLのゆとり仕様が逆に混沌をもたらしてきた

そりゃユーザーエージェントを実装する方にとってみれば地獄だろうけどね
HTML書く方は知ってる機能だけ使えばいいから苦労は無いけど

IE8もデフォルトではweb標準無視の仕様になるらしいな
いったいいつになったら統一されるのやら

すべてのブラウザがIEに合わせれば統一できるよ

IEが他に合わせるほうが早いのに
糞サイトが残ってるから・・・

統一というのは全てのブラウザが一つ残して淘汰されるまでありえないだろ
Amayaがもう少し使い物になる代物だったらみなあれを組み込んで使う
という流れになるかもしれないけどね

>>82
>統一というのは全てのブラウザが一つ残して淘汰されるまでありえないだろ
そんなことしなくても、基本的な部分をちゃんとしてくれたら
それで統一したことになると思うが。
SafariもMozillaもOperaも、おのおの独自拡張をやってるけど
必要最低限な部分はキッチリしてるから不便はしない。

ところでお前らはHTML 5の仕様書一回でも全部読んだのか？

Amayaは本当にひどいよなぁ
日本語もまともに表示できない
もう少しW3Cが本気を出してくれたら

未だに ruby 対応しないブラウザには滅びてほしいな

>>85
W3Cの求める標準準拠というのは所詮そんな程度なんでしょ
実用性は無視

Web標準としてのHTML 5は立ち消えになって欲しいなあ。
勘違いしたWebデザイナどもによって、
シンプルなページとリンクによるWebが滅茶苦茶にされてしまう。
イントラとかで独立したアプリケーションを作るだけなら結構だけども。

Webサイトは顧客を繋ぎとめるために一層ハコモノにされ、
リンクによるWebの接続（蜘蛛の巣）は失われてしまうだろう。
それは検索エンジンからの利益の奪還を意味するかもしれない。
あるいは孤島となって利用者から見放されるかもしれない。

そこでgopherの復活ですよ

>>86
そもそもAmayaはただのリファレンス実装であって
実用性を求めたものではない

>>84
"1. Introduction"は読んだ。今は
"3. Semantics and structure of HTML elements"
を読んでいるところ。何遍も通読しろって書いてあるが、
そりゃ無理だろ。

堅っ苦しい文章でだらだら書かれてるものは読む気がしない

>>90
だからそのリファレンス通りに実装すると実用性が無くなるというのが問題だろ
W3Cの規格自体が実用性無しという事になっちゃうんだから

Amayaがいつ参照実装になったんだよ？W3Cの誰もそんなこと言ってないし、どこにも書いてねー。
ただのデモプログラム。

あんなどうしようもない物がリファレンスだったら終わってるだろ。

HTML5が勧告されたら、Netscape復活して欲しいよな

>>88
剥げ同。
一部の勘違いした業者どもが「あれも欲しいこれも欲しい」と談合しながら
何億人も利用するインターネットの規格を玩具扱いしているのが見てて反吐が出る。

wwwと経済が結びついたのがいけなかったね

まぁ必然だろうけど

経済と結びつかなかったら、専門家とオタクのおもちゃになって終わっていた
だろうよ。普通の個人じゃ業者が貸してくれるサーバを使わないとサイト公開
もできないんだから。

今の様な魑魅魍魎なWWWになるんだったら、
専門家とオタクのおもちゃになっていた方が幸せだったかも...
勝手に入ってきて、勝手に自己正義を主張されてもなあ...

もう a と br だけ互換性があればいいよ

このスレは気持ち悪いくらい愚痴しか書いてないな
すごいな

ブラウザ業者乙。

articleとsectionって，ブログで言うと
記事と記事の中の段落みたいなかんじだと思うんだけど，
段落はp要素な気がしてる．
どこの理解がおかしい？

>>103
sectionは段落じゃなくて汎用的なセクション(章とか節とかを示す)

articleっていつ使うの？記事一覧とか？
sectionでいいと思うんだけど。

>>105
articleは「独立」という意味が強いセクションだから
articleが並列されてるときは
これらはまったく違う話題なんだな
ってことが機械的にわかる

>>106
「独立」させたいならidを使わない？
とりあえず記事別なら記事ナンバーで分けるとか。

>>107
「独立させるにはIDをつける」が正しいとすると
普通のセクション(章とか)なんかには
IDがつけられないことになるから誤った解釈だと思う

ニュースサイトの見出し一つ分の記事=Article　のようなものと考えればいいのでは？
ニュースサイトの記事同士は連続して何かを成しているわけではない。
一つの本の中で「前の節」「次の節」と言えば、本のテーマのもとに関連性があるだろ。
ニュースで「前の記事」「次の記事」と言っても通常記事同士は何の関係もない。
（カテゴライズされて似た記事が寄っているとか、別の記事の続報とか、そういうのはあるだろうけど）

参考までにDocBookで最大限構造化しようとすると
Book
└Part（部）
　　└Chapter（章）
　　　　└Section（節）
　　　　　　└Section・・・
　　　　　　　　　└Para(段落)
だな。
ParaはChapter以下どこに出現してもいい最小単位。
Articleは最上位要素またはBook,Partの下にのみ出現し、Section,Paraを複数含められる。

article要素ってどんな応用の仕方があるかな？nav要素ならナビゲーション
スキップ機能みたいなのが簡単に思い付くが。

もうHTMLとか忘れて全部adobeのバイナリリソースにすりゃいいじゃん

ブログの記事一つが article として妥当な例だよね
単独の HTML になる場合もあれば1つの HTML に複数並べられる場合もあるし
また複数並べられる場合も月単位だったりカテゴリー単位だったりで
単一の樹形図の末端に位置づけられないし

さっき流し読みしたけど酷いな
時代に逆行しすぎだろ

ブログなどに典型的なaside要素やarticle要素を導入したり、昨今の動画ブームを
後押しするvideo要素を取り入れたりして、流行に乗っていると思うけどな。
個人的にはvideo要素に期待。video要素を使えば、Windows Media Playerなどの
プラグインを使わなくても動画を再生できるみたいで、なかなか嬉しい。
でもsource要素だけじゃ動画に使われているコーデックまでは判別できないから、
ブラウザがファイルを1個1個ダウンロードする必要があるような…。
動画のフォーマットはいろいろあるが、標準化されないのかなあ。

動画がプラグインで再生されるかどうかと、動画を埋め込むのにobject要素やembed要素を使うかvideo要素を使うかどうかは別問題じゃね?

画像だと img でも object でもプラグイン指定なんていらないんだから
動画での object にプラグインが必要なのは単なる今の実装のせいだろ
わざわざ video なんて要素入れなくても img で動画も表示できるようにすれば
いいだけでは？
video 要素なんて全くの蛇足だよ

"object"なんていう埋め込みに対する汎用な要素型を
いつまで使い続けるんだよ
段落も何もかもdivでマーク付けするのと変わらんだろ

いっそ標準的な拡張子をそのまま要素名にすればいいよ
gif とか jpeg とか avi とか mpeg とか wav とか mp3 とかの要素名
 

>>118
HTML6ではそうなりそうな悪寒

<wmv href="http://hoge.hage/abc">いやぁ〜ん</wmv>

どう？

何かHTML5ってWindows Vistaと同じ臭いがする。

>>114
その流行にのることが時代に逆行してると言えるってこと
そのままだと省略できる XML になるだけ

ブログのためのHTML5じゃな
ホームページじゃなく、アプリケーションの部類に入るかと。

名前空間をXHTML 2もHTML 5もXHTML 1と同じにするとなると
三様の仕様で意味の違う要素型を区別できなくなるけど
その辺りはどういう風に解決するつもりなんだろうな

xhtml 2は多分完成しないでしょ。
万が一完成してもブラウザベンダに無視されて終わり。

もともとベンダ主導で作っていたhtml 5を、W3Cがワーキンググループごと
丸飲みさせられたあたりからして、もうW3Cに力がないのは明白。

無視も糞も、XMLアプリケーションなんだから
XMLさえパースできりゃ充分なんだが。

その3つだとDOCTYPE違うから問題ないだろ

>>125
それで version 属性が必須になったろ

>>127
それだと混合文書でHTML側がメインじゃないときは
どうしようもなくないか

要素全部にversion属性付けるようにして
言語指定みたいに継承とかする？

>>129
version 属性って、HTML 4 で非推奨になった、HTML 要素のあれだよな？
HTML 5 では復活するのか？

> 要素全部にversion属性付けるようにして
…こいつはひどい

>>130
XHTML M12N 1.1(XHTML 1.1含む)とかXHTML 2にはあるけど
HTML 5にはない

>>131
・version指定は祖先要素から継承できる
・version指定の継承は同じ名前空間のものに限る
というルールにすればいいかなと思ったんだが

XHTML2ってXHTML1.1以前と同じ名前空間になったのか？
数年前のドラフトでは別にするとか言ってたのに。

だからなんで XHTML1.ｘ と XHTML2.0 が混同する文書がでてくんだよ

>>134
http://www.w3.org/MarkUp/2008/ED-xhtml11-20080123/conformance.html#docconf
とかではもう同じ名前空間になってる

>>135
XHTML1.ｘ と XHTML2.0 が混同する文書？よくわからん

自分が思ってるのは、例えばSVGがメインでHTMLがサブの文書のときに
HTMLの名前空間がXHTML 2もHTML 5もXHTML 1も全部同じだったら
要素の意味(例えばstrongだったらXHTML 1準拠で「強い強調」なのかHTML 5準拠で「重要性」なのか)
を判別できなくなるんじゃないかってこと

HTML の名前空間（笑）

HTML 5 (笑)

>>137
そういう細かい点を除けば、XHTML 1.XとXHTML 2.0とXHTML 5で要素の意味が
大きく異なることはないんだから、そんなに問題ないんでは？
p要素が仕様によって段落(paragraph)だったり詩(poem)だったりしたら大変だが、
そうでもないのだから同じ名前空間でいいと思う。

HTML5って何だよw最近流行ってるのか？
HTMLは4.01で打ち止めになってXHTMLに移行したのを知らないのかよ？

久しぶりにWeb制作板覗いたが、レベルの低下が著しすぎてもう俺には付いていけねーよ。

バーナーズ=リーがReinventing HTMLという記事を書いて、今はW3Cが
HTML作業部会で新しいHTMLを策定しようとしているのを知らないのか。

>>141
浦島乙(笑)

おい、HTML5じゃなくてVendor1.0だろ

HTML5ってベンダーの野郎が勝手に考えてるのか。
犯罪者が刑法を作ってるようなもんか。

>>140
同じ名前空間でもいいんだけど
その上でもはっきりと判別できるルールがあれば、と思う
メインはHTML 5の文書だけど
dlだけXHTML 2のdl(di, dt, dd)を使いたい、とか

例えだけど
IE専用表記＝HTML
その他のブラウザでの表記＝XHTML

という感じで完全に分けてやってくれんかな
2度手間になるけどいつまでもIE独自仕様のおかげで同じソース書いても
表示が明らかにおかしいとかやられるほうが正直うざったい

誰かがXHTMLだからこそって言う画期的なものを作らないとHTML5への流れは変わらないんじゃないかな

>>146
今のところ区別する方法がないから、dd-diやdialogを同じ名前空間で
混ぜて使えるんだよね。

間違えた。dl-diね。
XHTML 2にnl要素があってHTML 5にnav要素があるから
<nav>
<nl><label>Contents</label><li>menu1</li><li>menu2</li></nl>
</nav>
みたいなのも書けてしまうわけで、名前空間の統一ってややこしいなあ。

なんか XML の基礎がわかってない人間が HTML5 にくいついてるだけってのが露骨にわかるスレだな

HTML5は断じて認める気にはなれん。
ブラウザメーカーの既得権益を保護し、寡占市場を作るための方便に過ぎんだろ。
ありとあらゆる不要な要素を定義し、しかもモジュール化を拒否する結果としてもたらされるのは、
既存の技術を持ったメーカー以外新規参入できない、巨大な参入障壁を持った寡占市場だけ。

連中はモジュール化に対して「Webの分断」などという意味不明な噴飯物の台詞を吐いているが、
実際にはモジュール化によってブラウザのサポートを限定することが可能になると、
自社より特定分野で優れた技術を持つ中小メーカーが参入してきてしまうという恐れと、
自らの利益を確保したいという自己保身にしか見えん。
湯水のごとく要素を定義することで、全ての要素をサポートできる既存メーカーだけの
独占市場を作りたがっているだけだ。

はっきり言わせて貰えば、HTML5はインターネットを食い物にしたブラウザメーカーの巨大カルテルに過ぎない。

そうだね
HTML5なんて作らないで各メーカーが勝手にタグ追加すればいいよ
モジュール化しようがしまいが知らないタグ/モジュール解析できない事には変わりないんだし

>>152
モジュール化以前の問題だと思う
基本部分でさえ既存のSGML/XML構文とか属性型とかをほとんど使わずに
独自構文定義してるのに明らかに種類の違うものが大量に入りすぎだ
最低でも7つ程度にはわけられる

各社が独自のタグをガンガン追加してそれに対応するDTDを自社のドメインにでも用意するならそれでいいよ

>>155
ベンダが要素型を定義することと
今のHTML 5をいくつかの仕様にわけることと何の関係があるんだ？

開発者向けSafari 3.1を試す - HTML5を先取り
http://journal.mycom.co.jp/column/osx/262/index.html

ページが見つかりません

見れるようになってるな。
サイト側の問題だったか。

Apple.comのように、ヘッダとメニューが一体化したようなデザインになってる場合
headerとnavのどっちを使えばいいの？

HTML5を使わない

>>160
headerの中にnav入れればいいと思うけど

>>160
nav要素の方がいいと思う。なんとなく。

>>162
nav要素はsectioning contentでheader要素にsectioning contentを含めては
いけないとなっているので、それは不可。

HTML5 で新しく増えた要素を div.class で再現するとしたら
どんなクラス名にできる？

どんなって……普通に要素名をクラス名にするとか好きにすればいいんじゃないか
そもそもクラス名に互換性なんて無いんだから作る人間が好きにするしかないし

テーブルタグについて質問です。
簡単なテーブルでスイスの国旗を描いてみたのですが、
縦方向（行方向？）に隙間が空いてしまいます。
これをぴっちり詰めてレンダリングさせる書き方はないものでしょうか？
<table width="400px" height="400px" align="center" border="0">
<tr>
<td bgcolor="#E60012" height="80px" colspan="5" cellpadding="0" cellspacing="0"></td>
</tr>
<tr>
<td bgcolor="#E60012" width="80px" height="80px" colspan="2" cellpadding="0" cellspacing="0"></td>
<td bgcolor="#FFFFFF" width="80px" height="80px" cellpadding="0" cellspacing="0"></td>
<td bgcolor="#E60012" width="80px" height="80px" colspan="2" cellpadding="0" cellspacing="0"></td>
</tr>
<tr>
<td bgcolor="#E60012" width="80px" height="80px" cellpadding="0" cellspacing="0"></td>
<td bgcolor="#FFFFFF" width="80px" height="80px" cellpadding="0" cellspacing="0"></td>
<td bgcolor="#FFFFFF" width="80px" height="80px" cellpadding="0" cellspacing="0"></td>
<td bgcolor="#FFFFFF" width="80px" height="80px" cellpadding="0" cellspacing="0"></td>
<td bgcolor="#E60012" width="80px" height="80px" cellpadding="0" cellspacing="0"></td>
</tr>
<tr>
<td bgcolor="#E60012" width="80px" height="80px" colspan="2" cellpadding="0" cellspacing="0"></td>
<td bgcolor="#FFFFFF" width="80px" height="80px" cellpadding="0" cellspacing="0"></td>
<td bgcolor="#E60012" width="80px" height="80px" colspan="2" cellpadding="0" cellspacing="0"></td>
</tr>
<tr>
<td bgcolor="#E60012" width="20%" height="80px" colspan="5" cellpadding="0" cellspacing="0"></td>
</tr>
</table>

スレ違いであれば適切なスレへの誘導でもいいのでよろしくお願いいたします。
## 白十字の縦横比および余白ならぬ余赤の比率が違う！という点はご容赦下さい。

スレチ杉

>>167
あがとうございます。
スレ違いのようですね　スレを立てましたので責任を持ってご回答至急お願いします

テーブルで国旗を作る方法
http://pc11.2ch.net/test/read.cgi/hp/1202993920/

だからって単発スレ立てんなボケ

俺じゃないし >>168
他人乙 >>168

>>170
単発スレ立てるな　死ね

だから俺じゃないし >>170

>>169
うるさいボケ

ほとんどのユーザにその意義を理解されず、また使用されないという理由でimgのalt属性は省略可能になったのか。
（HTML4では alt="" としろ、となっていたのが HTML5 では記述自体が不要)

現実を直視しているな。XHTMLは現実を顧みない机上の空論だったが、HTML5には期待できる。

>>174
もともと「alt=""にしろ」、というのはaltがないと画像のURLを読み出す
馬鹿スクリーンリーダーの対策でもあったらしいので、
むしろ現実を直視した仕様でもあった。

後にさらに馬鹿度が増してalt=""でもURLを読み出すようになったので
流石に誰にも相手にされなくなった。
altが必須じゃなくなったのはそれを反映した仕様なんだろうね。

>>172
ふざけんなキチガイ

フッ。
このスレも……堕ちたものだな。

>>176
だから俺じゃないって言ってるだろ
日本語読解力ありまスカー？
だいたいお前らtableタグの使い方すら教えられないのにHTMl語れるのかよ？
どうせ低学歴の集まりだろここは？？？　っていうよりもう怒ったよ俺　悪いけどさぁ

まあ
もう俺は二度とこんな糞スレにはレスしないけどな
脳が腐ったヤツと一緒にいたくねーし

まッなんだ
テーブル使ってる段階で池沼度100％なことに気がつけよ

風になびかないフラッグなんて旗じゃないだろw
俺はFlashで風になびくフラッグがつくれる
風速5の場合、20の場合、、、いろいろとなw

>>180
ここはHTMLのスレだ　フラッシュはスレ違いなんだがな

なにか勘違いしてるみたいだけど、
ここは「HTML」スレPart5ではなくて、「HTML version5」のスレですけど？

>>166

HTML5の草案が出ましたね〜、みたいな内容で、
HTML5の新要素について語っているブログがいくつかあって、
（body 要素内の直下にある要素を並べてます）

header 要素
section 要素
　article 要素
　　h2 や p など…
　nav 要素
　　ナビゲーション
footer 要素

という構成を例にして紹介しているサイトや、

header 要素
article 要素
　section 要素
aside 要素
footer 要素

という構成で紹介しているサイトがあります。

2つの例で、section 要素と article 要素の
ネストが逆に紹介されていますが、
この2つの要素の意味を考えた時、どちらが
合っているのでしょうか？

>>184
文書によるからどちらが合っている間違っているというものじゃないと思う
「記事一覧」ならsectionが親で複数のarticleが子になるだろうし
「ひとつの記事に複数のセクション」なら逆だろうし

セクションってどういう意味なんだ？？

>>186
典型的には章とか節とかの文章のひとまとまり

今まで <div id="dai1shou">〜</div> でやってたみたいなもんか？

sectionが章ならarticleも章じゃね？
ていうかarticleのほうがずっと大きい括りのような気もするけど。

section要素もarticle要素もセクションを明示するsectioning contentに
分類される。article要素は独立可能なセクション、section要素はもっと
一般的なセクション。

mの名前をmarkに変えたんだな
markってメタだな。何であんなのがいるんだ

altがない場合、
スクリーンリーダーはどうやって読むの？

>>192
HTML5の策定者にとっては「メクラなんかが我らが誇るインターネットに手を出すなどおこがましい」とでも思ってんじゃね？

ちょっと上のレスも読めないの？

「10数え終わるまでにゲロすれば命は助けてやらぁ、
　10・・・　ヒャア！がまんできねぇ！0だ！」
だったと思う

仕様を議論しているML
ttp://www.whatwg.org/mailing-list

直接提案を持ち込むも良し、不満点を伝えるも良し。

放って置けばいいよ。自然と消えてなくなる。

haha

前からずっと疑問に思っていて、誰も答えてくれなかったんだけど、
誰か教えてくれ。
ユーザが自由に文字色を変えられる掲示板やチャットを、
HTML5で作るには、どうすればいいんだ。

font要素は使えない。
style属性も使えない。
#000000;から#FFFFFF;までを指定した、2の24乗通りのクラスセレクタを作るの？
CSS3だと、rgbaで通過色も指定できるから、通過色も指定したかったら、2の32乗通り作るの？
あるいは、必要に応じて、必要な色だけ、style要素で流し込むの？
そもそも、ユーザが自由に文字色を変えられる掲示板など、作るべきではないの？

どうしても全色指定したいならクラスとそれに対応するCSSをを動的に作ればいいんじゃないか．
10色くらいから選ぶだけでも十分なら静的に．
文字色を変更できるようにするかどうかは自分の好きな方でいいんじゃないか．

てかスレ違いじゃね？「HTML5で」とか書いてるけどHTML5全然関係なくね？

>>199
色しか意味がないんだったらそうだろうね。
あとぱっと思いつくのでは

・scopedつけたstyle要素を1レス1レスに入れて色指定
・WYSIWYGエディタと言い張ってfontを使う
・クラス名を解析できる色のみ(class="#fff"とか)にして
　CSS3 Colorのcolor: attr(class, color)を使う
・自分で色属性定義(my:color="#fff"とか)して
　CSS3 Colorのcolor: attr(属性名, color)を使う
・スクリプトを使う

なんかがあるけど、あらゆる色+透過色まで指定できるような掲示板は
アクセシビリティも何もあったもんじゃないよね

うーん、やっぱりstyle属性は、たしかに邪悪だけど、残しておいてほしいのですが。
掲示板じゃなくても、例えばブログとかはどうするんだろう。
ブログなら、ユーザがあらゆる色を選択できてもおかしくないですよね？
HTMLもCSSにも詳しくないブログユーザーに、
簡単にどんな色でも自由に使わせるためにはどうすればいいんだろう。
あるいは自分が、HTML5なブログサービスを使っていたとして、
自由に任意の色を使う際にはどうすればいいんだろう。

あるいは本当に、そんなあらゆる色を指定できるなんて機能は作るべきではないのだろうか。
ブログなんかでも、ユーザにあらかじめ使う色を数十色ぐらい決めさせておいて、
それ以外使わせないべきなんだろうか。

でも、そんなことしたら、HTML5なんて誰も使わないと思うんだけどなぁ。
HTML5の中の使いやすそうな機能だけ使って、font要素をいつまでも使い続けるとか。

>>200
じゃあ、HTML5の規格上で、ひとつのHTMLファイルで、すべての色を使いたい場合とか。

>>201
せっかくレス帰してくれたので、感想を

＞・scopedつけたstyle要素を1レス1レスに入れて色指定
みんな、それほど律儀に面倒なことをしたがるとは思えない。
結局、font要素やstyle属性が、廃れることなく、広く使われることになる。
そのほうが圧倒的に楽に記述できるから。
主要なブラウザで、問題なく動くからと言い訳しながら。

＞・WYSIWYGエディタと言い張ってfontを使う
それがまかり通るなら、みんなWYSIWYGエディタと自称して、
あのmetaタグをおまじないとして使うようになる。
そもそもmetaタグを使わずに、font要素を使う奴が必ず現れる。
結果は上に同じ

＞・クラス名を解析できる色のみ(class="#fff"とか)にして
＞　CSS3 Colorのcolor: attr(class, color)を使う
＞・自分で色属性定義(my:color="#fff"とか)して
＞　CSS3 Colorのcolor: attr(属性名, color)を使う
すばらしい。が皆そんな面倒なことはしたくないので、font要素やstyle要素を使い続けるはず。

＞・スクリプトを使う
任意の色を指定するのにそこまでしないといけないの？


HTML5が、自分自身で運命を言及するようなことにならなければいいけれど。
ttp://www.whatwg.org/specs/web-apps/current-work/#relationship0
Webによく使われる意味を表す要素がない。

>>202
一般人はstyle属性すら使わないから杞憂じゃないかな
CGI等のWebサービスで生成されるものなら
GUIDとしてID属性作ってそこに必要なスタイルをCSSに組み込めばいいだけの話だし
手書きでHTML記述していた頃の常識に囚われちゃってる気がするよ

>>200
>てかスレ違いじゃね？「HTML5で」とか書いてるけどHTML5全然関係なくね？
style属性まで禁止になったのはHTML5が初だろ

理屈としては分かるが不便になるなあ

なんか……簡単なDTDをでっち上げて自己流のXHTMLを使ったほうが便利そう。

いままではこれでよかった。


ほげほげ<span style="voice-family : '堀江由衣' ; ">あうあう</span>ほげほげ


これからはこうしなければならない？


<!-- flow contentが許されるところ -->
<style scoped="scoped"> <!-- HTML5では、typeはデフォルトでtext/cssなので省略可能 -->
.horie-yui
{ voice-family : '堀江由衣' }
</style>
ほげほげ<span class="horie-yui">あうあう</span>ほげほげ

ttp://www.whatwg.org/specs/web-apps/current-work/#the-div
>divをclass=""と共に、悪用してるアホがいるけど、
>それってアクセシビリティの観点から考えると最悪だよね。
>そういうのはやめさせたいけど、でもdivを使って仕様を拡張することの妨げにはならない、
>なんというか、なんかこう、ソレ的な機能が欲しいよね。

じゃどうしろと仰いますか？
その悪用と拡張は、紙一重だと思うんだけれど。

>>209
うあ・・・俺様の考えを浸透させろというバカが無茶なこといいだしてるのか英文で・・・。

>>207

XHTML2にHTML5の追加要素を足すモジュールを作ればいいんじやないけ。

HTML5文書ではないがHTML5対応ブラウザは勝手にそれらしくレンダリングしてくれそう。

いっそのこと、DOCTYPE宣言なしのXHTML文書にして、普段はXHTML 1.1の
マークアップを行いながら、部分的にHTML 5のvideo要素を使ってみたり、
XHTML 2のセマンティックな属性を使うのってありかな？

宣言なしの時点で駄目に決まってるだろ

DTDを試験的に作っているyhtmlの出番ですかね（´・ω・｀）

>>213
XHTML 5は基本的にDOCTYPE宣言なしだし、XHTML 2でも省略可能なんですが。

宣言なんてあろうがなかろうが、
規格外の使い方する時点でダメだろ、規格的には

XHTML2はDTDならDOCTYPE宣言だし、
XMLSchemaならDOCTYPE宣言なしでルート要素でxsi:noNamespaceSchemaLocation、
RelaxNGなら何も指定しない。

んじゃなかったっけ？省略可能というのとは違う気が。

確認してみたところ、
> The start tag may also contain an xsi:schemaLocation attribute that
>associates this namespace with the XML Schema at the URI
>http://www.w3.org/MarkUp/SCHEMA/xhtml2.xsd.

> There should be a DOCTYPE declaration in the document prior to the
>root element.
http://www.w3.org/TR/xhtml2/conformance.html#strict
とあった。スキーマを明示しないこともできるが、
XHTML 2適合であるためには当然スキーマに従っていないといけないみたい。

空要素をすべて <要素 /> って形式にすりゃ、ただの勝手 XML だな、こりゃ。

わざと混乱させて、DWやホームページビルダーが売れればそれでいい
ってやつ？

だんだんWYSIWYGエディタ売るための規格というか企画に思えてきた……。
こんなの規格じゃねぇ！！！！

すみません質問させて下さい。
今『できる　ホームページHTML入門』という本を買ってきてプログラミングを
０から勉強している者です。

画像を表示する段階でつまずいておりまして、写真の位置が決まりimgタグを
打ち込んでみましたが、表示されるのは×印だけです。本に書いてある通りに
(写真は自分で撮った写真でサイズもHPサイズに加工済み)やってみましたが
どうしてもうまく行きません。

何が原因なのかわからず困っております。
どなたか教えて下さい。

>>222
Webサイト制作初心者用質問スレ Part 194
http://pc11.2ch.net/test/read.cgi/hp/1204015309/

HTMLで検索してここに来たのかな
ここは上級者向けだから上のスレにどうぞ

＞ここは上級者向けだから
そうでしたか、ご迷惑おかけしました。

上級とか下級とか以前にスレ違いだけどな

ttp://blogs.msdn.com/ie/archive/2008/03/05/internet-explorer-8-beta-1-for-developers-now-available.aspx
IE8のベータが公開された。

>We’ve started delivering support for HTML5
>because we understand that developers want to start delivering richer web experiences,
>with great interoperability, as soon as possible.
HTML5の未来は明るい。

IEはruby対応といい、新しいものに飛びつくのだけは素早いからな

必要なものだけ実装してくれたらいいから・・・

HTML5 は簡単だが単純に要素が多いだけなので金になりやすい
未来が明るいのはXML
未来過ぎて明るさが霞んでるのがRDF以降のもろもろ

>>227
飛びついて、でも途中で飽きて放置して、
結局一番迷惑を掛けるんだけどなw

HTML5が出来ればWYSWYGエディタ屋やブラウザメーカーはぼろ儲けだな。
今のうちに株でも買っておくか。

XHTMLのときみたく、「これからはHTML 5がウェブ標準」ってキャンペーンを
展開したりするのかな？

XHTMLのときにそんなキャンペーンってあったっけか？
「HTML5の大船に乗り遅れるな」とかやって来るテクニカルライターは出るだろうけど

キャンペーンって言うか、「ウェブ標準=XHTML+CSS」みたいな語りがあって、
それを宣伝文句にしている業者がたくさんあるのを見ると、HTML 5もそんな
ノリで普及することになるのかなと思った。

もうこれ以上規格変える必要ないだろ
ＩＥだけまともに対応すればいいんだよＩＥだけ

IEは8で標準化するだろ

4.01のままでいいよ
少なくとも現在審議されてる5はｲﾗﾈ

head要素とheader要素は紛らわしいなあ｡
header要素を作るのなら､ head要素はmetablock要素とかに名前を変えた方がいいんじゃないかなあ｡

てかそんな要素いらんｗ
divでいいじゃん、divで何も不自由してないよ
余計なもん作るなと言いたい

俺はdiv乱用でものすごい不利益を被ってるよ
必要ない要素ユーザスタイルで簡単に消せないし

それはそんな不要なもん作ったデザイナーに言え

divで何も不自由してないとかHTMLを何だと思ってるんだ

サイト作るための道具だよ坊や

>>240
万人向けにつくったってどうしても自分には必要ないものが
出てくるんだから自分で対処できるものはそうしたい

要素型を増やさずにいくなら
クラス名やIDの標準をもっとつくる必要があると思う

意味付けしたいけど適切な要素が無いせいで
仕方なくdiv使って構造のみを示すわけだから
そのために要素増やすのは普通のことだろう

>>238が消極的な理由でdivを使ってるのかは知らんけど

もっと意味を表す要素があればいいのにな。
まあ、必要な意味をすべて取り入れていったら、さらにカオスになりそうだが。

新たにHTMLに要素加えるよりは
DocBookとかをブラウザが表示できるようになればいいのに

CSSかませばできるじゃん

互換性を重視すると､ 既存の要素の名前を変えるのはまずいか｡

IE8も次期safariもHTML5対応するみたいね

>>247
docbook:link要素をリンク扱いしてくれないじゃん。

HTML5はそもそもSafariの独自拡張が発端だし。

>>251
そなの！？

http://www.whatwg.org/

>>251
だからどうした

>>254
>>249>>251

hosyu

Safari 3.1が公開。Windows版は高速化や日本語表示に対応
http://bb.watch.impress.co.jp/cda/news/21314.html

>　3.1ではHTML5で規定されている動画および音声タグに加え、
>CSSアニメーションやCSS Web Fontsをサポート。
>アップルによれば、Safari 3.1はHTML5の動画および音声タグをサポートした初めてのブラウザだという。

別にXMLアプリケーションみたいな使い方をするわけではないから、
HTML5というのは廃止予定要素だったTransitionalがなくなって、
HTML4.01Strict+FramesetをベースにしたシンプルなHTML、
いうなればXHTML1.1や2.0のHTML版みたいな感じになるのかと期待していた。

でも出てきたのは安物のWYSWYGエディタが吐き出す醜いソースコードを
後付で正当化するためだけに作られたような糞HTMLだった。

HTML5の追加要素をXHTML2に追加するモジュールを定義するのが一番便利っぽい。

XHTML2も(現状出ている情報では)Webページ記述という本来の目的からすると
逆にやりにくくなるだけの規格だから、要らん(あくまで今のままなら)

HTML5にもいいと思える部分もあるし
両者のいいとこどりで、XHTML.1後継を作ってくれるのがいちばんいいんだが。

XHTML１にHTML5の追加要素がよい。

これってさ
要素増えちゃうから結局互換性考えたらまず５年くらいはまともに使えなくない？
使ったらまた古いブラウザ用に別の作らなくちゃいけなくなるよね？
それじゃＩＥが対応してきた意味なくなるなるし
後５年くらいはｘｈｔｍｌ１のtranditionalで安定って認識でよろしいでしょうか？

なくなるなるしー♪

>>261
XHTML2みたく後方互換を無視した規格とは違うから
使える要素からどんどん使われると思う

つまり現状　XHTML1 の Tranditional 使う人なら
HTML5 使うという事になるかと
(Strict に拘る人だとまた違うだろうけど)

でも、XHTML5は5年ぐらい使えなさそうだぜ。
IE6と7が忘れ去られるまでな。
IE8もどうなるか分からん。
XHTMLまともにサポートするかねぇ。

さすがにXHTMLは大丈夫でしょ
これ外しちゃうと今あるサイトほとんどやばくなるし
５はＸＭＬと同じような扱いになるんじゃないかな
誰も使うことを望んでないしメリットがない

このスレ見てるとHTML4.01 Trantionalだけで十分だってよくわかるな。

HTML4.01 Trantionalですら、準拠していないサイトが多いけれどもなw

４．０１でほぼ完成しちゃったよね
もうあんまり余計なものをつけないで欲しい

HTML4.01 真 Strict とかあればいいのに

なんか真サルーインみたいだな

XSLが使えない規格になっちゃうと後々困るって

HTML 5 を XML として使えるとすると XSL で XHTML にして使うサイトが増えるかも？
いや、むしろそれが主流みたいになったりして。

……って HTML 5 も XML で定義しなおした、ある意味 XHTML になっちまうのかよ。

さっさとＸＨＴＭＬ２出せって話ですよ
今頃５とか出すなよ馬鹿たれ

まったくだ

XHTML2なんて出ても普及するわけがない

Windows版のSafari3.1がリリースされた直後に試して、ここにでも書こうとしたが、
そのとき規制くらっててかけなくて、すっかり忘れていたんだけど。

Safariって糞じゃね？
video要素をサポートしているから試そうとしたんだけど、
どうもQuickTimeを使っているらしい。

QuickTimeのデコーダは最悪だ。
例えば、H.264のデコーダは貧弱だし、HE-AACはデコードできない。
なにがvideo要素をサポートした最初のブラウザだよ。
貧弱すぎて使えないにもほどがある。

Flashは嫌いだけれど、もうしばらく、動画のストリーミング機能として、
Flashの地位は揺るぎないな。残念なことに。

>>276
video要素でぐぐったらまんま似たような内容のブログが出てきて吹いたけど、同じ人かね
>video要素をサポートしているから試そうとしたんだけど、
どこで試してきたのか教えてみ

>>277
うむ、確実に自分だ。

規格読んで自分で書いたから、どこを試したとかそういうことはない。
それで動かないから、Operaの開発者のブログからvideo要素の使用例を眺めたりしたけど、
何も間違っていなくて悩んでいたら、AppleといえばQuickTimeということを思い出した。
QuickTimeを入れる気はなかったから、Appleの強制的に入る自動アップデートソフトのウザさもあいまって、
インストールしてから一時間とたたないうちに、アンインストールした。

リンゴは昔から何も変わってないね。
これからも、一部の信者にしか受けない企業だね。

>>278
必死やなw
ていうかビデオ機能を試したくてSafariを入れるのに、なんでわざわざQuickTime外すの？w

ふむ、Win版のSafariは他社製プラグインの取り扱いにまだ問題があるっぽいな
Win版+QuickTimeプラグインの場合やMac版は問題なく動作した、俺の試した範囲では
先行実装のしょっぱななんだから、まぁこんなもんだろう

そのうちバグも修正されるだろうし、
どうせFirefoxとかも対応するだろうからもうちょっと待ってれば

>>276
未だにCSS2の対応すら完璧でないブラウザだってあるのに、
正式な仕様も決まってない要素で問題起こしただけで糞扱いかよ

>>280
「だってある」ではなくて、
完璧に対応しているブラウザなどいまだ存在しない。

>>280
いや、「問題起こした」ではないんだ。
機能が貧弱すぎるんだ。

>>282
機能が貧弱すぎるだけで糞扱い(ry

>>281
対応度には大きな開きがあるけどね

>>282
そうか？ただのバグじゃねーのこれ
Mac版は問題ないみたいだし

HTML5.JPはなんでカンバスばかり取り上げるんだ？　意味が分からん

HTML 5にはDTDがないみたいだけど、もしかしてXML応用のXHTML 5だと
実体参照って使えない(＆lt;などは除いて)？

DTD の代わりに、XML Schema を使うんじゃね？






……いや、それはないか。

>>286
数値文字参照使うしかないんじゃないかな
まあHTMLでも今までのSGML的には駄目だと思うけど
形式自体実体参照の定義読み込む風になってないし

>>287
XML Schemaって実体参照定義できたっけ

仕様でできないことはブラウザのほうで対応する。
これがHTML5じゃね？
だから、DTMじゃなくてDTP、じゃなくてDTDもXML Schemaもなくて実態宣言は有名無実化。
ブラウザにできないことはしちゃいけないこと、っていう本末転倒のシロモノだろ、これ。

仕様じゃページ見れないからね
規格よりもブラウザの実装が全てですよ

>>288
HTML 5はSGML応用ではないので(http://www.w3.org/TR/html5/#parsing
に書いてある)、仕様書に参照される実体のリストを書いておけばOKだと思う。
XHTML 5はXML応用なので、XMLの仕様書から外れるようなことはできないはず。

>>291
まあそれは知ってるがpgsmlとか
今までHTMLをきちんとSGML応用として扱ってきた実装との
相互運用性はないよね

そもそもスキーマと文書内で使うマクロ定義を一緒にしてたのが悪いと思う

DTDがないなら作れば良いじゃない

HTML5はSGMLアプリケーションじゃないんですよ？

>>294
yhtml と同じ流れになりそうな悪寒

もう面倒くさいから、SGMLっぽいけどSGMLじゃないHTML5みたいに
XHTML5もXMLっぽいけどXMLじゃない何かにしてくれ

XHTML 2.0 も出ていないのに 5 とは気が早いｗｗｗ

NetscapeとかMPEGみたいなもんですよ
2〜4は大人の事情でスキップ

"HTML 5"って言ったときに、XMLアプリケーションのXHTML 5も含めているのか
そうでないのかって、だいぶ違うよね。IEチームはHTML 5のサポートを宣言
しているが、MIMEタイプが"application/xhtml+xml"で提供されるXHTML 5にも
対応するつもりがあるのかどうか。

それは確実に無いな

いや、サポートする気はあるらしいんだが。
ttp://blogs.msdn.com/ie/archive/2005/09/15/467901.aspx

>いまの互換性重視の超寛容なHTMLパーサをもって、XHTML対応を謳ってしまうと、
>後にひどい互換性の問題を引き起こすだろうから、対応しないことに決めた。
>いや、俺はXHTML好きだし成功して欲しいと思ってるよ。


ってな事を言っていたのが3年前だ。IE8ベータも、まだサポートしていない。
本当にサポートする気あるのか疑問だ。

まー、厳格なXHTMLを使えるってのが幻想じゃないかって気はする。
厳格なXHTMLを吐く広告なんてないし、
Validationに通るXHTMLを吐くブログサービスも皆無。
Vistaをサポートしなくても良くなるまで、デフォルトで入っているIE7は無視できないだろうし。
XPもサポートするとなったら、絶望的なことにデフォルトでIE6・・・。
10年以上かかるんじゃないかねぇ。

http://annevankesteren.nl/2008/04/custom-data
もうほんとにDTDとかつくる気ないなw

だってブラウザは互換モードと標準モードを切り替える目的でしかつかってなかったしなぁ。
だからこそIE8は、それならいっそmetaタグでやろうぜってことになったわけだし。

>>302
>まー、厳格なXHTMLを使えるってのが幻想じゃないかって気はする。
そうかもね。
timblも「属性値は引用符で囲むとか、空タグにはスラッシュを付けるとか
言ってみたが、うまくいかないもんだな」って言ってるくらいだからなあ。
仮にIEがapplication/xhtml+xmlに対応したとして、個人サイトならまだしも、
企業サイトはミス一つあるだけでエラーメッセージを出すXHTMLを進んで
使ったりはしないだろうね。ブラウザのエラー補完に頼る状況はずっと
続きそう。

理想だけが先走ってるよね
昔のコミュニティとしてのインターネットならまだしも
今はほとんどビジネスになってるから
理想と現実があってない

最近はtext/htmlでSVGとかMathML入れるのをやってるのか

仕様では機能いろいろ入れるから
スキーマほしかったら自分で制限したのつくってくれって感じなのかな

HTML5のbr要素は詩や住所などの内容の一部である改行にしか使っては
いけないってなっているけれど、こんなルール守れる人は一部の文法
マニアを除くとあまりいないんじゃない？HTML5にはこういう禁止規定が
たくさんあって、ちゃんと仕様を守ろうとするとすごく面倒そうな予感。

使える物を使いたいとこに使うだけです

>>309
brのそれは最終的に折れて少なくともshouldにはなるんじゃないかね
validatorで検出できるもんでもないし、WDになる前にも制約結構緩和したし

>>309
文法マニアというより、言語ピュアリストとでも言うべきじゃないか。
たぶん思想としては、

昔は色々と貧弱だったから仕方がないけれど、
今は、
物理的に単純な改行を意味する要素よりも、
意味的な要素と、要素を修飾するCSSを活用するのが自然だ。

と。

たとえ DTD があったとしても、br の使い方にまで言及できないからねえ……。

sectionとかarticleとかheaderとかfooterとかnavとかasaideとかの関係がよくわかんなす

たとえばnavは
<section>
<nav>カテゴリ</nav>
<nav>アーカイブ</nav>
<nav>トピックパス</nav>
</section>
こういう包括の仕方なのか
<nav>
<section>カテゴリ</section>
<section>アーカイブ</section>
<section>トピックパス</section>
</nav>
こういう包括の仕方なのか
とかよくわからんです

>>184見て思ったんだけどsectionはかなり汎用的？

<section>
　　<header></header>
　　<nav>
　　　　<section></section>
　　　　<section></section>
　　</nav>
</section>
こういうのもあり？

>>314
sectionは一般的なセクション、articleは独立したページになれるセクション、
navはナビゲーションのセクション、asideは本文内容と関係の薄いセクション
という関係。
headerはセクションのヘッダ、footerはセクションのフッタ。

個人的には、「カテゴリ」「アーカイブ」「トピックパス」が別の
ナビゲーションセクションになっている上の例のほうがいいと思う。
もしくはsectionをasideに変えて、
<aside>
<nav>カテゴリ</nav>
<nav>アーカイブ</nav>
<nav>トピックパス</nav>
</aside>
仕様的にはどれでもいいんじゃないかな。

section -> nav -> sectionという入れ子も、仕様としてはありえるよ。
実際のページがそういう構造ならそのようにすればいいだけでは。

> 個人的には、「カテゴリ」「アーカイブ」「トピックパス」が別の
> ナビゲーションセクションになっている上の例のほうがいいと思う。
そうなのか
ttp://www.ibm.com/developerworks/jp/xml/library/x-html5/
に
ひとつのnavに複数のアイテム（InfoとArchives）が入っている例があったので
各種ナビゲーションアイテムをnavにまとめて放り込むものなんだと思ってた

というかなんでもありなのか
脱divした次はsection依存症になりそう

>脱divした次はsection依存症になりそう

だろうね。あんまりだから意味無いよ。
Webサイトってのはほんとに多種多様な構成がありうるわけで
彼らが想定している範囲外のものもいっぱいあるだろうし
結局無意味なVer.UPになりそうな気がする。

XHTML1でdivとかに指定する各内容用のIDやClassを
RFCみたいに紳士協定的に決めてみんなで統一していけば
それでほんとは済む話だと思う

決めたところでそもそも使い道がないんだから意味がない

マイクロフォーマットが流行りだしてるっぽいから
共通classとかをもっとこう偉い人が決めて
縛られたい

なんてマゾｗ
でも、自サイトのコンテンツを他人に再利用されるとか嫌だしー

XHTML2.0もHTML5もそうだけど、sectionで分けたいってのは
プログラム的に読み取れるようにしたいという意図だけど
それはRFCでclassやIDの共通名を決めればいいはなしで
現行のXHTML1で事足りる。
HTML2もHTML5も無駄に混乱生むだけ。

role

確かに、ID/classの標準を策定してくれれば、ユーザスタイルシートがもっと使いやすくなる。
広告類はdiv class="ad"とか統一してくれれば、 .ad { display:none !important; }とか出来るのに。

>>323
ワロタｗ

W3Cはもうなんか古きよきインターネットの文化を知らないような
規格策定マニアが仕切ってしまって、権力欲にかられがちなんだろう

こんなものはウェルノンポート(Telnetが23番Portとか)と同じで
基準をRFCで示せば済んだ話。

W3CはIETFより上のレイヤを扱っているだけで、規格はどのレイヤにも
あるんじゃないの。

W3Cの連中は規格策定マニア化してしまってるので
何かを取り入れたいと思ったら、すぐ新規格！と発想してしまうのだろう
RFC的に基準の指針を示せばそれで済むような話でも、別ランゲージとしたがる気がする。

W3Cの連中っても幅広いけど

4.01じゃ限界す。
divやliタグで頑張ってます。

4.01で十分だよ

どうせ規格なんて作っても誰も守らないんだから
W3C自身は遠慮なく規格策定マニアになればいい

>>330
それ本気で言っている？

俺もそう思う

>>323
そのためのrole属性でしょ？

>>333
それはいいんだが
疑問なのは、XHTML1＋role属性で済む話なのに
sectionだのなんだのとやりだすことがわからない。

あとroleなんてものを作ってXHTMLのバージョン自体を上げてしまう必要性はあるのか？
RFC的にid＆clase名について基準を示せば、現行のままで広く対応できるのに。

そういう意味で、規格策定マニア化とか言われてしまうのだろう。

>>332
もうちょっと大胆に改行した方が良かったな

>>334
> sectionだのなんだのとやりだすことがわからない。
sectionとか追加するのは文書をさらに構造化させるためでしょ。
見出しレベルが6段階で固定、定義リストで定義と概要を明確にグループ化できないとか
今の(X)HTMLだと不十分な部分はあるわけだし。

どうせsectionになっても濫用するんだから、
divを意味だけ変えて運用するとかで良かったんでは

ＨＴＭＬなんだからもっとざっくりでいいんだよ
作るべきは正しい構造を示す言語じゃなくて誰でも情報発信できる道具にするべき

誰でも情報発信出来るのは良い事だが、
現状誰でも情報受信が出来るとは限らないのを何とかして欲しいね

>>336
構造化？ div等には名前付けることができるわけで
基準さえ示せば構造化はそれでできるはず。
HTML5的ないろんな構造を示すタグも同様で、タグとして実現する必要性がわからない。

見出しレベル6段階はレガシーなHをそのまま見出しにするからおかしくなるわけで
XHTML1.0の時点で、H1とかじゃなく、Hタグにして階層を示すプロパティを用意すればよかった。
これは別にXHTML2やHTML5のようなSectionなどが必ずしも無いと実現できないようなもんではないだろう。
単に古いH１〜H6をそのままの形で見出しとして採用したのが考慮足りず悪かっただけ。

見出し６段階以上いる？
おれ３つも使えばいいとこだわ

見れればすべておｋ

HTML4にはセクションに関する規定がなかったので、XHTML 2やHTML 5で
セクションを明示できるようにしようってことでしょ。セクションは
文書の構造として重要な要素だから、言語仕様に取り入れるべきだと
思う。取り入れるのなら<div class="section">のように属性で
セクションを示すより、<section>のほうがよくない？

HTML4で見出しがh6までしか使えないのは問題ではないよ。セクションを
表す方法がなかったってのが一部の制作者には不満だったわけで。

ただそのセクションを規定すると
セクション以外のモノについてもなんだかんだと専用タグを作って〜みたいになる。際限なくね。
それがHTML5の発想だろう。
それってどうなんだろうと思うわけなのよ。

いっそDocBookでいんじゃね？みたいな？

>>341
一回だけ必要になったことあるなー

>>344
適度に新しいタグが増える事にどんな問題があるのか？
問題あるのはIEだけでしょ、今の所

馬鹿なの？
新しいのが増えたら古いのは全部ダメになるだろ

新しいフォームの部品とかなら分かるが、
実質ただのブロック要素と変わらないセクションが
どうやって古いのを全部ダメにするのか

>>340
divって名前付けられるの？
title属性の事言ってるの？

Hタグって？要素では？

>>350
340 は要素とタグを混同しているなあ。
おそらく「名前」は XHTML 1.1 で廃止された name 属性。
H タグは、あえて「タグ」っていうくらいだから要素とは別物なんだろうな。

何言ってんだこのバカ共は。
<div id="body">と名前を付ければ<body>と等価なことくらい常識として知っとけ。

body 要素と、id 属性の値として body を持つ div 要素の違いがわからないとは。

>>344
その辺は、仕様を決める側の方針によるんじゃないかな。XHTML 2はW3Cが
目指してきたXMLベースの文書構造化言語の集大成的なやつで、今必要
だからといって新しい要素を次々に導入してきたわけではない。HTML 5は
最近のウェブページに共通して表われるサイドバーとかエントリとかを
要素としてマークアップできるよう新要素を取り入れたりしていて、
「その方針では際限がない」って批判は真っ当なものだと思う。
便利そうに見えるのはHTML 5のわけだが。

>>353
ネタだろ

そういやWeb Forms 2.0は予定とかどうなってるんだ？
全然更新されてないみたいだけど

いまだに古いブラウザ使ってるヤツは氏ねってことだな。
同意だけど、次の世代のブラウザがIE7みたいなのだと萎えるなｗ

>>350-351
混同してないよ。
class及びid及び、もちろんnameもroleも含め、識別できる「名前」を定義する手段はあると書いたつもりだが
分かりにくかったか？　もちろんname属性のことを名前と書いてるわけでは全く無い。

タグと要素の意味の違いくらい分かってる。
「Ｈタグ」のタグ記法の話をしてんだからタグでいいんだよ。
記述用に作られた新規タグの話をしてんだからタグでいいところでしょう。

つーか Hタグなんて書くから理解がないと思われる。
H要素のタグと書けばよいものを。

>>358
>記述用に作られた新規タグ

あんまり意図する意味が理解できてないんだけど
それタグじゃなくて要素型って呼ばない？
あと>>340の「プロパティ」っていうのは属性？

属性は「プロパティ」じゃなく「アトリビュート」なのだが、とマジレス。

プロパティを属性という意味で使っていたとすればかろうじて意味が理解できるが
そうじゃなかったとしたら全く意味がわからん

>>358
手段はあるが、結局ブラウザから見たら、divはdivだ。
もし識別用にidやclassやtitleが付与されても、
極端な話、完全にdivとspanで構成されたハチャメチャなページのソース見たとき、
お前はどのdivが何の役目をしているのかぱっと見ただけで分かるのか？

つまり、そういうことだ。divの分類はできたとしても乱用は禁物だろ。


しかしHTML5はいただけない。
いらない追加機能盛りだくさんの店頭販売されているパソコンじゃないか。

そもそもタグを増やす事のどこが悪いのか
必要なら必要なだけ増やせば良い、それが10個でも100個でも

必要だとは思わないからですー

そもそも1つの仕様で全てまかなおうと言うのが間違いなのでは。
10個増やそうが100個増やそうが、あらゆる分野において必要な語彙をカバーできるとは限らないし、
そうやって増やせば増やすほどUAは負担を強いられる。

W3Cがやろうとしていたように、モジュール化、XML化を進めて
UAに見合った実装を求めるのが無難だったと思うな。
そうなればMathMLのようなものも増え、ブラウザも拡張性を重視するようになり
かえって幅広いニーズに答えられたのではないかと。

必要最低限でいいならDTDだけ使えばよく、
もっとほしけりゃXML使えばよくね？　とは俺も思うね。
ただ、XMLは敷居が高い感じ。
教科書見たらいきなり初心者に戻ったぞ……。

個人的にはXHTML1.0で要素増やせれば、まさにソレでよかったんだが。
1.1だとIE捨てることになっちゃうし、拡張子変えないとサーバーが扱ってくれないし。

div、hn、li、pだけでいいよもう

いや、pもいらんな。ぜんぶdivにしよう。spanもあらまほしきところかな。

div a spanだけでほとんどのサイトは作れるか

そうだ、aはいるな。
あとは、画像動画HTMLなどあらゆるものを「描画」するobject要素か。

>>366
HTML 5はさすがに仕様大きすぎだけど
モジュール化進めるっていっても相互運用性とか考えるとなぁ
ことウェブブラウザに関してはどこか1つが何かの仕様サポートしたって
足並み揃えなきゃまったく使えないし…　
モジュール化進めるとすればCSSの各種Profileみたいなガイドラインとか
要素が使えるか使えないかを判別する手法の標準化が必要だろうね

で、またブラウザの対応状況がカオスになって、
クロスブラウザをやろうとする連中がせっせとハックを探す羽目になるのか。
専門の仕事や趣味のヲタクならいいが、また「IEしか対応しません＞＜」みたいなページが増えるのか。

テストに通ったブラウザのみ認可マークの使用が許される！

>専門の仕事や趣味のヲタクならいいが
いやまて、専門の仕事人のだれが良いと思うんだ？

ブラウザのハックだけでご飯三杯いけるようなヲタならまだしも。

>>375
Webデザイナーは更新の仕事がもらえればそれでいいから、
難しくて素人にはとても手が出せないような業務の方がいいだろ？
まあ、最終的にスクリプトで振り分けてブラウザごとに違うページ見せるとか、
そんなことになるかもだが。

機能に対応しないからCSSよりも致命的だが。

>>373
だからモジュール化進めるにしても
対応状況がカオスにならないようにProfile策定するとかが必要
HTML 5はとりあえず要素(Web Forms含む)と
DOMなんかのAPIは仕様分けた方がいいと思うけど

>>367
> 必要最低限でいいならDTDだけ使えばよく、
> もっとほしけりゃXML使えばよくね？　とは俺も思うね。
マジで意味わからん。
DTD使って、そのDTDに従わないと妥当でない文書になるだろ。
その時点で「妥当でない整形式XML」でしかない、と思う。

フォームの部品みたいに新しい機能があるものならともかく
sectionだのnavだのは所詮普通のブロック要素に過ぎないのに、
なんでブラウザの対応がカオスになると思うわけ？

>>379
HTML5に関して言えばcanvasもあるし
>>379が言った通り新しいフォーム部品もあるぞ

>>380
あるのは分かってる
そもそもdivの代替的な要素の話だろこれ

じゃあフォームの部品は関係ないのか

なんでブロック要素だとカオスにならないと思えるわけ？

特別ブラウザが何か対応する必要がないからだろ

その増えた要素にＣＳＳは適用できるの？

出来るよ

新しい要素を認識しないブラウザでだよ？

IE6-7は既に対処法が見つかってる
HTML5が出来上がる頃にはIE8がそこそこ普及してるだろ

結局使うことに意味を見出せないよ
わざわざ手間かけてバグ増やすとか馬鹿らしい

5を使いたくなければ4.01を使えばいいじゃない
ずっとずっと

いや、１．０使う
後５年は確実に

言われなくても5がクソだったら使い続けるよ

>>392
4.01と言わず3.2をお使いくださいませ

このスレは要素型要るか要らんかとかHTML 5 vs XHTMLみたいな話ばっかりしてるが
HTML 5 DOMとかに興味のある奴はあんまりいないのか？

俺のページなんて画像とテキストくらいしかないから、
多機能にしても……ねえ。
そりゃRSS吐き出したり、他のソフトで読めたりしたら便利だし、
ブラウザの新機能も使ってみたいけど、なんか、仕事じゃないからhtml5もxhtmlもいいや。

とりあえず div と span さえ使えればなんでもいいよ

全要素を div と span のどちらかに統一して class と id つけておく。
CSS で display: block と display: inline を使いまくればいい。
div だけでマークアップしたり span だけでマークアップしたら、ソース見た人は唖然とする。

HTML5ではもうsectionだけ追加してくれればいいと思うよ

いちいち<div class="nav">とか<div class="article">とか
見た目が汚くなるから勘弁
<nav>や<article>で何が悪いと言うのか

divとspanだけで作ってみたいなｗ

<div class="h1">ようこそ！</div>
<div class="section" id="top">
<div class="p">
本文本文本文本文…
</div>
<div class="p">
本文本文本文本文…
</div>
</div>
<div class="section" id="contents">
<div class="p">
<span class="red">本文</span>本文本文本文…
</div>
</div>

ソースにこだわってもしょうがないだろ
そんなに同業者に自己顕示したいの？

>>401
あー、idは使うんだ

>>402
そんな発想しかできないのもどうかと思うが

>>403
なんでidまで禁止にするんだよ

>>396 からの流れバロスｗｗｗｗｗｗ

当然<a>も廃止して<span onclick="location.href=...">とかに統一

div万能すぎ

>>398
それ本気で言っている？











俺もそう思う

もうdivしか要らない

Predocでええがな
http://www.netfort.gr.jp/~kiyoka/predoc/index_ja.html

問題はdivとspanじゃソフトが拾い上げられないことだ。
idとclassを紳士規定で足並みを揃えたら、要素が増えたこととほぼ同じなんだけど、
ブラウザ以外のソフトに読み込ませることを考えたら、要素の方が楽だろ。

<head>
title要素を含むページ情報
</head>
<body>
<header>
h1とかナビゲーションとか色々
</header>
<contents>
読み出したい文章
</contents>
<footer>
著者名とか連絡先とか
</footer>
</body>

現状だとbodyの中身とheadの中身を拾い上げられるが、
肝心のcontentだけ拾い上げるのは無理。こればっかりは要素を増やすしかない。

ブラウザの後方互換を考えれば、
紳士規定でdivに名づけられたidとclassを認識するほうが便利だけどね。
要素増やすよりも指定してそっち拾ってもいい気はするし、むしろスマートな気もする。
だけど、肝心のdivが匿名要素だし、匿名要素と考えないとdivを引っこ抜いて考えることもできない。
最悪、ソフトがデーターを引っこ抜こうとしてidとclass被っていたら使えないんだし。

俺は元々一太郎やwordのようなソフトでも、ブラウザでも、テキストエディタでも扱いたい。
文章をソフトによって縦書きとして表示したり、あるいは表として表示したり、エディタでソースとして表示したりね。
色んなソフトで扱えるようにしようと考えたら、新しく定義し直した方がいいでしょ。

>>413
>紳士規定でdivに名づけられたidとclassを認識するほうが便利だけどね。
大して変わらんがな

紳士規定って紳士協定と同じ意味？

読み直したら内容がアレな上に言葉間違えてるわorz
吊ってくるぜ。

HTML5は、「理想的に使われるなら」それほど悪くない仕様だと思う
でもどれくらいの人が、このやたらと多い追加要素を正しく使えるんだ？
今あるaddress要素でさえ、一般の人はまともに使わないのに・・・

>>394
興味はあるけど、それよりも要素型の方が気になる

address要素はアドレスを表記しないから使わないだけだ。
わざわざ筆者名を下部に表示することもないし。

見出し直下にaddressでレポート風

>>417
そういう人種はそもそも規格を正しく使いこなそうとしないから、
タグが増えても使わないだけ。
問題はない…というのは言い過ぎだが、別に今まで通り

そういや５でもdivは残るのかい？

残ってるよ

div だけでマークアップする diver になろうぜ。

spanとaもいるだろ。

CSS
 .span { display: inline }
 .a　　　{ display: inline; text-decoration: underline }

HTML
 <div class="span">SPAN</div>
 <div class="a onclick="location.href='…'">アンカー</div>

これでよくね？

ミス
 <div class="a" onclick="location.href='…'">アンカー</div>

誰か作りな

画像の表示は
<div class="img1"></div>
.img1 { display: inline; width: 100px; height: 100px;
background-image: url(img1.jpg)}
でいけそう。

>>417
HTML 5は名前変えたところで結局Web Applications 1.0だしそこに価値があると思うから
そっちの話がもっと出来たらと思うんだがなぁ
要素型の話っていっても
テンプレート系の要素のことだったりをここで聞いたってほとんど無反応だろうし

>>428
<div class="img1">altに該当する文章</div>

そういやデザイン雑誌に上みたいな状態で背景画像のみを表示させるテクニックがあったな。

>>429
まず自分から話題を提供するんだ
DOMやテンプレート系要素なんて言われても、具体的に何を話したいのかが分からん

テンプレート系要素って何？

なんとなく気になっていたのもあって、>>427 に押されて作ってみた。
HTML5 なので文書型宣言は <!DOCTYPE html> ですよ。

div だけでマークアップした例
http://4mat.jp/experiment/divdiv

多分、HTML5 的には Valid じゃないかな、と思う。

10行目最後の</div>でエラー

>>431
じゃあ話題の一つとして…
テンプレート用にどこでも使える属性の
template属性とref属性がいまいちわからないんだが
あれって何で2つあるんだろう？
template属性だけ、ref属性だけ、じゃ駄目なんだろうか

いやはや、div html面白い

div html はdiv病を超えたネタだな
DTDは属性値ですます

>>433
ﾜﾛﾀ

ｈ２が残ってるのが残念

>>433
そこまでやるならhtmlもheadも全部divにしないと中途半端だよ
HTML 5だと文法的に文書型宣言が<!DOCTYPE html>固定なので駄目だが
HTML 5にこだわらなきゃ<!DOCTYPE div>にするか
HTML 4.01のサブセットとしてなら<!DOCTYPE div PUBLIC "-//W3C//DTD HTML 4.01//EN">にしてさ
あとCSSの適用はLinkヘッダ使えばできるでしょ
それでDTD的(W3CのValidator)にはHTML 4.01にvalidだ

>>440
それやっちゃうとHTMLじゃないだろ。

それはもう、DIVだな。

おまけ
http://4mat.jp/experiment/divdivdiv

無茶しやがって（ＡＡ略

<br />と<br/>と><br>の違い誰か教えてエロイ人

なぜこのスレで

>>443
ユーdivdoc勧告しちゃいなよ！

>>440
文書型宣言をXHTML 1.1(文書型名div)にして
DTDの内部サブセットかでdivにxmlns属性を固定するようにして
CSSは<?xml-stylesheet?>ってのもありだな
思いっきりスレ違いだけど

>>443
これでValidatorが合格判定出すのがすごく笑えるw

しかし、こうしてみると汎用な答えをテストに書いちゃいけない理由が改めて分かるな。

>>435
二時間ぐらいワーキングドラフトと睨み合ってみたが、よく分からなかった
template属性はdatatemplate要素のみを指定できるが
ref属性はどんな要素でも指定できる、という違いはあるようだが

自分も何に使うのかよくわからなかった。ググっても何も出てこないし…。
誰か解説キボン。

ようやく分かった
template属性とref属性は、一つの要素に対してセットで使うものらしい
つまりこういうイメージ

<div template="（テンプレートを示すURI）" ref="（データを示すURI）">
</div>

もしくはrefを省略して

<div template="（テンプレートを示すURI）">
　（ここにデータを書く）
</div>

眠い頭で適当に和訳しつつ理解したので、間違ってたらごめん

「テンプレート」がそもそも何なのか、誰か俺に教えてくれ

>>452
ref属性で指定した要素かtemplate属性が付けられた要素の内容を
template属性で指定したテンプレートのルールに沿って置換ってことか
イメージ掴めてきた、ありがとう

>>453
HTML 5でのテンプレートはdatatemplate、rule、nestで表現される構造で
それによってある構造(データ)を違う構造に変換して置き換えることができる
テンプレートの構造的にはXSLTに近いかなという感じ
(datatemplateがxsl:stylesheet、ruleがxsl:template、nestがxsl:apply-templateみたいな)

>>453
1. 置換ルールを書いたtemplate.xmlを用意します
2. htmlファイルの中で、HTMLタグではなく任意のデータを書きます
3. さっきのtemplate.xmlを呼び出します
4. なんと！　あっという間にデータがHTMLタグに！

すごく大雑把に言うとこういうこと

XML→HTMLをやりやすくしたもんなのか。
俺は一瞬テンプレ屋の元のデーターを示すものなのかと思ったよ。

どういう用途を想定してるんだろうなぁ
使い道がよく分からん

<記事のデーター>
<日付>投稿時間</日付>
<著者>著者名</著者>
</記事のデーター>

例えばこういう名前空間があったとして、
HTMLに書き直すときに使用するんじゃないの？
RDFを書き直したりもできそうだ。

最近入った<ol reversed>いいかも
今まで逆順(降順)リスト表すものがなかったからなぁ

別になくても自分で数字打つし・・・

勤勉家だな

XMLじゃない方のHTML5で空要素に/付けたら怒られるかな？
ちょっと昔の資料見ると/付いてるけど、最近のは付いてないね

>>457
今までは、PHP等を使ってやっていたことを
HTMLの機能だけでできるようになるということだろうな
便利だとは思うけど、互換性を考えるとしばらくは実用にならない気が

>>462
「使えるけど推奨はされない」らしい
ttp://www.html5.jp/trans/whatwg_html5faq.html#trailing-slash

なあに、また五年もすればすぐに実用化されるさ。
問題はIEが乗っからないことだ。
これじゃ主要ブラウザにHTML5を読ませられないからまだまだPHPにはお世話になりそうだよ。

そろそろまた新しい機能が気になって仕方ない。そんな俺は単純に新しい物好き。

HTML 5 オモロー

IE8は一応HTML5対応謳ってるよ。

でも XML としては扱えないんだろ？
何せ application/xhtml+xml が無理なんだから。

IE8はapplication/xhtml+xml対応するかねぇ
IEブログでも、いまだにIE8のapplication/xhtml+xml対応については言及されていないけれど。

あれ、いつの間にかProse contentがFlow contentになってる
今の仕様ってpにulとか入れられないよね？

入らないよ。
object使うとか、insとかdel使うとかそんな無茶でもしない限り。

>>470
やっぱ入れられないかぁ
p > ins/del > ulとかの構造はDTDの欠陥というか限界で出来るようになってる状況だから
HTML 5では普通に禁止じゃないかな

いれること自体おかしくね？
むしろ挿入でリスト入るほうが正しい
てか文書構造なんてどうでもいい

>>472
XHTML 2では入れられるしHTML 5も最初のワーキングドラフト出る少し前くらいまでは
pにリストとかblockquoteとか入れられたんだけどね
あとinsとか経由してpにリスト入れるのはHTML 4.01の仕様で禁止されてるから
正しい正しくないで言えば正しくないよ

そもそもの発端はpが段落って意味を持つって話からだったんじゃなかったっけ？
ところがどっかの誰かがpは最小節を担当するとか言っているから、もうわけがわからない。
俺は段落で使って、br使って区切るけれど、

<p>つまり、</p>
<ul>
<li>hogehoge</li>
<li>hogehogehoge</li>
</ul>
<p>　ということである。</p>

というのはちょっとねえ……。
本当ならpでulリストも内包したいけど、
そうすると、「つまり」と「ということである」がマークアップされないから、
ブロック引用の直下にテキストがぶちまけられるのと、変わらないかなあと感じてしまう。

>>474のマークアップ方法で何が嫌なのか分からない

「つまり、」
「・hogehoge
　・hogehogehoge」
「ということである。」

というひとつの段落としてマーク付けしたいところを、
リストを挟んでふたつの段落に分けてマーク付けしなくてはいけないのが
生理的に嫌。

個人的には
「つまり、次のとおりである。」
「・hogehoge
　・hogehogehoge」
という感じにするけど。

pの中にulが入れられるようになったら､ ulしかない段落でもpの中に入れたりするの?
そうしないと一貫性が保てないと思うけど｡

生理的に嫌とか言ってもねぇ
そもそも、文章の途中にリストが入るっていう
日本語としてあり得ないような文章は嫌じゃないんかい

リストはともかく引用が入る事はよくあると思うんだが

>そもそも、文章の途中にリストが入るっていう
>日本語としてあり得ないような文章は嫌じゃないんかい

と言われてもねぇ

リストにしろ引用にしろ、ブロック要素的なものが
文章をぶった切って入るのは日本語として変じゃないの

<p>リストはともかく引用が入る事はよくあると思うんだが

<q>そもそも、文章の途中にリストが入るっていう
日本語としてあり得ないような文章は嫌じゃないんかい</q>

と言われてもねぇ</p>

>>481
こういう場合はblockquoteを使うべきでは

<p>リストはともかく引用が入る事はよくあると思うんだが</p>

<blockquote>そもそも、文章の途中にリストが入るっていう
日本語としてあり得ないような文章は嫌じゃないんかい</blockquote>

<p>と言われてもねぇ</p>

めんどいから全部divね

class="blockquote"

class="innnyou"

>>480
日本語としては変じゃないだろ。
ただ仕様には沿わなくなるな。
>>476みたく、上下の文において意味の違いは無い。

ああ、代弁が入ってた。
文中に、リスト・引用が入って文章をぶった切られるのがちょっと勘弁して欲しいだけ。
で、結局、マークアップ付けはbrの乱打かdivマークアップのどっちかに別れる。
もしくは、その併用かな？
p要素が嫌われるのはデフォルトデザインに一段空白が出来るだけじゃなくて、
それを使うと文章がぶった切られる結果になる。
section要素が望まれたのは、文中ぶった切りや大量に分割されたp要素を
包括できる要素がdivくらいしかなかったからでしょ。

日本語文章の行頭インデント多用はp要素しかねーし

さらにはこんなマークアップだと訳が分からない

h2
p(一行)

h3
文章ずらずら(p複数)

h2レベルの一行文章(p一つ)

これを普通にマークアップすると

<h2>hoge</h2>
<p>h2レベルの文章</p>
<h3>hogehogehoge</h3>
<p>h3レベルの文章</p>
<p>h3レベルの文章</p>
<p>h2レベルの文章</p>

こんな元の文章がある時点で相当アレだけれど、
h3レベルにdlセットを何らかの理由で使えなくなったらもうめちゃめちゃorz

>>489
文章ぶった切り云々はよく分からんが、
それを何とかしてくれるのがsectionじゃなかったっけ

…と、よく見たら既にsectionの話題なのか、失礼

divセンターって微妙に携帯には反映されなくね？
なんか中途半端に真ん中になるんだが

>>482
今さらだが、そのマークアップ、正しくは こう。


<p>リストはともかく引用が入る事はよくあると思うんだが</p>

<blockquote><p>そもそも、文章の途中にリストが入るっていう
日本語としてあり得ないような文章は嫌じゃないんかい</p></blockquote>

<p>と言われてもねぇ</p>

blockquote にテキストは直接入らない。

だからー、日常会話でありえないマークアップは p 要素じゃないんだって。
リストはリストで、段落外にうまくまとめなさい、ってことだにゃ。

>>493
仕様によるよ
HTML 4.01 StrictとかXHTML 1.0 Strict、XHTML 1.1のblockquoteは直にテキスト入らないけど
HTML 4.01 TransitionalとかXHTML 1.0 Transitional、XHTML 2.0とかHTML 5は入る

>>494
もうちょっと詳しく書いてほしいにゃ

リストはともかく引用が入る事はよくあると思うんだが、
「そもそも、文章の途中にリストが入るっていう
　日本語としてあり得ないような文章は嫌じゃないんかい？」
と言われてもねぇ。

＞そもそも、文章の途中にリストが入るっていう
＞日本語としてあり得ないような文章

何この低学歴丸出し文？
学会なんか殆どどの業界だって文の途中にリスト入れて
プレゼン簡略化するのが常套手段なんだが視野が狭いってのは恐ろしい。

切った文をそれぞれpに入れて間にul置くのも常套手段ですがね

> 切った文をそれぞれpに入れて間にul置くのも常套手段ですがね
それは日本語として常套手段じゃない
日本語にpとかulとかって

不毛な議論だ

順調にストリクトスレの轍を踏んでいる

strictなんて糞くらえです

>>476でひとつの答えが出てるじゃん。

<p>〜はつぎのようになる。</p>

<ul>
 <li>hoge</li>
 <li>hogehoge</li>
</ul>

こういう感じで、段落の外に追いやればいいじゃん。
それとか脚注にリンクを張って、それを参照するようにするとか。

マークアップのために地の文を改変するのは本末転倒
マークアップのほうが大切だと思う人はマークアップ最優先にすればいいけど

現状のマークアップだってある意味限界。頑張りたくても、

・HTMLは一つの流れしかない
・HTMLに用いるタグには内包したくても内包できないものがある

だもんな。
もうどうすりゃいいのかと言ったら、元の文章とそのデザインをマークアップに適合するものを選ぶしかないな。
webで公開する文章や見栄えはwebに適合したものを使いなさい。仕様を作った人はそういいたいのかも。

限界もクソも、現状で可能なマークアップでこなせばいいだけ
それを生理的に嫌とか言っちゃうのが意味不明なだけ

ここでグルーピングdivですよ

好き？ 嫌い？ 好き？ 嫌い？
嫌いじゃないけど……生理的に無理！

「〜〜がムカツク」とか自分の感情を掲示板に書くことに意味があると思っている人です。
（中略）
もうちょっと賢くなるまでは放置してあげてください。

HTMLDocumentの生成なんだけど
DOMImplementationからcreateDocument()してopen()っていうのはわかりづらくないかな
createHTMLDocument()を標準化するか
DOMParserをWeb-API WGで標準化して
text/htmlをパース(返り値はHTMLDocument)できるようにした方がいいような気がする
open()でHTMLDocumentに変換ってどっかの互換仕様なのかな？

>>199
font消えたけどstyle属性どこでも使えるようになったぞー

style属性は元から汎用属性だろ？

>>511
お、ほんとだ。
いつの間に、と思ったら、昨日か。

やれやれ、多少現実的になったな。
style要素はたしかに邪悪だけど、HTMLだけで文字色を変えられないってのは、
さすがに現実として無理があるだろと思っていたもんで。

font要素は消したほうがいい。
WYSIWYGエディタ限定とかいうわけ分からん理由で残しておく必要もないし。

確かに、エディタのためにfontタグが残されるのに
style属性が消えるのは本末転倒気味だしな

まあ style 要素に入っているのは CSS だから HTML だけで文字色を変えられない事には変わりないけどな

font　big small　ってフォント遊びやっている場合に向くんだろうな。
最終的にそういうものはCSSで整形しなさい、なんだけど、
あれって整形するととんでもない手間が掛かるんだよな。

消したほうがいいが、spanだと長大になって仕方がない。

普通のサイトにはいらん

いや、使うんじゃね？
色の変更はチャットと掲示板じゃデフォ装備だろ

というか、2の32乗通りなんて絶対用意しないよ

ユーザーが色を追加できるようにスクリプト書き換えればいいじゃん
登録済みのコードと被ったらエラー吐き出すようにしろ

そもそもチャットや掲示板は普通のサイトじゃないだろ

ブログは？

ブログも普通に書く分にはいらんだろ
必要なのは読む気もしないゴミとアフィサイトくらい

でも、大多数はアフィとゴミだろ

だからspanにstyle属性付けりゃいいだろ

最近仕様の更新頻度低くてつまんないです＞＜
IanもGWかな

canvasにテキスト描画入った

なんで勧告前に実装させるんでしょうか。IEの真似したいんでしょうか。
一度実装したからには、事実上もう変更とか削除はできないわけですよ？

確定前の仕様に基づいてちょっと書いてみた、なんて人が、
その後の仕様変更を追跡し続けて、必ず書き換えるとでも思ってるんでしょうか。

勧告予定の2022年まで各ベンダーの内部でテストして、外部に出さないようにすべきではないの？

もうHTML5はだめだな

独自拡張はどこもやってるよ

>>529
どこの国でも自殺者いるからお前も自殺してくれ

>>527
実装が2つ以上ないと勧告までのプロセス踏めないからね
WGの意向としては勧告の時点で実用段階に持っていきたいというのもあるだろうし
ベンダとしては自分達が提案した独自機能を「標準技術の先行実装」としてためらいなく
実装できるというのもあるかもね

ただ実験的な実装は仕様の変更にあわせて変更・削除されるのが当然なので
そういうものに手を出すのは作成者の責任でしょう
非公開にしてると公平なテストを行うのに不便だし

この世界は、結果的に性善説で発展してきたからなぁ。
もしブラウザが、W3CのValidatorに通らないような腐ったマークアップを、
パースエラーだして排除するような世界だったら、
今のように、もはやOSではなくてWebアプリの時代だ。とはならなかっただろうし。

実際さ、使われて見なきゃ、問題点がわからんよ。

2022年まで待たずに、今からでもどんどん使ってフィードバックすべきってこと？

かつてのW3C信者が「勧告されてない仕様なんか使うな」とか言って怒り出しそうな事を
W3C自身が「やれ」と？

作ってるのは実質whatwgだもの。
w3cはワーキンググループごと丸飲みしたようなもの。

2022年ってどこで聞いたのか知らんが、勧告予定は2010-09だよ。
ttp://www.w3.org/html/wg/

2022年勧告はWHATWG WikiのFAQからだね
ttp://wiki.whatwg.org/wiki/FAQ#When_will_HTML_5_be_finished.3F

あれだけ仕様の大きいHTML 5をあと2年で勧告っていうのは無理があると思う
強引に出してもエラッタだらけの使えない仕様じゃ意味ないからな

ttp://wiki.whatwg.org/wiki/FAQ

>HTML5 will reach a W3C recommendation in the year 2022 or later.

2万ケースのテストを完璧にクリアする実装が2つ以上現れない限り勧告されないとか言ってるが。

W3Cとしては2010年に出したいってことかな。

CSS3やXHTML2の例を見れば、
2010年に出したいだけで、2022年になっても出ない気がする。

完全互換の実装が少なくとも2つ、そのためのテストがどんなに少なく見積もっても20000か。
・・・永遠に出ない気がしないでもない。

2012年の間違いじゃね？

>>536が引用した文章の後に
>This will be approximately 18-20 years of development, since beginning in mid-2004.

とあるから間違いではないでしょう

>>530
お前が死ねごみくず＾＾

W3C信者って何？そんなのがいるの？

>>541

>>543
死ね＾＾

>>535-536
2年はきついな……
2022年とすると、あと14年か。長すぎて達成可能なのかどうか今いちピンとこない

実装が2つあれば良いのなら、OperaとFireFoxがクリアしてくれればOKなわけか
14年もあれば、新しいブラウザの一つくらいは登場するかもしれないし
達成の可能性はそこそこありそうな気がする

Firefoxは５の実装終わったらやってくれるだろう
でも５とＸ２を並存させたら無駄な処理がめちゃくちゃ増えそうだな

先に完全に実装しようとするのはACIDテストへの反応なんか見てると
OperaとSafari(WebKit)かなぁと思う

まあ、IE は自分の興味のあることしか手を出さないからな。

それでも僕らはIEを意識せざるをえない

IEは広く浅く手を出しておいて、途中で放り投げるよな。

XHTMLはMSが言い出したようなものなのに、いまだにXML文書内の
接頭辞HTMLの要素をHTMLとして扱う、という意味不明な実装が10年続いている。
（名前空間は無視し、接頭辞だけを見る。XML名前空間の仕様にも準拠してない。）

CSSも昔は積極的にコミットしてたのに、最近はまるで興味無いっぽい。

XSL(T)も推進してたのに、XSL-FOは早々に見切りをつけ、XSLT1だけ対応し、
XSLT2は実装しないと言いだす。

SMIL2に早期に対応したのに、HTML文書でしか使えない、名前空間が独自、の糞仕様のまま放置。

SVGのAuthorsにも名前連ねてるくせに…

IE勝手だな。

IEはシェアが最大だから…標準準拠とか先行実装とかしてもこれ以上
シェアは増えないだろうから、他のブラウザにユーザーを取られない
程度にバージョンアップするんじゃないかな。シェアの低いOperaや
Safariほど標準指向が強いと思う(Acid 3合格をアピールしてみせたりとか)。

MSXML自体は新しいバージョンが出ているのに、MSXML 4.0(?)を使い続けて
いるのは、やっぱやる気がないだけなのか。

IE8のHTML準拠実装だって単にffにシェア奪われて
焦ってきたからやってるだけだろ？
このままだと「より正しい」ffに人がどんどん流れてくからな

利益を手放したくないから目新しい要素を勝手に実装して人目引いたら使い捨て

Fx と言いなさい。

おっとすまねえ

わかればよろしい♥

OSとバンドルされっぱなしな限り、そんなに状況変わると思わんが……って日本だけか、それは。
まあFirefoxはいい加減起動時のもっさりをなんとかしろと。3になって速くなったと言ってもなぁ。

rubyｷﾀ━━━━━(ﾟ∀ﾟ)━━━━━!!!!

えっ、ruby 入るの？

http://www.whatwg.org/specs/web-apps/current-work/multipage/section-text-level.html#the-ruby
rb要素がない?!

あー、そういや IE は rb 要素周りで誤解釈があったんだっけ……。

つーか XHTML 1.1 の ruby に慣れていると、この複雑ルビにいらっと来るな。
rbc と rtc がないと使い物にならん。

　斎 (さい) 藤 (とう) 信 (のぶ) 男 (お)

これはないだろ、これは。

　斎藤信男 (さいとうのぶお)

こうだろ、普通は。

rb要素がないとCSS3 Ruby Moduleでdisplay:ruby-baseに当てる要素がなく
なって困るんじゃないかな。

ルビとかめんどいだけでいらんだろ
ふらないとダメな時は普通に括弧書きするし

ルビはいいぞぉ〜。
ご飯がおいしくなるぞぉ〜。

>>565
括弧書きだと音声ブラウザで二重に読み上げられてしまうのが
よくないんだよね。

音声ブラウザなんて完全無視です
ブラウザの互換性を求めるなら余計に括弧書き一択です

前にどこかで誰かが提案してた

<ruby tite="さいとうのぶお">斎藤信男</ruby>

はすばらしいと思った｡ 簡単だし､ 音声ブラウザで二重に読み上げられてしまうこともない｡

titeじゃないよ､ titleね｡

title 方式は素晴らしい。

HTML5 の理想の配役は？
HTMLレッド　：
HTMLブルー　：
HTMLイエロー：
HTMLピンク　：
HTMLグリーン：

華やかさのかけらもないHTMLから紅一点のピンクか……難しいな

ピンクはエロサイトにばっちり対応でおｋ

Offline Web Applications
http://www.w3.org/TR/offline-webapps/

HTML5 を電子文書の標準にしたいひと
こッのゆッびとぉーまれッ

あいつに触ったらばい菌うつるぞー逃げろー
わーわー

XMLが既にあるだろ

yhtml もあるしな。

OpenDocumentとかならともかく
HTMLを「電子文書の標準に」
なんていう人はじめて見たよ

事実上すでに標準ですが何か

まぁ「電子文書」の定義にもよるけど

>>580
HTML, XHTML しかわからんのだろ

もうPDF捨ててGIFにしてくれへん？
http://pc11.2ch.net/test/read.cgi/software/1172413533/

ドラフト予定地

HTML 5 (W3C Working Draft 9 June 2008)
http://www.w3.org/TR/2008/WD-html5-20080609/
HTML 5 differences from HTML 4 (W3C Working Draft 9 June 2008)
http://www.w3.org/TR/2008/WD-html5-diff-20080609/
HTML 5 Publication Notes (W3C Working Draft 9 June 2008)
http://www.w3.org/TR/2008/WD-html5-pubnotes-20080609/

まだかなー

EDは見られるね。
http://www.w3.org/html/wg/html5/

モザイク、HTML3 のころは、とくに文系のあいだで、
一般人はHTML、大規模なものは TEI が標準
みたいな扱いされてたな。
TEI もトンと聞かなくなったと思ったら地味に XML化
してるね。

W3C WebApps Working Group
http://www.w3.org/2008/webapps/

きましたよー

とりあえずSelectors APIを名前空間なしでいいからlevel 1として早めに仕上げてほしいな
DOM XPathは腐ってるし
…ってスレ違い？

HTML 5 (W3C Working Draft 10 June 2008)
http://www.w3.org/TR/2008/WD-html5-20080610/
HTML 5 differences from HTML 4 (W3C Working Draft 10 June 2008)
http://www.w3.org/TR/2008/WD-html5-diff-20080610/
HTML 5 Publication Notes (W3C Working Group Note 10 June 2008)
http://www.w3.org/TR/2008/NOTE-html5-pubnotes-20080610/

6/10公開でした。

a要素にtarget属性が使えるのか。

パブリケーション・ノート見て知ったけど
dfnの扱いが大分おとなしくなったんだなー

Publication Notesの差分とかのリンク先ほとんど間違ってないか？

草案の方のページの区切り方も何かよくわからんなー
どういうルールで区切ってるんだあれ

<!doctype html>
<html>
<head>
<meta charset="UTF-8">
<title>タイトル</title>
</head>
<body>
<!-- ボディーｗｗｗ -->
<p>なんとかかんとか</p><br><p>え？なんだって？</p>
</body>
</html>

リストのポッチの色を変える方法教えてください

スレ違いだけど

<style>
li { color:red }
li span { color:blue }
</style>

<ul><li><span>かみちゅ!</span></li></ul>

li { display: block; }
li:before { content "・"; color: red; }
とか。IE7が対応していないけど。

リストマークは背景画像に置き換えるのが常識

HTMLスレPart5

<video src="video.ogv"
xmlns:cc="http://creativecommons.org/ns#"
rel="cc:license"
resource="http://creativecommons.org/licenses/by/2.1/jp/"/>
XHTML 5でこういうことができたらいいのになあ。video要素とRDFaを
両方使うとオレオレXHTMLになってしまう。せっかくスキーマを取り払ったん
だから、モジュール化して他のモジュールも自由に取り込めるような仕組みが
いいと思う。

what-wgが「HTML5はモジュールに分割せずモノリシックな規格を作る」って決めてしまったからなぁ…

>>600
べつにいいんじゃないの？
「XML書式では、SVG等を埋め込んだりできるよ」
って自分たちで言ってるんだから。

勝手に他の名前空間を使えないのなら、XML方式の存在意義0じゃん。

>>602
validatorにかけると
Error: Attribute rel not allowed on XHTML element video at this point.
などのエラーを返される。@relや@resourceをvideo要素に書くとHTML 5準拠
にはならないんだよね。ブラウザでの表示やRDFの抽出はできるだろうから
実際あまり問題はなさそうだけど、そのXHTML文書が準拠する仕様はどこにも
存在しないってのは、ブラウザの独自拡張時代を思い出させてあまり好き
ではない。HTML 6あたりで「やっぱりCSSみたくモジュール化しよう」って
ことになり、Multimedia ModuleとかMetainformation Attribute Moduleとか
が定義されて、制作者はいろいろなモジュールの中から好きなものを選んで
組み合わせて使えるようになったりしないかなあ。

それを言い出したら、
@rel等で使うための名前空間宣言をすべて網羅したDTD等のスキーマなんて存在しえないと思うけど。
xmlns:cc="hoge"
xmlns:dc="hoge"
xmlns:dcterms="hoge"
xmlns:xhtmlvocab="hoge"
xmlns・・・・
って全部FIXEDで定義したスキーマが用意されるの？
名前空間接頭辞も自分では決められないってことになるし。

HTML 5はスキーマがないんだから仮にRDFaが使えることになっても
気にしなくていいんじゃない？
むしろXHTML1.1+RDFaの方が名前空間宣言すると厳密なvalidationでエラーに
なってしまう。無視してよい類のエラーだとは思うが。

「Firefox 3.1」ベータ版リリースは8月19日を目標に--「HTML5」をサポート:ニュース - CNET Japan
http://japan.cnet.com/news/media/story/0,2000056023,20378488,00.htm

結局<b>と<i>が残る糞仕様か。
b, i { font-style:normal; font-weight:normal; color:red }
としたらマークアップの意味がなくなるのだから、物理要素全開だろ。

bとiくらいは残しておかないと不便でしょ。慣習的にボールドやイタリックで
表記するようなフレーズは仕様書に例示されているようにいろいろあるんだから。

bとiはそれぞれ他の文との「差異」を表す。bは「強調」的な意味での差異で、
iは「変調」的な意味での差異を表す

とでもしておけばよかったのに、「太字で表わされるもの・イタリックで表されるもの」
なんて何でそんな物理的な定義をしてんだよ、て感じはする。

そこまで定義を変えるなら新しい要素をつくったほうがいいような気もする。
bやiの定義が物理要素っぽいのは、CSSなしでも最低限のレイアウトは
できるようにという意図なんだと思う。

>>610
<em>と<strong>涙目

間違えた
>>609だった

結局は、太字で表わされるもの・イタリックで表されるものという意味で
使われるのだから無理やり理想に沿うように定義を与えても、
今度は定義をに基づいた、今までにない用法が生まれたり、
新たな矛盾や混乱を生むだけかと。それなら新しい要素作れと思うが。

まあ、結局bとiを残してるのがおかしい、というふりだしに戻るわけだ。

使わなきゃいいだけだし
実装に別に手間がかかるわけでもないからどうでもいいじゃないか

xhtmlは本格的に作りたい人向きで
htmlは初心者の登竜門ってことでおｋ？

ただの規格違い
上も下もない

その規格が誰向きかの話をしてるんじゃないのか

難易度で規格を分けているわけじゃなくてですね
strictとtransitionalを挙げるのならわからなくもないけど

というか「HTMLスレ Part5」か何かと勘違いしただけのような

難易度ではなくてタグだけで見栄えができるかってことを言ってるんじゃないのか

HTML5はHTMLでもルビとかMathMLが使えちゃうとなると、
わざわざ構文が厳格なXHTMLを選ぶ必要がないような…

>>618
だからその規格に誰向きも糞もないと言っておる

以前はHTML5でSVG埋め込みたければ、XHTML構文使うことになる
とか言ってなかったっけ。
MathMLは整形式じゃなくてもOKなの？

やっぱ、そんな「障壁」があったら「一般人」が敬遠してSVGの普及が妨げられるだけだよね。
（今更SVGが普及するとも思わないけど）

>>622
誰向きというか何をやりたい人に向くのかという実際の用途の話でしょ。
揚げ足取ることに固執しすぎだ

だから変わりないと言ってるんだよ
どう見たら揚げ足に見えるのか

>>623
そんなにXHTML構文が面倒くさいのか
まさかHTMLを手書きしてるとか？

そんなに面倒ってことはないだろうけど、XHTMLにSVGを埋め込みたければ
XHTMLを整形式で書いてapplication/xhtml+xmlとかで送らないといけないので、
結構敷居が高いと思う。世の中のXHTMLのほとんどは非整形式でtext/html。

XHTMLにSVGとかMathMLって名前空間組み合わせの例みたいなもので、
実用性はあんまりないよね。object使ったほうが確実で安心だし。

validじゃないソース書く奴はただの素人

そうでもないよ？

うそーん
validってそんな難しいもんじゃないよ？

ルール破りのこともしなくちゃいけないこともあるよ？

validって単に文法守ればいいだけのことだよ？
strictで書けって言ってるわけじゃないよ

>>632
代表的なのはformとtableな

>>633
何か難しい？

formとtableの入れ子関係でvalidで無くなる件を言ってるのだよ
しらないのか、あっそ

>>635
form要素の中にtable要素を入れるだけじゃん
tableが取れる子要素は決まってるよ。わかりやすい
何でも入れようとしてね？

念のために聞くが、table直下に
formを入れようとしたとかそういう話じゃないよな？

>>636
おまえは入れ子関係で改行が生まれる関係をしらんのか

638の日本語が理解できない

ここまで例示なし・・・と

validの関係と改行の関係にどのような関係が関係するの？？
改行のせいでvalidでなくなるって・・・知らないなあ
具体例を出してくれるかな

>>641
validのために普通にtableとformを入れ子にすると改行が生じる
この改行をなくすためにvalidに反する入れ子にする
もうこれは常識だと思うんだけどなあ、俺釣られたのか

>>636
trの直下にform入れて1行を1フォームにしたい場合のことだと思う。

私ならtableとは別にhiddenフィールドのみ含むform作ってJavaScriptで値を入れてsubmitする。
XFormsが使えればいいんだけど。

HTML 5はどうなってるかと思って見てみたらinput要素とかがform属性持ってて先祖以外のフォームに結びつけられるらしい。

# 改行うんぬんはしらね。

自分もHTML習いたての時にあったな。
tdの中にinputをおく時に、td > form > input　としたらテキストボックスの上下に改行が
入ったから、「じゃあtrの下におけばいいんだ！」とtr > form > td　とやっちまったことがあった。
偶然問題なく表示されたが、リファレンスを読んだらtable直下に置けるのはcaptionとかtrのみで
formなんて置けないと知って、結局tableの外に追い出したが。

入れ子でvalidじゃなくなる云々と言っている奴は、おそらくまだ習って間もないんだろうなあ。

>>643
trはthとtdしか取らないでしょ

>>642

<style type="text/css" media="all"><!--
form{ display:inline; }
--></style>

こんなことも知らんのか……。ひょっとして俺は釣られたのか。

>>642
だから具体例（あるいは情報源）を示せと言っているのに
なぜあいまいな言い方に終始するんだ

>>647
知らないなら勉強するかググレばすぐでてくるぐらい有名なことなんだが

>>647
知りたいなら教えてくださいって頭さげて聞けよ＾＾
聞く態度じゃないだろ素人君

tableに限らずdlもolもulも取れる子要素は決まってるし
form直下はblock要素と決まってるし
改行が入るだとか、改行が入るからvalidじゃないマークアップをしないといけないだとか、よくわからん
レンダリング結果を優先したためにvalidじゃないマークアップを選んだって意味？

改行が入るとか言い出した時点でもうvalidがどうとか言う話からかけ離れているような

「validじゃない入れ子にして改行を防ぐオレ、カッコいい」とでも思ってるんだろうか……。

>>649
教えて下さい、お願いします<_o_>。

なんだ、偉そうな初心者が暴れてただけか

>>643
そもそも一つのtable内で、別々のformに分けたい場合ってあるのか？
formの中にtableを置くようにすれば問題ないと思うんだけど

>>642
> この改行をなくすためにvalidに反する入れ子にする
> もうこれは常識だと思うんだけどなあ、俺釣られたのか

文字を大きくするにはH1〜H6を使います＞＜
インデントするにはBLOCKQUOTEを使います＞＜
みたいな常識？

やっぱり「HTMLのスレ！Part5」か何かと勘違いしちゃってたのかな

>>654
データを表す大きな表で、1行単位で編集したいときとか。

もちろんtable全体を1つのformにしてもいいんだけどそうすると表のデータが全て送信されてサーバ側がめんどい。

>>616からの流れ？
改行（笑）のために変な入れ子にしてinvalidにするような初心者にとってはxhtmlもhtmlも難しい
本格的に作りたい人にとってはxhtmlでもhtmlでも本格的に作れる
ということで

スレ違いの議論はやめてあげてお父ちゃん。

http://jintrick.net/agenda/2008/08/post-423.html
どう思う？

正論

ttp://www.bluishcoder.co.nz/2008/11/video-audio-and-cross-domain-usage.html

>It looks likely the that <video> and <audio> elements will be restricted
>so that requests for a media resource from a domain other than the page
>containing the element will be disallowed.

そんなバカな。
ttp://www.w3.org/TR/access-control/
のAccess Controlなんて、規格が制定されて広く使われるのに何年かかるんだよ。

まあ、adobeのcrossdomain.xmlとか、microsoftのclientaccesspolicy.xmlという独自規格が混在するのは良くないし、
何か統一規格が必要だとは、前々から思ってはいたけれど。

HTML: The Markup Language
http://www.w3.org/html/wg/markup-spec/

これは何？DOMとHTMLを分けて定義するとか？誰か解説キボン.

長いから分割したってことなのか.
http://www.w3.org/QA/2008/11/html_5_the_markup.html

>>663
昨日あった Firefox Developer Conference 2008 に Michael Smith 氏が出ていて（>>664 の QA に名前が出てる人）、そこで発言してたんだが

仕様書
　ブラウザ開発者向け
HTML: The Markup Language
　デベロッパ向け（少し高度な内容でも理解できる人という意味？）
今度出す予定の3つめの文書
　一般 HTML 5 ユーザ向け
　QA でいうところの "Web Authoring Guidelines" か？

みたいな位置付けらしい

"HTML: The Markup Language" は「ディレクター向け」的な発言があったような記憶があるんだが、一般的なディレクターとは定義が違うっぽい
たぶん「より専門的な知識を必要としている人」という感じ？

つまり、最終的にはさっき挙げた3つの文書が出回る予定らしい

そうなのか, ありがとう.
ガイドラインができるなら仕様書読めって言われなくてすむのかな.

これがそれなのかな.

The Web Developer’s Guide to HTML 5
http://dev.w3.org/html5/html-author/

あとで読もう.

最近の動きがまったくわからないのだけど
>>667のリンク先の3.3.1の
属性の省略は名前じゃなくて値の省略を意味して、
省略した場合値を空指定したのと同じ、ってやつは
もう確定事項なのかな？

disabled属性みたいなブール型の属性はブラウザの実装がそうなっている
みたいだから, たぶん変わらないんでは↓

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<title>empty attribute</title>
<script type="text/javascript">
if (window.addEventListener) {
window.addEventListener("load", viewEmptyAttribute, false); }
else if (window.attachEvent) {
window.attachEvent("onload", viewEmptyAttribute); }
function viewEmptyAttribute() {
var i1=document.getElementById("i1").getAttribute("disabled");
alert("input: id=i1 disabled=" + i1);
var i2=document.getElementById("i2").getAttribute("disabled");
alert("input: id=i2 disabled=" + i2);
var t1=document.getElementById("t1").getAttribute("frame");
alert("table: id=t1 frame=" + t1);
var t2=document.getElementById("t2").getAttribute("frame");
alert("table: id=t2 frame=" + t2); }
</script>
<div>
<input id=i1 disabled>
<input id=i2 disabled=disabled>
<table id=t1 void><tr><td></table>
<table id=t2 frame=void><tr><td></table>
</div>

HTML5は互換性を重視してるんだから, XHTML 1.0にあった
互換性ガイドラインみたいなのは作らないのかなと前々から
思ってるんだけど. あんまり意味ない？

>>669
ありがとー
関係ないけどframe=voidとかマニアックだなあ

<video>と<audio>のクロスドメイン制限がまだ変わるかもしれん。

http://www.w3.org/TR/html5/the-root.html#nav
http://www.whatwg.org/specs/web-apps/current-work/#the-nav-element
http://www.w3.org/html/wg/html5/#the-nav-element

> only sections that consist of primary navigation blocks
ってつまりどういうものですか？
> the footer element is more appropriate
とか言われても
人それぞれ捉え方が違うような・・・
例では「header要素やfooter要素に入れるケース」みたいなのを示しているけど
今一納得できない・・・
やっぱりnav要素がmost appropriateな気が

header要素やfooter要素にnav要素は入れられないけどデザイン的に
本来nav要素に入れるのが適切なものをheader要素やfooter要素に入れたい、みたいな
そういう使われ方をして、nav要素とか分けた意味合いが曖昧になりそうな

ナビだけで構成されているセクションにはnavを使えばいいんだから
曖昧なことはないと思うんだけど.
>>673としてはナビ関連は全てnavにしたいってことなのかな？XHTML roleだと
<ul role="navigation">とかしてやれば好きな要素をナビゲーションに
できるんだけど, HTML 5は内容モデルの関係でheaderやfooterにnavが
入らないからナビ的なものがナビ扱いできなくて, 確かにあまり嬉しく
ないね.

> >>673としてはナビ関連は全てnavにしたいってことなのかな？
そんな感じです
だってnav要素がかわいそうじゃないですか
なんでnav要素を差し置いてheader要素やfooter要素に入れるのが適切なのか
どういうものがその適切なものなのか
例を見てもよくわからないです
どう見てもナビゲーション的なアンカーの集まりじゃないか、みたいな

footer要素の例の部分でも
body要素のfirst-childとlast-childにfooter要素を配してるけど
その役割からすると明らかにnav要素だと思う
「インデックスに戻る」なんてまさに「link要素によるナビゲーション」を
body要素内に書いただけ、みたいな感じだし。
そういうのもfooter要素にお任せください！とかやってたらnav要素の仕事がなくなっちゃう
nav要素の専門性が。
footer要素はfooterって名前だけど最初に登場したりもできますよ！というのも、
footer要素でしゃばりすぎだろ・・・みたいな。
そんな感じで各要素の立ち位置が曖昧になる、って感じで曖昧になると思います、って感じです


nav要素は最大限守ってあげたい

そんなにheader要素やfooter要素とナビゲーション的なものをまとめたいのなら
header要素やfooter要素にnav要素を入れることを許容するか
さもなくば
<section>
　<header></header>
　<nav></nav>
</section>
みたいにセクション病が蔓延してしまえばいいんです

というかなんかもうかなりフリーダムに思えて
nav要素とかfooter要素とか分ける意味なくね？って思うんです


・・・たくさん言い過ぎました
divでラッピングする作業に戻ります

HTML 5みたく細かい意味内容を要素にして定義してしまうと内容モデルの都合
とかで不便になるから, HTML4みたいにブロックレベルの要素は大雑把な定義
にして, 属性(や属性値)でどうにかしたほうがいいのかもね.
まあ, 今さらHTML 5からnavが消えることはないだろうからやるとしたら
navの定義の変更だろうけど, headerやfooterにnavを入れられるように
すると, かなりややこしいことになる予感.

理想は素晴らしいんだけどね
もうＸＨＴＭＬ１．１で完成でいいよ
大事なのは問題なく見れることだろ
さらに問題増やしてどうすんだよ本当に
本末転倒もいいとこ

俺も XHTML 1.1 で完成していると思う。

iframeないけどいいの？

XHTML1.1モジュール改訂版（XHTML1.1Second Editionか？）
http://www.w3.org/TR/2008/REC-xhtml-modularization-20081008/

frameモジュール、iframeモジュール、それにtarget属性モジュールまである。
現在すでに実装され、それなりに需要が存在する要素がモジュール化されている。
これが出ればHTML5は正直要らん気がする。

HTML5もせめてモジュール化の方向へ軌道修正してもらいたいものだ
モノリシックな規格作ろうとするから15年かかるんだよ

>>681
XHTML M12N 1.1はXHTML 1.1とは違うものだよ
XHTML M12Nはモジュールの定義だけ

XHTML M12Nのモジュールを使って作られた仕様がXHTML 1.1
XHTML 1.1 SEはこれ
http://www.w3.org/TR/2007/WD-xhtml11-20070216

っていうかHTMLってはもう仕様更新しなくていいから
全部XHTMLでやってくれよ。
SGMLなんて古臭くて面倒くさい仕様でやるより、XMLでやる方が遥かに簡単で便利なんだから……。

HTML 5はSGMLではなくてね（以下略）。

XHTMLのほうがプログラミングしやすいのは確かにそうなんだよね。
「XHTMLの拡張子は'.xhtml'にする」ってのを習慣にすればよかったのになあ。

いっそのこと .htaccess か何かで ".extensiblehypertextmarkuplanguage" って拡張子に定義すればいいと思うよ。
".xhtml" っていう新たな拡張子が生まれても間違いなく対処狩野英孝。

じゃあHTML5は".html5"でキマリだな。

何か不定期に極論ギャグさんが出てくるな

拡張子xhtml？
仮にXHTML用拡張子が作られても、そんな名前にするわけがない。

skypeのムードメッセージでｈｔｍｌを使って文字の動きの表現を作ってるんだけど
メッセージ変更のアプリを使ってそのまま貼り付けても表示されない。
何が原因かわかりますか？

>>685
684じゃないけど、終了タグ省略可って時点で、SGMLみたいなもんだろ。

俺的にはHTML5出すのはいいが、XHTML5だけにして欲しい。
マークアップ言語なのにXMLが元になっていないってだけで気持ちが悪い。

TCP/IPといいさー、HTMLといいさー、性善説なんだよね。
TCPなんて機能的にもセキュリティ的にも不十分だしさ、
HTMLなんてブラウザがとっても寛大に解釈してくれるしね。

これがもし、TCPがもっと厳格なら、当時の多数あったネットワークプロトコルのひとつの中に埋もれてしまい、普及しなかっただろうし、
UAがHTMLをもっと厳格に解釈したならば、HTMLもまた流行らなかったと思うんだよね。

必然的に性悪説の必要がでてくるのに、性善説じゃないと広まらないってのは何なのかな。
XHTMLって、application/xml+xhtmlを初めとして、
ひとつでもシンタックスエラーがあれば、ブラウザはその場で描画を拒否しても問題ないんだよね。
そうでなくて、HTML同様に寛大なパーサーならば、せっかくのXMLの意味がないしね。

で、性悪説は流行らない。

>>692
そういや文法的に正しくないXHTMLがたくさんあって、XHTMLがXMLとしての意味
をなしてないから、HTML5を作るとか書いてあったページあったな。

text/htmlで書くと、XHTMLなのにブラウザがHTMLとみなしてXMLの文法ミスがあっても
無視するから実質XHTMLはHTMLであって、<br />の/は無駄だとかうんぬん。

って全部IEのせいだろうが！まじ死んでくれMS。

>>692
× application/xml+xhtml
○ application/xhtml+xml

確かに間違える馬鹿が多いってのはよく分かったｗ

>>693
激しく同意
IE マジ要らん

canvas要素に3Dコンテクストは追加されるのか。

>>694
うろ覚えで打ったから間違えた。

でもさ、もしすべてのブラウザが、この瞬間にtext/htmlで、XHTMLなサイトを、XHTMLとして厳格に解釈するようになると、
生き残れるサイトってのは、個人一人でやっている、一部の厳格な規格オタクのサイトぐらいだろうね。

Googleでさえ、まともじゃないんだぜ。

多くのブラウザ対応を迫られたサイトはある程度非準規を意識する必要があるだろう

諸悪の根元がde facto standardだからな

>>697
XHTMLなのに厳格じゃないサイトってあるのか？
と思ったら普通にあるねｗｗｗ

ただ個人サイトでXHTML使うこと自体ヲタ行為だから、XHTMLの個人サイトなら通る奴のが多いと思われ。

>>699
多くのブログツールが初期設定で XHTML を吐くようになっている今、ヲタ行為ともいえなくなっているぞ。

HTML 5では，HTML版のメディアタイプは'text/html'，XHTML版は'application/xhtml+xml'と
決まっているので，DOCTYPE宣言でXHTMLを名乗ってるミスだらけのXHTMLもどきが'text/html'で
送られてきて，それをブラウザがHTMLとして扱って，でたらめばかりじゃないかということは
なくなるはず．
んで，まさか今更'application/xhtml+xml'でXHTMLを提供することが主流になるとは考えにくいから
今後もほとんどのウェブの文書のメディアタイプは'text/html'と見てよさそうなんだけれど，
HTML5(HTML版)ではxmlns属性を書いてもよかったり空要素を/>で閉じてもよかったりするので，
こんな感じ(↓)のHTMLがなんとなく大量発生して仕様的にも正しいよってことになると予想．
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html;charset=UTF-8"/>
<link rel="stylesheet" href="style.css" type="text/css">
<title>Someone's blog</title>
</head>
<body>
<header><h1>Someone's blog</h1></header>
<article>
<h2>Getting Started</h2>
<p>Foo blog is succussesfully installed. Let's use ...</p>
</article>
<footer>Copyright (c) someone, powerd by Foo blog 1.2.3</footer>
</body>
</html>
で，一部の人がこれを気持ち悪がってHTMLなのにXHTMLっぽく書ける仕様は廃止すべき
じゃないかとか言うものの，ブラウザの動作は問題ないし大半のHTMLがこんな感じで
メディアタイプも'text/html'なので，わざわざ仕様をいじって非適合HTMLを増やす
必要はなくこのままでいいということになる．

XHTMLでtext/htmlにしてるのは互換性のためだろ
HTML5が普及するころには大方問題なくなってるだろうから今心配してもしょうがないだろ

>>702
現実には'application/xhtml+xml'なXHTMLをIEがうまく扱えないってのと，
仮に扱えたとしてもエラーチェックが厳格な割に使うメリットが感じられ
ないってところなんだろうね．GRDDLするとかXMLからXSLTでXHTMLを生成する
とかXMLとして応用するんでなければHTMLもXHTMLも大して変わらないわけで．
HTML 5が普及すれば>>702の言うとおりXHTMLのメディアタイプの問題はうまく
決着はついてるんだろうね．XHTML2 WGのほうは，XHTML 1.xを(1.0以外も)
'text/html'で送れるようにする方向みたいだけど．

どうもWebProg板にHTML5のスレがなさそうなのでこちらで。

HTML5で、フォームの機能が大幅に強化されるのって、正直どんな感じなの？
むしろこれが画期的な変更のような気がするんだが、このスレ見ててもあんまり
重要視されてないような気がするんだけど

やっぱり、HTMLとXHTMLは別々に進化すべきだと思うけどね。
XHTMLはデータ流し込みを早く入れて欲しいと思う。

<p>ギコにメールで馬鹿にされた。</p>
<blockquote src="giko.txt" type="text/plain"/>
<p>いつかもっとすごい返事を送りつけてやる</p>
<p src="mona.html" type="text/html"/>

こういう奴。
ただ、p要素の中のtext/htmlにブロックレベルな要素が入ってたらややこしいことになるから、
もっと安全なcontent-typeが出来るといいな。
"text/inline-html"とか。

object要素やxincludeがあるだろ。
src属性を汎用化する必要があるとは思わん。

Safari4 出てるらしいけど実装どうなってるかな

WD更新されたのにお前ら無反応なのな。

正式まで冬眠

>>708
未だにWDなのに20080610や20090212からどう変わったか調べるなんて面倒だからなあ。

フォームコントロールは魅力的だけど、まだOperaくらいしか対応してないし。

HTML5ｲﾗﾈ。役には立つだろうけどまた崩れたコードが増えてブラウザが重くなるわ
XHTML2に機能統合してくれ

>>711
その XHTML2 はブラウザベンダには完全に見捨てられてる

>>712
見放してんのはIEだけだろ
GoogleやOperaはわりと積極的

XHTML2に積極的なベンダーなんてあるか？
だいたいXHTML自体が、Web Developer側から見捨てられてるだろう。
IEがサポートしていないからなんて、言い訳にすぎんよ。
だれもWebに厳格なパースを望んでいないんだよ。

>>714

wwwの生みの親、ティム・バーナーズ＝リーは、それを、
正に厳格なセマンティック・ウェブを熱望しているんだけどもな

>>714
厳格なパースを望んだからXHTMLができたんじゃねーよ
サーバサイドでの動的生成もJavaScript(XHR)で動的ページの作成も
もっともっと早く楽にできるから、XML拡張版の規格が出来たんだ
開発者側から見ればIEのXHTML非対応こそ憎々しいよ

IEが未サポート云々はまず置く。
application/xhtml+xmlの問題もひとまず置く。

XHTMLを使っているWebサイトはたくさんあるよ。
でも、厳格にXMLの文法を守っているサイトなんて、皆無じゃないか。
実験的なサイトぐらいでしか見たことないぜ。
IEがサポートしていなかったとしても、文法に厳格なXHTMLを提供することは可能じゃないか。
サーバーサイドでの動的生成なんだから。
なぜしないんだ。
面倒だからなんじゃないの？

>>716
> 開発者側から見ればIEのXHTML非対応こそ憎々しいよ
本当にその通り

>>717
> IEがサポートしていなかったとしても、文法に厳格なXHTMLを提供することは可能じゃないか。
「厳格」をどういう定義で使ってる？
まさか「妥当 (valid)」と同じ意味で使ってるわけじゃないよな？

ここまでの議論を読むとHTML5のXML版があれば済む話に思えるのだが
XHTML1.2やXHTML2.0が本当に必要なのってどういうケース？

全てのベンダーが無理な補正をせずに正しく動けばいいじゃね?

「あ、これ、validなXHTMLじゃ無いから表示出来ないッス」
「あ、これ、宣言されたDTDに則って無いから表示出来ないッス」
って、エラーを吐けば良いんだよ

でも、そうなると「Yahoo」ですら表示されない事になるからなあw

HTMLの未来は何処にあるのか、未だ昏迷

>>719
HTML5 は XHTML5 として利用可能
HTML5 は "HTML5" という名の包括的な言語仕様、と考えたほうがいいかも（RDF みたいな）

http://www.whatwg.org/specs/web-apps/current-work/multipage/introduction.html#html-vs-xhtml
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-xhtml-syntax.html#the-xhtml-syntax

結局、W3Cが実効的権威を持たぬ限り、
どんな規格を打ち出そうと「絵に描いた餅」か...

すでに実効してますが何か

「今」思いつきました
「今」考えました
的な仕様しか出せないのが問題

「今」のスパン長すぎだろｗ

見出しを固める<hgroup>を実運用上どう扱っていいのかわかんない。

・メインタイトル
・サブタイトル
・見出し1
・本文
・見出し2
・本文

みたいな構造のテキストで、メインとサブをhgroupでくくって

<hgroup>
<h1>メインタイトル<h1>
<h2>サブタイトル<h2>
</hgroup>

とした場合、後続の見出しを<h2>としても<h3>としても
文書の正しい論理階層を表現できないような気がするのだけど
どうなんじゃろか。

従前なら、タイトルとサブタイトルを表現する場合は
<h1><h2>は並べないで、<h1>の中にSPANでサブタイトルを
マークアップするか、サブタイトルは<p>で処理するのが
正書法だって言われることが多かった気がするんだけど、
hgroupの用例見てるとその「常識」って間違ってたのか？とか
思ってしまう。

今朝のWWDCでSafariがHTML5とか言っててビビったんだが

ttp://standards.mitsue.co.jp/archives/001409.html

HTML5はもう「使える」のか？

Appleなどが自社のサイトにHTML5の要素を利用したことや、canvasなどの広まりもあり、
巷ではすこしずつですがHTML5を利用しようという流れになっているようです。

しかしながらHixie自身は Today is probably too early to start using HTML 5. と語っています。
新しいセクション関連の要素など、ブラウザーで実装されていない要素やインターフェースについては
今後のフィードバックによりいくらでも変化しますし、実装があったとしても充分に互換性が取れているかは、
機能ごとによって変わることが「まだ早い」としている理由なのでしょう。

>>728
> 今朝のWWDCでSafariがHTML5とか言っててビビったんだが

iPhone OSを3.0にアップデートするだけで、世の中に
4000万台のHTML5対応端末ができることになるんだよね。

AndroidやGoogle Gearsの動きも考えると、
当初予想よりはるかに速くHTML5への移行が進むかもしれないよ。

まだ不安定すぎるが、Chromeも最新のDev版でvideoに対応してる。
ただ、ffmpegを使っているのにmp4コンテナぐらいしかまともに動いてない不思議な仕様だが。

X/HTML5では@roleやRDFaは使えないんだよな？
セマンティックウェブがいいとは一概には言えないけど、せっかく使えるモジュールがあるのに取り込まないのは何でなの？
それとも5.1とかで取り込む予定なの？

5.1 かあ。サラウンドみたいだな。

1 周囲の電気機器でネットワークに接続されたら便利になると思うものをひとつ述べよ。さらに列挙した電気機器の設定を行うためのインターフェース部分をHTMLで記述せよ


1で作成するネットワークに接続したいと思う電気機器について、案を考えてみる。その機器を選んだ理由も考える。

これでエアコン選んだんですが、どうすればいいですが、本当に助けてください

インターフェイスってのは当然人間-機械間の話だよな？
それならフツーにform使えばいいじゃん

すみません。HTMLで記述するのは、授業を受けてからですね。書くのは、何が便利買って言うのと理由だけです多分。
でもありがとうございました

<H1>エアコンのほ〜むぺ〜じへようこそ！！Welcome to My EAKONN</H1 >
<MARQUEE>This Home Page is Japanese Only!! </MARQUEE>

video要素って何のためにあるんだよ
object要素に謝れ!

ビデオのためじゃないの？

>>738
そのobject要素関連の技術に特許が認められたから
だいたい、img要素からして意味なかったしな

特許ビジネスがある限り、標準化なんて絵に描いた餅ってことでFA？

んなわけねー
特許に触れなきゃいいんだから

>>741

今の、HTML技術に特許あるの?
結構、勝手気ままにやってねえ?

なんでもいいよ♪
願わくは一つにしてくれ
みんなの願い

>>744
今までのX/HTML勧告を全部撤回しろってのかｗ　無理すぎる

http://japanese.engadget.com/2009/06/23/hp-touchsmart-pc/
HPからブラウザ搭載のTouchSmartプリンタ、PCレスで地図やクーポンを印刷

> 専用アプリはHTML5で書かれており、驚いたことに映画の予告編動画をストリーミング再生することまでできます。
> アイデア次第ではなかなかリッチなアプリケーション環境になるかもしれません。

HTML5ってそういうこともできたのか

今まで何だと思っていたんだよ？

まさか、HTML5にはDOMは規定されているがスクリプト言語は規定されていないので、
厳密にはHTML5だけでは記述できないなんて野暮なツッコミをしたいんじゃあるまいな。

>>747
いや、JSじゃストリーミング配信はできないからそれはないだろ
しかしどういう仕組みなのか分からん

最近、HTML5に興味をもっていろいろ調べてるんだけど、ビデオコーデックってもめてるみたいだね。
でも、Google がゲリラ的にYouTubeでMP4で配信始めたから、済し崩し的に決まるんじゃないだろうか。

ブログとかみてても、”Youtube で Video タグのデモがはじまった。すごい！でもFirefoxじゃみれません”
みたいな記事ばかり検索にひっかかって笑ってしまう。

>>748
それ以前のnoobだったか。

>>749
もめてなんかいないし、なにも決まりはしないさ。
どのコンテナや動画圧縮形式をサポートするかなんてことは、ブラウザの実装の問題だ。
規格で決める事じゃない。
画像ならともかく、何しろ動画圧縮の規格は、やたらに多いからな。

Firefoxの問題は、単にその立場上、規格がフリーなコーデックを猛烈にプッシュしてるだけ。
Theoraも、アレで画質さえ良ければいいんだがな。

Firefoxにしたって、自前のデコーダーをフリーなものにこだわっているだけで、将来の実装ではOSのデコーダーも使う話だぜ。
Windows 7ならば、mp4スプリッタもH.264デコーダーも標準で入っている。

身の回りの電気機器でネットワーク接続されたら便利になると思われるものを一つ挙げ、さらに、 列挙した電気機器の設定を行うためのインターフェース部分をHTMLで記せ


他はいいんですがあとこれがどうにもなりません

上の図の<ここに本文>の所に下の図のようなやつを書くんだと思うんですが。エアコンが簡単かなと思ったんですが誰か助けてください

http://imepita.jp/20090624/697690
http://imepita.jp/20090624/700590

本当に助けてください

> Firefoxにしたって、自前のデコーダーをフリーなものにこだわっているだけで、将来の実装ではOSのデコーダーも使う話だぜ。
結局対応形式を増やそうとすれば外部アプリが必要ってこと？
制御部分（GUIコントローラ？）をHTML、CSS、Javascriptで作るってだけで

>>751
またお前かよ、いい加減にしろ

>>752
もうすこし低級な部分にも関心を持てよ。
HTML、CSS、Javascript、DOMを解釈して実行するのはブラウザだ。
ブラウザはハードウェアやOSの機能を使って実装されるに決まってるだろ。

規格が正しく実装されているなら、その実装方法がどうであれ、
HTML5からみれば、どうでもいい話だ。

javascriptで自前のデコーダーを実装するとでも思っているのか。
五十年後には可能かも知れないが、今は無理だ。

未だに<i>と<b>を消さずに屁理屈こねて正当化しようとしているのが萎える。

objectがあるのにimgやvideoがあるのには突っ込まないのか

一番要らない子はhr

>>755
まあ日本人からしたら完全に物理要素以外の何者でもないが
欧米人からしたら、ある程度の意味も持ってる装飾だからな
捨てきれないんだろう

でも捨てろ

Fx3.5がHTML5対応したとか何とか言ってるけど
フォームコントロールは全然じゃねぇか
マルチメディアだけじゃなくて手軽で効果の高い
フォームコントロールに対応しろよって思う

んだねえ

XHTML2が消えて、HTML5に合流したね！


これからおもしろくなりそうだ。

W3CがXHTML 2の策定打ち切りを決定、HTML 5の標準化に注力へ
http://tsushima.2ch.net/test/read.cgi/news/1246629436/

>>759
それってMozillaじゃなくて周りのニュースサイトが勝手に言ってるだけじゃないか
HTML5がweb2.0みたいな言葉の使われ方をしている

RDFaとか興味有っただけにXHTML2が消えるのは残念

つーか主要ブラウザはさっさとruby要素を実装しやがってください。
あと、CSS3のwriting-mode : tb-rlも。

>>758
正直、欧米人からしたら、
文字コードレベルで、boldとitalicには、別々にコードポイントを割り当ててもいいぐらいの歴史があるんだろうな。

>>763
> RDFaとか興味有っただけにXHTML2が消えるのは残念

RDFaみたいな個別要素はHTML5に取り込まれる可能性はまだ十分ある。
なんせランニング＆イテレーションで策定を進めて、fixするのが
2020年ぐらいかも、みたいな長大なプロジェクトだよ、あっちも。

というか、今も根幹レベルでいろいろ変化が起きてる最中＞html5
<header>要素と<hgroup>要素の分岐とかさ。

headerもfooterもsectionも、@role属性の規定値を設定するだけで解決するのに
何で新しい要素を三つも増やすんだ？

>>765
RDFaには期待しない方がいいよ
旧WHATWGの連中はsemwebが大嫌いだから。

たぶんそれはxhtml2WGから見てもwhatwgから見ても
中途半端な折衷策になっちゃうから、なのではないでしょか。

role属性にheader,footerなんかを足すのは、
xhtmlにある種の視覚整形的な概念を組み込んでしまうことに
なるので、標準で定義することはxhtml2WG側は嫌がっていたんで
ないのかな、と思う。
いまのところroleに標準語彙で割り当てられてるものを見ると
やはり論理・機能的意味にもとづいているものが多く
（navigation.main.note,search,contentinfo…）
bannerが唯一headerに「似てる」けど、やっぱちょっと違う。

あと、roleを使ってheaderなどを表現するとして、現実には
結局<div role="header">と要素自体を汎用化＝無意味化するか、
むりくり<ul role="header">みたいな感じで、
本来ならとてもリスト的とは言えない個別要素たち
（ロゴ、バナー、検索窓、ヘルプ系リンク、ログイン/ログアウト制御など）を
liとして束ねる、みたいな実装になってしまうと思う。どっちもあんまり
エレガントじゃない。

だったら<header>のほうが、人間向けの視覚（聴覚）レンダリングを
前提としたブラウザ向けに正確に簡潔に意味を定義できてていいじゃん、
というのが、whatwgの理路なんじゃないかなあ？　XML的にも
そのほうがいいような気もする。

俺はroleモジュールが視覚整形系の前段階としての属性振りに使えるのは
アリかな、って思うけど、roleモジュールとclass, idが並立したら
whatwgが当初から懸念していた、htmlから簡潔性が失われることで
マークアップ技術者以外の人を遠ざけてしまう、という傾向を
助長するかもしれない。

>>767
> RDFaには期待しない方がいいよ
> 旧WHATWGの連中はsemwebが大嫌いだから。

んー、確かにそうだね。semweb自体にあまり意義を見出してないってのもあるし、
やるとしてもmicroformatsみたいな現実志向で軽便な書式でええやんけ、
なんであんな複雑な書き方になんねや、というのがあるのかもね。

>>268
標準語彙じゃなくても、CSSWG辺りでちょちょっと拡張語彙用のIRIを作ってくれればいいのになw

早速ｈｔｍｌ５に準拠したぜ

>>771
おめでとう。

まだ勧告もされてないのに

http://slashdot.jp/articles/09/07/05/0522246.shtml
HTML 5の仕様からオーディオ・ビデオコーデックに関する要件白紙に。
ベンダーの意向の相違が原因。

なんや色々迷走してるな。Appleキャスティングボート取れなかったか。残念。

動画サイトとしては、今までH.264でアップロードされた膨大なリソースがあるわけだから、
仮にHTML5が普及したとしても普通に H.264 使うでしょ。

で、Firefox や Opera みたいな H.264 サポートしないブラウザには
Theora を使うんじゃなくて、Flash Player 版を送り込むようになると思う。

Dailymotion も今は Theora 持ってるようだけど、1つの動画につき、
MP4, On2VP6、Theora と最大3つのリソースを持つ余裕はなくなっていくと思う。

このスレ見てると資本主義の限界を感じる。

HTML5 の DOM インターフェイス仕様中途半端すぎると思う。

HTMLVideoElement と HTMLAudioElement がともに HTMLMediaElement から派生しているのはいいとして、
なぜ HTMLMeidaElement が HTMLObjectElement から派生していないのかが不思議。
ついでに、ol は、HTMLOListElement なのに、ul は HTMLElement とか。
各タグごとに、インターフェイスを定義して、適切な継承関係を作ってほしかった。

そうすれば、prototype 拡張とか動的メソッドを使って、
特定の要素だけ機能を拡張するようなことや、
特定のインターフェイスを実装するかどうか調べて、
それらに自動でスタイル適応させるとかが、簡単・簡潔になるのに。

抽象クラスHTMLMediaElementのスーパークラスが、
具象クラスHTMLOListElemenだったら、そのほうがおかしいだろ。

後方互換性の維持が絶対要件であるなら、設計が美しくないなんてのは妥協するしかないだろ。

>で、Firefox や Opera みたいな H.264 サポートしないブラウザには
>Theora を使うんじゃなくて、Flash Player 版を送り込むようになると思う。

それは違うだろ。
OSに丸投げする形になるだろ。
たとえばWindows 7なら、かなりのデコーダーを標準で持っている。

どうやってWebからOSに投げるのかと問い詰めたい
OSがデコーダー内蔵しててもブラウザがそれに対応してるかどうかは別問題
丸投げしたって勝手に再生してくれるわけない

結局一番穏当な案としても、後方互換対策としても、現状ほとんどのプラットフォーム
＆ほとんどのブラウザに対応してるFlashに頼るのは目に見えてる

> 結局一番穏当な案としても、後方互換対策としても、現状ほとんどのプラットフォーム
> ＆ほとんどのブラウザに対応してるFlashに頼るのは目に見えてる

ですなあ。このベンダ分裂で一番おいしいとこ取りできるのはAdobe。
AppleがiPhoneからのFlash締め出しを続け、さらにH.264とAACを
超押ししてきたら将来的にはどうなるかわからんけど、まあ、なさそう。

ま、あんまり高い期待はしてなくて、「swfobject.jsなしで
きれいな構文でサクッとflvとか入れられるならそれでいいよ」って人は
多いんじゃね。俺もそうだ。

>>781
どうしたらWebからOSという経路になるのか問い詰めたい。
（Webコンテンツを解釈した）ブラウザからOSに決まってるだろ。

あと、Flashに頼るわけないだろ。

ブラウザがFlashにfallbackするとか考えている奴はアホじゃねぇの？
なぜなら、Flashは、
動画はH.263とVP6とH.264、
音声はmp3とAAC、
コンテナはflvとmp4、
あと詳細不明な動画と音声の圧縮形式があるんだが、adobeの商用コードでしか使われてない。

これだけしかサポートしてないんだぜ。

>>776>>780の流れ読めよ
話してるのはブラウザとOSの間のストリームじゃないだろ

>>785は>>783へのレスな

>>784
Flashがクズなのは同意だけど
それ以上に多くのブラウザで直接閲覧できるファイルフォーマットがない

何だWebサイトからかよ。
それは今も今後も変わらないだろ。

そういや、現時点でもIEなら、独自拡張のimg要素を使うことによって、
適切なデコーダーとスプリッタさえ入っていれば、
H.264だろうが何だろうが再生できるんだが、使っている人はいないな。

HTML5でWebページとブラウザ以外の議論をするわけねえだろ
お前はもうちょっと

>>788
すまんな、ブラウザの実装の話かと思ったよ。

ただ、Flashは、H.264+AACなmp4コンテナの再生という点では、優れているんだけどな。
しばらくブラウザは勝てないだろ。
H.264のデコーダーはしっかりしているし、HE-AACもちゃんと再生できる。
さらにGPU描画もあるからな。
フレームレートの高い動画は、現状では、ソフトウェア描画では無理がある。

canvasも、Flashに比べると、やはり見劣りするんだよな。


ところで、canvasの行列変換が「逆順」に適用されるって誰が考えたんだ。
常識的に考えてアホだろ。おかげで何時間も悩むハメになった。
（いやまあ、規格を適当に読み飛ばした俺の落ち度もあるんだろうが）
あと、Identity Matrixにするメソッドぐらいあってもいいと思うんだ。

あんまり難しい話をするとついていけないぞ。
主に俺が

もう HTML 5 とか XHTML 2 とか、どうでもいいよ。
どうせこれからは yhtml の時代だし。

yhtmlは、<全裸で>マッパマン氏</全裸で>提唱の仕様が反映されるかどうかが疑問

>>789
下、どっかで読んだ文だと思ったら、blog にも同じ事書いてない?
ま、だから何だってわけじゃないけど…

>>793
みんな思ってても言わないだけでございます。

XHTML5/HTML5は未だにh1,h2...とかやってるんだねｗ
sectionがあるんだから<h>に一本化しろよ

禿どう

html４も、xhmtl1のルールが守れないのに、
html5が守れるのかよ?

>>797
日本語でおk

html４もxhmtl1もルールが守れないのに、
html5が守れるのかよ?

そもそもデザインは処理系依存って所が仕様云々の妨げになっているんじゃないかと思うんだが

Softbankの〆日がようやく来たので、
遅くなったけど今から>>307を実行するぜ

誤爆した・・・
ｽﾏｿ

新しいものでてきてもなぁ
結局ブラウザの解釈が統一してくれないとなぁ

HTML1.0
↓
HTML2.0
↓
HTML3.0
↓
HTML4.0　→　XHTML1.0
↓　　　　　　　↓
HTML5.0　　　 XHTML1.1
（いらない）　　（いらない）

個人的に XHTML 1.1 は要る。
複雑ルビのマークアップを覚えたら手放せなくなった。
逆にいえば、これがそのまま HTML 5 に入れば XHTML 1.1 にとどまる理由がない。

　 ﾆ ﾎﾝ ｺﾞ
　日 本 語
　Japanese

純粋なSGML構文でないHTMLなんて要らねーよ
XHTML5の仕様だけで充分だ

>>806
ｈａｇｅｄｏ−！

ValidなXHTML5以外は全てエラーで表示しないようにしてくれって各ベンダーにお願いしないとな

>>808
XHTML5 はメディア型が application/xhtml+xml じゃなきゃいけないから、多分大丈夫じゃない？
とりあえず整形式じゃないと表示されないし、IE では整形式で Valid であっても表示されないｗ

どうせならHTML5の前に、HTML4.01StrictにFramesetとルビ機能を加えた、
HTML4.5をHTML4系列最終版として出して欲しいなあ……。

HTML5のサブセットでいいと思うよ☆

http://groups.google.co.jp/group/html5-developers-jp?pli=1
HTML5の情報交換MLだそうだ。

ＨＰにクイックタイムで再生できるように自分がもっているＭＯＶの動画を

<EMBED src="./img/ファイル名.MOV" loop="1" volume="50">と書いて
ＵＰしてみたところ、ＨＰを立ち上げたと同時に動画が再生されてしまいます。

さらに、プレイヤーの下に表示されるはずの再生ボタンや停止ボタンが
表示されません。なにが原因かわかりませんアドバイスお願いします。

参考http://www.scnet.tv/~narinarito/contents03.html

スレ違い。

まあスレタイしか読んでなければ、HTML総合スレPart5みたいなもんかと思っちゃうしな。

YouTube、Diggに続いてIE6のサポートを打ち切りか？
http://jp.techcrunch.com/archives/20090714youtube-will-be-next-to-kiss-ie6-support-goodbye/

大手Webサービスデベロッパの方が
IE6を殺しにきたっぽい

こっちでやれ
↓
ＷｉｎのＩＥ６はそろそろ見捨てていいですか？
http://pc11.2ch.net/test/read.cgi/hp/1052099937/

むしろIE8も見捨てたいぐらいだ。

俺は、寧ろHTML5を見捨てたい

じゃあ何があるって言うんだよ？
XHTML2.0なんて規格が先行して誰も実装してないんだぜ。
具体的な実装なしで規格だけ考えても、ろくなことはない。

HTML5は、これまでデファクトスタンダードだった挙動も、規格化しようとしている。
理想的ではないが、現実的だ。

なんつーか、XHTML 2 には夢があったんだよ。
新しい要素がわんさか。
でも HTML 5 はブラウザは今のままでいいよ、って感じだろ。
だから、もう進化しないと思うんだ。

もう進化しない？
どうやってWebがここまで進んできたと思っているんだ。
まずどこかのブラウザが独自拡張を実装する。
その機能が悪くないんで、別のブラウザも、そっくりそのまま実装するか、
よく似た機能を実装する。
同等機能が並立して混乱しているので、規格化される。

という流れの中で進化してきて、その結果、今があるんじゃないか。
実装を離れて規格だけ机上で決めて、うまくいったためしがない。

そもそもモジュール化というのがダメだね。
すべての環境で動かない機能なんて、誰が使うよ。
あるいは使ったとして、動かない環境のことも考慮するわけないだろ。

>>822
その独自拡張の中から最大公約数的なものを選んで規格化したのがHTML5なわけで。
ままでの流れ、つまりXHTML2までだと、とりあえずW3Cがアイデアをまとめて規格化していたんだんだよ。
HTML5は各ブラウザがすでに持っているものを改めて規格化しようという強引な方向。

モジュール化は当然の方向性だと思うし、ひとつの目標。
ウェブブラウザを脱HTMLパーサ化できなかったのはW3Cにとってかなり痛い。

>>823
そのうち成功して広く使われている機能は、すでに先行実装が多数存在した機能だけじゃないか。

>>824
なおさら痛いな。

ここは一度進化をやめて何がまずいのか、過去に立ち戻ってみる時期だ

OSを問わず世界中で使うことが出来るウェブアプリが動く環境が
標準化されつつあるってのはすげーことだと思うんだけどな。

今はGoogleやMSが無料で公開とかやっちゃってるけど、
そのうちiPhoneのみたいな収益モデルができて行くんじゃないすかね。

標準化されつつあるならそりゃある意味すげーよな
Webアプリの何を標準化するのか知らないけど

独自技術を「標準」という名のもとに縛り付けているとしか。

ttp://dev.w3.org/cvsweb/html5/spec/Overview.html

「HTML 5は、プラグインを使わずとも、
動画や音声などをダイナミックに扱えることを目指しており、
Webアプリケーションを開発するためのさまざまな機能が盛り込まれていることが特徴。
ただし、その仕様が膨大なため、W3Cにおける策定はしばらく先と見られている」

ってあったんだけど、そーなの？
とりあえずネタ投下。

ttp://journal.mycom.co.jp/news/2009/07/27/007/index.html

マルチメディアとベクターグラフィクスは
どうせ IE が無視決め込むんだろ。

はやく IE10 出てくれー

>>833
ドラクエ10とどっちが出るのが先か('A`)

>>831
HTML5のVideoタグでニコニコ動画が再現できるかどうか考えてみればいいと思うよ。
ニコニコは結構 Flash の機能を使ってるから、指標として考えてみるのはおもしろい。

　□　load, timeupdate イベントが正しく発生すること。
　□　Video Element 上に canvas を重ねても処理落ちしないこと
　□　Video Element 上に、ボタンコントロールをおけること
　□　特定時間になったら動画を停止して、別の動画をオーバーレイすることができる。

最低でも、timeupdate イベントが全プラットフォームで同一の動作をしないと
Opera と Safari でコメントのタイミングが違うとか言うことになりかねない。

>>835
レスthx!

なるほど、ニコニコかー。
Flash頼りのサイトに一石投じる事になるんだもんね、HTML5は。
・・・ってことは、Flashプラグインって、実はすごい奴だったんだね。
その辺も調べてみるかな。

>>833
IE9はいつの間に出たんだ？

HTML 5アプリケーション開発について議論しよう! HTML5-Developers-jp発足
http://journal.mycom.co.jp/news/2009/07/27/007/index.html

HTML5スレはあるのにCSS3は無い？

よく言われるけど、HTML5　の audio/video や、canvas が、Flash を駆逐するかは、
使いやすいオーサリングツールが出てくるかどうかにかかってる。

たとえば、音楽にタイミングをあわせてアニメーションするような canvas アニメを考えた場合、
audio の load, play, pause, timeupdate イベントにあわせる形で canvas の内容を変化させる必要があるけど、
そういったスクリプトを手で書くのは余程の暇人しかいないだろうから、一般に普及させるには
クロスブラウザ・クロスプラットフォームで動作するオーサリングツールが必要。

HTMLのオーサリングツールって、Adobe の Dreamwaver と、Microsoft の Expression が有名だけど、
両者とも Flash, Silverlight っていう技術があるから、それ以外の会社（IBMとか）が奮闘できるかがカギ

haXeとかが頑張れば割といい線いけるんじゃないかと思う

5年ぐらい前にFlashでやってたこと（インタラクティブ紙芝居とか
凝ったUIとか）は、来年にはHTML5で普通にやるようになるかもね

今Flashバリバリでやってることはを年後HTML5でやるのは無理かもしらん

最初に完全対応を謳うのは Firefox か Safari か IE か。

そもそも仕様として完成できるのかが疑問

HTML5の勧告来年出すってW3Cは言ってるらしいけど、今までの感じを見てると厳しい予感が。
素晴らしい技術をみんなで創るのも大事だけど、
どれだけ速くリリース出来るか、そしてリリースのタイミング、エンドユーザへのアナウンスの仕方が、HTML5を浸透させるには大事な要素だと思う。

一企業の技術に頼っちゃってる構図は、あんまし良くないよね。MS然りFlash然り。
HTML5も普及する事を祈願してsage。

>>842
Chromeはこないかな？
俺的にはChromeが来そうな予感。
現時点の最新ブラウザでの比較だとChromeが一番多くサポート出来てるんじゃなかったっけかな？

>>836
11あたりじゃないと完全対応しない予感

Webkitのサポートが一番早いだろうな
続いてMozillaかOperaかってくらいで

またIEに悶絶することになるんだろうか

法人客が多い会社だと切り捨てが出来ないからね。

なんつーか、HTML5はGoogle社の規格だよね。オープンだけど。Adobeと変わらない。

某所でnavとかarticleとかをセマンティックな要素とか言ってる人がいて違和感を覚えた

HTML5にはセマンティックウェブの考えに基づいた要素・属性は入らないのかな

GRDDLすりゃいーじゃん
HTMLそのものにメタ情報埋めたらソースが汚くなる

つﾏｲｸﾛﾌｫｰﾏｯﾄ

GRDDLは使いたい語彙が一杯あるとき自分専用のXSLT書かなきゃいけなくてめんどくさいし回りくどい
class属性とかをメタデータの記述に使うのはあくまでも苦肉の策だと思う

HTML5はまだ語彙が固まってないんだしRDFaの属性ぐらい用意してくれればいいのになと思っただけ
別にブラウザにメタ情報を使って何かしろとかいうことを強制する訳じゃないんだし

http://dev.w3.org/html5/rdfa/rdfa-module.html
採用されるかはともかくドラフトは出てるんだな

素人にとって、HTML5は難し過ぎるんじゃねえか?
と言うより、名の有る法人がDTD宣言しているにも関わらずに
HTML4.01やXHTML1.0すら遵守してないのに
HTML5が罷り通るとは思えんなあ...

素人はオーサリングソフト使うから大丈夫じゃないの。
ドリームなんとかが対応するでしょ。

いっその事、条約にすればよい

>>844
http://gihyo.jp/design/serial/01/web-standards/0001?page=2

> 2009年4月に3回目の「草案」が公開されました。最終草案は
> 今年10月という話もありますが，まだまだ解決すべき問題も多く，
> このとおりに行くかはわかりません。2010年中の勧告というスケ
> ジュールがありますが，これは現実的ではありません。

だってさ

>>848
HTML5はWHATWGが初出
GoogleはWHATWGのメンバーだけど、Mozilla、Operaと共同でやってるからGoogleの規格というわけではない

RDFaはXHTMLとともにお亡くなりになりましたが。
そんなもんに何を期待してんの？

どう考えても素人が手で書けるわけないし。
書いたつもりでも間違いだらけになるだろう。属性の位置間違えただけで意味変わるんだから。

オーサリングツールが対応するとも思えない。
文書の構造と表したいグラフがちょうど一致していないとうまく埋め込めないとか、使えないにも程がある。

すでに勧告されてるのに亡くなるも何もねーよ
亡くなったのはXHTML2だけだからな

HTML5は別に素人を対象にしてるわけでもないだろ

XHTML2もRDFaも、端的に言えば
官僚的発想の記法・構造だ。エンジニアのそれじゃない。
「〜しなきゃいけない」「〜すべき」で窒息しそうになる。
だからみんなついてこないんだよ。

HTML5とmicroformatは、
ほどよく実利主義的で、ほどよくルーズだ。
「〜できる」「〜したい」って思わせるような枠組。
素人に可読性高いだけじゃなく、
エンジニアやコーダーにもフレンドリーだ。

このご時世にわざわざHTMLかじりたがるような素人なんて無視して良いっしょ

XHTMLはStrict好きな人やブラウザ間の問題などを意識している人には迎合されやすい。
ほどよくルーズなHTMLは、(比較的)多くの人がとっつきやすい。
HTMLを勉強して、その中で問題意識を感じた人はXHTMLにその解決を求めていくのかな(自分がそんな一人)。

ダブルスタンダードって言うんだっけ？二重基準的なやつ。
厳密に定義した文法を核にして、ほどよくルーズな文法を包み込むように定義するとか出来ないのかな？
てか、それはHTML4.01とかXHTML1.0のTransitionalとStrictと同じような構図になっちゃうのかな。

HTMLに関しては、今のダブルスタンダードと同じように
これからもHTML5+XHTML2の二本立てで進めて行くのが
実は最適解なんじゃないだろうか

いや、普通にXHTML5でいいんじゃないの
XHTML2はもうobsoleteでしょ、死産だよあれは

XHTML2は理想は高かったんだがそれとは別に色々要らん要素も増やしてたからなー
でもh要素と@roleと@xml:idモジュールはXHTML5に組み込んでほしい

>>866
RoleモジュールはHTML WGがひきとって策定続けるかも、という話があったからHTML5に組み込まれる可能性は残ってる・・・かも

>>858見たいな事書いてるblogがたくさんあって笑える
知ったか大杉だろ

どの点を差して知ったかと言っているのか
正してもらえると良いと思うんだがどうか

すんません
俺が知ったかでした

lll/lllllllllllll!　ll!　　/‐':ｰ'―:'^ｰ､/Lﾄ､l/::|l i　i　　　'　!
/lllllllllllll!　　　　 l::::::::　'´￣｀`丶、::::::::'!!Lﾉﾊ　　　 |
lllllllllllllll!i　 i 　 i !::::　 , ―- ､、　　　　　　 :'^ヽ! 　 |
lll`llll!ﾊﾄ+-ﾇi､;'l」―-/　　　　 ＼　　　　 ' ￣ヽ ﾄ､ |　　　見たまえ！
lllllllllll!:ヽ::::(:lj:::::::::::::::'、 　 　 　 /､_ , ‐- ､_○ / }, l!　　　　RDFaがまるでゴミのようだ！！
lllllllllll＼ ::　: :::::::::::　 ｀ ' ‐-- ' ::::::/　　　　）,ｲ / /lll
lllllllllllllllll｀~ﾄ:::::::::::　　　　　　 　 , ,丶、__／/llj/ /lllll
-､lllllll､ｯ‐ﾂ ヽ:::: 　 　 卞ﾆ_ｰ-- ､_ ､　　 /lllllレ'lllOl
　::､::::ヽ::::＼::::、　　　　＼ ｀ヽ ／~ '　　,'lllllllllllllllllll｡
　　|　　ヽ　 ＼＼　　　 　 `ｰ '　　　 ／lllllllllllllllllllllll
　　|　　　＼　::＼＼　○　｀"o　 ,. '´olllllllllllllllllllllllO
　　|　　　　 ヽ　 ...　｀ﾝー--― '´llllllllllllllllllllllllllllllllllll

僕が知ったかでした。
もうしません。
許してください。

今のところどれに準拠してればHTML5に移行しやすいの？

どれに準拠してれば、かぁ。
HTML4.01StrictとXHTML1.1とだったら、HTML4.01の方じゃないかな？
勉強中だから確かな事言えなくて、個人的な感覚だけど。

HTML4.01からHTML5で廃止される要素があるから、その辺りを押さえておけば、
その代替策も考えやすいし、移行しやすいんじゃ？
「HTML5　廃止　要素」みたいな感じでググると良い事あるかもよ。

廃止要素もブラウザはサポートし続けるだろうから、廃止かどうかなん
て関係ないよな。

携帯でのキャリア別の出力みたいに
CSSやJavascriptの振り分けどころかマークアップもIE向けとそれ以外向け等
複数の規格で出力しないといけなくなりそうな
コンテンツさえしっかり作っとけばガワは移行とか使い回しとか考慮しなくてもよさそうな考慮できなさそうな

>>874
XHTML 1.1から(X)HTML5の方が楽そうに思えるような思えないような。

＞XHTML1.1から(X)HTML5
rubyの複雑構文と文書型定義さえ書き直せば互換だろ

MathMLが使いたいけどXHTML5+MathMLってブラウザにサポートされるのかな
現状でもFirefoxとAmayaくらいしかサポートしてないから絶望的か

object要素使えよw

object使うなら素直にHTML5使うわｗ

4.8.15 MathML

The math element from the MathML namespace falls into the embedded
content category for the purposes of the content models in this specification.

User agents must handle text other than inter-element whitespace found in
MathML elements whose content models do not allow raw text by pretending
for the purposes of MathML content models, layout, and rendering that
that text is actually wrapped in an mtext element in the MathML namespace.
(Such text is not, however, conforming.)

User agents must act as if any MathML element whose contents does not
match the element's content model was replaced, for the purposes of MathML layout
and rendering, by an merror element in the MathML namespace containing some appropriate error message.

To enable authors to use MathML tools that only accept MathML in its XML form,
interactive HTML user agents are encouraged to provide a way to export any
MathML fragment as a namespace-well-formed XML fragment.

>>879見て初めてamaya知った。
W3Cが作ってるんだね。

>>874
ググったらこのスレが最初にヒットした

このデモがすごい

HTML5 Canvas and Audio Experiment
http://9elements.com/io/projects/html5/canvas/

Processingか

『Google、動画圧縮技術のOn2を約1億ドルで買収』(INTERNET Watch)
ttp://internet.watch.impress.co.jp/docs/news/20090806_307426.html

これってHTML5に向けた買収ってことになりそうだよね？

VP6、VP7、VP8とかクソだし。

つか、なんで標準押しつけてくるのに、縦書きを標準に取り込まないんだ。

きちがい集団のブラウザ対応なんぞするなよ。

CSSで取り込んでますけど

取り込んでないよ。

縦書きCSSについて
http://www.dinf.ne.jp/doc/japanese/access/daisy/report/g-daisy/css/vertical.html

まあプレゼンテーションレイヤだからCSS側の仕事だろう、JK

ttp://momdo.s35.xrea.com/web-html-test/vertical-text/index.html

正式仕様としてみとめられてないないから取り込まれてるとは
いえないな。

何でお前らは実際のCSSドラフトじゃなくて、何処の馬の骨とも分からん奴の個人サイト挙げてるんだ？
文盲か？

Summerだからさ。

夏だとなんかあんの？

個人サイトでも内容があってればいいんじゃないの

CSSに限らずW3Cのworking draftは基本的にスナップショットなので
それだけ読んでも経緯も方向性もわかんない。

ttp://standards.mitsue.co.jp/resources/mm_comic/

XHTMLはまだ終わってねぇ！

XHTMLの前に人の顔の描き方を学ぶべきだと思う。
今にも死にそうな顔しとるぞ。

絵では何も説明してないからコミックにする意味が一切無いな

HTML5は飲むヨーグルト、XHTML5はヨーグルトにした方がわかりやすいかも
<!--いいえ、ケフィアです-->

MS、HTML 5仕様策定に本格着手
http://japan.cnet.com/news/media/story/0,2000056023,20398117,00.htm?ref=rss

【レポート】HTML5を今日のブラウザで使う - Operaのエバンゲリストが実験 | ネット | マイコミジャーナル
http://journal.mycom.co.jp/articles/2009/08/18/html5/index.html

XHTML2.0の策定にモタモタ何年もかけすぎなんだよ

いや、だからXHTML2.0は失敗する運命の企画だったんだって。
ブラウザベンダは参加してなかったし。>>899見てみ。

HTML5リンク集
http://q.hatena.ne.jp/1250704513

HTML5ってbig要素は廃止なのにsmall要素は存続なのか
基準が分からん

smallには本文にはあまり関係ないメモ的(?)な文章に囲むって
使い方があった気がする

それにsmallという名称が相応しいとも思えない

物理要素じゃん。

>>908-911

言うならば「note」か?

「注釈」の英訳って、どうなの?

注釈なら@role="note"でいいんじゃないの

ぶっちゃけ、div(またはp)とspan(やb,i等)だけで良いと思うんだがな
nameかこれに変わるプロパティで役割を定義させればさ

>>914
> ぶっちゃけ、div(またはp)とspan(やb,i等)だけで良いと思うんだがな
> nameかこれに変わるプロパティで役割を定義させればさ

それはXHTML的な発想
WHATWGはHTML4的な要素と記法を復古させたがってたわけ

マシンリーダビリティと構造的な美しさよりも
人間の可読性とハンドコーディングの容易さを優先

「名称が相応しい」を突き詰めすぎるとXHTML2みたいになっちゃうよ！

di要素はすごく便利そうなのになー
css書いてるときに思うことだから文章構造的には不要なんだろうけど

>>914
サーチエンジンが把握し易くなるみたいよ。
例えばブログで、「article」を参考にインデックスして
「aside」とか無視すると綺麗でしょ？
でもこれだけだとmetaタグのkeywordsみたいに乱用されることが予想されるから
当てにはならないかもしれないけどね。

>>918
そういう使い方だったらmicroformatで十分だけどな

>>918
ロボットはその時代に使われているフォーマットを読むように作られる訳で
"特定のTagを読み飛ばす"のと"特定のPropertyを読み飛ばす"のは変わらないと思うが

わざわざ検索エンジンのためだけにarticleやasideを乱用する奴がいるか？
いや、いそうだな…

適切なマークアップはSEO的に有利って考え方は
正しいかどうかは別として既に十分広まっているかと

グーグル先生が適切なアルゴリズムさえ考えてくれればSEO的に引っ張られて自然と普及しそう

>>914
>>433

HTMLとして文章を表現する方法は"ブロック要素"と"インライン要素"があれば往々にして事足りる訳だよ
(ここでは動画とかMultimediaファイルの扱いには言及しないが)

そこで、作っては廃止される要素なんか追加するよりも、
要素名自体を絞った上で意味を付け足す方が生産性が高いだろうと思うのさ
(無数の変数名を与えられると殆ど使わないものが出てくるが、一つの連想配列が使えればスッキリ)

今ある材料だけでは材料不足ではあるし、構造の視認性・editのしにくさは生まれる様だけど
>>433のサイトを見る限り問題はそれ程大きくはない訳だし

使いたければ使う、使いたくなければ使わないという方向で。

>>925
それrole属性じゃね？

>>925
>一つの連想配列が使えればスッキリ
昔、ありとあらゆる要素をdivにしてclassの違いのみで制御する
っていうジョークを何かで見たなぁ

article, aside, footer, header, nav, sectionの順番はどのようにしてますか？
仕様によると順番はどうでもいいみたいですが、CSSに影響しますよね。

>>907に上がってるページは、sectionを除くと綺麗に
header, nav, article, aside, footerの順番で使われてますので、
何か理由があるのかなと思ったり思わなかったり。

>>929
すごく奇妙な質問だなあ。
「tableとpの順番はどのようにしていますか？」と同じくらい変。

常識で考えて先頭に header、末尾に footer だろうけど、
あとは場合によりけりでしょ。

・今では神話化しつつあるかもしれないがSEO的にはページの先頭ほど
　重要コンテンツがあるというのがお約束
・CSSではhtmlコードの流れとは逆に左・右に要素を並べるのは容易だけど
　上・下の関係をひっくり返すのはpositionバリバリに使わなきゃいけなくて
　調整が辛い

というわけで，ヘッダ・ナビ・サブナビ・コンテンツ・フッタで構成される
一般的なWebを作ろうとすると，自然と

header > nav > article > aside > footer

という流れになるのだと思われ。articleとasideはfloat次第でどうとでも
なるのだけど，重要度から言ってarticleを前にする，ということかと。

かつてのWHATWG自体，これらの決め打ち系タグをあえて定義することで
そうしたフォーマットのWebサイトを増やすことを意識してるような気もした。
XHTMLとは違った意味でのマシンリーダビリティ＆セマンティクスっつーのかな。

articleって要素が用意された時点で
コンテンツを上に持ってくるっていう一部で流行っていた旧来の方法は必要なくなったんでない

コンテンツを上に持ってくるのは、モバイル環境やCSSをオフにした環境では
メニューが本文の前に長々と並んで読みにくくなるのを防ぐため、という理由もある

html5でもこの事情は変わらないだろうから相変わらず並び順は重要かと

header、navタグにcssを使うと一部のプロパティーしか適用されないんですが、
どういう意図があるのでしょうか。

ちなみにfirefox3.5,chrome3で確認してます。
他の要素に関しては問題はないみたいです。

あの･･･初心者の初心者で申し訳ないのですが、テーブルを無料のHTMLを
ダウソしたのですがテーブルの中に文字を入れたい場合はどこに文字を書けば
フレームの中に入るのでしょうか?
<div style="margin:0px;padding:0px;"
align="center"><table width="98%"style="border-collapse:
collapse;border:5px dotted #FFB533;background-color:#FFD1E4;color:#000000;text-align:left;"><tbody><tr><td style="border:5px dotted #FFB533;"> </td></tr></tbody></table></div>

<CAPTION ALIGN="">

>>935
<td>と</td>の間。
あと一応言っておくとスレ違いです。初心者スレとか探してね。

>>934
FirefoxもChrome3も header/navには対応していないので、
意図なんてないと思われ。
Chrome4だとnavだけ対応しているみたい。

>>934
効くプロパティって何？

次からはスレタイがHTML5 Pert2とかになるから
HTMLスレのパート５と間違える人はいなくなるかな

きっと根絶出来ない

HTMLページ内にYouTube埋め込み動画の中央(横長のブロックを重ねたい) に
　　<div>あいうえお</div>　
というブロック要素を表示しようと

<div style="z-index:20:">あいうえお</div>
<div style="z-index:10">(１）：YouTubeタグ</div>
　　　※ <object width="425" height="344"></object>　・・・・(１）

(　YouTubeの動画エリアの上に<div>ブロックが重なる様にposition absoluteの表示は
　style部分に入れていますが、略しています。）

として、z-indexも指定しここでは「あいうえお」の部分がYouTubeの表示エリア(ブロック)
よりも手前に表示されるハズなのですが、なぜかYouTubeタグの方が手前に表示されてしまいます。
一体どうすればＹｏｕＴｕｂｅよりも手前にブロックを表示(被せて)する事が出来ますか？

【WHATWG】HTML5 Part2【W3C HTML WG】
みたいな怪しげな名前にしとけば↑のようなレスは無いと思

天才かお前は

それはいいかもw

IE8はHTML5対応してないんだね。
仮に来年HTML5が正式に勧告されたとして、
HTML5が標準対応されるのは次バージョンからになるのかな？
それともIE8の自動更新かなにかで対応してくれるのかな？

どんな些細な事でもメジャーバージョン上げてくるのがM$

MSは勧告されれば対応すると明言しているけど、来年勧告されるかどうかも怪しい。

>>945
XMLHttpRequestは対応してるじゃんｗ

てかHTML5に対応するって表現が曖昧すぎてなんともかんとも

なんで急にXHRの話が出てくるんだ？

曖昧かな？
新しい要素を理解してちゃんと動作・表示してくれることだと思うけど。

要するにHTML5で一個書けばFFでもSafariでもIEでも同じく動いてくれればそれでいい。

application/xhtml+xmlを理解していないIEはXHTML1.1に対応しているのかいないのか
HTML5でもたとえばabbrみたいなのだけがたったひとつ対応できてない等があった場合
それは対応しているのかしていないのか
完　全　対　応　！
だけを「対応している」と言えるのか
…って話かな

>>950
そしてコーデックの違いや、HTMLMediaElement イベントの細かな違いに悩まされるわけですね。

>>952
そこはキチっと決めていただける。と信じております。いやマジで頼むわー

このとき、のがれ様のない絶望感を味わうことになろうとはWebデザイナーたちは知る由もなかった・・・

HTML5が一般に普及する頃にはIEはバージョン10くらいになってたりして。

モジュール化してたら
どこまで対応した、とかわかりやすかった？

>>955
だいぶ前にも言われて棚11くらいじゃないと無理とかなんとか

IEは完全対応は無理だろ
application/xhtml+xmlで配信されたHTML5を弾くだろうからなw

XHTMLとは何だったのか。
どうせDOMで操作するんだから、HTMLだけ利用できればいいんじゃね？

それは、世にvalidなHTML5だけが存在する場合は正しい意見だが
not validなHTML5が溢れるだろうことを考えると、
クロスブラウザ対策の観点から、厳密さを保てる構文もあった方がいいのだよ

まあIEが対応しない以上はクロスブラウザもへったくれもないけど

>>960
NOT VALID な HTML を書く人がはたしてXHTMLなんか書くだろうか。
自動出力ならハナからVALIDだろうしな。

>>961
XML形式ではないvalidなHTML5を出力するのは面倒くさいぞ
自動出力ならXHTML形式だろjk

面倒くさいもなにも、XHTML5としてvalidな内容だったら
大抵はHTML5でもvalidにならね？
逆は無理だけど

ならない。
なぜならXML形式のHTML5はapplication/xhtml+xmlで配信しないといけないから。

内容の話ね
そりゃContent-typeやXML宣言は直さなきゃならんさ

googleのmapやadsenseがdocument.write使ってるために活用できないからapplication/xhtml+xmlは普及しないよ

xhtmlにするメリットが見当たらないものね
xmlパーサ使って何かする時くらいか。xsltとか。

あとGRDDLやE4Xも使える

E4XはDOMと独立してるし関係なくね？

は？　独立してたらどうして関係ないんだ。
XHTML形式ならE4Xで楽にDOMと同じことができるじゃん
火狐しか対応してないけど

いや、関係ないでしょ。

俺ンところのウェブサイトを利用したいんなら俺ンところのブラウザを使いなさい
と巨大なASPをやってる検索屋さんのための規格
狐にも餌付けをして手懐けている

html5とcanvasとwebGLの普及が見えてきた
あとはストリーミングがあればwebブラウザでMMOとか出来てしまいそうだ

Quakeもブラウザで出来る時代だしな

試しにエロゲでも作ってみるか。

エロでhtml5の普及促進脱IE

>>970
DOM⇔E4Xの変換はそんなに簡単じゃない
なんで両者が別物になってるのか謎だけどな

>>977
DOMをE4Xで置き換えるのが楽って言ってるわけじゃなくて
DOMと同じ処理がE4Xで楽に出来ると言っているんだが……

まあいいや。それに>>971には根本的な話が通じなかったようだし

>>978
現在ブラウザで開いているDOMを編集するんじゃなくて
外部からxmlhttprequst

途中で書き込んでしまった

>>978
現在ブラウザで開いているDOMを編集するんじゃなくて
外部からxmlhttprequstで取得したXHTML文書をパースするってのならたしかにXHTMLじゃないと無理だな

なぜvideoタグの標準コーディックなんてことで揉めるのさ
普通のメディアプレイヤーと同じように外部のコーディックに頼ればいいじゃないか