hr要素は改名して、インライン要素とするのが活路かも
なんだか br要素の話が賑やかなようなので便乗。(^ ^;)
- ここで改行ったら改行（カナかな団首領の自転車置き場）
- br 要素（カナかな団首領の自転車置き場）
- 私はbr要素が好きじゃない（der Gegenwart）
- br要素は好きじゃない（sky line blog）
- br 要素問題は CSS2.1 で解決か!?
どちらかというと現行規格ではなく、次世代規格の話になるので、少なくとも批判とかじゃありません。平たくいえば「br, hr 要素を論理セパレータとして見なすとこんな感じかな？」「その特性を活かすなら、仕様をこう変えた方がいい気がする」的な話です。
ちょっと小難しそうな感じがする方は、前置きはスルーして、ユースケースとサンプルコードだけ眺めてもらって、まったく支障ありません。っていうか、次世代規格の話だし、需要自体もそんなにたくさんあるようなネタでもないし、いっそ、全部まるごとスルーしてもいいかも。(笑)
構造本位か見栄え本位かは文脈や用法次第
まず <br/>, <hr/>, <seperator/>要素が構造か見栄えかの問題ですが、結論だけいってしまえば、僕はこれは文脈や用法次第だと思います。どちらにもなりうる、と。たとえば、「第3章の4段落目」と「56ページの16行目」は、それぞれ対象が文章にあるのか、書籍媒体にあるのかの違いがあるだけで、両方とも構造を示してますよね。もちろん、ホワイトスペースの調整のための見栄え本位な改行だってありえるでしょうし。
（そういえば、大学で編集の雑用をしていた時分、テキストファイルや Word 文書の行末に、ご丁寧にも毎行、改行を入れてくれる人が後を絶たなかったのを思い出しました。(^ ^;) ）
<br/>, <hr/>, <seperator/>要素の特性
ちなみに、これらの要素だからこそできる、構造化や意味づけの用法として、どんなものがあるかなんですが、鍵となるのは、おそらく空要素タグという性質になるかと思います。
ならば、空要素タグの性質とは何か？
真っ先に思い浮かぶのは、それは構造を持てない（＝子孫や内容を持てない）という性質。この性質は一般に空要素タグの短所や限界として捉えられることが多いんですけど、実は裏を返せば、ツリー構造（もしくは入れ子構造）を成していなければならないという、SGML or XML系マークアップ言語の制約に影響される部分が少なくなることも意味しています。
この辺に絡むこととして、表題のようなことを前々から考えてたので、ちょっとまとめてみました。動機が上掲の議論とは別のところからきているので、はたして参考に値するかどうかはわかりませんけど。
論理セパレータとしての hr, seperator 要素（+ br 要素）
(補: deprecate HR; replace with LS (logical seperator).) so that authors can attach meaningful title text, such as "page 21" as well as orientational info; this is a powerful but underutilized tool...
これは、hr要素を "logical seperator"（論理セパレータ）として重視している人の投稿の一節で、hr 要素が実はページ区切りなどの効果的な論理セパレータとなりうるにも関わらず等閑視されていると指摘されています。（なお、"ls"要素への改名という提案に関しては、結局、HTML5 では、後方互換性の観点から "hr" という要素名を保持しているという話になってます。→ 2007年4月2日: Anne van Kesteren の Reply 投稿）
とっても興味深い指摘なんですが、いかんせん、現行の hr要素はもとより、X/HTML5 の hr要素も XHTML2 の seperator要素もブロック要素扱いとなっていて、たとえば p要素（段落）内への挿入を認めていないんですよね（テキストノードの間に、こうした論理セパレータをはさむことができない）。
- XHTML2
- Content model of p element: (PCDATA | Text | List | blockcode | blockquote | pre | table )*
- X/HTML5
p elements can contain a mixture of strictly inline-level content, such as text, images, hyperlinks, etc, and structured inline-level elements, such as lists, tables, and block quotes. p elements must not be empty.
→ hr要素はブロックレベル要素になるので内包できず。
あちこちで指摘されているように、ブロックレベルでの区切りは、基本的に div 要素などでマークアップすることができるので、僕は、この論理セパレータはインライン要素として使えるようになって、はじめて威力を発揮できるようになるんじゃないかと感じてます。（del, ins要素のように、ブロックレベル・インラインレベルのどちらでも使える要素にすると、さらにいいのかも。）
こんな抽象的な言い方をしても、イメージが湧かないでしょうから、とにかく具体的なユースケースをひとつ出してみますね。
use case: 文書の論理構造と組版情報を混在させる
- 想定される用途:
- 書籍の内容を HTML文書化する場合など。（書籍と連動させたい教材とかで需要があるかも。）
- 解決すべき問題:
- 章・節・段落といった文書構造と、ページ数・行数といった書籍媒体上の組版情報が混在すると、入れ子構造（またはツリー構造）が保持できなくなる。
- 解法となる候補案:
- インライン要素の論理セパレータを、本文（テキストノード）中にはさむ。すでに長く利用されている br 要素を使えば、行の頭出しもできるようになる。（XHTML 2.0 なら状況に応じてl要素と使い分ける。）
サンプルコード（XHTML 2.0 もどき）
余談: 要素名はやっぱり変えるべき
もしインライン要素化する場合は、名前についてはモチロン hr ではなく、seperator なり sep なり ls なり、何か別のより妥当な名称に変えるべきでしょうね。よく目にするパイプ（" | "）や日本の中黒（"・"）なんかは、インラインで使われる論理セパレータともいうべき符号ですが、ご覧の通り、インラインじゃ horizon（"水平"線）にはなりませんもんね。誤用のもとにもなるので、やはりインライン要素化する場合は変えた方がいいかもしれません。
…とまぁ、以上のようなことを英文にしてみるのに腰が重くて、こうしてウジウジしてました。(^ ^;;)（英文にするとしても、その前にもう一度、過去の議論を漁ってみないと..。(- -;) ）
ちなみに、この空要素タグで改頁をマークアップするという発想は、TEI という XML ベースの規格の pb要素のモデルからきています。
追記:
改ページのための構造？それは文書構造よりも機能構造なんじゃないかなあ。それだったら、ページメディア用のスタイル言語に任せられないのかなあ。
（vantguardeさん@はてブ）コメント、ありがとうございます！"書籍媒体の"機能構造という点はおそらくおっしゃる通りなんじゃないかと思います。ただ、この場合は紙媒体書籍の「ページ数」（別に巻数でも、行数でもいいんですが）というメタ情報をマークアップする場合の話なので、Webページやプリントアウト時の見栄えレベルでどう処理するかとは、まったく別のレイヤーの話です。
とはいえ、このレベルのメタ情報をマークアップするのに HTML を使うかなぁ？とは、自分でも思わないでもありません。(^ ^;;) ま、「空要素タグな論理セパレータだからこそできること」の例として、少々特殊なユースケースになってしまいましたけど、探せばもっと良い例があるんでしょうね、きっと。
Web媒体では見出し毎に移動する方がわかりやすいので、書籍の内容をHTML化するにしても組版情報を残す必要はないと思う。
（dede-sukeさん@はてブ）少し特殊なユースケースの話をしているので、おっしゃるように処理されるのが、普通だと思います。（よほどのことがない限り、僕もやっぱりそうします。）ただ、紙媒体の読み物の場合、1章、1節、1段落が長いこともしばしばです。そういう時、本文中に「P.24 の 3行目参照」なんて出てきたら、探すのイヤになっちゃいますよね。もしかしたら、そこに需要が発生することがあるかもしれない、と思った次第です。
見栄えと論理構造の分離が一番の旗印なのに『文書の論理構造と組版情報を混在』というのは混乱しているのでは？SGMLのplatform independencyからもほど遠いし。
（beatakさん@del.icio.us コメント）うーん、"SGMLのplatform independency" って、こういうことを言ってるんでしょうか？
書誌情報や組版情報と Web ページの見栄えは区別すべきものだと思いますし、ページ数や行数といった情報の捉え方も、時と場合に応じて変わります。たとえば、プログラムのソースコード中のある場所を指定する時に、そのソースコードの行数を示すのは見栄えでしょうか？「行数」というメタデータとしても捉えられませんか？もちろん「ページ数」も同様。
hrをインライン要素とすべき根拠としては、ユースケースが特殊過ぎるのでは。/ 意味的な区切りにしたいのか、レイアウトのための区切りにしたいのかで混乱があるような
北村さん@はてブほかの追記でも書いてますが、否定はしません（というか僕自身、そう思ってる面があるので）。(^ ^;) 混乱についても、起こりうるからこそ、"hr" という名前を別なものに変えた方がいいと思うわけですけど、後方互換を考えると、むしろ hr 要素は hr 要素として現状のまま残った方がいいのかな..とも思ったり思わなかったり。
"書籍の内容を HTML文書化"するのに、組版情報を残す必要性は少ないような……hr要 素が仮にインライン要素になった場合、ブラウザデフォルトのスタイルって？
（木達さん@del.icio.us コメント）これも、「必要性」とか「需要」とかいう話でいえば、このユースケースでは確かに薄いといわざるを得ません。（やはり例が悪い..。(- -;) ）デフォルトスタイルについては考えてませんでしたけど、ブロック要素として使うなら水平線、インライン要素なら垂直線（パイプっぽいもの）？(^ ^;)
それにしても、この話題で、こんなに反響を（しかも具体的に踏み込んだコメントまで）いただけるとは思いませんでした。ちょっと意外。みなさま、ありがとうございます。m( _ _)m
| 固定リンク
「［Web］XHTML」カテゴリの記事
- HTML の見出しをめぐる議論(2007.07.11)
- Re: XHTML+CSS (r)evolution, 3rdの内容は信ずるに値するか?(2007.06.03)
- 論理構造を文脈に読み換えながら class 名を考える(2007.05.30)
- 定義リストの違和感（続）(2007.05.28)
- 定義リストの違和感(2007.05.26)
この記事へのコメントは終了しました。
コメント
あー、確かにサンプルコードみたいな構造は良いかもしれませんね。
というか、<br />が結構嫌われている事に驚きましたｗ。
俺は何も気にせず、使っていたのでｗｗｗ。
投稿: デッドリー | 2007-05-02 05:45