草案ラッシュに埋もれていて読むのが遅れましたが、これは結構一大事です。このノートの要旨は概ね次の通り(概要も参照して下さい)。
XHTML 1.1 / Basic などの XHTML ファミリ文書は
application/xhtml+xmlとして公開されるべき (should) であり、メディア型text/htmlの使用は HTML 4.01 などの旧来の HTML に限るべき (should) である。ただし、XHTML 1.0 文書の場合には、旧来の HTML との互換性を考慮してあるものについてはtext/htmlも許容する (may)。
An XHTML + MathML + SVG Profile などで HTML 版と XHTML 版 が用意されていたのは、このノートに沿ってのものだったようです。現状 application/xhtml+xml に対応している UA なんて Mozilla くらいだと思うんですが(WinIE6 はどうなんだろう)、text/html やめますか? XHTML やめますか?
.html と .xhtml を両方用意してコンテントネゴシエーション…っていうのも、サーバサイドで XSLT を動かせば(割と簡単に)できなくもないとは思うんですが、まだそういう技術は身についてないし。
SSI で文書型宣言だけ変えるってのも考えたけど、それだと XHTML 1.1 と XHTML 1.0 の共通要素型・属性しか使えなくなってしまうので、敢えてメディア型を使い分けるという趣旨からすると本末転倒か。
まあ、いつか通らねばならない、避けては通れない道である訳で、突然降って湧いたかのようにじたばたするのもどうかという感じですが。
# 念を押しておきますが、
というのはネタですよ。じゃあ大手振って text/html やめますか? XHTML やめますか?text/html を使えるように XHTML 1.0 で書こう、なんてのは輪を掛けて本末転倒ですので。
AddType "text/html; charset=Shift_JIS" html
AddType "application/xhtml+xml; charset=UTF-8" xhtml xht
Options +MultiViews
コンテントネゴシエーションについてはこれで OK? まだ(仮)くらいの扱いで。ていうか text/html で送られているリソースの中身も XHTML 1.1 のままだし。自分のブラウザがどっちを受け取っているかを調べるには、上のリンク先のソースの末尾を見て下さい。文書型宣言を見て下さい。<!-- Original URI "http://math.oheya.to/markup/notes/0205.xhtml" -->PUBLIC "-//W3C//DTD XHTML 1.1//EN" なら application/xhtml+xml の方を受け取っています。
現在の .htaccess の関連部分は概ね以下のようになっています。
AddCharset UTF-8 .utf8
AddCharset Shift_JIS .sjis
AddCharset EUC-JP .euc-jp
AddLanguage ja .ja
AddLanguage en .en
AddType "application/xhtml+xml; qs=0.95" .xhtml
AddType "text/html" .html
Options +MultiViews
で、ファイルは 05.html.ja.sjis とか 05.xhtml.ja.utf8 とかいった感じにしています。
Mozilla で回顧録を閲覧しようとしたら、表示されたのはエラーメッセージだったという。
XML Parsing Error: mismatched tag. Expected:</body>. Location: http://niaou.alib.jp/diary/?05020555 Line Number 584, Column 5:</div>----^
…思わぬ副産物というか、Mozilla で表示確認すれば XML 的な構文エラーは皆無になりますね、これ。いや、実は、望んでいた世界にかなり近づいているような。
冒頭の文章の訂正です。
ただし XHTML 1.0 については、旧来の HTML との互換性が高いことから、どちらのメディア型も許される (may)
なんて書いてしまいましたが、正しくは XHTML 1.0 のうち旧来の HTML との互換性を配慮してあるものについては
です。text/html も許容 (may) とする(あくまで application/xhtml+xml の方が好ましい(should))
なお、旧来の HTML との互換性を配慮してある
とは、XHTML 1.0 の HTML Compatibility Guidelines に沿っていることを指します。<br/> や <br></br> ではなく <br /> とする、lang と xml:lang は併用する、識別子としての name と id は併用する、など。
MacIE5.1.4@MacOSX では、
選択されたファイルの処理方法が不明ですとゆーダイアログが出て表示できなかった。ならば、ファイルヘルパー設定に新しい項目を作って、 MIME タイプ "application/xhtml+xml" 、処理方法「ブラウザで表示」とでもすれば表示できるかなと思い、試そーとしたですよ。ところが、設定ダイアログの MIME タイプ欄が+記号のキー入力を受け付ない…という状況。うげ。
MacOS9 では + は入力できたみたいですが…どうやって書いたんだろう…。あ、コピー & ペーストでいけました(typo 防止に初めからコピペで入力したんだった)。ただ、「ブラウザで表示」は巧くいかないようです。結局 Mozilla を「アプリケーションで表示」に設定しました。
これからは MacIE だけじゃなく Mozilla も常駐させる必要がありそうな予感が。
# 拡張子については確か RFC 3236 に記載がありました。.html .xhtml .xht どれでも良さそうです。
application/xhtml+xml で認識される文書は XML として解析される訳だが、Mozilla の XML の実装はちょっと厳しい。Mac 版だけなのかも知れないが、DTD の外部サブセット/外部実体を全く参照していないようなのだ。
例えば、外部サブセットで定義されている実体参照などは全く機能していない。XHTML 1.1 で © などの実体参照を記述すると、パージングエラーになってしまう(misuzilla.org なんかでも » がエラーになっている)。このエラーを回避するためには、実体参照の代わりに ‹ などの文字参照を使用するか、以下のように内部サブセットにも実体宣言を記述してやるしかなさそうだ。
<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd" [
<!ENTITY copy "©" >
]>後者はちょっと馬鹿馬鹿しいので、結局文字参照で記述している。Opera 6 も application/xhtml+xml に対応しているらしいが、その辺りはどうなっているのだろう。というか、きちんと XML としてパージングしているのだろうか。
本当は、application/xhtml+xml にしたなら XHTML でも XML の機能を存分に活用しよう、そうすればこんなことができてしまう、というようなことを書こうと思ったのだが、外部実体に対応していないのでは何にもできない。現時点で Mozilla に対して利用できそうなのは、CDATA 区間と XSLT くらいだろうか。この辺りも Opera の実装が気になるが。
# (XHTML 版では)上のサンプルコードは実際に CDATA 区間を使用して記述していますが、Opera でも正しく表示されていますか?
当時はこんなことを思っていた訳ですが、あるかないかも定かでないような実体宣言の読み込みだけのために DTD を参照することの方がよほど馬鹿馬鹿しい、と今は思います。いわゆる文字実体参照を利用すべきではない、とも。
どうしてもそういった機構が必要であるなら、個人的には XML Character Elements を利用することをお勧めします。もっとも、現段階では草案なので、その意味ではお勧めしにくいのですが。
ということで、情報ありがとうございます。
Opera も XML を正しく解釈できるらしいので、取り敢えずそちらの実装については余り気にしないことにします(何かあったら突っ込んで下さい)。それから、Mozilla のアレも Mac だけの模様とのことで(Mac でも余所でどうなっているかは不明ですが)。
Mozilla については、特定の公開識別子を指定された文書型宣言に対して、その DTD 中に記述されている一般実体宣言のみを抽出した DTD をローカルに用意して結びつける、という方法で実装しているようです。つまり、未知の公開識別子に対する外部の文字実体参照は解決されません。
学校で Windows マシンを使うことができた上に、思いがけず Moz も Opera もダウンロードして使用できました(アプリケーションの追加は制限されているかと思っていたので)。デフォルトのブラウザが Navigator 4.x というのが意味不明ですが、Mozilla も軽く動きます。というか、Opera 軽すぎ。アンカーをクリックするより早く読み込んでいるのではないかと疑ってしまうほど軽い。
で、まあ、ここぞとばかり色々試してみたんですが… Win の Moz はちゃんと 外部の DTD も読んでますね。しかも本当に MathML に対応しているし。行列が整形されている様には軽く感動しました。羨ましい。
ただ、外部実体には Moz も Opera も対応していないようですね。IE 5.x もほとんど対応していないに等しいような。外部実体を使えれば、HTML とはかなり違った世界が開けるんですが。
あ、でも、Opera は上の CDATA 区間を微妙におかしく解釈していたような。<!ENTITY copy "©" > と表示されるべきところが、<!ENTITY copy "©" > と表示されていました。どうも CDATA 区間内の数値実体参照を展開してしまっている模様(←勘違いがあったので修正しました)。
さっき学校で IE6 を使ってみたのだが、XHTML Media Types (邦訳) を text/html で読み込んだらおかしなことになった。a 要素がホットテキストになっていないし、テーブルが滅茶苦茶に崩れている。
ソースを見たら xml-stylesheet 処理命令にタイポがあったので、テーブルが崩れていたのは恐らくこのせいだと思われる。が、スタイルシートの指定ミスが a 要素の処理にまで影響するものだろうか(見た目アンカーになっていないだけでなく、実際にクリックしても反応しなかった)。
XML 宣言があると XML と見なしてしまうとかいう可能性はありそうだが、リンクは XLink しか認識しないなんてことにはならないだろうし。xhtml:href xhtml:a href にも反応するよなあ。…しないのか? とりあえずタイポは修正済みなので、後でもう一回確認してみるけども。
個人的に非常に嬉しかったニュース。
# でも、name 属性の値が ←誤りです。失礼しました。HTML 3.2/4.01 では妥当な記述です(詳しくは "青空文庫が XHTML 1.1 を導入 (2)" を参照して下さい)。name="02/5/7" ってのは、リンクを張る側としては微妙な気持ちになるんですが…(name の値にスラッシュは使えません)。今後の改善に期待したいところです。
# 石川は青空文庫を応援しています。
そう言えば、「拡張子が .xhtml もしくは .xht なら」という条件付きで、MacIE5.x に application/xhtml+xml ファイルを表示させる方法に気が付きました。ファイルヘルパーの設定で、メディア型は追加せずに拡張子 .xhtml .xht だけを「ブラウザで開く」に設定しておけば、application/xhtml+xml のファイルも通常通りに開けます。
ただし、ちょっとした問題があって、拡張子以下にクエリやフラグメントが付加されているとやっぱり認識できません。うーん。
© は ‹ ではなく © です。何か途中から typo していたので修正しました。で、それと併せて得た推測からすると、Opera には CDATA 区間内の文字参照を展開してしまうというバグがある模様(実体参照については未確認)。手元に Opera がないので調べられませんが、<![CDATA[&#hoge;]]> なんて記述をするとエラーになってしまうかも知れません。
敢えて試そうとも思わなかったんだけど、W3C HTML Validation Service が application/xhtml+xml 非対応ってのはどうなんだ。多分すぐに改善されると思うけど。
改善されました。
かあ。うーん。<xml:orphanedChar value="#x000c" />
仰る通りでございます。失礼しました。> 青空文庫御中
# XHTML の name が NMTOKEN なので早とちりしてしまいました。というか、某所で「HTML 4.01 の name は CDATA」という話を読んで「そうだったのか」と思った時点で気付くべきだったような。
む。img 要素の alt 属性は
画像の説明ではありませんヨ。「代替テキスト」ですヨ。"alternate text" の "alt" なんスから。
HTML 4.01 13.2 Including an image: the IMG element には The alt attribute provides a short description of the image.
という一文があるので、画像の説明
という解釈も間違いではありません(というか正しい)。ただ、大抵の img 要素では、「画像の説明」を記述されても冗長になるだけのことが多いので、アクセシビリティ的には「代替テキスト」を記述する方が好ましいと思います。
1024 段ネストの HTML ファイル (石川註: MacIE5.x では開かない方が賢明です) を何段までレンダリングするか。
- Netscape Navigator 4.78
- 0
- Internet Explorer 6.0
- 27
- Mozilla 1.0 RC3
- 33
- Opera 6.02
- 1024
IE も Moz も多分あえて打ち切っているのでしょう。Opera はレンダリング完了までには 3 分半ほどかかりました。何かの雜誌に載っていましたが Opera はもっと沢山うけつけます。たしか 3 万ぐらいだったかを 2 時間ほどで。Opera に対してはブラウザクラッシャーです。
HTML 4.01 や ISO-HTML では 1024 段ネスト
は文法違反です。どちらの HTML も、SGML 宣言で SYNTAX QUANTITY TAGLVL 100 が宣言されているため、パージング中に「現在開いているタグの数」が 101 を超えるとエラーになります。
ちなみに名前は TAGLVL ですが、実際にはタグの深度というよりも要素の深度をチェックしています。開始タグの省略があっても、それを補った上でカウントを行うので、見た目のタグの深さで検証がなされる訳ではありません。例えば HTML 4.01 なら tbody を補った上でカウントを行うので、25 段目のテーブルの途中で制限を超えてしまうことになります。
なお、XML は SYNTAX QUANTITY NONE なので、要素のネストその他に関する量的な制限を持ちません。従って、XHTML なら 1024 段ネスト
も妥当(整形式)の記述になります。
# ちなみに、ISO-HTML では tbody の開始タグは省略できません。あと table の summary 属性は必須です。