【野望の】XHTML 2.0【王国】

XHTML 2.0 について語りましょう。
良さげな案があれば、W3C に提案することも視野に入れて。

[最新版] http://www.w3.org/TR/xhtml2/
[2002-08-05 草案] http://www.w3.org/TR/2002/WD-xhtml2-20020805/

他参考文献・スレなど >>2-5 辺り。

2ch 関連スレ
　Strict-HTML スレ　http://pc3.2ch.net/test/read.cgi/hp/1022751972/l50

W3C 勧告
　XML 1.0　http://www.w3.org/TR/REC-xml
　Namespace in XML　http://www.w3.org/TR/REC-xml-names/
　XLink 1.0　http://www.w3.org/TR/xlink/

　HTML 4.01　http://www.w3.org/TR/html4/
　XHTML 1.0　http://www.w3.org/TR/xhtml1/
　Ruby Annotation　http://www.w3.org/TR/2001/REC-ruby-20010531/
　Modularization of XHTML　http://www.w3.org/TR/xhtml-modularization/
　XHTML Basic　http://www.w3.org/TR/xhtml-basic/
　XHTML 1.1　http://www.w3.org/TR/xhtml11/

　MathML 2.0　http://www.w3.org/TR/MathML2/
　SVG 1.0　http://www.w3.org/TR/SVG/

W3C 草案/勧告案/勧告候補
　XHTML ロードマップ　http://www.w3.org/MarkUp/xhtml-roadmap/

　XML 1.1　http://www.w3.org/TR/xml11/
　Namespace in XML 1.1　http://www.w3.org/TR/xml-names11/
　XML Events　http://www.w3.org/TR/xml-events/
　XForms 1.0　http://www.w3.org/TR/xforms/
　XFrames　http://www.w3.org/TR/xframes/

　XHTML + MathML + SVG　www.w3.org/TR/XHTMLplusMathMLplusSVG/
　SVG 1.1　http://www.w3.org/TR/SVG11/

W3C ノート
　XHTML Media Types　http://www.w3.org/TR/xhtml-media-types/

W3C メーリングリスト
　XHTML 2.0 の仕様書のエラーは www-html-editor@w3.org へ報告しる
　(過去ログは http://lists.w3.org/Archives/Public/www-html-editor/ )
　XHTML 2.0 についての意見は www-html-request@w3.org へ投稿しる

>>1
全部英語サイトか・・・・・・・・・・・・・・・・・・・・・

>>4
そんなあなたに。
http://www.w3.org/Consortium/Translation/Japanese
http://www.doraneko.org/sitemap.html

XHTML 2.0 in RELAX NG (非公式)
http://www.w3.org/People/mimasa/test/schemas/rng/xhtml2.rng

>>6
　 　 　 　 　 　 　 　 　 ∩
　 　 　 　 　 　 　 　 　 | |
　 　 　 　 　 　 　 　 　 | |
　 　　 　 　 ∧＿∧ 　 | |　　　／￣￣￣￣￣￣￣￣￣
　 　　　 　 （ ; ´Д｀）/./　＜　みまさ先生! pre に sup はどうかと思います!
　 　 　　 ／ 　 　 　 ／　　　 ＼＿＿＿＿＿＿＿＿＿_
　　 　 / /|　　　　/
　＿＿| | .|　　　　|
　.＼　 ￣￣￣￣￣￣￣＼
　 　||＼ 　　 　 　 　 　 　 　 ＼
　 　||＼||￣￣￣￣￣￣￣||￣
　 　||　 ||￣￣￣￣￣￣￣||
　 　|| 　||　 　 　 　 　 　 　

　 　 　 　 　 　 　 　 　 ∩
　 　 　 　 　 　 　 　 　 | |
　 　 　 　 　 　 　 　 　 | |
　 　　 　 　 ∧＿∧ 　 | |　　　／￣￣￣￣￣￣￣￣￣
　 　　　 　 （ ; ´Д｀）/./　＜　先生! このスレ終了します。
　 　 　　 ／ 　 　 　 ／　　　 ＼＿＿＿＿＿＿＿＿＿_
　　 　 / /|　　　　/
　＿＿| | .|　　　　|
　.＼　 ￣￣￣￣￣￣￣＼
　 　||＼ 　　 　 　 　 　 　 　 ＼
　 　||＼||￣￣￣￣￣￣￣||￣
　 　||　 ||￣￣￣￣￣￣￣||

>>5
ありがとう

でマジな話、マークアップを変えれば何か便利になるのか？

いいからビルダーでも使っててください.

あのこ良さげー

svgみたくxlinkつかうのだ。
svgみたく<metadata><rdf:RDF>〜</rdf:RDF></metadata>とか。
addressだのnlなんてheadに入れちまえ。

>>13
激しく同意ですこの野郎。

　

　 　 　 　 　 　 　 　 　 ∩
　 　 　 　 　 　 　 　 　 | |
　 　 　 　 　 　 　 　 　 | |
　 　　 　 　 ∧＿∧ 　 | |　　　／￣￣￣￣￣￣￣￣￣
　 　　　 　 （ ; ´Д｀）/./　＜　先生!XHTML2.0っていつでますか!
　 　 　　 ／ 　 　 　 ／　　　 ＼＿＿＿＿＿＿＿＿＿_
　　 　 / /|　　　　/
　＿＿| | .|　　　　|
　.＼　 ￣￣￣￣￣￣￣＼
　 　||＼ 　　 　 　 　 　 　 　 ＼
　 　||＼||￣￣￣￣￣￣￣||￣
　 　||　 ||￣￣￣￣￣￣￣||

>>16
Recommendationのことか？
なら、今までの例からすると、大体1stWDから一年強くらいだったような…

と、マジレスだか何だかよく分からんレスを付けてみるテスト。

>>17
スマソ、ちと嘘だった。
最近の傾向だとどーもステップが一つ進むのにえらく時間がかかっているですな。
もっとも、こんなスレにくる面子はその辺のことは重々承知だろうが…

念の為に参考URI
http://www.w3.org/MarkUp/xhtml-roadmap/

フライング実装してるサイトを探せ。

line:before {
position: relative;
left: -1em;
}

こんなミスばかりが目立つ。

>>19
隊長！ﾊｹｰﾝしました。

http://diary.noasobi.net/

>>21
application/xhtml+xml じゃないじゃん。

tp://hms.vis.ne.jp/zhizhi/

ここもapplication/xhtml+xmlではない。

発見というより自己報告ですか？
nlも使ってよ木違いさーん！

http://members.tripod.co.jp/monar01/

を上から順にBuffalo Loveまで見てみますたが
２３のﾔｼしかﾊｹｰﾝできませんですた。
だれか続きおながいしますた。

XHTML1.0ですらろくに普及してないのに

>>26
おまえには無理

（´-`）.｡oO(http://www.w3.org/TR/xhtml2/DTD/xhtml2.dtdが見つからない…)

>>28
そもそもまだない。

IEが対応するのはいつ？

>>28
RELAX NG 版で概要を掴め。

あれだよ、もっと思いきって
MathMLみたいに意味の要素とプレゼンテーションの要素にわけて
意味の要素使うときはXSLT使うことを前提にするとか

だれも続きやってくらないので自分でやりますた。
上から# masa0822's roomまで。
飽きたので下からやることにして、こっちは# bh　=Adventure Game Laboratory=まで。






ものの見事に皆無ですた。
http://katsuno.cool.ne.jp/　のウコン話が唯一の収穫。

せっかくＷＤなったのだから早めに実装おながいします。
(オレモナー。)

早漏めッ

>カレー独特のあの色はウコンの色なのです．

萎え。

ばか！
うこんは精力のみなもと！！

お前ら紛らわしいこと書くなや（ｗ

誰も続きやってくれないので自分で残りもやりますた。


結果ですが、新たなXHTML2.0フライング実装サイトはﾊｹｰﾝされませんですた。
みんなもっとフライングして下すい。

しなくてもいいじゃん
他に話題ないのね？

2.0 になったらimg要素がなくなるって本当ですか?

>>40
object要素に統一する方向で進んでるようだね。

そうなるとIE5.5は逝ってよしだな

>>42
IE6も逝ってよし。
特定要素の対応以前に、application/xhtml+xmlを処理できない。
XHTML2 を text/html にはできんだろ、いくらなんでも。

いや、text/html用のUAに配慮してあればいいんじゃない？

要するに、新規な要素のタグ等は全部不明なものとして
無視してレンダリングしても、文書としての意味が伝わる
ものになっていれば。

あと、objectで画像表示する件についても、UAの対応ぶりは
ともかく、以前から指定は可能だったのだから、これを
理由にtext/html失格ってこともないと思われ。

> 要するに、新規な要素のタグ等は全部不明なものとして
> 無視してレンダリングしても、文書としての意味が伝わる
> ものになっていれば。
HTML非互換の要素・属性を使用するなら、その時点でtext/html失格。
UAのエラー処理に期待する不正文書の仲間入り。
運用上の良し悪しは制作者がそれぞれ決めることなので
「今んとこ全てのUAで表示できてるからいい」という判断も有りだとは思うが。

HTML4で追加された要素・属性を使用した文書は
（HTML3.2時代の）text/html失格ですか？

>>46
当時としては失格でしょ。
その時代のtext/htmlの仕様で定義されていない形式であることを指して
俺は「失格」という言葉を使っている。
46 の言う「失格」はどういうこと？

>>47

text/htmlというMIMEタイプ自体に『仕様』も何も
ないでしょ。

そう仕様

>>48
RFC1866: Hypertext Markup Language - 2.0
http://ftp.ics.uci.edu/pub/ietf/html/rfc1866.txt
> The "text/html" Internet Media Type (RFC 1590) and MIME Content Type
> (RFC 1521) is defined by this specification.

RFC2845: The 'text/html' Media Type
http://www.rfc-editor.org/rfc/rfc2854.txt
> Published specification:
> The text/html media type is now defined by W3C Recommendations;
> the latest published version is [HTML401]. In addition, [XHTML1]
> defines a profile of use of XHTML which is compatible with HTML
> 4.01 and which may also be labeled as text/html.

>>50

その定義によりますと、XHTML2を云々する以前に、
XHTML1であってもHTML4.01と互換でない限りは
text/htmlは名乗れないことになりますね。

<img src="hoge.gif" width="64" height="64 alt="hoge"/>
とか書いたらtext/htmlではないという話に…。

あたりまえ。XHTML1はtext/htmlを更新するものではない。
http://www.w3.org/TR/2002/REC-xhtml1-20020801/#guidelines
> This appendix summarizes design guidelines for authors who wish their
> XHTML documents to render on existing HTML user agents. Note that this
> recommendation does not define how HTML conforming user agents should
> process HTML documents. Nor does it define the meaning of the Internet
> Media Type text/html. For these definitions, see [HTML4] and [RFC2854]
> respectively.

# 繰り返すけど、運用上の是非に口出す気はないよ。

>>51
> その定義によりますと、XHTML2を云々する以前に、
> XHTML1であってもHTML4.01と互換でない限りは
> text/htmlは名乗れないことになりますね。

現に SHOULD NOT と言われてまさあ
ttp://www.w3.org/TR/xhtml-media-types/xhtml-media-types.html#summary

application/xhtml+xmlが新設されるより前、
XHTML1.0のMIMEタイプは何であるべきだったの
だろう？

application/xmlかな？

>>54
SHOULD としては何も定義されてなかったと思う。
http://www.w3.org/TR/2000/REC-xhtml1-20000126/#media

参考:
http://www.w3.org/TR/1999/WD-html-in-xml-19990304/#media

てことは、XMLアプリケーションなのでXMLとして
扱うしかなかったってことね。
これまでXHTML1.0〜1.1をtext/htmlとして公開してた
サイトは全部インチキだったってことで。

なに、つまり
text/xml
つーことか？

>>56
じゃあXHTML1.0仕様書の後方互換性ガイドラインは何の為にあったんだよ

全部インチキは言い過ぎだと思うけど。
ガイドラインに従ってHTML4と互換性を持たせたXHTML1文書は
text/htmlにしてもよい(MAY)、と初版からなっていた。
# 関連仕様の整備を待たなければならない事例はいくらでもある。
# JavaScript の MIME なんか未だに棚上げ。

>>58
既存のHTML専用UA上でのレンダリングをXHTML文書に望む著者のために。

XHTML1.0は後方互換重視。
XHTML1.1は比較的XML寄り。

XML寄りっていうかXHTMLはすべてれっきとしたXML文書だよ。正しく書いてある限り

http://lists.w3.org/Archives/Public/www-html/2002Aug/thread.html
面白そうなんだが...誰か俺に英語読解力を下さい。

>>59
HTML4.01では空要素だったmetaやimgなどで
終了タグ書く時点で、もはや互換性は取れていない。

>>45
>UAのエラー処理に期待する不正文書の仲間入り。

これも引用しとこう。

>>63
<img 〜 />という形式なら大丈夫なのでは。

http://www.ne.jp/asahi/minazuki/bakera/html/sgml/shorttag

>>63
その点で互換性が取れていないというのはその通りだが
仕様で MAY と言ってるものをつべこべ言ってもねえ。

>>65

大丈夫、というのはUAがレンダリングしてくれる
というだけの話で、HTML4.01に存在しないはずの終了タグが
(省略形であれ)書かれている時点でHTML4.01では
不正文書であることにはかわりない。

結局、45の指摘に戻るわけ。

＞UAのエラー処理に期待する不正文書の仲間入り。

　　　　　　　　　　　　　　　　　　　　　　　　　　　 ,,.-‐''""""'''ー-.､
　　　　　　　　　　　　　　　　　　　　　　　　　　,ｨ"　　　　　　　　　 ＼
　　　　　　　　　　　　　　　　　　　　　　 　 　 /　　　　　　　　　 　 　 `､
　　　　　　　　　　　　　　　　　　　　　　　 　 ,i　　　　　　　　　　　　　　i 　なんだい？兄弟
　　　　　　　　　　　　　　　 ⊂二￣⌒＼　 r'-=ﾆ;'_ー-､___,,.ｨ‐‐-,,_　　__|　　　　 　 ノ）
　　　　　　　　　　　　　　　　　　 ）＼　　（　| r,i　　　~`'ー-l;l : : : `l-r'"ﾒ､　　　　／　＼
　　　　　　　　　　　　　　　　　／＿＿　　）ヾ､ 　　　　　　　`ー‐'": i!_,l_ノ`　　／ ／＾＼)
　　　　　　　　　　　　　　　　/／／／　／　　|　　　　　　　　 ,:(,..､ ;:|/ ⌒￣＿／
　　　　　　　　　　　　　　　/ / / ／／　　　　|　　　　　　　　,,,..;:;:;:;,/　￣￣
　　　　　　　　　　　　　　/ / / (／　　　　　　＼　`::;;.　　　'"`ﾆ二ｿ＿＿＿
　　　　　　　　　　　　　　（（／　　　　　　　　　　>　ﾞﾞ:`-､;:;:;;;:;:;:;;/　　 ＿　　）
　　　　　　　　　　　　　　　　　　　　　　　　　　/　　／￣　　　　　￣　/　／
　　　　　　　　　　　　　　　　　　　　　　　　　/　 ／　　　　　　　　　/　／
　　　　　　　　　　　　　　　　　　　　　　　／　／　　　　　　　　　（　　/
　　　　　　　　　　　　　　　　　　　　　　/　／　　　　　　　　　　　 ） /
　　　　　　　　　　　　　　　　　　　　／ ／　　　　　　　　　　　　　し′
　　　　　　　　　　　　　　　　　　（　　/
　　　　　　　　　　　　　　　　　　　） /
　　　　　　　　　　　　　　　　　　　し′
　　　　　　　　　　　　　　　　　　　　　　　　　　　 ,,.-‐''""""'''ー-.､
　　　　　　　　　　　　　　　　　　　　　　　　　　,ｨ"　　　　　　　　　 ＼
　　　　　　　　　　　　　　　　　　　　　　 　 　 /　　　　　　　　　 　 　 `､
　　　　　　　　　　　　　　　　　　　　　　　 　 ,i　　　　　　　　　　　　　　i 　なんだい？兄弟
　　　　　　　　　　　　　　　 ⊂二￣⌒＼　 r'-=ﾆ;'_ー-､___,,.ｨ‐‐-,,_　　__|　　　　 　 ノ）
　　　　　　　　　　　　　　　　　　 ）＼　　（　| r,i　　　~`'ー-l;l : : : `l-r'"ﾒ､　　　　／　＼
　　　　　　　　　　　　　　　　　／＿＿　　）ヾ､ 　　　　　　　`ー‐'": i!_,l_ノ`　　／ ／＾＼)
　　　　　　　　　　　　　　　　/／／／　／　　|　　　　　　　　 ,:(,..､ ;:|/ ⌒￣＿／
　　　　　　　　　　　　　　　/ / / ／／　　　　|　　　　　　　　,,,..;:;:;:;,/　￣￣
　　　　　　　　　　　　　　/ / / (／　　　　　　＼　`::;;.　　　'"`ﾆ二ｿ＿＿＿
　　　　　　　　　　　　　　（（／　　　　　　　　　　>　ﾞﾞ:`-､;:;:;;;:;:;:;;/　　 ＿　　）
　　　　　　　　　　　　　　　　　　　　　　　　　　/　　／￣　　　　　￣　/　／
　　　　　　　　　　　　　　　　　　　　　　　　　/　 ／　　　　　　　　　/　／
　　　　　　　　　　　　　　　　　　　　　　　／　／　　　　　　　　　（　　/
　　　　　　　　　　　　　　　　　　　　　　/　／　　　　　　　　　　　 ） /
　　　　　　　　　　　　　　　　　　　　／ ／　　　　　　　　　　　　　し′
　　　　　　　　　　　　　　　　　　（　　/
　　　　　　　　　　　　　　　　　　　） /
　　　　　　　　　　　　　　　　　　　し′

>>66

仕様書でMAYと言っているのはHTML4と互換性を
持たせたXHTML1文書の話。

しかし、ガイドラインに従っても互換性を持たせる
ことが出来なければ、結局それを適用する事が
できない。

慶応にでも入ってつべこべ言えばいいじゃん。

苦情は>>45へ

>>69
MAY の主語は「Appencix C "HTML互換ガイドライン" に従った XHTML 文書」。
> しかし、ガイドラインに従っても互換性を持たせる
> ことが出来なければ、
従ってりゃ MAY ですよ。

http://math.oheya.to/markup/TR/xhtml-media-types-1#text-html

XHTML1についての互換性ガイドラインをRFC2845が
承認している訳ではない以上、無意味なのでは？

XHTML1の話題はどうでもいいよ、このスレでは。

>>74
>>50 [RFC2854]の引用部の訳:
「出版された仕様:
text/htmlメディアタイプは現在はW3Cによって定義されている: 最新版は[HTML4.01]である。加えて、HTML4.01と互換性がありtext/htmlとラベルしてもよいXHTML使用のprofileを[XHTML1]は定義している。」
この"profile"が"C. HTML Compatibility Guidelines"のことでないと言うなら、どれだよ？

>>76

そのprofileに従うとは書かれていないでしょ。

text/htmlはW3Cが定義している、としているのに
text/htmlとラベルしてもよい、とW3Cが定義したprofileを
RFCは認めないわけか。
じゃあHTML4についても怪しいものだな。それに従うとは書いてないから。

XHTMLからa要素が廃止されるのはいつかな……？
……再来年くらい？（藁）

>>79
そもそもa要素廃止の方向でいるかどうかが疑問だ…

XLinkが完全に実用化されればa要素は用済みじゃないの？

XLinkが完全に実用化されればXHTML自体が用済みになりかねない罠。

>>82
いや、一応マークアップ言語として必要だろう。

>>83
や、論文や文学に特化した文書型は他にも存在するわけで
中途半端なだけのマークアップ言語になりそうだな、と。

CSS2が完全サポートされればそれで意味付けは出来るな

XML+CSS の形式が一般的になれば
XHTMLでないと記述できない特殊な挙動を要求するものって
object(img含む), scriptとイメージマップくらいじゃないだろうか。

HTMLとの互換性を捨てたらXHTMLのメリットって一体…。
要素の定義を自分でしなくていいくらいのもんか？

互換性が必要ならXHTML1を使えばいい、ということでしょうな。
大体、HTMLとの互換性以外のメリットに挙げられない時点で
既にXHTMLとしての新天地に背を向けている。
そういう著者が殆どなのだから、XHTMLの未来は明るくはないよ。
まあ、真っ暗じゃないと思うけどね。

>>88
＞互換性が必要ならXHTML1を使えばいい

ではXHTML2はどういうときに有用なんだろう？と
考えると、XMLで自分で要素定義する手間が省ける
だけしかメリットなくない？

>>89
まあ、自分で文書型作成できる人は一握りだから。
他人が作った文書型が標準化されていて無料で使えるってことは
多くの人にとって大きなメリットだと思う。

# Webに特化したものを作ろうとしてnl要素とかやっちゃったのかな…と思う。

何にせよUAの対応が

でAmayaはどうなのよ

使ったことないけど、使うまでもなく逝ってよし、でないの？

Ayaya

iCabがapplication/xhtml+xmlに対応した模様。
がんばってくれ。早くちゃんと使えるようになってくれ。

>>95
対応って…、 <script src="hoge.js" /> とかやってもOKってこと？

>>96
Accept: application/xhtml+xml
を送るようになったってことじゃないの。

>>97
だとしたら、正式対応がんばって欲しいなあ。
困ったUAが一つ増えておしまい、にならないように。
XHTMLをまともに処理できないのに
無責任に Accept: application/xhtml+xml 送られたんじゃたまらん。

全て理解した上で、対応したのならいいんだけどな
とりあえずやっとけみたいな感じでされたら逆に困る

しょうがなく100get

http://www.w3.org/MarkUp/xhtml-roadmap/
ロードマップが更新されてる。

来月にも 2nd draft がでるってのはまあ妥当か。
大体 1st draft には未定事項が多すぎだし…。
2nd はその辺を埋めて ML で報告のあったエラッタを
修正する程度のものになるんだろうけど。

しかし CR が Oct 2003 で PR が Jul 2004 ってのは
想像はついてたけど微妙に鬱…。

>>102
> PR が Jul 2004
のんびりしすぎと見るか、急ぎすぎと見るか。
その頃のWeb事情がどうなってるかも気になる。
IEは相変わらず今の実装を引き摺り続けてるんだろうか。

XHTML2.0勧告時にIEが対応していなくても2.0使う？　それともするかどうか分からない対応を待つ？

1st draft 見る限りでは方向性がイマイチなので
どっちにしろ使わないかも…とか今は思ってるけれど。

とりあえず志としては、作成する文書に相応しい形式を使いたい。

XMLが今のHTMLのように名実共にウェブページ記述言語の
スタンダードになったら使う。

で、その頃には3.0の勧告が出ているという罠。

3.0勧告って、XML3.0だったりするかもね。

IEの対応状況に関係なく、
最初はXHTML/HTML両方用意する形での導入になるかなあ。
待ってるだけでは需要が発生せず、いつまでも今の状況が続くと思うから。

でも、XMLがスタンダードになったら俺、XHTMLじゃなくXMLを取るな。

大体XHTMLってネーミングがダサいXTMLにすべきだ






ぽ

ﾃﾞｻﾞｲﾅｰage

Content-Type辺りでVersionが識別出来るようにならないものか。

>>110
RFC2854: The 'text/html' Media Type (2000年6月)
> Note that [HTML20] included an optional "level" parameter; in
> practice, this parameter was never used and has been removed from
> this specification. [HTML30] also suggested a "version"
> parameter; in practice, this parameter also was never used and has
> been removed from this specification.
という経緯があるからどうだろう…

>>110
んなもん xmlns 属性で十分だと思うが。
XHTML 1.1 なら version 属性なんてのもあるけど(XHTML 2.0 では廃止?)。

>>112
コンテントネゴシエーションを意図した話と見た。
Accept: application/xhtml+xml だけじゃ
各種XHTMLのうちのどれに対応してるのか判断が難しい。

>>113
仰る通りです。

>>113-114
なるほど、確かに。

…んーでも、そもそも XHTML って "Extensible" なわけで、
例えば XHTML 1.1 + MathML 2.0 なんかも MIME 的には
application/xhtml+xml にすべし、ってな話になってるんだよねえ。

そういう意味では application/xhtml+xml ってのはあくまで
"application" と "+xml" の部分がメインなのであって、
"xhtml" ってのはあくまで対象 UA がウェブブラウザだってことを
示す程度のものでしかない、っていうふうに考えるしかないんじゃない?

拡張された部分、つまり MathML や SVG 、あるいは
将来のヴァージョンの XHTML といった名前空間に属する要素については、
プラグイン任せみたいな感じでも仕方がない部分もあるんではないかと。

…とは言え XHTML 2.0 の現段階の草案での新しいリンク関連属性なんかは
現状の Accept: application/xhtml+xml な UA では全く対応できないしなあ。
せめて、使用している名前空間を示すパラメタくらい書けるようになると
便利だと思うんだけど。

Accept: application/xhtml+xml な UA に確実に期待できるのって
XHTML Family User Agent Conformance の内容くらいなんだろうか。
www.w3.org/TR/xhtml-modularization/conformance.html#s_conform_user_agent

>>115
RFC3236 の 8. The "profile" optional parameter 参照。あと
draft-stlaurent-feature-xmlns-02.txt も。
http://www.ietf.org/internet-drafts/draft-stlaurent-feature-xmlns-02.txt

…ってかこの Internet Draft、8月で期限切れなんだよなぁ。

>>117
情報サンクス。

しかし、なんで profile にしちゃったんだろう。
現状の profile じゃ漠然とし過ぎていて UA の対応は
ほとんど無理のような気がする(T_T)
せめて各種勧告が profile のデフォルト値を
(勧告なり DTD なり名前空間なりの URI に)定めていてくれれば
使い物になるとは思うんだけど。

あと、profile の値は URI じゃなく URIs じゃないと困る…。
これは元々 HTML/XHTML の勧告側のエラッタに起因するものだと思うけど。

# 悪気はないんだけどちょと文句多いな。仕様策定した人ごめん。

>>118
>あと、profile の値は URI じゃなく URIs じゃないと困る…。

なんで? profile 属性と profile パラメータは全然役割が違うんだけど。

>>119
> The parameter is intended to closely match the semantics of the
> "profile" attribute of the HEAD element as defined in [HTML401]
> (section 7.4.4.3), except it is applied to the document as a whole
> rather than just the META elements. [RFC3236]

て書いてあるけど?

(雑把な意訳:
> profile パラメタは、その値が meta 要素のみならず
> 文書全体に対して適用されるという点を除いて、
> HTML 4.01 の profile 属性と同様の(*1)意味内容を持つ(*2)。

*1: 本当は closely match つまり「厳密に一致する」とまで言ってる。
*2: is intened to だから、本当は
「そのようなものとして意図されている」程度の意味だけど。)

# でも Accept とかの書式との整合が取れなくなっちゃうか?
# Accept: application/xhtml+xml;profile="uri1" かつ
# Accept: application/xhtml+xml;profile="uri2" な UA に対して
# application/xhtml+xml;profile="uri1 uri2" を受け取らせることとかは
# 無理そうっていうかそもそも書式として不正かも。

>>120
"except" 以下が重要、というかその後に続けて

>More specifically, the value of the profile attribute is a URI that can be
>used as a name to identify a language.

って書いてあるんだからこれは意図的な制限だと思うんだけどな。
言語を一意に URI で特定するためのパラメータで複数の URI が
指定できたらかえって困らない?

まぁそもそもなんでここで profile 属性を参照する必要があるのか疑問だし、
どっちも underspecified ってことではやっぱりあんまり使い物にはならない
気はするけど。

>>121
その部分は単に「一つの URI は一つの言語と対する」ってことを
述べてるだけだと思うけど。
例えば名前空間識別子での、http://www.w3.org/1999/xhtml が
XHTML の空間を表すもので、他の何を表すものでもない、っていう程度の。

で、例えば XHTML + MathML + SVG なんかは名前空間を三つ使ってるけど、
これは XML 的にはやっぱり言語を三つ使ってるって見なした方が
何かと都合が良いと思う。

例えば XHTML + MathML と XHTML + SVG と XHTML + MathML +SVG を
それぞれ個々別々の言語として、それぞれの profile URI を
定めるっていうのは効率が悪いし、個人が勝手に拡張した
無数の XHTML ファミリ一つ一つに対して profile URI を指定するのでは
それこそ限がなくなってしまう。

だから、"XHTML" とか "MathML" とか "SVG" と言った、
名前空間で分類できるレベルのまとまりを「言語」と見なして、
「この文書は "XHTML + MathML + SVG" という言語で記述されています」
ではなく、「この文書は "XHTML" "MathML" "SVG" という言語を利用して
記述されています」という遣り方でパラメタを提示できた方が
便利だろうと思うわけで。XHTML の profile が(本来) URIs なのも
そういう理由によるものでしょ。

>>122
それは名前空間と文書型を混同してると思うなぁ。そもそも例に XHTML Basic が
挙がってる時点で、意図してる用途にとっては名前空間だけでは必ずしも十分では
ない、ってのは明らかじゃない。

RFC3236 を読めば profile パラメータが「短期的な」解決策と想定されてるのは
明らかなんだから、どうしても文書型を特定したくて当面それで用途に合う人は
profile パラメータを使えばいいし、名前空間がわかれば十分なら
draft-stlaurent-feature-xmlns-02.txt で提案されてるように Content-features
でも使え、ってことでは。XHTML+MathML+SVG ならこんな感じで。

Content-Type: application/xhtml+xml
Content-features: (|
(xmlns="http://www.w3.org/1999/xhtml")
(xmlns="http://www.w3.org/1998/Math/MathML")
(xmlns="http://www.w3.org/2000/svg")
)

どっちが正しい、ってんじゃなくてどっちもアリだと思うけど。で、将来的には
CC/PP でも使え、と。

>>123
> そもそも例に XHTML Basic が挙がってる時点で、
> 意図してる用途にとっては名前空間だけでは必ずしも十分ではない、
> ってのは明らかじゃない。

それは分かるけど、それこそ文書型なんてモジュールをいじれば
無数に作れちゃうわけだから、そのレベルの細かさで UA の
Accept を指定しようとするなら、現実的には XHTML 1.1 とか
XHTML Basic とかの大きな団体が定めた仕様以外は
無視せざるを得なくなっちゃうことになると思う。
その辺りがちょっと気になったものだから。

まあ遡れば HTML の profile 属性のそういう性質について
云々するべきなんだと思うけど、profile 属性の場合は
最悪でも人間が指定されてる URI を参照しさえすれば済むことだから
あんまり気にならなかったんだよね(あくまで個人的な印象だけど)。

もしこのパラメタが正式に採用されて一般に普及することがあっても、
このパラメタを記述するのはやっぱり大きな仕様を
大した変更なく使ってる場合に限ることになると思う。
下手にパラメタを指定して大半の UA に 406 返すようになるのは困るもの。

結局「profile なんて必要なの?」って思ってしまうんだけど。

結局、XHTMLファミリ間でのネゴシエーションは技術的に非現実的だなって
俺は思った。少なくとも HTTP1.1 では。
MIME の仕組み自体、XMLみたいな拡張性に富む形式を
あまり想定してないような気がするし。

うーん、なんか話が噛み合ってないなぁ。別に profile がいいって言いたいわけじゃ
ないんだが…。

>>124
>それは分かるけど、それこそ文書型なんてモジュールをいじれば
>無数に作れちゃうわけだから、そのレベルの細かさで UA の
>Accept を指定しようとするなら、現実的には XHTML 1.1 とか
>HTML Basic とかの大きな団体が定めた仕様以外は
>無視せざるを得なくなっちゃうことになると思う。
>その辺りがちょっと気になったものだから。

だから読めばわかるけど profile は最初から限定された用途向けの短期的な
解決策だってば。もっと端的に言ってしまえば WAP 2.0 のサービスとかが主な
対象。そういう特定の用途にとっては XHTML Basic なり XHTML Mobile
Profile なりが特定できれば必要十分。名前空間が指定できても自分で
いくらでも定義できてしまうことには変わりない。

>もしこのパラメタが正式に採用されて一般に普及することがあっても、
>このパラメタを記述するのはやっぱり大きな仕様を
>大した変更なく使ってる場合に限ることになると思う。

最初から 80/20 を狙ってる (8割方の要求を満たすには2割の労力でできる)
んだから、それはそれであってもいいんじゃないかと思うんだけど。これが
唯一絶対の解決策とか言われたら「冗談じゃない」と思うけど、世の中の
大半の人は出来合いの仕様を使うだけだろうし。

>結局「profile なんて必要なの?」って思ってしまうんだけど。

必要だと思う人は必要な局面で使えばいいし、要らないと思う人は使わなければ
いいだけの話だと思うんだけどなぁ。別に使用を強制されてるわけでもないし。

話が高度で意味がわからん。
もっとわかりやすく話してくれ暮。

おい、誰か噛砕いて教えてやれよ

>>110-126 あたりは、各種XHTMLをUAに合わせて切り替えられないかなーって話。
MIME型の application/xhtml+xml に profile パラメータってのがあって
使って使えないことはないと思われるんだけど
なーんか使いにくそうだなーそれ、という風な感じ。

はしょり過ぎ＆噛み砕きすぎで意図が変わってたらフォロー頼む。

　

This is a page in XHTML 2.0 format:
http://w3future.com/weblog/gems/xhtml2.xml

chimera 0.4.0 では見えたので age.

>>131
xbl(Moz), htc(IE) による href 属性の実装方法は参考になるなあ。
その気になれば nl 要素も今のMoz1.1/IE6で実装できそうな気がしてくる。

>>132
satoshii氏がCSSだけで対応してらっしゃいましたよ>nl

>>133
してないしてない。

>>134
あれ、勘違いでしたか。すみません。
別の方だっけ？

http://homepage2.nifty.com/tomchem/xml/xhtml20.xml
こちらではないかと。

>>136
XLink か…。

nl li と nl:hover li が入れ子の数だけ指定してあるけど
これって nl>li と nl:hover>li だけ指定すれば済むことのような。

対応してればね。

　　■■■ HLink 始めました ■■■
http://www.w3.org/TR/2002/WD-hlink-20020913/

>>139
ちゃんと読んでないけど…XHTMLがまた一つややこしくなるということか…？

XLinkをまともに対応してるブラウザすらないってのに……
とりあえず勧告されたらMozilla辺りが真っ先に食いつくかな？

HLink だけど、いままでの X/HTML では「この仕様のこの要素はリンク」
みたいなのを各仕様で勝手に決めてて、前の世代のブラウザなんかには
新しく定められた要素型がリンクを示すものであることを
理解させられなかったと(例えば NN4 の object, IE5 の q/blockquote)。

で、せめて「この要素はリンクなんだ」ってことは伝えられるようにしよう、
というのが HLink の目的、かな? まあ XLink もそうなんだけど。
XLink との最大の違いは「要素名を自由に決められる」ということ、
のような気がする…。ていうかむしろそれだけ?

あるいは、先方互換とかを考慮しての UA のための付加情報、
というふうに考えるのがいいのかな。XLink は「この仕様を知らない
UA はリンクを扱えません」的なスタンスで、HLink は
「この仕様を知っている UA はリンクを確実にリンクと判別できます」
みたいな。

HLink を知らない UA でも、XHTML 2.0 の名前空間を知っていれば
a href やら dfn href やらをリンクと見なせる訳だし。
プラスアルファで HLink を知っていると、要素型を追加した
場合なんかにも対応できると。

あ、つーか、そうか。要するに後方互換とかユーザエクスペリエンスとか
考慮したら、href とか src とか cite とかを全部 xlink:href にするのは
好ましくないんだよね。

でも、従来の XML の各仕様の機構では、cite とか src とか言う名前の
属性(あるいは q とか img とかの要素)がリンクを示すなんてことは
明示できないから、これじゃ都合が悪い。XLink 以外の属性がリンクを
示すってのは、XML の仕様から逸脱しちゃっている訳だから。

この不合理を解消するために HLink って機構を新設した、ってことね。

キャップ付ければ？石川はん

>>144
別にいらないんじゃないかなあ。

他人が自分の意見であるかのように書いた
可能性もなきにしもあらず

>>146
そうですね。名無しで書き込んで置いて
ttp://math.oheya.to/markup/notes/0209#day13-2
ていうのはちょっとアレだったかも。今後気を付けます。

XHTML2で後方互換を気にするってのもなんだな。
ユーザエクスペリエンスだって気にしてたら先に進めないぜ。
リンクは全部xlinkにした方がむしろスッキリ。
SVGもそうなってるし。

> リンクは全部xlinkにした方がむしろスッキリ。
かも知れないけれど、それじゃ全然 eXtensible じゃない。
XMLは自由に文書型を作成できるはずなのに
リンクに限っては名前も名前空間も特定されてしまうわけだから。
…という話かなあと漏れは推測しますた。

XHTML 2.0は要らないね.
authorは各自で言語を作ったらいい.

　　　　　　　　 .┌┐
　　　　　　　　／ /
　　　　　　.／　/ i
　　　　　　|　( ﾟДﾟ) ＜そんなバナナ
　　　　　　|（ﾉi　　|）
　　　　　　|　 i　　i
　　　　　　＼_ヽ＿,ゝ
　　　　　　　 U" U

さぶっ

>>150
自作めんどいじゃん…

横着者めが...

>>154
言い直す。自作難しいじゃん…

自作するにしても、結局標準的なフォーマットに
変換して公開するだろう?

そのフォーマットとしてのXHTMLだと思うのだけど。

それとも何?
各々が勝手に言語を自作して、authorの数だけ言語が出現しても
良いわけ?

そういうのがセマンティックウェブだとは思えないのだけど。

というか、ここはWeb制作の板なので、イントラネットの話なら
他所でやれって感じ。

>>156
激しく同意。

>>156
「〜をマークアップしたいんだけど、適切な要素が無い…」
という類の話はずっと残り続けるということだろうか、つまり。

XMLなら変換はかんたんだろ？

XLink使うときにtarget="ほにゃらら"にあたる振る舞いはできないの？
_blank相当と_self相当のやりかたしか見つからない。
MozillaかNetscape6+なら独自拡張でもいいんだけど。

HLINK: 現在のXLinkは(1)名前空間接頭辞が必要、(2)リンク先を示す属性名がhrefに
固定されている、(3)ひとつの要素に複数のリンク属性を指定できない（ex:リンク先URIとプ
ロファイルURIなど）といった点から、XHTMLほか既存の文書型では利用し難いという議
論があります。これを回避するための代替仕様HLink: Link recognition for the XHTML
Familyの草案が2002年9月13日に公開されました。

XHTML文書内で、どの名前空間に属するどの要素型のどの属性がリンク機能を持つかと
いうことを、hlinkという要素で定義しようというもので、これは外部文書とすることも可能
です。スキーマで構文を定義するだけでなく、それを解釈するための定義をさらに別に用
意する（schema annotationの一種？）というわけですが、XLink自身でこういう定義ができれ
ばいいものを、W3Cの内輪もめというか何というか…

乳輪もめなら歓迎ですが・・・

ほっしゅ！ほっしゅ！
　　　,.、,､,..,､､.,､,､､..,_　　　　　 　／i
　　;'・д・、. .:、:,　:,.: ::｀ﾞ:.:ﾞ:｀''':,'.´ -‐i
　　'､;: ...: ,:. :.､.:',.: .:: _;.;;..; :..‐'ﾞ ￣ ￣
　　　｀"ﾞ' ''`ﾞ `´ﾞ｀´´

チェックするなら、w3cとミケネコどっちがいいわけ？

って、スレ間違えた・・スマソ

週明けまでに 2nd draft 出ると思う人、手あげて〜。

>>166
・手を上げるだけだと誰も書き込まない罠。
・誰も同意するヤツがいない。
・つーかここを見ていない。

さあどれ！？

>>167
誰も同意するヤツがいない。

ttp://www.w3.org/MarkUp/xhtml-roadmap/#schedule

XHTML 2.0 と XFrames の 2nd draft は十月に延期だそうです。

あげ

XHTML 2.0 草案邦訳計画
http://www.loops.jp/~hkt/wd-xh2/info.html

>>171
凄い訳だな……Ver.1は完全な機械翻訳だし（少しは自分で手を入れろって）。
つか、
> 1. Introduction
> This section is informative.
が
> 1.紹介
> このセクションは、有益です。
はひどいよ。

このセックスは、有益です。

>174
2点

<?xml version="1.0" encoding="Shift-JIS"?>

なんじゃこりゃ

> 8.9. The div element
> 8.9。 悪霊要素
機械翻訳とはいえ個人的にはヒット。ちなみにExciteに聞いたら「臆病者要素」だそうだ。

http://info.loops.jp/~hkt/design/

なんかすごいじゃない、ここ。

>>178-179
へぼい。ネタですか？

>>178
今となっては「イケてる」と言う程でもないけど、
へぼいと言う>>180のサイトは知りたい。

ごめん、ｲｹｽﾚと素で勘違いしていた。
俺がへぼかったんでOS終了して逝ってきます。

>>182
うんうん、お前の気持ちはよーく解る。

俺もイケスレかと思った。

>>181
>>178よりかはｶｺｲｲサイト作ってる。もちろん自分自身での主観でだけどな。
沢山あるサイトのうちのテストページならうｐしてあげてもいいぞ。土下座してお願いするならな。

Web土下座

>>183
　　　　　　　　　　　 ∧＿∧
　　　　　∧＿∧ 　（´<_,｀ 　）ﾌﾟｯ
　　　　 （　´,_ゝ`）　/　　 ⌒i 　
　　　　／　　　＼　 　　　|　|
　　　 /　　 　/￣￣￣￣/　|
　 ＿_(__ﾆつ/　 FMV　 / .| .|＿＿＿＿
　 　　　 ＼/ 　　　　　 /　（u　⊃
　　　　 　 ￣￣￣￣￣

よくあかんね。

>>184
土下座するからXHTML2.0なサイトを公開しれ。

保守を兼ねてage。

そろそろ2nd Draftなのでは？

といか、XHTMLとHTMLの違いはなんですか？
初心者でｽﾏｿ

>>191

http://kanzaki.com/docs/htminfo.html

読んでからまた来るがいい。

そうだーー。よんでこーーーーい

2nd Draft…延期なら延期と言って欲しいものだ脳。

htmlをxhtmlに変換するフリーソフトでなんかいいの無い？

>>195
Tidyではなく？

object 要素に content-length 属性なるものが増えてるね。

Modularization of XHTML には無いから
XHTML 2.0 で新設された属性だろうけど、
名前から察するにHTTPとかで管理するべきものじゃないの？

mime typeもね

XFormsが勧告候補に。
http://www.w3.org/TR/2002/CR-xforms-20021112/

記念ﾊﾟﾋﾟｺV(^o^)V

2nd Draft, TBD になっちゃったよ…

止まってる

2nd Draft 目処たったのかな。スケジュールが Dec 2002 に変わったね。

XHTML™ 2.0 2nd Draft
ｷﾀ━━ヽ( ´∀`)･ω･) ﾟДﾟ)･∀･)￣ｰ￣)´_ゝ`)`Д´)-_-)冫､ )´Д`)=ﾟωﾟ)
( ･∀)∀ﾟ)Дﾟ)▽^)Д´)ωﾟ)_-)ゝ`)з゜)(´∀`)･ω･)ﾟДﾟ)ﾟ∀ﾟ)･∀･)´_ゝ`)-_-)
´Д`)ﾟーﾟ)`Д´)ﾟ〇ﾟ)･ρﾟ)'▽')^‐^)ﾟロﾟ)`∇´)ﾟωﾟ)´ェ`)ρ_;)( ´∀`)･ω･) ﾟДﾟ)
･∀･)￣ｰ￣)´_ゝ`)ﾉД`)･ﾟ･｡━━━!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

はやく誰か解説してクレクレ

主な変更:
* line 要素 → l 要素(だと思うんだが説明がない)
* nr 要素案？(数を表すらしい)未採択
* ins, del, area, map, bdo 要素削除
* DataType の ContentType,ContentTypes(RFC2045ベース) が
RFC2068 14.1の media range に
* LinkType に Parent, Meta, P3PV1 追加
* 'root' 属性 コア属性集合に追加案？
* 双方向テキスト属性集合 dir
* 編集属性集合 edit, datetime, cite
* ハイパーテキスト属性集合に xml:base, rel, rev 追加
* 埋め込み属性集合 src, type
* イメージマップ属性集合 usemap, ismap, shape, coords
* blockquote に Inline 可
* h1-h6要素 非推奨案？未採択
* strong 削除案
* META 要素が空要素でなくなった
* hr 要素を削除または改名案
* script要素 内部にscript要素・noscript要素をネスト可
あとobject, table の記述に変更があるようだけど読んでない。
Diff-marked版ざっと見た感じだが
全体的に要素・属性の統廃合を更に進めているような印象。
見落とし・誤読があったら誰かフォローおながいします。

ひげ

edit属性ってのは前からあったものですか？

ねえな

ということは今回のdraftからご登場ということでしょうか

edit は ins, del のかわりだよね。

http://www.w3.org/TR/2002/WD-xhtml2-20020805/
http://www.w3.org/TR/2002/WD-xhtml2-20021211/

ﾎﾞｸはどうなったの？

>>213
忘れられちゃいました。
もう、ここにいちゃいけないのです。

なんかもうグチャグチャだな

h1-h6非推奨にならなかったのかー。残念。
そのあたりの経緯って、どこかで読めますか？

>>213
l（line）になりました。

すっきりしたんだかしてないんだかよくわからん仕様になっちゃった気がするなぁ。
HLinkとXLinkはどうなるんだろう。

最小限の修正を施したXHTML1.2みたいなのを作ってくれた方がうれしいかも。

なんかどこも実装しないまま幻の仕様になっちゃったりしないかなぁ。
ライトなユーザはついてこれるだろうか…。

Microsoft次第かもNE!

どうせまた独自拡張に走るんだろ。

うーん、なんかだんだんXHTML 1.1でいいじゃんって気がしてきた。

HTML 4.01で十分だよ。

ISO/IEC 15445:2000。

厨の来ないスレはいいですな。

Editorの所を見ろ。
Microsoftの人間は関わっていない。

ということは、つまり、まず実装されない。
されたとしても、勧告されてから数年後とかの遠い未来だ。

まあ、関わってたら関わってたで、今度は草案の段階で実装されて
後で困るからどっちもどっちだけどね。

＞Microsoftの人間は関わっていない。
いや、そんなことはないはずだ

XSLTがある現状、書き手としては結構どうでもいいなぁ。
ソースはXHTML2.0の正式草案前に勝手にsection/hっぽいもの使ってるし、
表示はXHTML2.0が勧告された所で、結局IE実装まではXHTML1.1に変換する
羽目になるし。

まぁ、IEがXMLパーサとしてバグがなくなってCSS2を完璧に表示できるように
なれば、XHTMLの各バージョンの実装なんかどうでもよくなるんだけどな。

XHTML 2.0 3rd Draft
http://www.w3.org/TR/2002/WD-xhtml2-20021218

ﾅﾝﾃﾞﾔﾈﾝ━━━━(ﾟ∀ﾟ)━━━━!!

つーか単なる 3rd Draft であって Last Call なんかではない罠

3rd Draft は 2nd Draft のミスを修正しただけだそうです。
2nd からの変更点:

・name 要素型→ label 要素型に名前変更
　(要素名が分かりにくいと不評だったため?)
・l 要素の解説が欠落していたので追加。
・Client-Side Image Map Module の項が欠落していたので追加。

これだけかな?

> ・name 要素型→ label 要素型に名前変更

いやー素晴らしい。
私も「name って名前はちょっと……」と思っていた奴の
一人なので、この変更は大歓迎です。

identifierの問題見てるとWikiの代替記号問題と変わらんな

正直、編集属性のあたりはXHTMLの範囲を越えてると思った。

それ言い出したらハイパーテキストリンク以外はみんなXHTMLの範囲外だって。

ハイパーテキスト関係は XLink にまかせたほうがいい気がするなぁ。

あとは、文章構造のみ定義されたセットを新しく作って
XHTML はレガシーなもの全て背負う存在でいいんじゃない？

意味要素は用途毎にかなり異なるだろうから別ネームスペースでつっこんだほうがいいと思うし。

>>236
いやいや、段落とか箇条書きとかは立派にXHTMLの範囲内だろ。

まだ WD だから突っ込むのは詮の無いことかもしれないけど、
XFrames って Content-Type は何で送ればいいんだろう。
application/xml でいいのか？

>>239
RECになってIANAにMIME登録されるまではそれしかないだろうね。

<顔文字></顔文字>

ってのはどうよ？

>>241
どうよって、どの観点から？

要素型としてどうかってこと。





ま、8割方ネタなんだが…

preがあればいいよ

視覚系以外の他のUAに対してだと顔文字は単なる記号の羅列だからなー。
そこらへんも考慮して欲しい。

>>245
視覚系の場合、CSSでascii属性を表示させ、
音声系の場合、内容を読み上げるって事で、こんな実装はどうだ？

<p><顔文字 ascii="(ﾟдﾟ)">ハァ</顔文字>？</p>

xml:space="preserve" を XML に書き込むか、CSSで実現するかはお好みで。

激しくツカエネェ

>>246
どうでもいけど xml:preserve を記述しなかったら
CSS でも空白の調節はできなくなるよ。

>>248
そうなの？　そしたら普段XHTML1.1でxml:preserveなしにpre要素使ってる
んだけど、そしたら本当は好ましくない表記？

>>249
<!ATTLIST %pre.qname;
%Common.attrib;
xml:space ( preserve ) #FIXED 'preserve'
>

>>250
感謝＆仕様ぐらい自分で見ろ、と自分自身で思た。教えて君でスマソ。

>>249
ごめん、>>248 嘘だわ。仕様書読み直したら勘違いだった。スマソ。

ていうか気付いたの昨日なんだけど、実際の仕様がどうなってるとか
引用を交えつつ詳細なレスを書いてたら IE がクラッシュして、
むかついてフテ寝してた。重ね重ねスマソ。

ちなみに >>249-250 だけど、外部 DTD を読まない UA に対しては効力がないわけで、
本当は逐一書いた方が良いのかなーとは前から気になってた。
それとも名前空間+要素名だけで良しとしてもいいのかなあ。

岡田克彦ファンクラブからのご案内です。ご高承のとおり、岡田克彦氏の卒業した早稲田大学政治経済学部
と、ひろゆきの卒業した中央大学文学部は比較にならないほど差があります。中央大学文学部のような
ヘボい大学に共通しているのは、文化水準が低いという事です。18歳から22歳をヘボい大学で過ごすという
ことは、感受性において致命傷と言えます。２ちゃんねらーの大半は岡田克彦氏に比べて、著しい低学歴で
頭が悪いだけでなく、感受性も愚鈍で腐っているという、取り返しのつかない状態なのです。
せめて、http://www.geocities.co.jp/MusicHall-Horn/1091/で、岡田氏の作品に触れましょう。

定義リストってわかりにくくありません？
特に以下のような形式。

<dl>
　 <dt>Center</dt>
　 <dt>Centre</dt>
　 <dd> A point equidistant from all points
　　　 on the surface of a sphere.</dd>
　 <dd> In some field sports, the player who
　　　 holds the middle position on the field, court,
　　　 or forward line.</dd>
</dl>

これだと dd がどこの定義なのかはまだしも、
最初の dt が「定義なし」なのか「次のdtに同じ」なのかが判断できないような…。

>>254 の続き。

で、xhtml 2.0 の草案で採用された、
section要素みたいなのを導入するのはどうでしょう？
ちょっと冗長（というか厳めしいというか）な気がしますが…。

>>254
そういう場合はDDを一つにして、DDの内部をulあたりでmarkup汁。

DTに関しては複数の用語を解説する例として >>254 が載っている以上、
かならず「次のDTに同じ」と解釈して、「定義なし」の場合は
「そもそも定義リストに載せない」か「それでもDDを書いてCSSなどで消す」
と言うことに成るかと思う。

解り難いってのはあるが、解らないわけではない。

こういうときこそbrの出番

>>256
> 解り難いってのはあるが、解らないわけではない。

解り難いってのは大問題だと思うよ。
シンプルな定義にすれば author も UA も(ﾟДﾟ)ｳﾏｰなんだから、
もっと解りやすい定義にすりゃいいのにってのは真っ当な意見だと思う。
前に Piro たんが書いてたが、例えば dli って要素型を定義して

<dl>
　<dli>
　　<dt>...</dt>
　　<dd>...</dd>
　</dli>
　<dli>
　　<dt>...</dt>
　　<dd>...</dd>
　</dli>
</dl>

って感じの構造にできりゃいいのにね。

>>255 の言ってる "section 要素みたいなの" ってのも
こういう奴のことでしょ?

コンテナ要素を導入するよりは

<!ELEMENT dl (dt+, dd+)>

にして(　ﾟдﾟ)ﾎｽｨ

>>259
・・・やはりコンテナを導入した方が融通が利くと思うなあ。

dl以外のlist系もXHTML2.0では手付かずだよな。
nlでlabelは付けられるようになったが、labelとliを関連付けるnl用の
section的要素は無いし。

＃labelとliはISO-HTMLの見出しと本文的な関連付けの判断が要求され、
　一つの文書のschemaでダブルスタンダードな文脈判断が要求されるのが嫌。

ol、ul、nl、dl、全ての直下にlg(List Group)要素キボンヌ。
ol、ulでも無闇なネストが減る分UA、人間共に負荷の軽減が期待できるし。

>>256
> そういう場合はDDを一つにして、DDの内部をulあたりでmarkup汁。
ddは一つだけじゃなく複数個書けるのに、
わざわざulを用いてマークアップしなきゃならんのですか？
それはなんか間違ってませんか？

> DTに関しては複数の用語を解説する例として >>254 が載っている以上、
> かならず「次のDTに同じ」と解釈
…、そうなのか…。
つまり「ddが一つも無いdt」ってのはありえないんですね…。
英語苦手なんで自信ないけど、仕様書に明確に書いてなかった気がしたんで
ありえるのかと勘違いしてました…。
また一つ賢くなりました。

> 「定義なし」の場合は 「そもそも定義リストに載せない」か「それでもDDを書いてCSSなどで消す」
「そもそも定義リストに載せない」ってのは、定義リストである以上当然ですね。なるほど！

>>258
> >>255 の言ってる "section 要素みたいなの" ってのも
> こういう奴のことでしょ?
そうです。「コンテナ」ってやつです。


>>259
> <!ELEMENT dl (dt+, dd+)>
>>260 さん同様、そうするぐらいならコンテナにした方が良いかと…。


>>261
> nlでlabelは付けられるようになったが、labelとliを関連付けるnl用の
> section的要素は無いし。
nl ってのは <!ELEMENT nl (label, li+)> だと思うんで、特に必要はないんでは？
# 何か間違ってたら直して下さい。

> ol、ul、nl、dl、全ての直下にlg(List Group)要素キボンヌ。
lgってのは、>>258 さんでいうところの dli という解釈でよろしんでしょうか？

>>261
＞nl ってのは <!ELEMENT nl (label, li+)> だと思うんで、特に必要はないんでは？
結論から言えば「必要無いです」。

ただ、処理系の都合として「兄弟要素を参照するより、親子関係を参照する
ほうが負荷が低い」と言うのがありまして、見出しと本文を関連付ける
要素があると便利なのであります。

例として「あるli」の属するlabelを調べるときに
「liの兄要素（数が不明）をlabelが出現するまで検索」と
「liの親要素（必ず1つ）の子要素のlabel（これも一つ）を検索」だと
後者の方が圧倒的に楽なのです。

＞lgってのは、>>258 さんでいうところの dli という解釈でよろしんでしょうか？
そうです。XHTML2.0はabbrとacronymの一本化、strongの廃止検討など
類似用途の要素を一まとめにする動きが見られるので、だったらlist系全部
と言う事でlg(List Group)要素と言うものを勝手に妄想しました。

>>264 は >>263 の誤り。スマ

>>264 （261）
「兄弟要素」ってのがわからない…、と思ったら、
非常に分かりやすく丁寧な解説がついていて(ﾟДﾟ)ｳﾏｰ
処理系とか全然分からないんで、参考になりました。ドモ

>>261
度々すみません。も一回考え直したら疑問が出てきたので。

> ol、ul、nl、dl、全ての直下にlg(List Group)要素キボンヌ。
> ol、ulでも無闇なネストが減る分UA、人間共に負荷の軽減が期待できるし。
「無闇なネストが減る」とありますが、減らないような気がするんですが…。
よろしければ説明お願いします。

> 例として「あるli」の属するlabelを調べるときに
> 「liの兄要素（数が不明）をlabelが出現するまで検索」と
> 「liの親要素（必ず1つ）の子要素のlabel（これも一つ）を検索」だと
> 後者の方が圧倒的に楽なのです。
今の仕様でも「liの親要素は一つ（nl）」だと思うんですが…。

>ol,ulのネスト
a1,a2,b1,b2の様な2元軸を持ったデータをリストで書くと
(２元軸ならtableとも思うが、飽くまでリストである場合)
<ul>
<li><ul><li>a1</li><li>a2</li></ul></li>
<li><ul><li>b1</li><li>b2</li></ul></li>
</ul>
と成っている。

ol、ul直下にグループ化要素を作れば
<ul>
<lg><li>a1</li><li>a2</li></lg>
<lg><li>b1</li><li>b2</li></lg>
</ul>
となる。

>今の仕様でも「liの親要素は一つ（nl）」
説明不足だったが、ここで味噌なのは「親要素（必ず1つ）」ではなく、
「label（これも一つ）」の方。つまり gl は <!ELEMENT lg (label, li+)>
となる。例えば以下のようなマークアップの場合、
<nl>
<label>a</label>
<li>1</li>
<li>2</li>
<label>b</label>
<li>1</li>
<li>2</li>
</nl>
li要素から親(nl)に移動しても、その親(nl)は子のlabel要素を2つ持っている
から特定のliとlabel要素を関連付けるには、labelが現れるまで１個づつ
兄要素をさかのぼっていかねばならない。

この程度の規模のlistなら１個づつ兄要素を調べていっても大した事は無いが、
仮に一つのlabelが100個のli要素を従えている場合、最短なら１回だが最悪
なら１００回も兄要素をさかのぼって調べなければならない。

<nl>
<lg>
<label>a</label>
<li>1</li>
<li>2</li>
</lg>
...
</nl>
lgを途中にかまして、lg と labelを必ず1対1にすればどんな場合でも、
liから親要素のlgに移動して、その子要素のlabelを参照すればよくなる。
仮に一つのlgにliが１００個あっても、li -> gl -> label と２回移動すれば
必ず対応するlabelが見つかる。

オフトピックスだが、似たようなものとしてdlも説明しておくと。
<!ELEMENT dl (dt, dd)+ >
こんな風になると、処理系は一番ありがたい。この場合、コンテナは
存在しないが、nlの例と違ってdtとddは必ず連続した一対の要素になるので
dtの次は（要素の名前しらべなくても）必ずDDだし、逆にDDの前は必ずDTに
なるので、「次」「前」の１回の命令で必ず対応するdt/ddを発見できる。

従って
<dl>
<dt>マリオブラザーズ</dt>
<dd>マリオ</dd>
<dd>ルイージ</dd>
</dl>
より

<dl>
<dt>マリオブラザーズ</dt>
<dd>
<ul>
<li>マリオ</li>
<li>ルイージ</li>
</ul>
</dd>
</dl>
の（dtとddの関連付けだけなら）処理系に優しい書き方だといえる。

labelをそんなに増やしてどうする。

>>268
それだとul/olの内容としてli以外の内容が出現しうるので、スクリプトなんかを書くときは面倒になるかもなあ。

あ？　nlの内容は(label, li+)であって(label, li+)+ではないぞ。
http://www.w3.org/TR/2002/WD-xhtml2-20021218/mod-list.html#edef_list_nl

一つのnlにlabelは一つしか出て来ない。

>>273
はぅ。スマン｡クリティカルな所を勘違いしてた。
じゃあ、一連の話は"無かった事"に

ごめんよぉ…。

age

（＾＾）

age

↓岡たんウザイ

残念でした。

ttp://www.w3.org/TR/2003/WD-xhtml2-20030131/

W3C Working Draft 31 January 2003がｷﾀ ━━━ (ﾟ∀ﾟ) ━━━ !!!!

age

man

目立った動向は無いよ。

(ミスで消えてたらしい) cite 要素が復活したとか、
cite 属性が Edit から HyperText へ移されたとか、
hr, sup, sub が Presentation から Text へ移されたとか、
(Presentation Module は消滅) その程度。
あとは文章の推敲とかサンプルコードの修正くらいかと。

目立ったミスとしては、type 属性が HyperText と Edit で重複してる。
cite 属性移動の際に一緒にコピペしちゃったものと思われ。杜撰だなあw

ttp://www.w3.org/TR/2003/WD-xhtml2-20030131/abstraction.html#s_abstraction_issue_2

そういや LinkType に 'redirect' を追加しようかっていう案が出てるけど、
XLink で xlink:actuate="onLoad" すりゃいいだけなんじゃないかと思う。
わざわざ XHTML 使って(=XHTMLの全機能を付随させて)することじゃないって。

<?xml version="1.0" ?>
<doc xmlns:xlink="http://www.w3.org/1999/xlink"
xlink:type="simple" xlink:actuate="onLoad"
xlink:show="replace" xlink:href="http://pc2.2ch.net/hp/"/>

で済むんだから。

> cite 属性移動の際に一緒にコピペしちゃったものと思われ。

んなわけねえなと自己ツッコミ。つか連続投稿スマソ。

ぼくを早く殺してよ。

ぼくは <quote cite="http://www.w3.org/People/mimasa/test/schemas/rng/xhtml-text-2.rng">Death to acronym.</quote> とか言われちゃったけどね。
ていうか hr も h1-h6 も strong もイラネ。

２ちゃんの糞スレの皆様に、作曲家・岡田克彦ファンクラブからのご案内です。
ご高承のとおり、岡田克彦氏の卒業した早稲田大学政治経済学部と、ひろゆきの卒業した中央大学文学部夜間は
比較にならないほど差があります。中央大学文学部夜間のようなヘボい大学に共通しているのは、文化水準が
低いということ。18歳から22歳をヘボい大学で過ごすということは、感受性において致命傷と言えます。
２ちゃんねらーの大半は岡田克彦氏に比べて、著しい低学歴で頭が悪いだけでなく、感受性も愚鈍で腐っている
という、取り返しのつかない状態なのです。
せめて、http://www.geocities.co.jp/MusicHall/5933/で、岡田氏の作品に触れましょう。
また、学歴至上主義は、学歴がないか、東大のような高学歴であっても学歴に相応しいだけの自分の特技
等を持っていない人が不愉快に思っているだけのことです。２ちゃんのひろゆきの卒業した中央大学
文学部夜間のようなものは、学歴と言えるようなものではなく、これは、拭うことの出来ない、生涯つきまとう
汚点で、絶対に取り返すことは出来ません。２ちゃんの皆さんの大半は、波風を立てずにその場限りの平穏無事を保守する
という、下らない事なかれ主義にうつつを抜かしていますが、私共は心優しい仲間なので、はっきり申し上げられます。
ひろゆきは、感受性において、まさに取り返しのつかない状態にある、ということです。
従って、阿呆のひろゆきのやっている２ちゃんは阿呆の危険集団だということです。

>>284
実装にXLinkのサポートを強要しない方針なのではないかしらん。
XLink対応を前提にするなら不要になるものは他にも沢山ある。

XHTML 1.0 よりも、XHTML 2.0 で書いた方がよいのでしょうか？

その方がよいとしたら、どこを参考に勉強したらよいのでしょうか？

英語には自信がないし、間違ったサイトを参考にしてしまった過去もあるので、良いところがあったらお願いします。

XHTML2.0 はまだ草案段階です。
仕様が固まるまで、今後も改変が繰り返されることが予想されます。
欠点のフィードバック等を目的とした試験的導入ならよいかと思いますが
正式勧告になるまでは一般公開用途には向かないでしょう。

で、正式勧告になったら XHTML2.0 にした方がいいのかというと
そうでもなく、対象 UA 等を考えて個別に判断することかと思います。

>>291
マジレスありがとうございました。泣くほど感動しました。

>>291
だよなー。正式に勧告されても主要UAがきっちり対応してくれないことには
結局使えないんだよな。

後方互換性の無い物をIEが対応するはずが無い

結局、HTML4.01 で書くのが無難であったりする。
XHTML1.0 だと半端だしねぇ。

なんかL->(X)HTML ってケースは結構あるけど
XHTML->なんか ってケースは今のところほとんどないもんね。

個人的に XHTML2.0 は好きになれん。

XHTML1.1は？

デフォのIEで見られない。

現時点で使用されているブラウザの95%はアップデートなしに
XHTML 2.0 を解釈できるわけだが…。対応とはなんぞや。

XHTML1.1以降は Content-Type が application/xhtml+xml なので
現時点で使用されているブラウザのほとんどはアウトなんじゃないかと思うんだが。

あと css 非対応な UA も h1 とか無くなったら死亡かと。
media type あんだけたくさんあるんだから
いつまでも css 非対応ってわけにもいかんだろうけどね。

>>299
application/xml

CSS 非対応は残りの5%の世界でしょ。
つーかそういうUAは「見えれば何でも良い」という仕様なのでは?

CSSはあくまでおまけ。

「HTML+CSS」という形式を恒に期待したら、
それはHTMLで見栄えを表現するというのと同じ過ちを再び犯すことになる。

そうか？

HTML の各要素のデフォルトレンダリングなんかとっぱらって
レンダリングエンジン部分はすべてCSS依存にして
XMLじゃ意味構造のみ記述が美しいと思ってるんだが。

css 非対応で xhtml1.1 対応の UA があったとして、
xhtml2.0 で section/h の構造が導入されたら
hn 相当にレンダリングするなんて逆立ちしたって出来ないっしょ？

さらに、独自の語彙を namespace を切って導入した場合、
それを人間が区別出来るように表示するには css で設定するしかない。
UA は独自の語彙をどう表示したらいいかなんかわからんわけだし。

いわゆる"ブラウザ"っていわれる UA がするべき仕事は
XML を"見栄え"よく人間に見せること。

> いわゆる"ブラウザ"っていわれる UA がするべき仕事は
> XML を"見栄え"よく人間に見せること。

突き詰めて言うと、「スタイルシートを実行する」ってこと。

ちゅーことで視覚系UAはスタイルシートを実装すべしなんだな。

でもさあ、だったらスタイルシートはもっと簡素にならなきゃいけないと思うよ。
XMLでせっかくマークアップ解析が簡単になったのに
代わりにCSSが複雑化していてブラウザ開発が全然楽になってないじゃん。
新ブラウザが出るたびにバグ報告が飛び交う現状っておかしいと思う。

俺は display プロパティだけ解釈/適用して後はツリー表示するUAが欲しい。

ニーズ優先だろ。普通は。
開発がしんどかろうがなんだろうが
CSSで多彩なレイアウトが求められてるんだからUAベンダはそれに従うべきだ。
複雑な分ビジネスチャンスもうまれるってこった。

CSSはUIも司るんだからもっともっと強力であるべきだ。
複雑なのは困るけど、
PostScriptみたいにコンピュータで生成すれば問題無い程度の複雑さなら
全然問題なし。手書きなんてする必要ないし。

>俺は display プロパティだけ解釈/適用して後はツリー表示するUAが欲しい。
ユーザスタイルシートでも定義すれば :-)

保守

保守

ネタ切れか…

じゃあ関連技術でもどうぞ。
XML Events
http://www.w3.org/TR/2003/CR-xml-events-20030207/
どうなんでしょうなぁコレ。
すごく使いにくそうな気がするんだが、しょうがないのかなぁ。

なんかもう W3C 不信。

んと、漏れは XML Events や XForms は使わないと思うので
正直その辺のことはよく分からないんですが、
取り敢えず XHTML 2.0 それ自体は非常に（・∀・）ｲｲ!! です。

つーか、実験的に XHTML 2.0 使ってたら
XHTML 1.1 で書くのが激しく鬱になってしまいますた。
早く勧告してﾎｽｨ。

>>312
しかし、XHTML2.0 は CSS 非対応 UA から見たら意味不明になっちゃわない？
XHTML2.0 に直接対応してるのなんて当分でないだろし。

>>313
いや、application/xml か application/xhtml+xml で処理してますから。
つーか、XHTML 2.0 を text/html で扱うのはいくらなんでも無理でしょう。
そもそも XML なんてスタイルシート使わずに読むためのもんじゃないし。

# text/html にすると、href とか src が効かないので威力が半減します。
# どちらかと言うと CSS 云々よりそっちの方が問題。

>>314
なるほど。
しかし、application/xml だとしても、
UA が XLink とか XPath とかに対応してないと実際使えたもんじゃないような気が。

># text/html にすると、href とか src が効かないので威力が半減します。
># どちらかと言うと CSS 云々よりそっちの方が問題。
これって HLink だかなんかで解決するようになるんですよね？たしか。

>>313
HLink は UA がネイティヴ(というかスタイルシート抜き)で
対応するための仕様なんで、XSLT を使える環境であれば
XHTML 1.1 辺りに変換すればいいだけの話だったりします。

もしくは、CSS3 の @Linking 使うとか(対応 UA 見たことないなw)、
XBL (mozilla.org の策定した言語で、W3C Note にもなってる) 使うとか(w
>>131 は XBL 使ってますね。

どうでもいいが、href の 'h' ってもう別になくてもいいような。

>>317
確かに(w　ハイパーな方法で参照出来るかどうかは UA 依存だしな。

ハイパーな方法で参照してくれると嬉しいぞ、という意思表示でしょ。
ただの参照とは違うのだよ、ってさ。

「ハイパー」の妥当な日本語訳を教えてたもれ。

普通の参照が HTML に無い以上、普通の ref で良いような。
なんかなんにでも X とか J とか V 付けてた風習を思いだしてしまう。

>>320
超超超　　超参照
超超超超　超参照

あっげー！　さげー！　激しく同意！
コテハン野郎は逝ってよしー♪ (違

超は SUPER だろ

超だね。

⇒ ハイパー【hyper】
(１)外来語の上に付いて複合語をつくり，度を越した，極度の，などの意を表す。普通「スーパー」よりも高い程度を意味する。
(２)コンピューターの上で，テキストなどの情報が同一線上にあるのではなく，多重に結びつけられているさまをいう。

極

2.0のソースどうやってレイアウトする？

XSLでHTMLやXMLに出力してCSSで飾る？
HTMLに出力しないとlink要素なんてほとんど無意味なものになるんだよな……多分

ほんとは link 要素とかって
UA ががんがん利用するのを期待してたんじゃなかったっけ。
next だの prev だので一括ダウンロードとか一括印刷とか。

>XSLでHTMLやXMLに出力してCSSで飾る？
何もしなくても XML だという罠。
まあ、現行の UA に h とか認識させたいなら XHTML 1.1 ぐらいまでは落さないとだめだよね。

がんがれ

W3Cには、正式なXHTML 2.0をリリースする時に、初心者にわかりやすく
エキスパートの批判にも耐えられる、精密なユーザーガイドも
同時にリリースしてもらいたいものだな。

しかし XHTML2.0 は UA 側も対応してないと普及しようがないような。

そういうのをネスケやオペラに望むんだが。

>>330
いままでのHTML4.01の仕様ってなにか問題あった？
よんだらよんだで解りやすい文章だし、あれ以上簡単にするとしようとして
役に立たんし、というレベルで解りやすかったと思うが。
（dlの用途があやふやとかツッコミどころはあったが、他に解説本がいらない
　ほど秀逸だったということで）

具体的に、どんな書き方をすれば、よいHTMLドキュメントになるのかが
さっぱりわからなかった。
だから、div厨やtable厨が平気でValid HTMLのバナーをはりつけていただろう。

dfnやcite、kbdのようなインライン要素の説明も不足していた。
HTML 4.01の仕様書は、わかりやすいと言えばわかりやすいが、
すこし踏みこんで考察すると、とたんに多様な解釈を許してしまう点で
甘さがあったと思う。

わざと色々解釈出来るようにしておいたって可能性は？

そんなことをして、何かメリットが？

そんなの、W3Cに聞いてくれよう。

HTMLは、広く利用されることを期待された言語だからねえ。
var だの kbd だのといった矛盾はあるけれども、具体的な意味付けより広範な、汎用的な意味付けができるように設計されている筈。

>>336
確かにHTMLどっぷりな我々【誰】には一見メリットはないのだけれど、
多くの人に利用され得る言語として考えると、特にブロック要素などは
確実に一般的な文書を構成するであろう包括的な要素として定義される
ことが好ましいと思われ。

多くの人に利用されるには、利用方法をきっちり決めておいた方がよいとは思うな。
解釈に巾を持たせると、わけがわからないと言って、いいかげんな使い方をする
香具師が出てくるしな。
ま、あんまし厳密に定義すると、反感を買うってこともあるんだろうけどさ。

XMLになったんだし、
細かい意味付けは問題ドメイン毎にきっちり策定されるようになるでしょ。

XHTML2でobject要素にsrc属性とdata属性とを両方とも指定したらどうなるんだろう。
ContentTypeもどちらもtype属性によるから競合するし。

>>341
http://www.w3.org/TR/xhtml2/mod-object.html#s_objectmodule
src属性どこ?

実体参照Embeddingだ。

>>341
えーっと「とあるサイト」へのバナーによるリンク生成時に
<object data="とあるサイトバナーのURL" src="とあるサイトのURL">とあるサイト</object>
となるんでは？

> src="とあるサイトのURL"
href 属性じゃないの？

src は置き換えで href はリンクだと思ってた。違うのかな。

>>346
いや、それであってると思う。

object 要素に src 属性なんか指定してどうするの？って気がする。
グラフ画像を table 要素の src 属性にしている用例から考えると
src 属性を持つ要素自体は src 属性による埋め込みリソースの代替っぽくない？
# ていうか気になるならW3CのMLに投げてみれば？既出かどうかは知らんが。

src属性が、id属性やtitle属性のような一般属性としての扱いなら、
逆にobject要素のdata属性は何なんだ？ということになるが。。。

まだ草案の段階で、両論併記というか、整理できていない感じがしないでもない。

ていうか、XHTML1 の script 要素で、内容と src 属性が
両方とも記述されている場合の扱いはどう定められてるんだろう？

自己レス。HTML4 曰く

> スクリプトは、この SCRIPT要素の内容か、または外部ファイルで
> 定義される。 src属性の設定がない場合、ユーザエージェントは
> 当該要素の内容をスクリプトであると解釈しなければならない。
> src属性の値がURIだった場合、ユーザエージェントは当該要素内容を
> 無視し、このURIからスクリプトを取得する必要がある。

だって。

data と src の併記は、許されるのであれば src 優先だろうね。

XHTMLの欠点は逐次レンダリングができないこと。
全部受信するまでWell-formednessすらわからないんだから
何も表示できない。Netscape登場前の時代に逆戻り。
ローカルで変換する分には関係ないんだろうけど
ネットワークを通して渡すことを前提とした言語にしては
かなりお粗末だと思う。

>>352
逆だろ。
Well-formed であろう事を前提に逐次処理できるほうが
処理コストが掛からないと思うが？
読み込んだ結果、 Well-formed でない文書だったとしたら、
エラー回復コストがそこそこ掛かるかもしれんが、
application/xhtml+xml でそんな腐れマークアップを垂れ流す方が悪いと。

> エラー回復コストがそこそこ掛かるかもしれんが、
それは心配ないでしょ。XMLではWell-formedでない文書の
エラー「回復」は禁止されてる。
むしろ受信途中の段階では明らかにWell-formedではないのに
勝手に
> Well-formed であろう事を前提に逐次処理
を進めていいのか気になるんだけど。

XHTML1.0からXHTML1.1にしたほうがいいでしょうか？

>>355
ruby を使いたいならどうぞ。
application/xhtml+xml の普及に一役買いたいだけなら 1.0 でも充分可能。

>>356
しばらく1.0で様子見ます。
とりあえず勉強だけしといて
thx

つか、勉強しなきゃいけないほど奥が深いもんでもない。
変な本とか変なサイト読まなきゃ大丈夫かと思うんだが。

変なStrict厨の発言を読んだ場合が一番ヤバい感じ。

>>359
余りに匿名ブロックを嫌って、全てのli要素の中のテキストを
（１フレーズしかないのに）p要素で無理矢理マークアップしちゃうような奴？

>>360
やったら dl dl うるさいやつもな。
h* つかえよとか素直に table 使えよってときですら dl にしたがる。
あとふるくさい日本語使ってるやつもいれといてな。

ふるくさい日本語とは具体的に何のことですか。

降臨

昇天

わずか1時間47分の命でした。

新しければ何でもイイノカ？

ものが良ければ何でもいい。

のじたんの日本語はobsoleted

XHTMLの話は終了ですか

WG側の進展がないことには一時停止かと。

obsoletedってvalidなEnglishなのか？

何故？　他動詞にもなるけど。

デイリーコンサイスには形容詞としてしか載ってないんだけど、他の辞書だと違うの？＞obsolete

>>373
どうぞ。
http://www.m-w.com/home.htm

>>374
ありがと。
obsolete[1, adjective]
obsolete[2, transitive verb]
って書いてあったのでobsoletedでも間違いではないのね。

日本人的には、
The br element is obsolete. (あたかも他人事のように)
アメリカ人（英語圏）なら
We make the br element obsoleted, (意志をもって廃止する)

XFrames の Working Draft in Last Call はまだか！

保守

<!--========== 統合リスト ==========-->
<!ELEMENT list (lig)+>
　<!ELEMENT lig l( %list; | (li?,lid*) )+　　-- List Item Group -->
　　<!ELEMENT li (%inline;)*>
　　<!ELEMENT lid (%flow;)*　　-- List Item Description -->

ol,ul（,dl）の置換えとして統合リストを考えました。
項目の中の一部だけにも説明をつけられるというのが一番の改善です。

ordered="yes"を指定するかどうかの基準としては、「順番が要素の内容と同じくらい重要な意味を持つかどうか」です。
ただし、ordered="yes"が指定されていないからと言って、無闇に項目の順番をいれかえるべきではありません。
また、UAはordered="yes"だからといってliの先頭に番号を振る必要はありません。

・序列リストとしての使用例
<list ordered="yes">
　<lig>
　　<li>手順１</li>
　</lig>
　<lig>
　　<li>手順２</li>
　</lig>
　<lig>
　　<li>手順３</li>
　　<lid>手順３は、具体的には…</lid>
　</lig>
</list>

・箇条書きとしての使用例
<list>
　<lig>
　　<li>バナナ</li>
　</lig>
　<lig>
　　<li>みかん</li>
　　<lid>ただし、青いみかんは除く。</lid>
　</lig>
　<lig>
　　<li>りんご</li>
　</lig>
</list>

・（定義リストとしての使用例）
<list>
　<lig>
　　<li>バナナ</li>
　　<lid>黄色</lid>
　</lig>
　<lig>
　　<li>みかん</li>
　　<lid>橙色</lid>
　</lig>
　<lig>
　　<li>りんご</li>
　　<lid>赤</lid>
　</lig>
</list>

>>379
DTDの内容とは直接関係無いけど、
XML DTDではマーク付け宣言の中に註釈を入れることが
認められていないから、コメントを書く時は
独立した註釈宣言にしなきゃINVALIDだよ。

<!--========== 統合リスト ==========-->
<!ELEMENT list (lig)+>
　<!ELEMENT lig l( %list; | (li?,lid*) )+　　-- List Item Group -->
　　<!ELEMENT li (%inline;)*>
　　<!ELEMENT lid (%flow;)*　　-- List Item Description -->

ではなく

<!--========== 統合リスト ==========-->
<!ELEMENT list (lig)+>
　<!ELEMENT lig l( %list; | (li?,lid*) )+> <!-- List Item Group -->
　　<!ELEMENT li (%inline;)*>
　　<!ELEMENT lid (%flow;)*> <!-- List Item Description -->

ということ。

>>382
おお！知らなかった…。
そもそも、DTDの書式があってるかどうかも全然自信ないんだけど…。

thanx!!

忘れていたので>379の案に追加。
<list>の中に<caption>を置けるようにする。

<!ELEMENT list (caption?,lig)+>
　<!ELEMENT caption (#PCDATA | %inline;)>
　<!ELEMENT lig ( %list; | (li?,lid*) )+> <!-- List Item Group -->
　　<!ELEMENT li (#PCDATA | %inline;)*>
　　<!ELEMENT lid (#PCDATA | %flow;)*> <!-- List Item Description -->

う〜む、結構変な部分があるなぁ…。
リストを入れ子にしたとき、すっきりさせたい。

絶対2chからxhtml2に何か取り込んでもらうゾ!!

>>384
なんか、どんどん <TABLE> に近づいてる感じ。

>>384
その %list パラメータ実体はどこで定義されてるの？

>>385
<caption>あたりのこと？
よーし、パパ summary属性もつけちゃうぞ〜、と。

>>386
まだ考えてなかった･･･。
ちょっと変更を加えて、こんな感じはいかがでしょうか？

<!ELEMENT list (caption?, (lig | list)+>
　<!ELEMENT caption (#PCDATA | %inline;)*>
　<!ELEMENT lig (li, lid*)+> <!-- List Item Group -->
　　<!ELEMENT li (#PCDATA | %inline;)*> <!-- List Item -->
　　<!ELEMENT lid (#PCDATA | %flow;)*> <!-- List Item Description -->

http://www.w3.org/TR/xhtml2/
XHTML 2.0
W3C Working Draft 31 January 2003

きたぁぁぁぁ

どこがどうキタんだ？

fool

会話要素ってなんでないの？

http://saitama.gasuki.com/kaorin/
〜oノハヽo〜 ／￣￣￣￣￣￣￣ 　　　　　　　　　　　　　　　
　 (　＾▽＾) ＜　こんなのがございまーす♪　
= ⊂ 　　）　　 ＼＿＿＿＿＿＿＿
= (__/"(__)　ﾄﾃﾃﾃ...

　（　・∀・）＜　こんなのみつけたっち♪
http://muryou.gasuki.com/moe/hankaku10.html
http://muryou.gasuki.com/moe/hankaku09.html
http://muryou.gasuki.com/moe/hankaku08.html
http://muryou.gasuki.com/moe/hankaku07.html
http://muryou.gasuki.com/moe/hankaku06.html
http://muryou.gasuki.com/moe/hankaku05.html
http://muryou.gasuki.com/moe/hankaku04.html
http://muryou.gasuki.com/moe/hankaku03.html
http://muryou.gasuki.com/moe/hankaku02.html
http://muryou.gasuki.com/moe/hankaku01.html

>>388
applet要素書き換えのサンプルがかなり壊滅的…
> <object
> codebase="http://www.example.com/applets/classes"
は明らかに<appletの間違いだし
> #obj1 {width:150; height:150;}
Unitless numberｷﾀｰ

>>388
LinkTypes の Stylesheet は xml-stylesheet 処理命令に
委せて削っちゃえばいいのに。

あと何故か ClassName に使える文字が ID (NAME) 並みに
制限されてるし。XHTML 1.0 までは CDATA で XHTML 1.1 でも
NMTOKENS だったのに何でまた更に厳しくするのか。

＞ClassName
lists.w3.org/Archives/Public/www-html/2003Feb/0125.html
放置されてるっぽいねえ。

>>395
> あと何故か ClassName に使える文字が ID (NAME) 並みに
> 制限されてるし。

NAME 並どころか、これじゃ HTML*4* の NAME っす。
何が困るって仮名漢字 etc. を使えない。

Class*Name* っていうタイプ名から察するに、NMTOKEN でなく
NAME に制限するっていうのは意図通りなのだと思うので、
多分 "letter ([A-Za-z])" ってのが単なる記述ミスだと思うんですが。

# でも、そうだとしたら colons (":") は使えないようにすべきなのでは
# って疑問もある。

>>396
> 放置されてるっぽいねえ。

放置されてます。ﾊｧﾊｧ。

つーか、ひょとして www-html-editor に投げるべきだった?
でも、当時はエラッタじゃなくて意図的にそうしたのかも知れないし
とか考えて、無難に【謎】www-html に投げちゃったんだよなぁ…。

>>397
漏れは 6.1. Core Attribute Collection の class = ClassName っての見たとき
え、クラス名複数書けなくするの？ と思ったりしました。
"This attribute assigns one or more class names to an element;"
とあるわりには複数指定する方法が見つからないんだけど、どっかに書いてある？

>>398
http://lists.w3.org/Archives/Public/www-html/2002Aug/0039.html

一応報告されてはいるけど、side issue だから見落とされたのかも。

そうそう。

>>395
> LinkTypes の Stylesheet は xml-stylesheet 処理命令に
> 委せて削っちゃえばいいのに。

僕もそう思うんですが (script も PI にして欲しい派)、
ドン曰く "PIs considered harmful" らしいので
多分削られることはないんじゃないかなあ…。

まあ "personal opinion" と断ってはいるんだけど、"hope that PIs
would be eliminated as soon as possible." とか言われちゃうとねえ。

http://lists.w3.org/Archives/Public/www-tag/2002Feb/0057.html

>エラッタ
ﾌﾟ

>>401
？

>>401

Not Found

ttp://dictionary.goo.ne.jp/voice/e/02031123.wav

おお

ほしゅ

（＾＾）

話題がない…

http://www.w3.org/MarkUp/xhtml-roadmap/#xhtml-print

XHTML-Print って一体……。

http://www.w3.org/TR/2003/WD-xhtml2-20030506/

久々にｷﾀｰ！

前の草案からの主要な変更点

* normative で RELAX NG スキーマ追加 (>>6 のやつ)
* ブロックレベルのソースコードを示す blockcode 要素型
* object 関連の standby 要素型
* table の summary が要素型に
* title 要素型の内容が (PCDATA|Inline)* に (HTML+ …)
* meta の内容モデルが ((PCDATA|Inline)*|meta+) に (meta の入れ子って一体…)
* style 属性復活(けど、扱いが不明瞭。要修正)
* class は NMTOKENS に(よかったよかった)
* br はまだ必要なんでは? って話が出てる… (Strict-HTML スレ参照)
* ちなみに、hr, h[1-6], strong などについては変化ナシ

>>411
乙。

＞(meta の入れ子って一体…)
メタデータのメタデータって考えられませんかね。
個人的には blockcode の内容モデルが謎。

その他の変更:
* Text Module の分割
* Client-Side Image Map Moduleの削除
* Ruby Module 追加

brが必要なら1.xとか使ってりゃいいのに。
以前もimgだか何だかを削除するなんて論外だ！
とかW3CのMLかどっかで騒ぎ立ててた奴いなかったか？

>>413
＞brが必要なら
自分で追加すりゃいいじゃん、だろ。

>>414
br を追加するってのは XHTML1 の br を使うことに他ならないわけだが。
まさか勝手に XHTML2 に br を追加する訳にはいかんし。

>>415
あい変わらず仕様側が用意した要素型だけで無理やり構造化するつもり？
それじゃHTMLと変わらんなあ。全然eXtensibleじゃない。
漏れは1.xにしても2にしてもそのまま使う気が最初からなくて
どれをベースにするのが改造が楽かを考えてるからそう思うんだろうけどな。

漏れ自身はbr要素についてそう深く考察したことはないけれども
l要素ではbr要素の代替にならないと言う人は
それなりの考えがあるから言うわけで、そういう意見に対して
br使いたきゃ1.x使えってのは相当乱暴な意見だ。
# と思うんだが、brｷﾎﾞﾝﾇって考え無しに出た話なの？

>>416
だからさ、例えば br のない XHTML2 を br を使えるように
「拡張」するって言っても、普通は

<p xmlns="http://wwww.w3.org/2002/06/xhtml2"
>なんたら<br/>かんたら</p>

じゃなくて、

<p xmlns="http://wwww.w3.org/2002/06/xhtml2"
>なんたら<br xmlns="http://wwww.w3.org/1999/xhtml"/>かんたら</p>

でしょ?　XHTML1 使うってのはそういう意味。

別に他の(自分の自由にできる)名前空間を使ってもいいことはいいけど、
わざわざ <br xmlns="http://www.2ch.net/2003/br"/> とかやっても
分かりづらいだけだもの。

XHTML2 にも br が必要云々言ってる人たちは、
専ら後方互換を念頭において話をしてるだけから
(h[1-6] だの hr だのにしてもそうだけど)、それだったら
XHTML2 にそれらの要素型を定義してそれを使うってんじゃなく、
XHTML1 の要素型としてそれらを記述すれば済むことだと思うんだけど。

# 論理要素として br が必要だとか言うなら話は別だけど、
# (納得いく説明を付けて)そういうことを言ってる人は見たことない。

・HTML（text/html）のみを対象にしたUAに対する後方互換性は無視
・対象はapplication/xmlに対応したUAのみに限定
・後方互換性という束縛から逃れて、よりXML的なHTMLを設計する

というのがXHTML2.0だと思ってたんだけど、違うんだろうか。
brとかhnとかは考え方が非XML的だと思うので、2.0では無くしてしまって良いと思うのだが。

>>417
＞でしょ?　XHTML1 使うってのはそういう意味。
そういうことか。了解。

うーん、あのissue読んだときは
brを論理構造とする主張でも出たのかと思って興味そそられてたんだが。
後方互換とかって安い話なのかなあやっぱ。別にbr欲しいわけじゃないんだけどさ。

>>418
＞よりXML的なHTMLを設計する
これは微妙かも…と思う。
「XML的/非XML的」の語意が不明瞭なので断言はしないが。

>>420
変な用語を使ってｽﾏﾇ
<h2/><p/><p/><p/><hr/><h2/><p/><h3/><p/>...
という風に要素が並んでいてスキーマがないと構造が分からないものよりも
<section><h/><p/><p/><p/></section><section><h/><p/><section><h/><p/>...</section></section>
という風に要素ツリーが構造をそのまま表しているものでは、
後者の方が汎用のXML処理系で扱いやすいし、他の名前空間の
要素を埋め込むコンテナとしても扱いやすいのではないかと。
そういうつもりで。

処理系は楽なのかも知れんが、文書はややこしくなるな。

>>422
漏れのサイトのXMLそんな感じ(>>421)なんだけど、普通のエディタだと混乱するね。
かなり。同じような要素が並ぶから。だから、書き間違えちゃったりして、
XSLTプロセサが文句言ってきて、行番号調べたりなどの間違いしで少し手間取ることがある。
でもあるセクションをいきなり他のセクションにぶちこめたりできるのは便利。

そんな感じです。

XMLの編集には専用のツールが必要だと思うよ。

IEって拡張子で読むかどうか決めてんの？
xmlから、htmに変えたら読んでくれたよ

>>425
IEは、Content-Typeや拡張子なるものは一切調べず、
内容を自分勝手に判断してレンダリングしてくれます。

たとえば、拡張子をjpgにして、Content-Type: image/jpeg として、
内容がHTMLのファイルを送るとHTMLとしてレンダリングされます
（この機構を利用したブラクラがありましたね）。

>>426
いつの実装だよ。

それじゃXHTMLを application/xhtml+xml で送ると
ダウンロードダイアログ出すことの説明つかねーじゃん。

説明なんてつかなくっていいんだよ>>426は

知ったかぶりｽﾏｿ

MSがもっと情報を出してくれればいいんだけれどNE!

>>430
＞どNE!
＞どNE!
＞どNE!
＞どNE!

…

ドットNET！！みなさん、社員が居ますよー！

>>431
これほど「オマエガナー」というレスがしっくりくる書き込みを久々に見ました。

.neck//黄昏の首輪伝説

情報をよこせと雛鳥のように囀る奴ほど
MSが実際には情報を出しているのに調べようともしない
http://msdn.microsoft.com/workshop/networking/moniker/overview/appendix_a.asp
IEは知らないMIMEタイプ(たとえばapplication/xhtml+xml)は
尊重することがわかる。
知っているMIMEタイプに対してはまず内容をsniffするが
どんな場合でも拡張子を一切見ないわけではないこともわかる。

　　　 　∧＿∧
ﾋﾟｭ.ｰ　(　　＾＾ ） ＜これからも僕を応援して下さいね（＾＾）。
　　＝〔~∪￣￣〕
　　＝ ◎――◎ 　　　　　　　　　　　　　　　　　　　　　山崎渉

>>434
＞実際には情報を出しているのに調べようともしない
そういう輩はそもそも調べ方を心得ていない場合が圧倒的に多いので
その情報の探し出し方も披露しておくと助言としてはより効果的かと。

>>436
「site:msdn.microsoft.com Internet Explorer MIME-type」で
ぐぐったら先頭に出た
ポイントは「site:msdn.microsoft.com」かな

あげとこ

野暮ウ

XHTML-DTDに独自のDTDをプラスして文書を作成した場合、
独自DTDの要素記述には名前空間を使うわけですが、
どうやっても結局Validityなんて達成できませんですね。。

Valid信者としては、真の意味でextensibilityを得たければ、
XHTMLの要素を一部ぱくって、独自XML文書型を作成しなきゃいけないのかな？

しかし、一本の独自DTD(or スキーマ)で書き上げるのは、さすがに疲れるな。。

え、DTD上書きするんじゃないの？

そのためにflatっていう展開されてるDTDがあるじゃん。
あれをちょこちょこ書き換えるのがいいんじゃないかな。

xhtml11-flat.dtdの直接編集って
html要素直下にp要素置くようなことも出来ちゃうわけじゃん。
あれはそういうことのためのDTDじゃないと思うぞ。

モジュールと、必要なモジュールを組み込むためのDTDを自作、が
恐らく正攻法(というか想定される使用法・設計法)かと思われ。

こういうことは出来ないの？（以下イメージ）

new.dtd
#include "自作.dtd"
#include "xhtml11.dtd"

自作.dtd内で独自要素を追加。
xhtml11の内容モデルとかの一部を自作.dtdで書き換え。

>>444
実体参照でできまくりです。

できまくりですか。ありがとう。やっぱ仕様書読まんといかんね…　XHTMLMODは苦手だ

既存のXHTMLにある要素の意味を変えちゃうとかすると問題だと思うが、
（だれもそんな事しないだろうが、例えばblockquoteをinlineにしちゃうとかな）
今までにない新しい要素を追加するならいいんじゃなかろうか。

例えばリストモジュールにcodelistってのを新設して
<codelist>
<li>function(){</li>
<li>・・・・</li>
<li>}</li>
</codelist>
みたいなのとか
（改行の有無に意味があるプログラミング言語だと結構切実だとおもう。）

>>446
SGML時代からずっとある機能ですが:

<!ENTITY xhtml11 PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">

としておけば、 %xhtml11; で任意の場所にXHTML1.1の文書型定義を挿入可能でし。
文書型の拡張についてはXHTMLMODのAppendix-D,Eが参考になる…かも。

>>448
さらにありがとう。勉強してきます。

　__∧＿∧_
　|（　　＾＾ ）|　＜寝るぽ（＾＾）
　|＼⌒⌒⌒＼
　＼ |⌒⌒⌒~|　　　　　　　　　山崎渉
　　 ~￣￣￣￣

ハッキリ言ってアメリカなどの多民族国家では黒人の方がアジア人よりもずっと立場は上だよ。
貧弱で弱弱しく、アグレッシブさに欠け、醜いアジア人は黒人のストレス解消のいい的。
黒人は有名スポーツ選手、ミュージシャンを多数輩出してるし、アジア人はかなり彼らに見下されている。
(黒人は白人には頭があがらないため日系料理天などの日本人店員相手に威張り散らしてストレス解消する。
また、日本女はすぐヤラせてくれる肉便器としてとおっている。
「○ドルでどうだ？(俺を買え）」と逆売春を持ちかける黒人男性も多い。）
彼らの見ていないところでこそこそ陰口しか叩けない日本人は滑稽。

>>451
コピペ

XHTML 2.0は要らないのではないかと思うがどうか

煽りではないが、思えばいいんでないの。
根拠の提示されない意見では議論出来ないのだし。

ドラフトのXHTML 2.0の仕様、HTMLをXHTMLにした時生じた矛盾を場当たり的に解消しようとしているのがミエミエなんだよね。
じき破綻するのが目に見えている。

てことはXHTML2.2ですか。

XHTMLもバージョン3にならないと使い物にならないんじゃないか？

>>455
場当たり的でも、今ある矛盾がとりあえず解消されれば、解消された分だけマシ。

別にXHTMLを恒久的につかいつづけるわけでもあるまいし。

解消しようとはしているが、解消されてはいない。

そもそもDTDに拘束され続けているから、extensibleも何もあったもんじゃない

拡張ってDTD上書きして実現するんじゃないのか？

>>460
DTDの限界に拘束されるのがいやならXMLスキーマでもRELAX-NGつかえばいいじゃないか

XHTML 2.0は不要ということでよろしいか？

あなたの脳内だけでならよろしい

XMLスキーマやRELAX-NG使ったらXHTMLは要らんじゃないか？

>>463
お前にとっては不要ということで宜しいんではないでしょうか？

おれはsection/hとか、blockレベルの要素を格納できるpとか、汎用属性hrefとか
色々欲しいけど。

別に最初から完璧なものなんか期待してないし、規格名に「HTML」を
含んでいる時点でそもそもHTMLの呪縛を完全に断ち切るなんてムリなのは最初から解ってる訳で。

勝手に期待して、期待が大きすぎて、失望すると「全部駄目」とか言い出すのはちょっとみっともない。

>>465
Web上に文書を書くだれもがXMLスキーマやRELAX-NGを使えるならその通り。

XHTMLをだれもが使えると思ったら大間違いだ。俺は使えねえ。

学ぶ気のないやつには無理だわな。

>>468
少なくとも2chに書き込みできるならtextファイルかけるだろ。
それでいいじゃん(藁

学ぶ気がありゃだれもがXMLスキーマやRELAX-NGを使えるようになるんでないかい？

つーか、html4.01,xhml1.0,xhtml1.1が勧告されたときは
W3C信者、strict信者が新規格に素早く対応して、我先にと
自分のサイトを新しいDTDに従って記述し始めたのに対し、
今回のxhtml2に対応しようとする動きは、彼等の間でもかなり鈍い。

その事実こそが、xhtml2が期待はずれであったことを物語っている。

XHTML 2.0はまだドラフトだがな

先走って使ってるサイトはないの？

あったね確か。随分前に見たような。

>>474
>>19-

brがXML的でないからline要素を作る、という発想が場当たり的だ。
pの中にブロック要素を入れられるようにする、というのも、気持ち悪い。

<p>今日の晩飯は
<ul>
<li>ラーメン</li>
<li>ぎょうざ</li>
<li>ビール</li>
</ul>
だった。</p>

みたいに書くんだろ？ 「だった」が何となくおちつかない。

慣れだろ。

＞brがXML的でないからline要素を作る、という発想が場当たり的だ。
じゃあ、他に改行が意味を持つ場合の表現方法は？

＞pの中にブロック要素を入れられるようにする、というのも、気持ち悪い。
そんな個人的な「気持ち」を語られましても(藁

>じゃあ、他に改行が意味を持つ場合の表現方法は？

改行に意味があるんなら、改行をマークアップしなければならないんじゃないかい？
line要素は改行をマークアップしていないぜ。

>そんな個人的な「気持ち」を語られましても(藁

一般に、匿名ブロックが出来るマーク付けは好まれないとえび氏も言っているよ。

<DIV>
テキストその1。
<P>テキストその2。</P>
</DIV>

すみけん氏も、ブロックを閉じた後に「匿名ブロック」をぶら下げられるのは気持ち悪い、と言っているね。

<UL>
<LI><P>文1</P>
文2
</UL>

これと

<p>今日の晩飯は
<ul>
<li>ラーメン</li>
<li>ぎょうざ</li>
<li>ビール</li>
</ul>
だった。</p>

と、どこが違うんだい？

>>480
＞改行に意味があるんなら、改行をマークアップしなければならないんじゃないかい？
ああ、失礼。それはその通り。

l(ine)要素に関するものなのだから「行」にかんして質問すべきだった。
んで、行が意味を持つ場合の表現方法はどうします？


あと匿名ブロックに関しては元来CSSに関する用語であって、SGML/XMLの用語ではない。
また、HTML4.01の流れを汲むX/HTMLで同レベルでのブロック/インラインの混在が
発生するのは確かに好ましくないが、XHTML2.0では、「p要素でそれが可能」としている
訳だから、ここでは(SGMLとかXMLとか言うレベルではなく、HTML4.01とかXHTML1.0とかの
個々の仕様レベルでの)概念がシフトしたと考えるべき。

えび氏やすみけん氏が仕様策定者だってんなら、その名前に権威を感じて、
仕様に無い概念に関しても従おう、と言う気も起きるが、他人の名前を使って
しかも新たな仕様に関して古い仕様に関する解説の引用で「だから好ましくない」
とか「気持ち悪い」とか言われましても(藁

具体的にどのように匿名ブロックがXML的に好ましくないのか説明できるもんなら
してほしいし、また、仮にこのましくないなら、それこそ匿名ブロック分を
l要素なり、(lが妥当でないなら)div要素なりで囲えばいくらでも回避できると思うが？

もうちょい勉強しれ。

行が意味を持つ場合って、どんな場合ですか？
つか、line要素がどうして作られたか、知ってますか？

概念がシフトしたつったって、わけわかんね。シフトするのは正しいことだとでも思っているのか?

>また、仮にこのましくないなら、それこそ匿名ブロック分を
>l要素なり、(lが妥当でないなら)div要素なりで囲えばいくらでも回避できると思うが？

それを場当たり的っつーんだよw

>そんな個人的な「気持ち」を語られましても(藁

>えび氏やすみけん氏が仕様策定者だってんなら、その名前に権威を感じて、
>仕様に無い概念に関しても従おう、と言う気も起きるが、他人の名前を使って
>しかも新たな仕様に関して古い仕様に関する解説の引用で「だから好ましくない」
>とか「気持ち悪い」とか言われましても(藁

個人的かどうかが問題なのに、個人の権威に話をシフトしていやがる。
こういうシフトはよくないね。反省しる！

横レス。
Pにブロックを入れられるようにするよりも、
インラインのリスト要素を作るとか。
Inline List→ILとか。

>>484
リストだけでもol,ul,nl,dlの4種あって、さらにインラインのテーブルと、
インラインのpreとかインラインのフォームとかつくって、さらに今後
そういう新しいブロックの概念が誕生するごとに全部インラインの奴も作るの？

pなど特定ブロック要素にブロック+インラインの内容を認めればそれで済むのに？

匿名ブロックが駄目、という理由があればとにかく、無いなら非効率過ぎ。

ブロック要素の中にインラインでブロック要素を埋め込むならobjectをかませばいいじゃないか？

>>486
中に入るブロック要素がobject要素の（仕様的な）内容ならそれもいいな。

DTD的におｋかどうかってだけなら、body要素の中を全部divにしちまえばいいが、
そうは行かんのと同じ理由でobjectかませばいい、と言うのは解決策になってない。

>>483
んで、匿名要素が駄目な理由は？

こういうシフトはよくないね。反省しる！

＞んで、匿名要素が駄目な理由は？
匿名「ブロック」要素だよ。

反省する。

どっちにしろ個人的な話か。

>>479晒しage

DTD的におｋかどうかってだけなら、body要素の中を全部divにしちまえばいいが、
そうは行かんのと同じ理由で、pの中にブロック要素を入れていい、とするのは
解決策になってない。

＞中に入るブロック要素がobject要素の（仕様的な）内容ならそれもいいな。

DTD読め。HTMLの仕様でもobject要素の中にはブロック要素を入れられる。

>>492
後半部分の引用部は君が思っているような意味ではないと思ったぞ

>>492
＞DTD読め。
日本語読め。

>>479
お前こそ日本語読めないんだろ？
「個人的な」気持ちじゃねえだろが。複数の人間が感じていることなんだよ。

>>495
だから、それはHTML時代のルールな。

あと、こう言う規格って、多数決できまんのか?
匿名ブロックが理論的によくない理由を、説明してくれ、って俺は言ってんだぜ。

なんか、お前の中では5〜6名が「1+1が2なのは気持ち悪い」って言い出すと
数学的真理にまで疑念の余地が生じそうだな。

>>495
もういっこ補足。

「個人的意見」とか「個人的感情」ってのは、複数の人間が同じことを言っても、
やっぱり「個人的意見」や「個人的感情」であって、事例が２、３あるから
個人的ではない、と言う意味で「集団的なもの」にはならない。

ただ、複数の人間が同じ個人的意見を述べている場合、そこに万人が
そう感ずる理論的理由がある場合が多い、と言うだけで、この種の論理的な
（コンピュータの文書フォーマットなんか、純粋論理からの産物いがではありえない）
理由があるなら、考慮に値するが、そうではなくて、単にその内容が
「気持ち悪い」といってるだけなら、やっぱりそれは「個人的な〜」と
評されるべきであって、考慮には値しない。

なんだ、やっぱり日本語の問題だった(藁

英語なら

<p>The main reasons are :</p> <!-- ←ここで文章が完結している -->
<ul>
　<li>foo</li>
　<li>bar</li>
　<li>baz</li>
</ul>

とできるが、日本語の場合リストの前で文章を完結しない場合がある。

<p>主な理由は、
　<ul>
　　<li>ほげ</li>
　　<li>ふげ</li>
　　<li>はげ</li>
　</ul>
です。</p>

文章そのものを書き換えれば済む話なんだが、本からの引用か何かで
文章を書き換える訳にはいかない理由がある場合もあるので、p要素の中に
リストを包含できるようにしておいた方がいいように思う。

確かに匿名ブロックが気持ち悪いというのは理解できるんだけどね。

もういっちょ>>479晒しage、と。

＞<p>The main reasons are :</p> <!-- ←ここで文章が完結している -->
リストまで含めてひとつの文。
英語の場合でも、一つの文の途中で段落を分断した
おかしなマークアップと言える。

「匿名ブロック気持ち悪い」ってよく聞くけどさ、
「彼は"ほげ"と言っている」「主な理由は、ほげ・ふげ・はげです。」はよくて、
「彼は
　　ほげ
　と言っている」
「主な理由は、
　　・ほげ
　　・ふげ
　　・はげ
です。」はダメって言ってるんだよね。
p に内包可能にしようとしている要素の想定されるデフォルトスタイルに
とらわれすぎだと思うのだが、どうか。

>>499
晒されてるのはお前だよ。

>>479の痛さは>>483がわかりやすく書いてくれてますが。

W3C Working Draft - XHTML Text Module
8.14. The p element
http://www.w3.org/TR/2002/WD-xhtml2-20020805/mod-text.html#sec_8.14.

XHTML™ 2.0
W3C Working Draft 6 May 2003
8. XHTML Block Text Module
8.7. The p element
http://www.w3.org/TR/2003/WD-xhtml2-20030506/mod-block-text.html#sec_8.7.

どうしてpの下に直接pを書けないんだろうね？

<p>
「匿名ブロック気持ち悪い」ってよく聞くけどさ、
「彼は"ほげ"と言っている」「主な理由は、ほげ・ふげ・はげです。」はよくて、
「彼は
　　ほげ
　と言っている」
「主な理由は、
<ul>
<li>ほげ</li>
<li>ふげ</li>
<li>はげ</li>
</ul>
です。」はダメって言ってるんだよね。</p>
が可だとしたら、

...
<html>
...
<body>
<div>
「匿名ブロック気持ち悪い」ってよく聞くけどさ、
「彼は"ほげ"と言っている」「主な理由は、ほげ・ふげ・はげです。」はよくて、
「彼は
　　ほげ
　と言っている」
「主な理由は、
<ul>
<li>ほげ</li>
<li>ふげ</li>
<li>はげ</li>
</ul>
です。」はダメって言ってるんだよね。</div>
</body>
</html>
が不可である理由は何？

>>506
div では意味が伝わらないから、だろうね。

そのケースで、実際にマークアップに困って
過去にStrictスレに質問投げてきたのは一人二人じゃない。
あのスレではしばしば回答として
A: パラグラフを途中でぶった切る(構造に妥協)
B: 矛盾が出ないように文章側を直す(文章に妥協)
等の妥協案を与えてきたが、>>506 の例だって
C: データ構造を重視してdivを適用(意味に妥協)
なわけで、相当問題のあるやり方だけれども
その問題性はA,Bの場合と大して変わらん。どのやり方をとっても、
もとの問題を何一つ解決できてない、validなだけの不自然な文書。

p に List や Table を入れられるようにってのは
こうした従来のHTMLが抱えている問題の解決策として出ている話なわけで
それがおかしな策だと思うなら、代案を考えて欲しい。
ブロック/インラインの並列するデータがおかしいと思うなら
まず内容セットFlowの廃止を訴えることから考えた方がいい。

>>506-507
極論の上に *仮* の話をするが、

仮にHTML4.01に「ブロックレベルを内包したいp要素はdivで代行しても良い」
と言った類の例示がでていれば、(どうやってその他のdivと、p代行のdivの
区別をつけるか、と言う手段はさて置いて) こんな不毛な論争 (にもっなってないが) も
しなくて済むんだがな。(勿論その場合、現状のdlの様な、どこまで拡大解釈を
認めるか、という別の問題が浮上する)

俺個人としては実は >>506 のマークアップ法を完全には否定しない。
>>507が指摘している問題があることは良く承知しているが、しかし

<pre class="code"><code>…
…
…</code></pre>

例えばこんなマークアップに関しては、好ましくないとしつつも
黙認する人も多いんじゃないか？

既にインライン要素にcodeがあるのに、ブロックレベルに存在しないからと言って
divやpreがその代行をし、あるケースにおいて許容されるなら、他のケースで
拒否する理論的な理由はない。

>>479ってよくあんな恥ずかしい発言しといて居座れるね。
>　こんな不毛な論争
にしてるのは>>479が余計なところに突っ込んで自爆したからだと思うんですけどね。

DTDを超えたレベルの議論はStrictとしては不毛？

>>479からセルンの匂いがする。

>>509
うむ。是非とも「匿名ブロック」が「容認されるべき」または「否定されるべき」
論理的理由を仕様やSGMLやXMLの見地から明確に述べて俺なんかひねり潰しちゃって欲しい。

「気持ち悪いからヤダ」とか「あの人が駄目って言ってるから駄目」なんて
幼稚な相手ならとにかく、ちゃんと理性的な発言をできる人なら俺なんか
論破するのは簡単な事だから。

ジャズ紳士よりセルンの方がまだマシ

>>510
DTDを超えたレベルでも、仕様レベルの論議は有益だし、
仕様を超えたレベルの話であっても、他の関連する仕様から、
解釈上の問題をどのようにマークアップレベルで対応するか、という論議も有益。

(この例えは既に語り尽くされた感があるが) XHTML1.0 strictで容認されている
「hr を、しかし、自主的に使用禁止すべきか否か」などは不毛ではないし、
そのような見地から次世代のXHTML2.0はどのような姿であるべきか、また、
発表されている草案からW3Cはどのような思想を現在持っているのか、を
考えることは非常に興味深く面白いとおもう。

>>512
言ってる意味がよくわからんけど要は構ってってことでしょうか？
なんかこの数レスで>>479以外は普通に意見交換できてるように見えるけど、
論破とか幼稚なこと言ってるのは>>479だけですよ。

論破とか言うとこあたり本格的にセルン臭い。

所で、セルンって何?

欧州原子核共同研究所しか心当たりないけど、それだと意味わかんねぇし。

スルー↓

>>512
> 俺なんかひねり潰しちゃって欲しい。
> 「気持ち悪いからヤダ」とか「あの人が駄目って言ってるから駄目」なんて
> 幼稚な相手ならとにかく、ちゃんと理性的な発言をできる人なら俺なんか
> 論破するのは簡単な事だから。

なんだただの荒らしか。

>>479
ラベリングだから、数字外せば。

>>479はテーブルレイアウトも「DTD的にValid」ならば容認しかねないな。

>>520
>>479自身が >>487 で
＞DTD的におｋかどうかってだけなら、body要素の中を全部divにしちまえばいいが、
＞そうは行かんのと同じ理由でobjectかませばいい、と言うのは解決策になってない。
っていってるけどな。

>>479 も >>479 だと思うが、反対派のレベルが余りに低い。

>>512
論破って…。

>>479が論破がどうとかしょうもない煽りを入れなければ
読む価値のあるレスの流れだったのにな。
なんだろうこの既視感は。

メタ議論にすりかえるのが何件か。

てかー、別にいいじゃん。
xml使えばparagraph elementの内容にordered list elementを含めたり、
思いのままに定義できる。
結論：xml使いになりましょう。みなさん。

>>525
現行のXHTMLMODで %p.content; を書換えた文書型を設計すりゃいいのさ。
ｲｸﾅｲって言う人多いんだろうけどねw

>>526
現行のXHTML-Basicで(特にコアとされているものの)解釈や内容を変えちゃう場合は、
名前空間 http://www.w3.org/1999/xhtml は避けた方がいいと思う。

XHTMLからスピンアウトした独自の名前空間を持ったXMLって位置づけなら
誰もイクナイとは言わないかと思われ。

>>527
仕様にそういうことが書いてあるなら納得してやるよ。

>>525-527
その具体例としての XHTML2 だと思いますが。

>>528-529
勿論、XHTML2.0が勧告されたあとはそれでいいとおもうよ。
実際XHTML2.0の名前空間はXHTML-Basicのそれとは別なんだし。

今回のスレの流れ「XHTML2.0は場当たり的な物で、イラネ」って話が出て、
>>479 は多分それに反対したくて変なことになったんだと思うんだけれども

1: 匿名ブロックは本当に良くないのか
2: l(ine)要素は小手先の解決なのか
ってな点が興味深かった。

ちなみに「2」に関してはプログラミング言語を解説する文章を書くとき、
preでもbrでもlでもいいからとにかく「改行位置を特定する方法」か
「1行を特定する方法」ってのは何らか必要だと思う。
そして、マークアップはポイントではなく、範囲を表すほうが相性がいいというなら
brよりlの方が良いかな、と言うのが俺の意見。

で、1に関しては結局気持ち悪いって言った人はどうなんだろう。
実はおれも気持ち悪い、と思う１人なんだけれども「それはHTML4.01時代の
感覚なのでXHTML2.0時代には捨ててください」といわれると、
そうなのかなぁ、と言う気もしてくる。

>>507
＞まず内容セットFlowの廃止を訴えることから考えた方がいい。
これに関しては(匿名ブロックｲｸﾅｲ派)廃止を訴えたいが、
技術的な問題があるので解決しておく。

匿名ブロックｲｸﾅｲとしてはFlowは ((inline)+ | (block)+) としたい所だ。
こうすれば、inlineかblockがはいっても、両方が入って匿名ブロックが発生する事はない。

ところが例えば div の内容を ((inline)+ | (block)+) とすると、

例１：<div> <p>contents</p></div>

このように div と真の第一子たる p の間に半角スペースの混入が許せなくなる。
なぜならパーサは先に半角スペースがあった場合それがinlineの内容なのか、
tagの開始に先立つ無視すべき内容なのかの判断ができないからだ。

これに関してパーサはtagの開始に先立つ半角スペース、改行、tabを解析前に
掃除してしまえばいい、と思うかもしれないが、そうすると、

例２：<p>My name is <em>hoge</em></p>

の(ベタテキストでの) is hoge が ishoge に化けると言う問題が生じる。
当然、例２を避ける為に、先に解析すればいいのだが、先に解析すると
今度は例１の問題が復活する、と言う訳だ。

したがって、
＞まず内容セットFlowの廃止を訴えることから考えた方がいい。
とあるが、「Flowの廃止」は訴えたいが、技術的にできないからしてない
と言うのがこの場合の解答となる。

>>479が出て来さえければいい流れになりそうな予感。

ていうか
inline/blockという区分けだって便宜上のものでしかないし。
<p>文章<a href="...">文章文章<em>強調</em></a>文章文章</p>
と書いただけでさえ（CSSでいえば）匿名のボックスが三つもできるわけだし。
匿名ブロックだけなくしたところで、上記のような匿名のインラインボックスが残っている以上、DOMツリーを走査する際の手間に何ら変わりはないし。

なので、匿名ブロックだけを廃止する論なら、自分は賛成できない。

>>528
名前空間は、特定語彙(要素名とか属性名とかエンティティとか)の意味するところを
保証するものなんだから、拡張するならまだしも、書き換えちゃったら駄目でしょ。

仕様とか以前に名前空間の意味が無くなる。

>>534
確かにDTDはエンティティの名前としてinlineとかblockとか使ってるだけで、
実際ブロック要素か、インライン要素か、と言うのは気にしていないので、
匿名インラインはOKなのに匿名ブロックだけ嫌がるのは変、と言うのは同意。

ただ、
＞匿名ブロックだけなくしたところで、上記のような
＞匿名のインラインボックスが残っている以上、
＞DOMツリーを走査する際の手間に何ら変わりはないし。
これはDOM側のテクノロジ上の都合じゃなくて？

例えば連続した同一階層にあるテキストノードをDOM Rangeに格納するクラスとか
作れば解決する、「DOM側」の話であって、新しいXML系言語を作る時には
考慮しなくていい事だと思うけど。

>>532
( (#PCDATA|%inline;)* | (%block;)* ) は
XML1.0 の生成規則[45]-[51]にそわないので不可。

匿名ブロックｲｸﾅｲなんて言ってるの日本だけじゃないの？と思ったりする。
もし国外でもそういう議論があるなら、当然www-htmlにも出てるだろうと
検索してみたんだが "anonymous block" で１件しか引っかからない。
www-htmlやHTML WG内でそういうが議論が出たことってあるんだろうか。

匿名ブロックを嫌うのは勝手だけど、嫌いだからって「望ましくない」と
仕様策定者の意図であるかのように流布するのはやりすぎだろと思う。
望ましくない理由って、嫌いとか気持ち悪いとか、そんなんしかないの？
ブロック要素・インライン要素・文字データが並列することに
どんなデメリットがあるのか、そのデメリットは
インライン要素・文字データだけの並列なら発生しないのかを
説明してもらわないことには納得できない。

>>535
「ここに〜と書いてあるんだからダメ」みたいなレスを期待していたんだが
やっぱそういう記述はどこにもないのか。残念。
#「常識で考えろ」みたいな不文律は脳内仕様の混入する余地が多すぎる
# (珍解釈が出回りまくる)から嫌いでしてね。

>>537
＞( (#PCDATA|%inline;)* | (%block;)* ) は
＞XML1.0 の生成規則[45]-[51]にそわないので不可。
ええっと、だからSGMLでは非推奨とされ、XMLでは不可としている
理由に関して解説したつもりなんだけれども？
長文で申し訳ないけど、とりあえず、レスは読んでからつけてね。

＞匿名ブロックを嫌うのは勝手だけど、嫌いだからって「望ましくない」と
＞仕様策定者の意図であるかのように流布するのはやりすぎだろと思う。
ここにいるのが仕様策定者じゃないのは明白。勘繰り過ぎ。
俺が仕様策定者だったら、2chネラなんか相手にせず、直接XHTML2.0のWGにメールだすよ。

＞ブロック要素・インライン要素・文字データが並列することに
＞どんなデメリットがあるのか、そのデメリットは
＞インライン要素・文字データだけの並列なら発生しないのかを
＞説明してもらわないことには納得できない。
一言で言えば「同じレベルのデータは同じレベルに書く事の強制」。
全く同じレベルに存在すべきテキストデータがあり、一方は段落を成し、
もう一方が既存のXHTMLの要素には無いものであった場合
<div><p>段落を成すテキスト</p>既存の要素には無いテキスト</div>
とするよりも
<div><p>段落を成すテキスト</p><div>既存の要素には無いテキスト</div></div>
とした方が好ましい。

で、匿名ブロックを禁止することにより、例えばpにブロック要素を含めなくなる代わりに
と言う表現を許さないデメリットと引き換えに、上記で述べた
「強制」同一レベル化フォーマットが実現できる。

なんつーか ISO-HTML の見出し出現順位の是非の論争みたいなもんで、
「不自由の代償として一定の厳格さが保証される」フォーマットと、
「自由の代償として、厳格さを失った記述が『一部』で容認される」フォーマットの
是非に関する話だと俺は思ってる。

蛇足だけど、じゃあ、俺個人はと言うと、>>531の最後の段落で述べたとおり

ま、その上で勧告されたXHTML2.0が気に入らなければ、俺が個人的に使わない事にするよ。
別にXHTML2.0が1.xを上書きするわけじゃ無いしね。

>>538
だったら、
<p><em>強調を成すテキスト</em>既存の要素には無いテキスト</p>
よりも
<p><em>強調を成すテキスト</em><span>既存の要素には無いテキスト</span></p>
の方が好ましいんじゃないの？
インライン要素とベタテキストに限っては同じレベルでいいと思うのは何で？

>>537
＞「ここに〜と書いてあるんだからダメ」みたいなレスを期待していたんだが
＞やっぱそういう記述はどこにもないのか。残念。
ハァァ？

じゃあ、教えてやるよ
http://www.w3.org/TR/REC-xml-names/#sec-intro
だよ。

namespace in XML の一番最初の「Motivation and Summary (動機と要約)」
にかいてあるよ、どうして名前空間が必要なのか、が。

悪いんだけど、仕様も読まず、ググりもせず、思いつきを書き込んで、
思い通りの返事がないとダダこねるの辞めてくれる？

>>541
ども。読んでみるよ。

>>540
強調されたテキストと、強調されてないテキストは
既にレベルが違うからこの場合は
<p><em>強調を成すテキスト</em>既存の要素には無いテキスト</p>
が正しい。

強調を含んだ、何らかマークアップすべき、しかし、既存の要素には無いものの場合、spanを使う。

具体的な例としては、後半部分の内容がルート要素で宣言したものと違う言語の場合は、
他言語という要素が無いのでspanで代行して
<p><em>強調を成すテキスト</em><span xml:lang="xx-xx">(xx-xx語の)既存の要素には無いテキスト</span></p>
となるのはご存知のとおり。

>>536
その一手間が必要なのが「手間」という意味でつ。
余計な条件分岐が必要な分、処理速度が低下するのは避けられないし。

>>543
そういうことを言ってるのではなくて、
あくまで匿名のボックスができるのが望ましくないというならば、
#PCDATAを内容に持てる要素型を一種類だけに限定した上で
<p><em><text>強調</text></em><text>地の文</text></p>
こう書かなければならないのでは、という話。

>>544
＞あくまで匿名のボックスができるのが望ましくないというならば、
だったら、それを主張している奴に聞いてくれ。
少なくとも俺じゃない。

>>536
＞その一手間が必要なのが「手間」という意味でつ。
＞余計な条件分岐が必要な分、処理速度が低下するのは避けられないし。
具体的にどの程度？

XHTML2.0は過去のHTMLの制約からの脱却を行う事になる。つまりそもそも
HTML語群のみに対応した HTML用 UA から XML パーサとしてのUAにその処理の対象が移る。

はっきり言って、(例えばIEやMozillaの開発が滞るほどの) 技術的困難を伴うなら
とにかく、既に DOM Range などの技術的問題解決の方法が示され、また実装されている以上、
理論的、思想的是非を押しのける理由になるとはとても思えない。

どうせ、コンピュータなんか、数年もすれば速度が２倍、３倍と速くなるんだから、
勧告当初に「贅沢なリソースを必要とする規格」であっても、１年２年で解決する。
そして、XMLの規格の寿命はその比ではないのだから。

>>546
御意。PCのパワーの向上が解決してくれるのはわかっとります。
匿名ブロックをなくすべきという主張の根拠の一つに「効率をよくするため」というのがあったと思うので（勘違いならｽﾏｿ）、
効率云々言うならそういうところにも病的なまでにこだわるのが当然なんじゃないのか、
そこに特にこだわらないんなら効率云々は根拠にならないだろう、と。

h/sectionとh1〜h6/divが文書の構造を表わすための要素として平行して存在するのは無駄だよな。

>>548
俺もそう思う。h1-6がどうしても使いたければ、XHTML1.0の名前空間で
使えば良いんだから、もし、後方互換とか考えてるなら、すっぱり切るべきだと思う。

あと、汎用属性hrefはいいけど、個人的には XLink の全面採用をしてほしいなぁ。
XHTML2.0の処理対象はXMLパーサなんだから、他のXML系規格で定まってる内容に関しては
各々それを使うと言う事で。

>>548-549
禿同。
でもdivには残ってもらわないと困る。

例えばブロックレベルでの xml:lang の格納要素として。

結局の所 >>454-463 の流れは一体なんだったのか。


l要素と匿名ブロックの話はこの100レスくらいの中で、概ね、問題ないことが
確認されたと思っているのだが、他に問題はあるのだろうか？
マジな話、問題があったり、場当たり的な対応をしていると言うなら
知っておきたい。

// h1-6を残しつつ h を追加が場当たり的、と言うならそれはそう思う。

>>532
Flow.mix ::= (Inline.mix|Block.mix)
のような内容モデルの定義は XML DTD でこそ禁止されてますが、
RELAX NG や XML Schema では問題なく記述可能ですんで、
「技術的にできない」ということはないです。
今後の Flow.mix の定義変更も有り得ないことではないと思います。

実際、blockquote li dd td なんかの内容に関しては
(Inline.mix|Block.mix) の方が適切だと思いますしね。

RELAX NG なら

<define name="Flow.model">
<choice>
<zeroOrMore>
<text/>
<ref name="Inline.class"/>
<ref name="Misc.class"/>
</zeroOrMore>
<oneOrMore>
<ref name="Heading.class"/>
<ref name="Block.class"/>
<ref name="List.class"/>
<ref name="Misc.class"/>
</oneOrMore>
</choice>
</define>

こんな感じですか。

あと、以下余談ですが

>>538
> ええっと、だからSGMLでは非推奨とされ、XMLでは不可としている
> 理由に関して解説したつもりなんだけれども？
> 長文で申し訳ないけど、とりあえず、レスは読んでからつけてね。

>>532 をそんな風に読めというのはちょっと無理ではないかと。
漏れも「それは SGML DTD の話で、XML DTD では not well-formed」
みたいなレスを付けようかと思ってました。

DTD と言った場合、通常/現在は XML のそれを指すものと思われ。
特にこのスレは XHTML2 についてのスレである訳ですし。


それと、「技術的な問題」云々というのは
ttp://math.oheya.to/markup/notes/0302#day25-1 辺りを
参照しての書き込みかと思いますが、あれは *現状* の Flow.mix の
定義が (Inline.mix|Flow.mix)* となっていることについての
単なる「歴史的経緯」を述べたものであって、その制約が未来永劫
続くことを述べているわけではありませんので、ひとつよしなに。

ありみかたん生きてる

>>552-552
１：今現在、本来「(Inline.mix|Block.mix)」を意図とするが、
　　DTDの技術的都合で「Flow.mix」になっているものがあるかもしれないこと。
２：その技術的都合は解決の目処が立っており使用スキーマの変更で本来意図する
　　「(Inline.mix|Block.mix)」になるかもしれない事

は解った。

で、結局の所、その技術的都合が解決したら「Flow.mix」は滅びるべきなの？
それとも今現在ＷＤにあるようなp要素は本来の意図として「Flow.mix」を
内容とすべきなの？

話がずれたり、荒れたりしてるけど、一番重要なのは、ここな訳で。

蛇足：
＞実際、blockquote li dd td なんかの内容に関しては
＞(Inline.mix|Block.mix) の方が適切だと思いますしね。
この blockquote li dd td はどの名前空間の要素？
XHTML1.xのこれらの要素に関しては確かに(Inline.mix|Block.mix)の方が相応しいように
俺も感じるが、XHTML2.0ではどう？

>>555
重箱の隅だけつついて申し訳ないが、XHTML2 WD の p が内容にしようとしているのは
一部のブロック要素であって Flow.mix ではない YO!!

結局、 >>505 の事例のベストな解決は何なのか、だろうねえ。
Flow.mix 撲滅派は p の理想的な内容モデルとして
( Inline* | ( l | List | blockcode | blockquote | pre | table )* )
あたりを考えてるのかなと勝手に思ってたけど
よくみりゃ l 要素が Inline Text Module で考えられてるじゃんね。

>>556
＞p が内容にしようとしているのは一部のブロック要素であって Flow.mix ではない YO!!
そでした。失礼。

defはともかくとしてsampとかcode とかvarとかkbdってさ、コンピューターに関する文章のための要素じゃん。
そういうのはXHTML2.0に含めないで他の規格に分けたほうが良くない？ せっかく複数のネームスペースが一緒に使えるXMLなんだし、過去のしがらみを忘れて大改造するんだし。

今日の刺激！
http://homepage3.nifty.com/coco-nut/

（＾＾）

>>558
じゃあ、XHTML2.0が含めるべき分野ってどこまで。
ベーシックな文書構造が有する要素の範囲とは？

例えば原稿用紙にテーブルって概念ないから、テーブルいらない？
subとかsupはどう？

逆に日付を記述する為のdate,year,month,day要素なんかは今のHTMLの使われ方
みてたら必要じゃない？

って言うレベルで論議すると、XHTML2.0の設計なんか何時までたってもできないから
とりあえず「いままでのしがらみ抜きにXHTMLを再設計したら」ってことじゃない？
一応XHTMLの名前は継承するわけだし。

tableは要らないな

tableはモジュール分けされてるからいいじゃん。

>>558
varは数学系とか物理系の文章だと使うと思うよ

開発したのが研究所だから名残が残ってるのか

XHTML 2.0 って何か意味あんの？

>>565
だったらとっくにmathMLとかがとりこまれているんでは？

>>566
現行のXHTML1.xシリーズで満足している人には不要です。（マジレス）

>>567
XHTML 1.xで満足していない人が2.0で満足するとしたらどういう点で? (マジレス)

従来のHTMLの文書構造に不満があるのはわかるけど、
2.0の変更がそれに十分こたえられるのか、どんな良い点があるのか
がはっきりしないと、わざわざ変える必要は無いのではないかと思う。

>>568
> 2.0の変更がそれに十分こたえられるのか、どんな良い点があるのか
> がはっきりしないと
それは自分で調べることだと思いますが。

>>568
＞2.0の変更がそれに十分こたえられるのか、どんな良い点があるのか
＞がはっきりしないと、わざわざ変える必要は無いのではないかと思う。
別にここはXHTML2.0の紹介スレでも、普及促進スレでもないぜ。

＞従来のHTMLの文書構造に不満があるのはわかるけど、
そうじゃなくて、お前に不満があるか、ないか、だよ。
お前に現行XHTMLに対する不満があるなら、その部分がXHTML2.0の草案で
解決されているかどうか確認してみろよ。

お前が別にXHTML2.0はXHTML1.xを上書きするものではないんだから、
現行XHTML1.xに不満が無いならそれで満足してればいいし、
不満があるが、XHTML2.0でも未解決だったり、あるいは中途半端な解決案しか
でてないようなら、そのとき初めてこのスレで「なんでXHTML2.0はこんななんだ」
と言えばいい。

ちなみに、俺がXHTML2.0のメリットと考えるのは、
seciton/h の部分と href の汎用属性化と p の内容属性の拡張、
それに幾つかの重複要素の削除(たとえばimg)かな。

特に重複属性の削除は、CSSやXSL、DOMの記述時に大変助かる。

ゴメン。
＞お前が別にXHTML2.0はXHTML1.xを上書きするものではないんだから、
＞現行XHTML1.xに不満が無いならそれで満足してればいいし、
は

別にXHTML2.0はXHTML1.xを上書きするものではないんだから、
お前が現行XHTML1.xに不満が無いならそれで満足してればいいし、

の誤り。

HTMLで満足してるのですが、XHTMLに移行しなければいけませんか？

>>572
HTML であっても strict に書いてあれさえすれば
利用者も不便は感じないんじゃないかな。

>>572
>>573 に禿同

ちなみにXHTMLへの変換はプログラムが可能なので
HTML > XHTML と1段階通せば、XMLとして XMLパーサなどXMLの恩恵が
受けられるようになります。

そのうちサーバ側が勝手にXHTMLに変換してくれる時代も来ると思うので、
HTMLで満足している人は極力正しいHTMLを書くことに注意していれば
本格的なXML時代が到来してもリソースを無駄にする事なく、
スムーズに移行できるかと思います。

>>570
ようするに、XHTML 2.0には他人に説明できるような利点はないってことだね。
そんなに必死に糊塗しなくてもいいよ。( ´_ゝ`)

>>575
？？？
ちゃんと下に利点と思われるもの書いてあるけど…？
え、必死に糊塗？ん？？
>>575ってよくわからん

えっと…どうやったら>>575の結論に達するのか、誰か日本語の達者な方説明して下さい。

一言でいうと釣りってことじゃないかな

xhtml2.0が勧告された場合使ってみたいのですが古いUA用にxthml1.1の代替ページも用意しようと思っています。
その場合どのような構成にするのが良いでしょうか。
私が今考えているのはxhtml1.1の方をメインにしてlink要素でalternateとしてxhtml2.0のページに張るというものです。

IEだとどっちにしても読めませんがな… あ、application/xml派の方ですか。
でも余計な記述増えますしねえ…

>>580
？？XHTML1.1は読めると思うが。

>>579
自分で適当にXMLで言語作って、それをXHTML2.0とXHTML1.1にXSLTで変換すれば楽？なのかな？

>>581
ちゃんとパーサに処理させるとIEは(IEのパーサのバグで) XHTML1.1を
えつらんできません。

>>579
まずは、XHTML2.0が勧告されたときのUA状況次第では有りますね。
最大手のIEが例えばある日パッチ当ててXMLパーサとしてまともになるかもしれない(今のところ望み薄ですが)。

そしたら、気兼ねなくXHTML2.0をメインで公開できる訳で。

で、本題。
＞古いUA用にxthml1.1の代替ページも用意しようと思っています。
こう思ってるなら、当然 XHTML1.1がalternate
＞私が今考えているのはxhtml1.1の方をメインにしてlink要素でalternateとしてxhtml2.0のページに
こう思っているなら、XHTML2.0がalternate

どっちがメインでどっちが代理でもそんなのは書き手が自由にして良い領域なんだから、
貴方次第だと思う。

>>582
書き手が自由にして良い領域だからこそ決めかねてるのよ

>>583
じゃあ、「俺なら」 XHTML2.0メインで「XHTML1.0が代理」だな。(not 1.1)
XHTML1.xがメインつとまるならXHTML2.0は（俺的に）要らない。

１．HTML1.xじゃ力不足だからXHTML2.0が必要とされて、XHTML2.0で文書が書かれる。
２．そんでも、閲覧者側UAとかの都合上従来のXHTML1.xが必要とされて代理でXHTML1.xも用意される。

多分こう言うプロセスで２つの文書が書かれるから。

もしサーバ側がコンテキストネゴシエーションを許可してくれるなら
XHTML2.0をapplication/xhtml+xmlで、XHTML1.0をtext/htmlで公開。

そんでこの場合、代理の(従来フォーマットの文書）はtext/htmlにしたいので、
XHTML1.1ではなく、XHTML1.0を推奨します。

穏当な判断だ。

rel="alternate" と rev="alternate" を使えば
メイン文書と代替文書の両方でその関係を表現できそうだな。

>>581
実は静的にですが、XMLから変換しようと画策してます。XSLTもだいたい書けてます。
昔はemacs-lispからhtml4.01に変換してました。

>>582
すいません書き方が変でした。メインはXHTML2.0版ですが、サーバー側でUAを見て出力を切り変えとかできないので古いブラウザ用に代替ページを最初に表示したい、という意味でした。

というわけで>>586さんの案を使って、代替文書をまず表示してrev="alternate"としてXHTML2.0にリンクを張るのが良いかな、と思ってます。

　　　 (⌒V⌒)
　　　│ ＾ ＾ │＜これからも僕を応援して下さいね（＾＾）。
　　⊂|　　　　|つ
　　　（＿）（＿）　　　　　　　　　　　　　　　　　　　　　　山崎パン

XHTMLやらDHTMLやらわけわからん。なんじゃそりゃ？
XHTMLは新しいなんか規格で推奨されてて今度からこっちを使った方がいいですよ〜
みたいな奴でしょ?これとCSSで書いてくださいね〜みたいな、じゃあDHTMLとか
ってなんじゃらほい？
これってもう使わないほうがいいの？

まだまだあるわな　CHTMLとか

>>589
HTMLもXHTMLもDHTMLもCHTMLもCSSも、兎に角凡そコンピュータの規格を
「良く解らないけど、新しいし、推奨されてるから」程度の理由で使うべきではない。

例えばHTMLは解ってるけどXHTMLは良く解らない、と言うならHTMLをつかってればOK。

ちなみに、HTMLを本当に良く解っていて仕様の大切さを知り、守る人は
まず >>589 の様な書き方をしない。

DHTMLは規格じゃないよ。

MHTMLなんてのもあるよ
Mはマクロの略ね

>>591 えらそぶるな！！おもんないんじゃｳﾞｫｹｶﾞ!!

>>594
（　´_ゝ`）ﾌｰﾝ

DHTMLはたしかにわけわからんな

>>592
公開か、非公開かはしらないけど、ＭＳの規格では？

少なくとも誰かの脳内にはないと、IEが作れない訳で。

>>597
おいおい、DHTMLが何か分かって言ってるのか？

>>597
http://yougo.ascii24.com/gh/search/?pattern=DHTML

DHTMLって技術用語みたいに言われてるけど
Dynamic(動的な) HTML ってだけでどっちかっつーと普通の英語だよね。
もともと静的なものであるHTMLを動的にするために駆使される
各種技術の混成物を言うこともあるし
そうして作られたHTML文書を言うこともあるし。

マークアップ言語が動的になってどうすんだっつーのな

>>601
文書に動きが出る

文字が動いたら読みにくくてしょーがないだろ

文章は動かないよ
DHTMLの文書を読み込んだIEやNNが動くらしいよ

>>604
IEやNNは動かないよ
徹夜続きで頭おかしくなった奴が勝手に動くらしいよ

自然と動態視力が鍛えられる　ｳﾏｰ

>>603
なにやら、一部のDOM利用HTMLまで否定した予感。

ユーザのアクションに対して答える形で動的に変化する文書ってのは、
物によってありだよね。と余りに当たり前のことを言ってみる。

マークアップ言語が動的だと、何を信じてマークアップすればいいのやら

379って何だ…。ごめんなさい

動的って、marquee とか blink のことを言ってるんでしょう？（違

XHTMLで<br />って使えないんですか？
使えますよねぇ〜？
絶対ココでエラーが出るのですがなぜでしょうか？

とりあえずソース見せてくれ

HTML文書が動的なのは良いがHTMLが動的だったら困るって話だと思ってたけど。

上は省略しますがXHTMLの宣言とかです。
<link rel="stylesheet" type="text/css" href="top.css" title="top" />
</head>
<body>
<div class="colorname">
<ul>
<li><a href="選択.html">選択</a></li>
<li><a href="選択.html">選択</a></li>
<li><a href="選択.html">選択</a></li>
<li>Bbs</li><li >Links</li>
</ul>
</div>
<br />
<div>ココに内容があります。</div>
<br />
<div>ココにも内容</div>
<br />
<br />ここから数行に渡って続きます。本当は
<br />
<br />
<p><a href="http://validator.w3.org/check/referer" class="image">
<img src="img/w3c.gif" alt="Valid XHTML 1.1!" height="31" width="88" /></a>
<a href="http://jigsaw.w3.org/css-validator/validator?uri=http://www.myurl/index.html" class="image">
<img src="img/vcss.gif" alt="Valid CSS!" height="31" width="88" /></a></p>
<div>
<address>Copyright © 2003<a href="mailto:メールアドレス">秘密</a>. All rights reserved.</address>
</div>
</body>
</html>
だいたいこんな感じなんですが・・・本当はもう少し<br />って多いのですが、
ここに書き込むのに改行が多すぎるとゆうエラーが出るので減らしていますが
場所は<br />があるところにあと７行ぐらい書いてます。

……………

614 はネタ。

>>614
（ ﾟдﾟ）ﾎﾟｰｶﾝ

>>614
（ ﾟдﾟ）br多すぎですぜ・・・
間隔はﾏｰｼﾞﾝとかで開けましょうよ・・・

HTML3.2からやりなおせｗ

やっぱまずいっすよねぇ〜？これじゃあ。まぁもっと煽られてボロクソ言われる
と思ってたので比較的よかったです。
もっとHTML勉強して出直したほうがよさそうなのでそうします。
失礼しました。
それと<br />自体のエラーの出る理由ってありますか？

一応勉強のため教えていただけませんか？

何行目でエラー出るんだよ

>>620
DTD嫁

>>620
body直下にインライン要素の<br />を置いてるから

ありがとうございました。１から勉強して出直します。

どうして>>614級のアホが初心者スレでなくこのスレを選んだのかが疑問。

本当の初心者だったから

悪かったの〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜

このスレは開始後すぐに初心者スレまたは糞スレになって現在に至るわけだが。

>上は省略しますがXHTMLの宣言とかです。

XHTML 1.0 Transitionalならvalidではあるが

一応<br />以外は1.1でも十分valid

><div class="colorname">
><ul>
><li><a href="選択.html">選択</a></li>
><li><a href="選択.html">選択</a></li>
><li><a href="選択.html">選択</a></li>
><li>Bbs</li><li >Links</li>
></ul>
></div>

の div は要らん。 ul に class="colorname" を入れとけば良い。

>>632
おまえが決めることでない。全体の構造見てから言え、アホ。

わかったんすよ！！要はインライン要素である<br />の前に
<p>とか<h1>とかいれたらいいんすよね〜

見出しの中で改行…

その他の至らないところはこれから勉強するとゆうことで勘弁してもらって
<br />の所だけ限定でいえばそうゆうことですよね〜？

色々すいませんでした。ありがとうございました。
<div>は色をまとめて表示するのに使っているのですが、だめですか？

そうゆうことってどうゆうこと？

>635
ありえない話じゃないでしょ？
（共通ロゴ画像）
ページタイトル
とか

h1 img{display: block; }

>>638
>>639

だから、そもそもbrは（ry

２ちゃんねるが書き込みの中の改行をbr要素にするのは構わないが、
>>638は明らかに（ｒｙ

そかそか，それでいいですね，頭悪い
>642
頭悪いついでに，略してある部分を略さずに教えていただけないでしょうか？

>>643
わかっｔ（ｒｙ

頭悪いってことですね，納得です

絡むわけではないですがもう一点だけ
○○○○：
■■■■■■■■
という場合（両方文字）は？■は例えば○の日本語訳とか
○か■を span で囲んで class 振って block が普通なんですね？
お答えは strict スレでいただければ

>>645
table か dl でも使えば？

>>645
ruby

>>645
dfn

>>645
marquee

>>645
頭が悪いうえに自分で調べようとしない姿勢がどうしようもない。
strictスレじゃなくて初心者スレ行ってな。

The World Wide Web Consortium (W3C)
Leading the Web to Its Full Potential...

なら

<h1 id="logo"><img alt="The World Wide Web Consortium (W3C)"
height="48" width="315" src="Icons/w3c_main" /></h1>

<h2 id="slogan">Leading the Web to Its Full Potential...</h2>

だな

>>611
マルチポストするときはその旨明記しましょう。

勝手なルール作るな

>>653
そろそろ夏休みも終わるが宿題は大丈夫か？

どーでも良いが毎年のようにこの時期になると
「読書感想文 フリー」で検索してウチに来るヤツが居るんだが
どうしよう。

「フリー」ってねぇ…。何を考えてるんだろうな。

結構有るんだな。

Google 検索: 読書感想文 フリー
http://www.google.co.jp/search?num=100&hl=ja&inlang=ja&ie=Shift_JIS&c2coff=1&as_qdr=all&q=%93%C7%8F%91%8A%B4%91z%95%B6+%83t%83%8A%81%5B&lr=lang_ja

>>654
アクセスアップしたいときはこの２語をキーワードに入れろということだな！
よーし、がんばってアクセス稼ぐぞー！

以上、厨房でした。

伺いたいのですが、
<p><a href="http://validator.w3.org/check/referer" class="image">
<img src="img/w3c.gif" alt="Valid XHTML 1.1!" height="31" width="88" border="0" /></a>
<a href="http://jigsaw.w3.org/css-validator/validator?uri=http://www.aaa.com/index.html" class="image">
<img src="img/vcss.gif" alt="Valid CSS!" height="31" width="88" border="0" /></a></p>
としたときに二つある画像の前の画像の<img>の中のborder="0"だけがW3Cの
チェックに引っかかります。エラー箇所は下記です。
... 1.1!" height="31" width="88" border="0" /></a> <a href="http://jigsaw.w3.org
エラーの詳細は
Below are the results of attempting to parse this document with an SGML parser.

Line 34, column 141: there is no attribute "border" (explain...).
こんなのですがなぜですか？
後ろの画像につけているborder="0"はエラーになっていません。

すいません。ややこしいので簡単に説明しなおします。
W3Cのバナーにリンクつけていてそのバナーのどちらにも
border="0"で周りについている囲いをなくしているが、
前の画像につけたborder="0"だけエラーがでる。
後ろのcssのバナーにつけたborder="0"はエラーが出てないのに
前のXHTML用のバナーにつけているborder="0"にはエラーがでる。
それはなぜでしょうかとゆうものです。

九月七日（日）に全国のｺﾝﾋﾞﾆでうまい棒を買占めようというオフ会です
この日以降は買わないようにして、ｺﾝﾋﾞﾆを驚かそうとする予定です。

更に突然売れたことを記念して、製造会社がうまい棒の日に制定する事を目論む予定です。
方法は単にｺﾝﾋﾞﾆでうまい棒を買えばいいだけ！　簡単です。
九月七日はコンビニにゴー
元ネタスレ（お笑い板）
http://human2.2ch.net/test/read.cgi/owarai/1058701840/l50
本スレ
http://off.2ch.net/test/read.cgi/offevent/1061691902/

まとめてスレ違い

DOCTYPEくらい書けよな。
とりあえず、XHTML1.1 とかでは border は駄目です。

> 後ろのcssのバナーにつけたborder="0"はエラーが出てないのに
> 前のXHTML用のバナーにつけているborder="0"にはエラーがでる。
> それはなぜでしょうかとゆうものです。

Validator の出来が悪いから。

>>662 そうなんすか？Validatorって出来悪いんすか？
じゃああれでエラーチェックすんのってあんま意味ないんすか？

もっと出来の悪いお前のサイトをチェックするのには役立つ

フィードバックを…

>>663
擦れ違い

W3C信者にサイトを正しい記述に直して貰うスレ3
http://pc2.2ch.net/test/read.cgi/hp/1061741473/

xml to xhtml ga tigau mono dato sitta noha saikin desu.

ちがうというか、包含関係だ。概念のレベルが別。

SGML ≒ HTML (1)
SGML ⊃ HTML 4.01
XML ⊃ XHTML

図で書くなら

　SGML ∋ HTML
　 ∪
　XML　∋ XHTML

だと思うが。

つーか、"SGML ≒ HTML (1)" って何のことよ?

age

SGML →（派生）→ HTML 、 XML
XML ⊃ XHTML

XMLはSGMLの派生規格かもしれないが、
HTMLはSGMLの単なるサブセット(部分集合)。

XMLってSGMLアプリじゃなかったの？

適合SGML文書として成立するように設計されてはいるけど
XML用のSGML宣言はnon-normativeだよ。

>>669, >>672
意味不明。

>>673-674
・HTML は SGML アプリケーション
・XHTML は XML アプリケーション
・XML は SGML のサブセット

というのが一般常識と思われますが…。

> HTMLはSGMLの単なるサブセット(部分集合)。

SGML に対する HTML みたいなのは、アプリケーションとか
応用とか具体例とか表現するのが慣例です。
確かに集合論的にはサブセットって表現も可能ではあるけど、
SGML/XML の世界の用語としてはちょっと意味合いが違うので…。

> XMLってSGMLアプリじゃなかったの？

違います。XML アプリは必ず SGML アプリになります(*)が(十分条件)、
XML の仕様それ自体はそもそもアプリケーションじゃないでしょう。
SGML は SGML アプリですか?　違いますよね?

* 規定の SGML 宣言を補えば。

>>675
non-normative ではあるけど、そもそも整形式の XML である時点で
その SGML 宣言に適合しちゃいますし…。
まあ SGML 宣言が記述がされていない時点で、
それそのものとしては SGML 非適合である、という意味では
異論ありませんが。

>>676
> 違います。XML アプリは必ず SGML アプリになります(*)が(十分条件)、
> XML の仕様それ自体はそもそもアプリケーションじゃないでしょう。
これはいいとして、

> SGML は SGML アプリですか?　違いますよね?
この文の意図がわからん。ひょっとして、
SGMLはSGMLアプリでないから、XMLもSGMLアプリでない、って演繹なのかしら…
なんか繋がってない気がするのは気のせい…？

>>678
> XML の仕様それ自体はそもそもアプリケーションじゃない
すなわち「メタ言語の仕様それ自体はアプリケーションとは言わない」
ってことの補足説明のつもりでした。つーか蛇足でしたね。

初期のHTML(1.0)はSGMLに合致してないところがあるので、SGMLからのただの派生。

この手の話、HTML 1.0 と i18n 以降を一口にHTMLというのはどうか。

>>679
なるほどthx。

>>680
HTML と言ったら少なくとも HTML 2.0 以降で
RFC なり W3C Recommendation なり ISO なり JIS なりに
なったものを指すのが普通の感覚だと思うんだが。

HTML1(謎) だの HTML+ だのに言及するときは
断りくらい入れるべきじゃないかしらん。

# ひょっとして >>669 もそういう意味なのか…?
# SGML ≒ HTML (1) と書かれちゃ、HTML1 がメタ言語みたいだよ…。

誰かここらへんの話を正確にわかりやすくまとめてくれ。

できればベン図も添えてほしい。

次にお前は「まって! 便座もついでに添えて!」と言う!

まって! 便座もついでに添えて!・・・あっ！

ベンザエースsage

XForms and XML Events Are W3C Recommendations

XForms 1.0
http://www.w3.org/TR/2003/REC-xforms-20031014/

XML Events
http://www.w3.org/TR/2003/REC-xml-events-20031014/

>>688
ｷﾀ━━━━━━(ﾟ∀ﾟ)━━━━━━ !!!!!

>>690
今夜のズリネタにします…

あ、>>690 → >>688 ね。

W3C萌え。

>>690

おもしろい!

XForms 1.0 Basic Profile
http://www.w3.org/TR/2003/CR-xforms-basic-20031014/

サブセットも作ったのか。
XML Schema にもサブセットが欲しかったなぁ……。

XForms は結局 XSD だけで勧告ですか。
Relax NG への変換は大した労でもなかろうけど、
XHTML 2.0 の勧告までにはどのみち DTD も
誰かが書かなきゃならないだろうにね。

# この辺をきっかけに、XHTML 2.0 が勧告までに
# DTD を破棄するようなことがあればいいんだけども、
# 多分そうはならないだろうしな…。

そういや、任意の要素型に *ホスト言語の* ID 型属性を記述できる、
ってのもそのまま勧告になったのか…。

http://www.w3.org/TR/2003/REC-xforms-20031014/slice3.html#structure-attrs-common

ホスト言語の ID 型属性がグローバルに定義されてりゃいいけど、
XHTML みたいにローカルで定義しちゃってる場合、
XForms の名前空間に勝手な属性を追加することになっちゃうが…。
xml:id の勧告まで待つべきだったんじゃないのかなあ…うーむ。

まあ XHTML 2.0 の ID 型属性も勧告までには xml:id に
なってるだろうとは思うのだけれども。

XML Events いーかげんですが邦訳しますた。
ttp://www2u.biglobe.ne.jp/~oz-07ams/prog/xml-events/Overview-ja.html

>>696
お疲れさまです。つーか仕事はやいなあ(感動)。
是非とも [email protected] にも報告して下さい。
参考: http://lists.w3.org/Archives/Public/w3c-translators/
ここに報告すると、W3C の翻訳一覧にも掲載されてみんなハッピー。

# base 要素は外した方が便利なんじゃないかなあ?
# 目次のリンクや参考文献へのリンクはページ内参照(謎)の方が
# (つまり、<a href="#なんたら"> の方が)ベターなような。

>>697
PRとかCRの頃から訳し始めてればRECのときは差分だけ訳せばいいので
比較的楽というか仕事は全然はやくなかったりします。

＞base要素
RFC的は基底URIに関係なく"#hoge"は当該文書を参照する部分識別子なんですけどね。
大した理由もないので外しました。ご指摘どもです。

# 英語わかんないから報告できない…とか言ったらダメですか？

>>698
> RFC的は基底URIに関係なく"#hoge"は当該文書を参照する部分識別子なんですけどね。

RFC2369 読み返してみたら、確かに…。うわあ…知らなかった…。
ごめんすまん…つーかショックだ… IE も Moz も駄目じゃん…。

> # 英語わかんないから報告できない…とか言ったらダメですか？

Subject: Japanese translation of XML Events

Hi translators,

I have translated XML Events http://www.w3.org/TR/2003/REC-xml-events-20031014
into Japanese. The translation is available at:
http://www2u.biglobe.ne.jp/~oz-07ams/prog/xml-events/Overview-ja.html

Comments are welcome.

こんな感じでいいんじゃない?
つか、実利上は訳したモノとアドレスさえ判れば問題ないでしょ。
さあ、報告しる!

>>699
報告したよぉぉぉぉぉぉ！
恥ずかしながら丸々コピペさせていただきますた。激感謝ありが�dです。

I have translated XML Events.
って、
I translated XML Events.
じゃだめなの?

別に深い理由は無いんでないの？

>>701
終わったということを強調するんだったらいいんでないの？
W3Cの方々も仕事の速さにビックリ射精しちゃうよ。

現在完了の方が自然だよ

>>700
乙。つーか英語間違ってたらｽﾏｿ(w
そういや、今の邦訳集がこっちなの忘れてた。
http://www.w3.org/2003/03/Translations/byLanguage?language=ja

>>701-704
ぶっちゃけ www-translators ML に投稿してる人の文章を
リミックスしただけなんで、深い意味はないです(ぉ

でも >>704 の言うように現在完了(謎)の方が自然と思われ。

MathML2SEきたね。
http://www.w3.org/TR/2003/REC-MathML2-20031021/

XML 1.0 Third Editionｷﾀ━━━━━━(ﾟ∀ﾟ)━━━━━━!!!!
http://www.w3.org/TR/2003/PER-xml-20031030/

ごめんなさいごめんなさいカナブンよりごめんなさい。
今更ですが >>2 にコピペミスがあったことに気付きました。

> XHTML 2.0 についての意見は www-html-request@w3.org へ投稿しる

というのは、www-html@w3.org の間違いです。

ただし、www-html@w3.org に投稿するためにはこの ML を
あらかじめ subscribe する必要があるので、
*それ用の* アドレス www-html-request@w3.org に
件名を "subscribe" と書いたメールを送って下さい。

ということで訂正でした。

# それにしても 6th Draft でませんね。

話題がないので保守がてら、これまでのおさらい。

草案以前
　　http://www.w3.org/2001/09/21-orf/xhtml-family/slide22-0.html
1st draft
　　http://www.w3.org/TR/2002/WD-xhtml2-20020805/
　　http://www.satoshii.org/markup/notes/2002/08
　　http://www.mk-net.jp/cgi-bin/misc/diary.cgi?200208A#d20020806m02
2nd draft
　　http://www.w3.org/TR/2002/WD-xhtml2-20021211/
　　>>206
　　http://www.mk-net.jp/cgi-bin/misc/diary.cgi?200212B#d20021213m01
　　(消えている…)
3rd draft
　　http://www.w3.org/TR/2002/WD-xhtml2-20021218/
　　>>232
4th draft
　　http://www.w3.org/TR/2003/WD-xhtml2-20030131/
　　>>283-285
5th draft
　　http://www.w3.org/TR/2003/WD-xhtml2-20030506/
　　http://tr.vis.ne.jp/diary/d200305a.html#d08a
　　>>411-412
　　http://www.kanzaki.com/book/html/spec-nofollow.html#xhtml20

実装例
　　http://w3future.com/weblog/gems/xhtml2.xml
　　http://www.w3.org/2003/Talks/1114-W3CDay-Japan/mi-iaweb/demo/hybrid.xhtml

関連仕様など
XML 1.0 Third Edition (PER)
　　http://www.w3.org/TR/2003/PER-xml-20031030/
XForms 1.0
　　http://www.w3.org/TR/2003/REC-xforms-20031014/
XML Events
　　http://www.w3.org/TR/2003/REC-xml-events-20031014/
　　http://www2u.biglobe.ne.jp/~oz-07ams/prog/xml-events/Overview-ja.html
HLink 1.0 (WD)
　　http://www.w3.org/TR/2002/WD-hlink-20020913/
MathML 2.0 (SE)
　　http://www.w3.org/TR/2003/REC-MathML2-20031021/

これは?実装例には入らない?
http://www.remus.dti.ne.jp/~a-satomi/bunsyorou/Camino_benriSet/sample2.xhtml

>>711
あ、失念してました。
まあリンクが XLink だったり XHTML1 だったりするのは
やや反則だけど (w　CSS の実装例って意味ではアリでしょう。

そうそう、CSS の実装例と言えば、nl のスタイル例を含む
http://homepage2.nifty.com/tomchem/xml/xhtml20.xml
というのもありましたね。

ロードマップ更新されました。Last Call は来月だそうです。

つーか XHTML 2.0 と XHTML-Print 以外全部 TBD なんですけど…。
はっきり言って XHTML-Print のロードマップなんてどうでもいいしなあ。

草案以前の情報といえば、こんなのもありましたね。

http://pc.2ch.net/hp/kako/1008/10083/1008380243.html
(>>83-126 辺り)

>>103に未来から手紙を出したくなった…。
なんかなつかしいな。

あるといいなリスト
・会話文を示す要素
・反強調(コメント?)を示す要素

>>716
> 会話文を示す要素
ってのは、対話文を dl で書く代わりになるもの、と解釈してええ？

>>717
返事をもらえるとは……。

それとは違って、小説なんかで出てくる会話文です。
日本語の場合は大体、
・鍵括弧でくくり
・前と後で改行が入り
・複数行になる場合の二行目以降は先頭が一文字分インデント
てな感じです。

l なり line なりってことかな

会話文と段落とは違うのかしら

>>720
（ ﾟдﾟ）ﾎﾟｰｶﾝ

　ちがうから、会話か否か、段落か否かで４パターンあるよ。

　ちなみに、小学校で教えてくれる「改行してかっこを書きましょう*1」
ってのは段落と見なすタイプ。段落なので、行頭１文字目は字下げるするのだが、
"「"には、半角の字下げが含まれていると見なされるので、"「"が行頭に
くる場合は字下げしない、となっており、「改行してかっこを書く」」となる


*1 会話に続き「と、」がくる場合などは、「と、」以下が会話の段落に
付け足されることになる。

ロードマップがまた TBD に。

>>718
＞・複数行になる場合の二行目以降は先頭が一文字分インデント
最近の小説はそういう様式なの？

XHTMLにこだわってる奴って、具体的にXHTMLをどんな風に活用してる？

>>724
手元の小説はそうでなかった。
うーん…

>>725
XMLからXSLTで変換してるから自動的にXHTMLになる。「活用」方法っていったら
XMLとの親和性ぐらいしかHTML4.01からのアドバンテージはないんじゃない。
後は要素が整理されたぐらいかな。XHTML2.0はだいぶ要素に変更があるから
HTML4.01から移行するだけの根拠にはなるかもね。

俺はXHTMLをPHPのXMLパーサでXMLとして読み込んで、
iモード用のページとして出力させたりしてる

>>725
Xlinkを埋め込んでる。
異なるネームスペースを複数つかうようになるとXMLの利点がでる。

＞XMLからXSLTで変換
SEO対策はどうしてるんだよ

>>730
SEO対策って？XMLファイルだとクロールされないって意味なら、実際に
アクセスされるのはPHPだからあんまり関係ない。

> XMLからXSLTで変換してるから自動的にXHTMLになる。
XSLTはHTMLへの変換も可能なのでXHTMLになることの理由にはならないのでは。

XMLだとクロールされないの？
だったら世の中のXHTMLで書かれた文書は皆検索結果に出てこないような…

そもそも、検索エンジンって何でファイルの種類を見分けているんだろうか。
拡張子だけが見分ける手段だったら、
XHTMLでも拡張子をHTMLにすれば済む（？）話だが

メディアタイプがapplication/xmlの場合とか？

そんなときは「GIF89a ﾀﾀﾀ」で検索。

>>732
HTMLへも変換できたんだ。知らんかった。meta要素とか空要素の閉じタグ
が無いと変換するときに怒られない？

>>733
表現が悪かった。拡張子が.xmlだと、っていう意味ね。絶対数が少ないのも
あるとは思うけど
ttp://seo.ecjapan.jp/product/am_g_report_02.htm
みると.xmlが2件しかないからGoogleには嫌われてるのかと思って。

Googleはメディアタイプがapplication/xhtml+xmlのページを
「不明なファイルタイプ」とみなすらしい。

http://www.toybox.jpn.org/studio/weblog/2004/200401.shtml#td1000

>>737
一応、*.xmlのファイルも取得されてるっぽい。
http://www.google.com/search?q=index.xml

XHTMLの理由？ emacsのxml-lite-modeが使えるから。

>>739
ファイルタイプ不明になっちゃってるな…

>>739
解説がいっさい表示されないからSEO的観点から見ると使えないな…

SEO 云々って、それは bot の実装がしょぼいのが問題なのだと思うが。
文句は google へ言うべ。

Wikiからの変換って、XHTML2.0になるとやりやすくなるかな?
headerとかsectionとか、置換に便利そう。

googleに文句言ってそれがすぐに繁栄されるなら問題ないがな

ストリクトたんでもそんなことを問題にするの？

そこで application/xhtml+xml と text/html のコンテントネゴシエーションですよ

strictしてる動機によっては気になるだろうね。

XHTML2.0ってもう使えるの？

今はまだ策定中で草案がいくつか出ているだけの段階の仕様です。
まあ、その辺理解した上で使うのは自由ですが。

>>750
ありがとう

そう無理して上げなくてもいいんですよ。

というか、XHTML2.0にしろ何にしろ、
UAのシェアの問題が越せない限り、新しい仕様は作るだけ無駄な罠

当分はXSLT行きですよまったく。

http://www.w3.org/TR/xhtml2/の
>A list of current W3C Recommendations and other technical
>documents can be found at http://www.w3.org/TR.

の"http://www.w3.org/TR"って正しいURIで書くと"http://www.w3.org/TR/"だよね？
4.01の勧告読んでも同じ表記だったんだけど、W3Cの文章ってみんなこうなの？

リダイレクトで飛ばしているようだ。

「正しい」って何よ。>>755
すくなくともそのURIはシンタックス的には間違ってないし、リダイレクトされるけどちゃんと目的のリソースにアクセスできるぞ

>>757
失礼でした、質問言い換えます。
明らかに指し示しているのはディレクトリなのに、
わざわざ"TR"という名称のファイルへのURIを提示するのは何故？

ディレクトリなのか…？

なんですかこれは。
http://www.w3.org/TR/Default.htm

なんじゃこれー

<html>
<head><title>F:\Default.htm</title></head>
<body>
<p align="center"><big><big><big><big><big><big><big><big><big><big><big><big>
<font face="Times New Roman"><em><strong>WELCOME TO THE LCS-35 PROJECT WEB </strong></em></font>
</big></big></big></big></big></big></big></big></big></big></big></big></p>
</body>
</html>

ハクられた？

>>762
Googleにインデックスされてるくらいだから相当前からあるんじゃないの？

>>758
W3Cのドキュメントは恒久的なURIを保証するためにコンテントネゴシエーション
を用いた無拡張子のアドレスが使われてる。サイト内回ってみるとわかるけど
リンクはほとんどディレクトリ名か無拡張子のファイル名になってる。
http://www.hoge.com の最後のスラッシュが抜けてるのと同じように糾弾する
と自分が恥をかくことになるかもしれない罠。
http://www.w3.org/TR/に関してはどっちが正解かわかんないけどね。
トップページからのリンクはスラッシュ付きだし。リダイレクトされること考
えるとスラッシュ付きが正解なのかも。

将来それがディレクトリじゃなくてファイルになる可能性もあるから
/ なしにしてるんｼﾞｬﾈｰﾉ

そうかもね。XHTML2もドキュメント内ではスラッシュ無いけど
実際はリダイレクトされるし。

ていうかW3C内でもなんか統一されてないみたいだね。
http://www.w3.org/TR/css-print
なんてThisはスラッシュ内のにPreviousは付いてるし。ユーザーが混乱する
だけのような。

そんなことで混乱するか…？

>>768
>>755とか。
リンクする方としては正しいURIがどれだかわからないのは結構困る。

>>765
それなら現在は"http://www.w3.org/TR/"にしといて、
変更されたら"http://www.w3.org/TR"へリダイレクトしたほうが自然な予感。

ところで、ファイルが無かったとき同名のフォルダがあればリダイレクトしてくれるって
ApacheなりWebサーバーの(主にURI指定を間違えたときのための)仕様だよね？


直接リソースを指定するURIとしては"http://www.w3.org/TR/"が恐らく正解、
もしかしたら"http://www.w3.org/TR"はURNとしての意味合いを含めて使ってるのかもしれない。


#>シンタックス的には間違ってないし、
#>リダイレクトされるけどちゃんと目的のリソースにアクセスできるぞ
#個人的には論外

>>770
それだとURIが変更されることになるから駄目なんじゃない？
無し=>有りは真だけど、有り=>無しは偽な気がする。現状でリダイレ
クトしないでそのままディレクトリの内容を表示するようにしておけば混乱
しなくて済むのに。

Apacheだとスラッシュ無しでリクエストすると301返してくるから大抵のブラ
ウザはlocationに指定されたスラッシュ有りのURIに移動するね。

スレ違いだな、この話題は。

おまえらマジか？

勧告した！？

Working Draftか...早とちりでｽﾏｿ

XML 1.0 Third Edition
XML Infoset Second Edition
XML 1.1
Namespaces in XML 1.1

は勧告になりましたね。

Modularization of XHTML 1.0 SE の Working Draft が出ました。
概要は http://www.satoshii.org/markup/notes/2004/02#date19 でも
見ていただくとして、汎用属性が global でも使えることになりました。

つまり、以前から懸念されていた属性の区間の観点から宜しくない
云々の議論に終止符が打たれるヨカン (誰も議論してない)。
RDF では随分前にそのようになってますが、XHTML もようやく、
って感じですね。

恐らく XHTML 2.0 も (というか Modularization 2.0 と呼ぶべきか)
次のドラフトでは汎用属性はデフォルトで global にするんじゃ
ないでしょうか (希望的観測ですが)。

というか、実際問題 global じゃないと XForms の扱いに関して
問題が生じてしまうのは明らかなので、なるべくしてなるだろう
という感じなのですが。

×区間
○区画

# http://www.kanzaki.com/docs/sw/names.html#ns-partition の辺りの話ね。

同じ鯖で日本語の他に英語のページをつくろうとしてるのですが、
PHPの関係で、日本語版ページはSJISにしてるので、
英語版ページも文字コードがSJISにしかできません。（＜ちがったら誰か指摘してくらさい）

で、こういとき、
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en-US" lang="en-US">
のあたりはどうかくのがいいのでしょうか？

xml宣言のencoding属性をshift_jisにすりゃいいのでは。

xml:lang="en-US" lang="en-US"はxml:lang="en-US" lang="en-US"のままでいいのでしょうか？

>>778
そもそも文字コードとlang属性に関連性はないよ。

例えば
<span lang="en">ディス　イズ　ア　ペン。</span>
<span lang="ja">Kore wa pen desu.</span>
この２つは両方ともlang属性の使い方として正しい。

文字コードに関しては >>779 の言うとおりエンコーディングを変更すれば
それでOK。少なくとも文字コードの変更に伴ってlang属性の表記が変る事はない。

英数字だけ使うならシフトJISもUS-ASCIIもUTF-8も全く同じだぞ
文字コードについて勉強しる

ああそうか・・・・勉強してきます！

いいわすれましたが、ありがとうございます。

http://www.w3.org/TR/2004/CR-CSS21-20040225/
CSS2.1

http://www.w3.org/TR/2004/CR-css-print-20040225/
CSS Print Profile

http://www.w3.org/TR/2004/CR-css3-page-20040225/
CSS3 Paged Media Module

CSS3ってモジュール別に勧告されるのか。

>>782
>英数字だけ使うならシフトJISもUS-ASCIIもUTF-8も全く同じだぞ

んなこたーない。

>>786
792じゃないが…
「英数字だけ使うならシフトJISもUS-ASCIIもUTF-8も全く同じ」にするために
JISをシフトさせてShift-JISを企画したんじゃなかったっけ？

うろ覚えだが。

792は俺だよ

うお、なにをバグッたことを書いてるんだ、俺は
誤:792じゃないが…
正:782じゃないが…

>>788
792のゲトよろ。

>>787
SJISの英数字部分はJISローマ字。ASCIIとは一致しない。
（一致しているかのように処理する実装も多いだろうが）

ISO-2022-JP, EUC-JP, UTF-8, ASCIIの英数字部分は共通している。

英数字ってのは7Fまでの部分のこと指してるんじゃﾈｰﾉ
オーバーラインと円記号以外は一致する品

英数字だけ使うならシフトJISもUS-ASCIIもUTF-8も全く同じだぞ
文字コードについて勉強しる

>>792
いい香具師だな。

英数字ってのは[0-9a-zA-Z]のことじゃ(ry

|

つーか、スタイルシートも XML で書きたい……。

そこでXSLですよ

いや、今そうやってんだけど……。
スキーマ定義も RelaxNG や XML Schema みたいに XML で書こうって流れになってるのに、
CSS も XML で書こうって流れにならないのかが不思議。

>>796
XMLはスタイル指定方法がなくても価値は減らないが（あれば増えるけど）、
スキーマやシマンテック性がないと価値が減る。というか瓦解する。

目の前に課題が山積しているので、すでにCSSで実現している部分まで
「今」手を出す必要がないというか、単に後回しなだけかと。

>>798
僕も割とそう思うっていうか、以前 agenda で CSS の XML 化について
述べられていて、なるほどなぁと思った記憶があります。

人間が手で書くのは現在の CSS 文法的なもので良いと思いますが、
UA が処理する (配布される) 形式としては XML の方が好ましいかなーと。
人間が RelaxNG Compact Syntax を書いて、
それを機械的に RelaxNG に変換するようなノリですね。

# うーん。ちょっと agenda の該当記事を見つけられず。
# そんな記事ありましたよね?

> 「今」手を出す必要がないというか、単に後回しなだけかと。
というか、今やっちゃわないと、また互換性だの何だので
ゴタゴタするのが目に見えてると思うんだけどなぁ。

xml:id Version 1.0
http://www.w3.org/TR/2004/WD-xml-id-20040407/

ようやく xml:id の草案が出ました。
早く勧告になってめでたしめでたしと行きたいなぁ。

へー、xml:idってこういうのだったのか。
application/xmlなXML文書のfragment idが
何を指すのかをお手軽に解決してくれたりするわけじゃないのね。
やっぱXPointerなのか…

http://www.w3.org/TR/2004/WD-xml-id-20040407/#IDAQVQRB
>DOM: ?

単純に getElementById の適合対象として機能するんじゃだめなんかぃのう。
DOM2-3レベルで名前空間と要素の書き換えを連続的に行った場合、既存の
ID要素との兼ね合いと有るんだろうか。

http://hpmboard2.nifty.com/cgi-bin/bbs_by_date.cgi?user_id=QGB02161

非公開部分
http://www.spiegel.de/video/0,4916,2549,00.html

http://lists.w3.org/Archives/Public/w3c-wai-curric/2001JulSep/0000.html

野望の王国は俺も好きだ。
いいタイトルをつけたね。
>>1

一年八ヶ月越しのレスかよ

あら、流出ですか。

また一歩野望に近づいた

とりあえずはっけそ。

野望の王国のブロック／インラインレベルの概念に一言物申す
http://www.homoon.jp/users/www/diary/2004/04a.shtml#d02b

野望の王国の list module に一言物申す
http://www.homoon.jp/users/www/diary/2004/04a.shtml#d02a

なぜ野望の王国って言われてるの？

>>1に訊いてくださいな。

誰が最初か分からん。

http://www.amazon.co.jp/exec/obidos/ASIN/4537101245

XHTML2.0まだー？

あんな段階で勧告されてもな。

XHTMLスレは何でこんなに過疎化してるんだ？
勉強しようと思ったんだけど実用的じゃないのかな

普通にHTML　4.01 Strictが書ければ理解は大して難しくないからじゃないか？

>>819
というか、実用的な話題については Strict-HTML スレを参照した方がいいかも。
ここは将来のバージョンの XHTML について話をするところなので。

まあこっちはXHTML2側に動きがないときは過疎だよね。

strictスレと住民は被っているし、ね

「XHTMLやるぞー」と思ったときに
Strict-HTMLスレって目に付くスレタイじゃないかもな。
# strict書きたいとは必ずしも思ってないだろうし。

ここは実質、草案を読んで感想を言うだけの受動的なスレッドだからな。
こうしたらどうだろう、ああしたらどうだろう、とワーキンググループのメーリングリストのように活発な意見交換がされるようになれば面白いのだが。

同意。それに俺はあんまり英語分からないから
こういうところでやれると面白いと思う

MozillaでいうBugzilla-jpみたいな役割を誰かがやらないと
ここでいろいろ提案してみたところで
「じゃMLに投げてみれば？」で終わってしまう気が。
どんなに有意義な議論が出てもMLに直接投げられないなら結局は空しいと思う。

ま、実りがなくても議論自体を楽しめるならそれでいいんだろうけどね。

今後の Web の行方を左右し得る XHTML2.0。それの開発議論に参加するためにはある自然言語に長けていないとならないなんて、Web の理念からしてあってはならないことだと思う。
現実問題として、ノン・ネイティブ・イングリッシュ・スピーカー以外が盛んに意見するための架け橋――翻訳者の存在は必要不可欠。
具体的には、このスレッドまたはそれに準ずる場所で交わされた議論を何かしらのフォーマットでまとめ、英訳し、議論のステータスと共に W3C のワーキンググループに送信する役目か。
Bugzilla-jp のように大規模でなくても、議論のトピック毎にその能力のある有志が自主的に行えばいいだろう。一人ですべてを行うのはさすがに厳しいだろうし。

W3C Japan なんて団体があれば最高なのだが。

XMLスキーマに対してRELAX-NGが存在するみたいに、2chの悪ふざけじゃなくて、
非W3C系次世代XHTML草案を策定しちゃってもおもしろいと思うけどな。

> W3C Japan なんて団体があれば最高なのだが。
作ってみれば？「有志」が集まらなかったらそれまでってことで。

参考:　　…になるかどうか

WEBの英語化を考えてる管理人が集うスレ
http://pc5.2ch.net/test/read.cgi/hp/1028515750/l50

目に付くとこにあるから>>812にレス

箇条書きすべてをlist要素としてまとめ、現存の三種（＋nl も？）を区別する属性を作ったらどうだとのことだが、細かいことは知らんが、とりあえずCSSでのセレクタ指定が
dl{ ... } から list[sort="definition"]{ ... } となるのは単純に面倒に思う。
たとえ値をもう少し縮めて list[sort="def"] のようにしてもだ。

まぁ、それをいうと p[edit="changed"] とかも十分面倒なんだが。

<p><cite id="q1" href="http://pc5.2ch.net/test/read.cgi/hp/1076693129/589">Strict-HTML スレッド18 の 589</cite>が
　<quote cite="#q1">
　　<p>引用内容でないものを引用内容としてマークアップするのはどう考えても間違いだろ。</p>
　　<p>「本当はこうしたい」の部分は同意だけど。</p>
　</quote>
　と言っているが、俺はこんな感じのを望む。quote 要素内をマウスオーバーすると、cite 属性内の id に対応する cite 要素の内容がポップアップされ、さらに href 属性の値の URI に飛べる。フォームの label 要素と for 属性の関係とは真逆、かな</p>

<!-- こうしてみるとマルチっぽい。。 -->

あ、blockquote だった.

><!-- こうしてみるとマルチっぽい。。 -->
とごまかしているが、確実にマルチ。

>>828,830
慶應義塾大学の存在理由は…

今のところないな>>836

理由はどうあれ、意味なし。

>>833
XLink でいいよ。

http://www.hixie.ch/specs/html/forms/web-forms

http://www.w3.org/2004/04/webapps-cdf-ws/papers/opera.html

> Backwards compatibility, clear migration path

XHTML2.0(WD)への不信任か?

The Web Hypertext Applications Technology Working Group
http://whatwg.org/


Web Forms 2.0
http://www.whatwg.org/specs/web-forms/current-work/

Web Applications Markup Language 1.0
http://www.whatwg.org/specs/web-apps/current-work/

Web Controls 1.0
http://www.whatwg.org/specs/web-controls/current-work/

野望の王国 1 完全版 (1) ニチブンコミックス
雁屋 哲 (著), 由起 賢二 (イラスト)
http://www.amazon.co.jp/exec/obidos/ASIN/4537101245

ロードマップが更新されました。

XHTML 2.0 の Last Call、XFrames の 2nd draft、M12N SE、
XHTML-Print の PR 辺りは全て九月の予定だそうです。

所でroad mapに書いてある「TBD」ってなんの略？
ってかどういう意味？

To Be Determined
いつかやります

>>845
ありがとう、結構長年の謎が解けました。

TBDと書かれて実際にいつかやられたのなんて見たこと無いが・・・
放置と同義なのでは

まぁ、具体的な予定が立っているなら、その予定の日付を書くな。

その内やる、というより、その内やりたい、やらねばならないけど未定、
と言う感じか。

http://www.w3.org/TR/2004/NOTE-xforms-11-req-20040611/

XForms 1.1 の requirements が出てます。
XHTML 2.0 における実装の簡易化なんかもあがってるみたいです。

>>847
それは to be delayed なのでは…

XHTML2.0だとh1にあたるh要素はsectionじゃなくてbody直下なのね。
そうするとh1が複数ある文章の場合どうすんだろう。

野望の王国 1 完全版 (1) ニチブンコミックス
雁屋 哲 (著), 由起 賢二 (イラスト)
http://www.amazon.co.jp/exec/obidos/ASIN/4537101245

>>851
別にhをsection要素内に書いちゃいけないわけじゃないから、なんとかなるかと。
HTMLって、いっつも書き方にいろんな流儀ができるような曖昧さがあるよね。


そういえば、なんでリンクって<a href="">なんでしょう?
<link href="">のがわかりやすかったと思うんだけど……。
そもそも、aって何の頭文字? Attribute?

でもbody/section/h は2レベル目の見出しだし。

ちなみにaはanchorのaです。
http://www.northerntool.com/images/product/images/153776_lg.jpg
http://www.topperfloats.com/hardware/images/d728.gif
http://www.sciline.com/images/earthq23.gif
こんな感じの壁などに付ける、鎖を繋げるためのパーツのことで、転じてリンクの端を指します。

>>854
>でもbody/section/h は2レベル目の見出しだし。
だとすると、
<body>
<h></h>
<section>
</section>
<h></h>
<section>
</section>
</body>
になるんでは。でもそもそもbody/hってtitleと同じになることが多い気がする。

ttp://www.w3.org/TR/2003/WD-xhtml2-20030506/mod-block-text.html#sec_8.5.
の例の<h>の前の<p>ってどこに属するんだろう……。
やっぱ、その後ろの<h>かな……。

<body>
　<div>
　　<h>
はアリだろうから、必ずしも h1 = body/h (body/child::h) ではない。
正しくは body/descendant::h[not(ancestor::section)]

h[not(ancestor::section)] で十分だった。