Blog

※ブログ移転しました。 → hamashun.me

空白類文字についての補足・及び言及への返信

前回の記事、li要素などを改行すると、要素と要素の間に半角スペース分の余白が現れる件について調べてみた。 | Blog hamashun.comを書くために空白類文字について調べたら、記事に必要な内容以上の知識を得ました。
また、ブクマコメントで言及を頂いたので、続編記事を書きます。

連続した空白類文字

ユースケさんのブクマコメントの内容です。

ちなみにどんなに改行や空白が連続してあっても、1つの空白として認識する(はず。あんまし覚えてないけど確かそうだったはず)

はてなブックマーク - yu-suke@double-team.orgのブックマーク / 2008年11月04日より引用

これはHTML4.01仕様書の9.1 空白類の節に載っていて、まさにそのとおりでした。

ここで、ソース文書中で語間に空白類が複数連なっている場合、PRE要素を除いて、レンダリング結果の語間スペース調整は全く異なるものになるという点に注意されたい。特にユーザエージェントは、語間スペースの出力処理に際しては、連続する空白類の入力があった場合は1つにまとめてしまう必要がある

Paragraphs, Lines, and Phrases (ja) 9.1 空白類 より引用 (強調は引用者による)

はじめてHTMLをさわった人の多くが不思議に思う、半角スペースをたくさん入力しても反映されない件は、この仕様によるものです。

インライン・匿名インラインボックス内の改行でも、空白類文字が描画されないケース

前回の記事の結論で次のように書きました。

インライン及び匿名インラインボックス内で改行をすると、空白類文字(半角スペース)が表示される。

li要素などを改行すると、要素と要素の間に半角スペース分の余白が現れる件について調べてみた。 | Blog hamashun.com より引用

しかし、実はこれにあてはまらないケースが存在します。
例えば次のようなコードの場合です。

<div>
てってってーてってっててー
</div>

このような、開始タグの直後や終了タグの直前で改行しているコードは、よく見かけます。
この改行は匿名インラインボックス内での改行に思えますが、ブラウザ上で確認すると空白類文字は描画されていません。

この動作も、仕様書によって指定されたものです。

SGMLの行区切り規則への抵触や、現存する実装間の矛盾を回避するため、著者は、ユーザエージェントが開始タグ直後または終了タグ直前の空白類をレンダリングするとは期待しないようにすべきである。

Paragraphs, Lines, and Phrases (ja) 9.1 空白類 より引用 (強調は引用者による)

この仕様を知っておかないと、逆に「入れたはずの半角スペースが描画されない」というトラブルも起こりえますね(レアケースでしょうけど)。

北村さんより頂いた言及への返信

北村さんよりブクマコメントで頂いた言及です。

『この分割された面』は、インラインボックスの途中で(br要素により)改行された部分のことなのでは。この図の通り→ http://www.mozilla.gr.jp/standards/webtips0015.html#c1_5_1

はてなブックマーク - 徒栞 / 2008年11月05日 より引用

言及元記事の引用先の問題の部分(複雑><)は次のようになっています。

例として以下のものがあります。

  • a
  • abbr
  • acronym
  • b
  • bdo
  • big
  • cite
  • code
  • dfn
  • em
  • i
  • kbd
  • label
  • q
  • samp
  • small
  • span
  • strong
  • sub
  • sup
  • tt
  • var

上記の例にあるように、要素中に改行が混じるとやや複雑な形で表示されます。

ブロックレベル要素とインライン要素 - Web標準普及プロジェクト 3. インライン要素 より引用(スタイル属性は引用者による)

この上記の例というのは、インライン要素が並んでいる部分を指していると思うのですが、そのコード部分はli要素一つごとに改行されているだけで、br要素は登場していません。

なので、ここだけを見ると、br要素による改行ではなく行区切り類による改行を指しているのではないかと思ってしまうのですが、北村さんのコメント内にあるリンク先を見ると確かにbr要素による改行を指しているように思えます。

両方を読んだ結果、br要素による改行と行区切り類による改行の両方を指しているのではないか、と思えました。

あーでも、要素中に改行が混じるとやや複雑な形で表示されますの"要素中"って要素の中というようにも思えるので、要素の外で改行をしている場合はあてはまらないような気もしてきました。 それにそもそも、"やや複雑な形"というのも具体的に何が複雑なのかよく分からない…。 うーむ。

3 Comment

> "やや複雑な形"
これは確かに、読めば読むほどハマりますねー。素直に解釈すれば、改行文字とかでなく、表示上の改行のことを指しているんでしょうけど。
テキストフローにおいて、ある程度の長さを持ったインライン要素が改行されるときの、レンダリングの複雑さを表している...と思う。liの中身が日本語だったら確信もてたんですけどねー^^;

その流れで言うと、「Web標準普及プロジェクト」6.1の例は、連続する改行で複数行になっているインライン要素のborderが、このインライン要素自身("margin,"と表示される部分)に重なっていたりして、実際に挙動を予測しようとかレンダリングエンジン作ろうとか考えるとなかなか複雑だなあとは思います。

Name:Sig. | 2008年11月10日 17:34

key-childさんから以下のコメントを頂きましたが、なぜか反映されなかったのでこちらで再投稿しました。 また、コメント通知メールがGmailの迷惑メールに紛れ込んでいたため、気づくのが遅れてしまいました。 すみません。
----------------------------------------------

> 『上記の例』というのは、インライン要素が並んでいる部分を指していると思
うのですが

もっと上の「1. はじめに実例」を指している。
さらに今回のこととは関係ない。


ブロックボックス(今回の場合はリスト要素)の直接の子は、ブロックボックスの
みかインラインボックスのみとなる。
(CSS 2.1 9.2.1 あたり)
li要素のdisplayプロパティをinlineにしているなら、インラインボックスのみ
となり、リスト要素内の空白類(li要素前後の空白類)は匿名インラインボックスに
含まれる。
(CSS 2.1 9.2.2 あたり)
これまで調査してきた結果から、開始タグ直後の空白類と終了タグ直前の空白類
は表示されず、匿名インラインボックス内の空白類が複数あるなら1つにまとめら
れる。

Name:hamashun | 2008年11月15日 00:05

>key-childさん
なるほど。 深く考えすぎたあまり煮詰まってしまい、関係無い文書を無理やり脳内でつなげていたようです。
おかげですっきりしました。 ありがとうございます。


>Sigさん
というわけで、僕の暴走が含まれていました。
Sigさんまで混乱に巻き込んでしまってすみません^^;

Name:hamashun | 2008年11月15日 00:23

Contribution Form

Blog Search
Search
Recent Entry
Category
Monthly Archive