Diary--/*isaji*/MIDI Lab.

サイドバーの中身を下方に追いやってシングルカラムにしてみました。思い起こせば、このブログツールを利用し始める前はシングルカラムの日記だったんだし、それをレイアウトそのままで無理矢理サイドバーを付けたようなデザインにしたのが拙かった。CSSを修正する度にInternetExplorerでのサイドバーの配置に手こずってましたし、サイドバーはお荷物だったんです。

私自身、他の方のブログを見て回っているときも、サイドバーの存在を意識した事はあまりないですし。それにOpera Mobileで閲覧しているときには邪魔にすら感じるんですよ。サイドバーと本文の横幅をパーセントで指定していれば、それ程邪魔には感じないのですが、例えばサイドバーの横幅を300pxで固定なんてされていたら、本文を表示する部分の横幅がもの凄く狭くなって読みにくいったらありゃしない。2カラムならまだいい。3カラムで両側のサイドバーが横幅固定で配置されていようものなら、本文の表示幅はヘタをすると一行だけになったりしかねません。

試しに横幅200pxのサイドバーを両側に配置した3カラムリキッドレイアウトを書いてみました。

sidebarの横幅を固定した3カラムのサンプル

極端な例かもしれません。しかし、たった200pxのサイドバーが両側に配置されているだけで、本文の表示幅が狭くなってしまうことには変わりありません。

んで、うちは2カラムでしたし、サイドバーも本文も横幅可変のレイアウトにしていましたので、画面の狭いモバイル環境でもそれなりに閲覧できていたと思うのですが、上記のようなものを見てから、せめてSSRモード用のCSSを用意しておこうと思いまして、サイドバーやカレンダー、それから検索フォームなどの表示しなくてもいい物をdisplay : none;するという方向でhandheld用のCSSを書いたんです。

こんなの書いてたら、通常のブラウザ向けのCSSもシングルカラムでいいんじゃないの？　なんて思うようになりまして、htmlテンプレートを修正するついでにCSSも書き換えてしまいました。ただ、いつでも2カラムに戻せるようにhtmlを書いているので、シングルカラムにしては無駄なdiv要素が幾つか残ってますが気にしない方向で。

その他、細かい変更点。

• フォントサイズを少し大きくしました。
• 既読リンク色を変更。
• エントリタイトルをパーマリンクのリンク文字列にするのをやめて、[permalink]としてリンクすることに。
• エントリタイトルの横に、はてなブックマークへのリンクを付けてみた。ほとんどブクマされていませんけど。
• 日付表示を簡素化。今までがでかすぎた。
• 月別アーカイブリストを削除。
• Amazonおまかせリンク（TM) ベータ版を使ってみたかったの。「rcm-jp.amazon.co.jpへの接続が切断されました」ってよく出る。あと表示が微妙。
• 個人的には文章の両端がぴっちり揃ってるのってあまり好きじゃないんだけど、Firefoxユーザのためにtext-align : justify;を。

handheld用のCSSは下方のナビゲーション及びAmazonアソシエイト関連をdisplay : none;しているだけで、ほとんど変わっていないはず。なお、表示確認は Konqueror 3.5 , Opera 9 , Internet Explorer 5.01/5.5/6 とか。それとFirefox 1.5でなんとなくさらっと確認しておきました。たぶん大丈夫。

見た目は全く変わっていないと思うけど、html内の記述順とCSSの配置に関わる部分を大幅に書き換えました。今までは日記本文を記述してある部分(content)の前にsidebarを記述して、左にフロートする事で左メニューの2カラムレイアウトにしていたのですが、contentに内在するブロック要素の横幅がcontentの横幅を越える、または文章が正常に折り返しを行わない状況になると、IEではcontentがsidebarの下に配置される事がありました。CSSの解釈が比較的正しいとされるKHTMLやOperaではこういった事は起こらないのですが、現状最もユーザが多いとされるInternetExplorerでもある程度は表示出来ないと困るので暫定的な処置、みたいな感じ。

フロートで配置している以上、フロートされたブロック要素が直前のフロートした要素の下に配置される事は避けられないので、どうせ下に落ちるならばcontentよりもsidebarの方が良いだろう、ということで。html文書内での記述順をcontent→sidebarの順に変更し、右にフロートさせることにしました。

IEと他の先進的ブラウザではwidthプロパティの解釈が異なるようで、width:80%;のcontentの横にwidth:20%;のsidebarを配置しようとしても、IEでは20%中の20%の横幅で表示されてしまうので、IEがまともに解釈しない隣接セレクタ(もしくは隣接セレクタによる同一プロパティの値を上書きしない？)を用いてIEではsidebarの横幅を100%になるようにしているのですが、IE5ではこの隣接セレクタを解釈してしまい尚かつwidth値の解釈がおかしい為、sidebarがもの凄く細く表示されます。IE5は切り捨てる方向で。

表示の確認はKonqueror 3.5,Opera 9.0/8.51,Firefox1.5及びIE6/5で行いました。InternetExplorer 6では以前よりも崩れにくくなった、という程度。IE5は前述のとおり意図した表示にはなりませんが本文の閲覧に支障は無いはずです。

sidebarよりも先にcontentが表示されるので、w3m等のテキストブラウザでも読みやすくなったと思います。

先日書いた[CSSなんて飾りです]の記事へ、はてブでh要素に関してのコメントを頂戴しました。

2005年11月25日 retlet 『[css]ブログ時代のマークアップ入門。h要素はデザインによっては本文とレイアウト側で齟齬が生じる罠が』

はてなブックマーク - Diary--/*isaji*/MIDI Lab. | CSSなんて飾りです

こーいうコメントを見ると、はてブってなんだかんだと言いながらも便利だよな、と思います。blogのコメント欄に書くまでもないけど、ちょっと言っておきたい、みたいな内容の時は特に。

それはともかく。

blogツール上での本文記述時に利用する、という前提で話を進めていたのに、h要素に関して深く考えなかったのは手落ちでした。

htmlテンプレートを自分で書いていれば、どこでh要素が利用されているか把握しているので問題ないですが、誰かが作ったテンプレートを流用しているような場合、コメントしていただいたように齟齬が生じる事があるかもしれません。

まずは出現順。ページタイトルだけh1要素でマークアップされているような場合に本文中でh3要素を使うと、ページ全体から見るとh2要素が抜け落ちていることになり、見出しの階層を明確化する事になりません。HTMLの仕様からすると問題はないそうですが、あまり勧められた書き方ではありません。

スタイル的にも…例えばページタイトルをh1要素で、エントリ名をh2要素でマークアップしていれば、本文にh3要素を使ってもなんの問題もないでしょう。しかし、サイドバー上の"最新のエントリ"等の文字列をheadingとして解釈し、h3要素でマークアップしている事があるかもしれません。そんな時に、本文中の小見出しへh3要素を使うと、同じスタイルが適用されてしまいますね。

深く考え始めると話がややこしくなるのでアレですが、たぶん上記のような事を意見していただいたと、私は解釈しました。

blog上でのレイアウトに限らず、オンラインのRSSアグリゲータで読み込んだ際にも、同様の問題が起こる可能性があります。

例を挙げると、はてなRSSではRSSリーダーのタイトルはh1要素、グループ名がh2要素、各エントリタイトルがh3要素でマークアップされています。はてなRSSは過度な装飾がされていないので気になる程崩れたりしませんが、本文中にh1要素が使われていると、それはやっぱり妙な表示になってしまいます。

試しにcontent:encodedへh要素だけを書いたrssを、はてなRSSに食わせてみました。

んー。もうちょっと分かり易く崩れてくれればよかったんですけどね。とりあえずh3ではちょっとインデントが。んでh1には画像が張り付いてます。

要するに、h要素は場合によって執筆者の意図しないスタイルが適用される可能性がある、と言うことで。

余談。

現在策定中のXHTML 2.0ではh1..h6要素に加え、新たにh要素とsection要素が追加されるそうです。

There are two styles of headings in XHTML: the numbered versions h1, h2 etc., and the structured version h, which is used in combination with the section element.

XHTML 2.0 - XHTML Structural Module

数値による見出しレベルの指定では6以上を指定出来ないし、その数値を増やすというのもあまり現実的でないからでしょうか。h要素と合わせてsection要素を使いネストする事で階層による見出しレベルを指定する。

<h>大見出し</h>
  <section>
    <h>中見出し</h>
      <section>
        <h>小見出し1</h>
          <section>
            <h>小見出し2</h>
          </section>
      </section>
  </section>

これでh1からh4までと同じになるのかな？単純にh1等とマークアップするのではなく、section要素で階層を構築することでheadingとその内容を明示出来るので実に合理的だとは思いますが、書くのがちょっと面倒かも。

文書構造と見栄えを切り離し論理マークアップを行うということは、単にCSSを使ってレイアウトや装飾を行うというだけに留まらず、見た目にとらわれないマークアップが重要なのではないかと思ったり。

日常的にCSSを無効にしてブラウジングしている、なんて人もそんなにいないだろうけど、Operaのスモールスクリーンレンダリング(京ぽんとか)ではmedia allのCSSは適用されないし、w3mやlynxといったテキストブラウザを頻繁に利用する人は少なくないと思う。

そんな特殊な状況下でなくとも、もっと身近な例。

blog等のRSSをアグリゲータで読む場合なんてのは、当然スタイルシートが適用されていない本文だけが表示されるし、もしそのRSSがcontentモジュールを利用して全文配信していれば、わざわざそのサイトへ足を運ばないでしょう。
そんな場合いくらp要素へclassセレクタを使って文字に色々装飾したとしても、それは読者に伝わらない。文字をデカくしたりカラフルにしたり、という事ではなくて、p要素に別の意味を持たせようとしても、それはどうやってもp要素以外になり得ない、という事。

分かっていれば大したことじゃないんだけど、CSSを覚えたての時はよくやるミス(オレもそうだった)なのでまとめておきます。一応blogの本文を書く時、という状況でのマークアップを想定してみる。

//blogツールによっては本文中に使えないタグがあるとか、wikiみたいに独自の記法だったりとか、そーいう場合もあるかもしれないけど、そのへんは考慮してない。

//あとstyle属性は無視。あれあんまり好きじゃない。物理マークアップするのと大差ないし。

小見出しはh要素

そのページの大見出しとなるページタイトルは、通常h1要素でマークアップされ、小見出しに関してはh2からh6を用いるのが一般的。

blogなどでは、エントリのタイトルがh2要素でマークアップされている事が多いのではないでしょうか？

で、そのエントリ内で見出しを付ける場合。

本文内だからってテキトーな要素にテキトーな装飾したりしないで、これもやっぱりh要素でマークアップすべきでしょう。そうすればRSSアグリゲータなどで見た時に、そこが小見出しであることが丸分かり。これだけで格段に読みやすくなります。

引用マークアップ

引用してリンクして、言及してトラックバックを飛ばす。という状況が多いblogでは、引用のマークアップは比較的使用頻度が高いのではないでしょうか。

また引用する際は引用元の明示が不可欠なので、少々面倒でも引用のマークアップはしっかりと行いたいものです。

長い文章の引用はブロックレベルのblockquoteを使う。基本形はこんな感じ。

blockquote要素のcite属性とtitle属性は、あればなお良い、というくらいのものでしょうか。引用元へのリンクはcite要素でblockquote要素内に記述していますが、これはblockquote要素の外に書いても問題ありません。

なお、blockquote要素で記述すると、多くのブラウザではインデントが設定されて表示しますが、インデント目的でblockquote要素を使うべきではありません。

短い引用はインラインのq要素で

こんな感じでお手軽に。

q要素でマークアップされた部分は、多くのブラウザではダブルクォーテーションに囲まれて表示されます。まれに対応していないブラウザもありますが。

斜体、太字など

文字に'斜体|太字|下線|打ち消し線'などの装飾を行う要素はありません。

しかし、以下のような要素を利用する事が出来ます。

• em要素は強調を意味します。多くのブラウザでは斜体で表示されるようです。
• strong要素は、より強い強調を意味します。多くのブラウザでは太字で表示されます。
• del要素は削除文を意味します。間違った記述を削除する際に利用します。多くのブラウザでは打ち消し線を伴って表示されます。
• ins要素は追加文を意味します。訂正した新しいテキストを追加する際に利用します。多くのブラウザでは下線を伴って表示されます。

物理要素であるs要素やb要素が廃止されたのに、何故emやstrongは許されるのだろう、と。そんなふうに思っていたのですが、要素そのものに斜体や太字といった物理的な意味があるs要素やb要素と違い、emやstrongはそれ自体には強調という意味が与えられているだけ。そう考えると納得出来ます。

ところで、削除文を意味し多くのブラウザでは打ち消し線を伴って表示されるdel要素ですが、これを削除文でもないのにただネタとして利用するのは問題ではないでしょうか。それと便座カバー。

……こんなカンジに。
こういった場合は、その要素の意味にそぐわないので、むしろspan要素をclassセレクタで装飾した方が良いような気がするのですが。

//いや、ネタの時は打ち消し線じゃなくて^h^h^hとかやるか。
//strike要素も廃止されてるので使わない方向で。

リストマークアップしよう

こんな書き方は如何なものか。

リストならばul要素や、番号付きのol要素を用いてリストマークアップするべき。

ol要素はli要素以外を含むことが出来ないけれども、li要素内には別の要素を含ませる事が出来る。

ただ、こーいう場合はむしろ定義型リストマークアップにした方がすっきりするかも。連番付かないけど。

と、いうことで

私が日記本文中によく使うマークアップをまとめてみました。

本格的な(x)htmlの解説には遠く及びませんが、日常的なマークアップ作業ではとりあえずこれだけ知っていれば困らないのではないでしょうか。

webにhtmlを公開するときは、validatorやlintでチェックするのも大事ですが、色々な状況を想定して表示確認する事も重要だと思います。そして、その手間を可能な限り減らす為には、標準的で適切なマークアップをすること、なんじゃないのかなぁ。

//CSSでの見た目にとらわれないhtmlを、というテーマだったけど書きかけて飽きたから途中でごっちゃになってる。

htmlにおいて段落はp要素によってマークアップされます。またp要素の区切りは多くのブラウザで行間を空けて表示されます。しかし、多くの紙面媒体においては、行頭を一字下げて表記され、またこれが日本語の文章としては慣れ親しんだカタチなのではないでしょうか。

判読性の面から考えると、Web上の文章に限っては行頭字下げを行わずに行間を空けた方が良い、と思うのですが、これは主観的なものなので、人によっては字下げされていないと見難いと感じるかもしれませんし、一概には言えないでしょう。

なのでマークアップの観点から考えます。行頭全角スペースの可否ではなく、どのように挿入すべきか。

行頭に2バイトのスペースを挿入するのは文書構造的に有りなのか？

もうちょっと絞り込むと、行頭スペースは"文字"なのか？それとも装飾なのか？

文字として扱うのであれば、p要素内の先頭にスペースを挿入しても問題ないと思われます。しかしその場合、特別意味のない2バイト文字が余計に含まれることになります。そして、それを除去したいと思った時に、閲覧者サイドからはどうになりません。

さらに……ちょっと飛躍し過ぎかもしれませんが、一字下げのスペースが文字として扱われるのであれば、センタリングなどの行頭揃え目的で用いられる全角スペースもまた文字として扱って良いということになりかねない。無論これは間違った使い方であるべきなんですが。

なので、装飾として考えてみます。

行頭字下げスペースは文字ではなく、あくまでも段落の区切りを明示する為の装飾であると。言うなれば、疑似要素:first-letterで装飾されるドロップキャップと同様のものと解釈します。

文章や構造ではなく、あくまでも装飾であるとするならば、html文書内に行頭全角スペースを挿入するのは良くない書き方という事になります。htmlは文書構造を記述するためのものであり、装飾はCSSを用いるべきだからです。

ならば、cssでp要素に対してインデントを設定すべきではないでしょうか。

ページ制作者が、段落をp要素によって適切にマークアップしていれば、閲覧者側でインデントを設定することも出来るし、制作者がcssでインデントを設定している場合は、これを無効にすることも出来る。ユーザcssで

などとしてやれば良い。

しかしtext-indentで全てのp要素に対して字下げを行った場合、地の文は問題ないとしても単一の段落として書かれた会話文も字下げが行われてしまう。これは単一の段落となる会話文に対しては別途class属性でインデントを設定してやれば問題ないのですが、そこまでCSSでのインデントに拘るというのも、Webに慣れた層なら別として、原稿用紙などの紙面媒体の延長としてhtmlをとらえている層には向かないかも知れませんね。尤も、そんな層はただ書いたテキストの行末に<br />を付加しただけでhtmlを公開していそうなので、p要素云々というところまで達していないケースが多いですけど。

それが悪いとは言いません。しかし様々な閲覧環境を考慮してWebページを制作する場合は、やはり上記のようなケースは問題です。たとえば、横幅の狭い携帯端末上でCSSを無効にして文章のみを読んでいる時、全角スペースで字下げなどのインデントが行われているとそれが煩わしく感じることがあるのです。

字下げの有り無しによる判読性が環境や個人によって定かではない事を思うと、全角スペースではなく、閲覧者側でどうにか出来るcssでtext-indentを設定してくれた方が有り難いなぁ、と。