2002年1月 - マーク付けノート

2002年01月12日

XHTML 1.1 ファミリの話

どこかで noscript 要素直下にインライン要素を記述できるように DTD を変更したいという話がありましたが、文書型宣言を以下のように記述すれば一応適います。

<!DOCTYPE html
     PUBLIC "-//W3C//DTD XHTML 1.1//EN"
            "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd" [
<!ENTITY % noscript.content "( #PCDATA | &#37;Flow.mix; )*" >
]>

なお DTD を書き換えた場合、それは厳密には "XHTML 1.1" とは異なるので、"XHTML 1.1 Family" などと表現します。bubble hour - 2001年12月18日 あたりも参照のこと。

# 2003-11-10 追記

ただし、このような拡張(同一の名前空間内での内容モデルの拡張)は Modularization of XHTML の仕様からすると好ましくないと思います。

XHTML 2.0 の予習

14日に最初の草案が公開される予定の XHTML 2.0 では、quote 要素型なるものが導入されるという噂です (XHTML 2.0 (3))。恐らく神崎さんの「ユニバーサル HTML/XHTML」170ページにあるような、XLinkXPointer を組み合わせて埋め込み型の引用を可能にするものであると思われます。

旧来の HTML 文書に対してリンクを行う場合、URI によって文書内のある範囲を示すことは一応可能であるものの、範囲が一つの要素でなければならず、当該要素に id 属性や name 属性が記述されている必要がありました。これに対し、XML 文書に対するリンクの場合には、XPointer (XPath を含む)という機構が利用でき、「最初に出現する h2 要素から次の h2 要素まで」といった複雑な範囲を示すことができます。quote 要素型というのは、この機構を利用して別ファイルからの部分的な引用を可能にするものではないかと思います。

重要な点は、XPointer を利用するためにはリンクの文書が整形式の XML で記述されている必要がある、ということです。つまり、引用したい文書が HTML 4.01 や ISO-HTML で記述されている場合には、XPointer を用いた引用は行えません。さしたる理由がないなら XHTML に移行していただきたいな、と。後方互換が大切だ、ということについては異存ありませんが。

2002年01月15日

quote要素型

quoteは埋め込み型の引用を可能にする要素型ではないか、という予想は外れていたようですが、結局どういう要素型なのでしょうか。というか、草案はまた延期ですか。お仕事頑張って下さい。

そう言えば以前、q要素、blockquote要素という区別は本当に必要なのだろうか、引用は全て quote 要素か何かに統一すべきだったのではないだろうか、などと述べたことがありましたが、この quote 要素みたいなものでしょうか?

上の発言をした文脈の通り、p 要素内にブロック要素が認められるなら、引用のブロックレベル/インラインの区別は不要であると思いますし。

# 2003-11-10 追記

その後 XHTML 2.0 の草案をご覧になった方には言うまでもないことですが、quote は q の代替となるインラインの引用要素でした。

2002年01月17日

"EMPTY""(EMPTY)"

ようやくすみけんさん"スタイルシート Web デザイン" を入手しました。評判通りの良書であると思います。

CSS より先に SGML の概要を解説しているため、初学者にはやや難い印象を持たせてしまうような部分もありますが、HTML+CSS という組合せを根底から知る上では必要な構成かも知れません。正確さ・解り良さという二つの面で、"ユニバーサル HTML/XHTML"・"詳解 HTML &スタイルシート辞典" と同様に推薦されるべき数少ない書籍の一つでしょう。

ところで。この "スタイルシート Web デザイン" (初版第1刷)の p56 に、文書型定義では、空要素の子要素は「(EMPTY)」と書かれています。とあり、続けて厳密には、カッコは冗長です。しかし、本書は見やすさのためにカッコを追加しています。と注記されています。しかし、この括弧があるのとないのとでは、要素宣言の意味が全く異なります。

前者は「内容が空の、すなわち空要素である」LINK 要素を定義する物ですが、後者は「内容が『EMPTY 要素』である」LINK 要素を定義することになってしまいます。後者の場合、例えば <!ELEMENT EMPTY - - (#PCDATA) > などという宣言があれば、以下のような記述を求められることになります。

<link>
 <empty>(EMPTY要素の内容)</empty>
</link>

要素宣言において括弧を記述した場合、予約名は "PCDATA" しか記述できず、また、これが予約名であることを示すために RNI を付して "#PCDATA" と記述する必要があります。RNI のない名前字句は、要素名と見なされてしまう訳です。

しかし、ふと思ったのですが、どうもこの (EMPTY) という表記に見覚えがあるような。以前、古い規格を調べていたときに見たような気がして、HTML+のDTD を参照したところ、ありました。

…括弧無しと括弧付きが入り交じっていますが、括弧付きのものも明らかに「空要素」のつもりで記述したものでしょう。ちなみに当時の TR 要素型row separator とある通り、表の中で列の「終了」を示すものであったようです。「お尻 P」みたいなものですね(もっとも、HTML+ の P 要素型の定義は既にお尻 P ではありませんが)。

なお、もしこの DTD の作者が意図したような記述をしたのなら、どのように解析されるのでしょうか。DTD で <!ELEMENT TR - O (EMPTY)> と宣言しても文法的には問題がありませんが、実際に文書インスタンスで TR 要素が出現すると、これはエラーになります。

<table>
 <caption>(見出し)</caption>
 <td>(項目1-1)</td><td>(項目1-2)</td><tr>
 <td>(項目2-1)</td><td>(項目2-2)</td><tr>
</table>

HTML+ の DTD に EMPTY 要素型なるものは定義されていません。内容モデル中に未定義の要素名が出現した場合、パーザはこれを内容モデルから自動的に脱落させます。しかし、混合内容モデルで内容が空ということは有り得ませんから(後述追記参照)、例えば TR の子要素 EMPTY は定義されていないといったエラーを返されることになる訳です。

# なお、「スタイルシート Web デザイン」の記述は第2刷以降で修正されているかも知れませんが、正誤情報:スタイルシート Web デザインにも記述がないようなので、取り敢えずここで周知しておきました。

# 2003-11-10 追記

混合内容モデルで内容が空ということは有り得ませんというのは、「要素型宣言中の内容モデルが空ということは有り得ない」すなわち「<!ELEMENT foo - O () > のような宣言は有り得ない」の誤記です。

なお「スタイルシート Web デザイン」の記述については、すぐに正誤情報に反映していただきました。今更ながら、迅速な対応に感謝。

2002年01月21日

heading と header、見出し要素

h1要素の "h" を "header" の略とするのは誤りで、正しくは "heading" の略だ、という話があります。しかし、HTML+ では見出し要素を Headers として解説しています。また、手元の英和辞書は "header" に "見出し" の意を挙げていませんが、便利ツール[英和辞典]: headerコンピュータ用語として見出し、表題、ヘッダーの意を挙げています。

HTML 1.0, HTML 2.0, HTML 3.0, HTML 3.2, HTML 4.01 などでは全て h1 を "heading" としていますが、th が "table header"、(HTML 3.0 の) lh が "list header" であることを考えても、header にもいわゆる "見出し" に近い意味があるのは確かではないかと思います。

これに関連する資料を探していたところ、「HTML 鳩丸倶楽部」過去の更新履歴でこんな記述を見付けました。

WAI のガイドラインを読み直していたら、Techniques for Web Content Accessibility Guidelines の 4.1.2 に

Sections should be introduced with the HTML header elements (H1-H6).

とか書いてあるのに気付いた。文脈からして H1 や H2 を header elements と呼んでいるような気がするのだが、その舌の根も乾かないうちに

Note that in HTML, heading elements (H1 - H6) only start sections, they don't contain them as element content.

と来る。"header element" と "heading element" が使い分けられているようなのだが、違いが分からない。

この "header" と "heading" の使い分けは、恐らく「英語では同一単語の反復が嫌われ、同意語が反復する場合には別の同意語を用いようとする」という原則によるものではないかと思います。やはり、両者の意味には大差がないのではないでしょうか。

とは言え、英語にそれほど自信があるわけでもないので、正確なところはネイティヴの人に訊くのが一番だと思いますが。

2002年01月22日

TAGCの省略

タグの閉じ忘れなら、如何なるブラウザを用いようとも、書き手の期待通りの表示にはならない気がした。

<!DOCTYPE html
     PUBLIC "-//W3C//DTD HTML 4.01//EN" >
<html>
 <title>sample</title>
 <p>title only</p>
</html>

上のように書くつもりが、うっかりタグを閉じ忘れ。

<!DOCTYPE html
     PUBLIC "-//W3C//DTD HTML 4.01//EN" >
<html
 <title>sample</title
 <p>title only</p
</html>

この場合、「正しく挙動する UA なら」書き手の期待通りに表示してくれるはずです。

参考:マニアックな文法論議 - SGML の短縮タグ機構

2002年01月24日

PCDATAの要素型

この <body> 〜 </body> の間に書かれている内容が、ウェブページとしてブラウザに表示されている部分です。

body 要素の中身としてマークされてゐる以外の部分にテキストがあるのは不正です。しかし、さう云ふテキストも、多くのブラウザが平氣で表示します。

title 要素の内容はテキストです。もっとも、多くのブラウザには title {display:none;} というデフォルトスタイルを与えられていますが。

2002年01月25日

定義リスト

よくある'100の質問'の各項目に通し番号を振るとすれば、どのようなマーク付けを行うべきだろうか、という話。

100 という数字を挙げているということは、数字あるいは質問番号が重要だと考える。そうであるならば、HTML 4.01 などでマークアップする際には番号付きのリストである ol 要素を使っていきたい。

また、列挙された質問群こそが重要であり、連番は装飾に過ぎないという考え方もあるだろう。 その場合、定義リストである dl 要素などで質問と回答を列挙し、装飾である連番はスタイルシートやクライアントサイドスクリプトなどを用いて表現するという手段を用いることになると思われる。

大きく分けるとこの2つになるのではないだろうか。

例えば、三択問題に対する解答の仕方を考えてみます。出題が「ア・イ・ウ」という形式を取っていた場合、解答者は「僕は『イ』だと思う」というような答え方をすると思います。

この三択問題を HTML でマーク付けする場合、「ア・イ・ウ」という記号をリストマークとして扱ってしまうと、問題が生じてしまうかも知れません。閲覧者がユーザスタイルシートを利用していたり、スクリプトを切っていたりすれば、リストマークは「ア・イ・ウ」ではなく「1・2・3」や「A・B・C」と表示されてしまうかも知れないからです。この場合、「答は『イ』だ」という解答の仕方は無意味になってしまいます。

ol は確かに序列リストですが、「順」があることを意味しても、「記号の種類」までは意味しません。「ア・イ・ウ」という記号がリストマークとして扱われていれば、これに解答する場合にも、「僕は『二番目』だと思う」という答え方しかできないでしょう。これはスクリプトでリストマークを振る場合にも同様です。

解答者が素直に「『イ』です」と答えられるようにするためには、選択肢の記号をリストマークとして扱うのではなく、生のテキストとして扱うべきであると思います。これは、想定するリストスタイルが数字であっても同じことです(「100」と「100番目」では意味が違いますから)。

'100 の質問'の話に戻ります。「別に番号が振られなくとも良い」という考え方の場合には、上のようなことは余り気にする必要がありません。しかしその場合には、例えば「誰それの文章の何段落目」などというのと同様に、やはり記号に関わらない指定をする必要があるでしょう。つまり、シューティングゲーマーに48の質問について、「僕なら23はツインビーか ASO II で、24はグラディウスか同 II か極上パロディウスだ」という書き方をせず、「23番目は」「24番目は」と記述するべき、ということです。

この文書のステータス

URI
http://www.satoshii.org/markup/notes/2002/01
初版
2002-01-12
最終更新
2003-11-22
著者
石川哲志
Copyright © 2002-2003 Satoshi ISHIKAWA, All Rights Reserved.