double-team.orgでタグ「(x)html」が付けられているもの

ここ3ヶ月くらいずっと悩んでいる。どうにも解決方法と言うか、「これ！」と言う回答が見つからないので一旦整理する意味でブログに書いてみる。

よく、「ページトップに戻る」と言うリンクがある。
例えばドコモの製品ページ。ここでは「このページのトップへ」と言う表記でページ内の #top へリンクされている。この #top がどこに書かれているか探してみると、ドコモのロゴの a 要素に name 属性と id 属性の併記でなされている。
今度は mixi のヘルプページではどうか。「TOPへ戻る」と表記され、同様に #top へリンクされている。この #top はソースを見ると164行目に空の a 要素に name 属性で書かれている。

で、自分は何を悩んでいるのか。

1. ページトップなどの表記は正しいのだろうか
2. 本当にページの先頭に遷移するリンク先は #top（または #pagetop など）でよいのだろうか
3. ページの先頭はどこなのだろうか
4. そもそも古典的とも言えるこの手法は正しいのだろうか

この4点が全て。
今まで常識的にやっていたことを1回でも疑問に思うと、そこから先全てが疑問に思えてくるから不思議。うむむ。

ちなみにこのナビゲーションの存在そのものは否定しない。mixi のヘルプページのように、長いページであるとユーザビリティ上あってもよいと思う。だけどこれまで通りのやり方でよいのかが疑問視する点。

1. ページトップなどの表記は正しいのだろうか

ここで問題なのは「ページトップ」や「トップ」、「先頭」それに「戻る」の意味。これらの組み合わせでいろいろな表現がある。

• ページのトップへ
• ページの先頭へ戻る
• ページトップへ
• ページトップに戻る
• トップに戻る
• 先頭へ
• このページのトップに戻る
• このページの先頭へ
• TOPへ
• その他いろいろいっぱい

これらの言葉をかなり砕くと「あなたが現在閲覧しているページの最初に移動します」となる。

そもそもにおいて「トップ」や「先頭」と言う言葉の意味を考えると、header や footer と同じように、位置を意味することになるような気がする。だからそこから導かれるように #top が生まれたのではないかと思う。

2. 本当にページの先頭に遷移するリンク先は #top（または #pagetop など）でよいのだろうか

じゃあ #top と言う表記は正しいのだろうか。フラグメント識別子を含めた URI を1つのリソースとして見ると、top を示すリソースが固有名詞（例えば本のタイトル）であるなら問題ないが、それがページ内の位置を示すのであれば間違いではないか。

参照するリソースが固有名詞の例

<h2 id="top">山田太郎著「トップ」</h2>

参照するリソースがページの位置を表す例

<p id="top"><img src="logo.png" alt="ほげほげ株式会社"</p>

前項で header や footer と同じ、位置を表す意味となると言ったのはこうした理由である。

では代替案はあるのか。それはページの最初がどこであるか定義するかによると思う。

3.ページの先頭はどこなのだろうか

まずはこの double-team.org の大まかな構造から考えてみる。

1. ブログ名（double-team.org）
2. 検索窓
3. ナビゲーション
4. エントリのタイトル
5. エントリの内容
6. （上記2つが続くので略）
7. 最新のエントリ10件のタイトル
8. 月別ごとのエントリ
9. エントリのタグ一覧
10. コピーライト

これをもとに、ページの先頭として考えられる候補はいくつかある。

1. 純粋にページの最初から
   • ブログ名（double-team.org）
2. ヴィジュアル上の最初から
   • ブログ名（double-team.org）
   • 検索窓
   • 最新のエントリ10件のタイトル
   • これらのいずれか
3. ユーザが次に行動しやすいような箇所から
   • 検索窓
   • ナビゲーション
   • 最新のエントリ10件のタイトル
   • 月別ごとのエントリ
   • エントリのタグ一覧
   • これらのいずれか
4. 必要なのはコンテンツなのでエントリから
   • エントリのタイトル

考えようと思えばいくらでも考えられる。
恐らくその Web サイトまたは Web ページにあわせた、適切な箇所を参照するのが良いのだと思う。ただ、Web ページ単位で考えると制作者が思考迷路に陥る可能性が高いので、現実的ではないのかもしれない。
そしてもし Web ページ単体で考えるとなると、ページごとにフラグメント識別子を埋めて行く必要があり、それ以前に前項の #top が本当に正しいのかと考える必要がある。

4.そもそも古典的とも言えるこの手法は正しいのだろうか

フラグメント識別子を含めた1つの URI として考えるのならば、別の解決策を考えてみるのも1つかもしれない。

前項ではページの先頭がどこかを定義する必要があったが、純粋にページの最初であるのが多いと思う。アクセシビリティの分野で名高い富士通株式会社や株式会社インフォアクシアでは body 要素の開始3行以内にページの先頭へのリンク先として id 属性が記述されている。

つまり、極端な話をしてしまえばページの最上部へブラウザが表示してしまえばいいとなる。
これを実際にやっているのがニコニコ動画である。

ニコニコ動画では body 要素の開始直後にページの最初に戻るための id 属性が空の a 要素で記述され、そこにページ下部にあるリンクから参照されているが、その方法が JavaScript で id 属性値が PAGETOP であるところまでスクロールさせると言う手法である。

この方法であれば URI はフラグメント識別子を含めずにページの最初に遷移させることが可能となる。ただし、潜在的には #PAGETOP があるために、見た目上はフラグメント識別子を含めない URI であっても実質的にはこれまで通りの方法とあまり変わらないのは確かである。
さらに言えば、あくまでブラウザ上の表示位置をスクロールして変えただけであって、例えば音声ブラウザではそこに遷移したことにならないので意味が無い。

結論

ここまで書いても結局答えはでてないのだが、一番近いと思っているのはこれ。

<p><a href="filename.html">このページの最初から再度読む</a>

ただしこれも問題があり、再度同一のリソースを参照することになるので「最初から読む＝HTML の参照」となってしまう。意味合いが変わってくる。
また、最初から読むのが必ずしも HTML の先頭からとは限らないので、無駄が発生する可能性がある。
さらに、サーバへのリクエストが増える可能性もあるので、やはり無駄が発生する可能性がある。

なので、やはり結論が出ていない。この辺の考え方を偉い人がブックマークのコメントとかで教えてくれると助かったりします。

あー長かった。これ書くのに3時間かかるとかどんだけー。

参考サイト

• ハイパーリンク -- ごく簡単なHTMLの説明

はてなブックマーク経由で見つけてきた。

• How Many HTML Elements Can You Name in 5 Minutes?
  （5分間にいくつ HTML の要素を言えますか？）
• How Many CSS Properties Can You Name in 7 Minutes?
  （7分間にいくつ CSS のプロパティを言えますか？）

自分の結果

HTML の結果

51

JustSayHi - A Free Dating Website

CSS の結果

65

Free Online Dating from JustSayHi

まあ CSS はプロパティによって使う・使わないが激しく分かれるので、まあこの辺が無難だろうと思います。印刷関連や音声関連が一切出てこなかった。

しかし HTML はちょっとなぁ。。非推奨要素まで入ってるから困る。b 要素とか s 要素とか偶然出てきたレベルだし。あとフレーム関連は一切知らない。
けどフォーム関連が全然思い出せなかったのは自己嫌悪。ダメだなぁ。

たぶんどこにでもあるネタだと思うけど、きっかけは”position プロパティの fixed 値を印刷時にはどーやって表示されるのか”が気になったので試してみたら”これでプレゼンテーションツールが作れるんじゃね？”ってことで作ってみた。

• XHTML+CSS Slideshow Tool Ver 1.0 サンプル ファイル
• PDF 印刷したサンプル

XHTML+CSS Slideshow Tool とは

純粋な XHTML と CSS の組み合わせで PDF 印刷することを前提に作られたプレゼンテーションツールです。
XHTML 文書の中身は S5 と似たような構造になっています（かなり単純化されてますが）。
なので JavaScript によるエフェクトは一切ありません。個人的にそんなのはいらないと思っているし。

使い方

• title 要素にタイトルを記述し、これがヘッダのプレゼンする内容のタイトルとなる。
  サンプルでは”XHTML+CSS Slideshow Tool Ver 1.0”がそれに該当。
• <div class="canvas"> がスライド1ページに相当するので、この中に内容を記述。
• 見出しは h1 要素となっているので、そこにスライドごとに記述。
• <div id="footer"> がスライドのフッタになるので、必要に応じて自身の名前や所属、コピーライトや連絡先を記述。
• あとは PDF で印刷するだけ。

いろいろと思うこと

実はあんまし有効性がない。その辺の話はサンプルの中で書かれているけど、まあただ単に作ってみたかっただけ。
あとエフェクト演出がないとダメって人には向かない。だったら Keynote 使えって話だけど。

具体的な中身に関しては向こうのブログで書くつもりです（ネタ確保）。

追記 2007年8月23日 13:30

このツールの詳しい中身の説明を plucore.log で解説しています。こちらもご覧ください。

• XHTML+CSS Slideshow Tool の仕組み

「Web 標準の日々」初日を終え、まったり中。レポートみたいなのははてなダイアリーの方にとりあえずその場の勢いで書いた。本当はセッション3の「富士通の実践、アクセシビリティ/ユーザビリティ。そしてファインダビリティ」も受講したんですが、資料配布なし、録音を認めていなかったので、エントリはしてません。記事としてはあるんですが、この辺表に出さない方がいいのかと思って。聞いておけばよかった。。

で、自身のエントリにレスを付けるのも変な話ですが、分かりやすいと思ってこうします。
「float プロパティを使用する場合はその要素の幅の明示が必要」に対するコメントをいくつかいただいてますが、それにちょっち返答と言うか、自分の考え方を残しておきます。

• 2007年07月13日 kits CSS 2.1 だと仕様が少し変わっています。 http://hp.vector.co.jp/authors/VA022006/css/css21_visudet.html#float-non-replaced-width
• 2007年07月15日 NiPeke 2.1 なら shrink-to-fit するぜ？　2.1 には日本語で言う『明示的な幅〜』というのも無いような

• 最近のモダンブラウザは概ねCSS 2.1の仕様に沿ってレンダリングされるから、最新ブラウザのみが対象であ れば必要ないかもしれないと思う今日この頃。e_luck
• 2.1 なら shrink-to-fit するぜ？　2.1 では日本語で言う『明示的な幅〜』という部分も変更されていますね Kaminogoya

確かに CSS 2.1 では幅の明示は必要ないです。そして CSS 2.1 が草案（まだ最終草案の段階ですよね？）であるにもかかわらず、すでにブラウザ側が実装しているのも知っています。
でもこれは個人的な思いなんですが、現段階で「内容に合せて縮めた幅を算出する」と言う仕様があったとしても、実際に勧告してみないと分からないじゃないですか。ワーキンググループメンバーの主義主張でひっくり返る可能性だって無いわけではないですし。と言うかそっちの方は全然詳しくないし参加もしてないですし分かりませんが、未だ CSS 2.1 が10年くらいずっと今の状態であるわけなので、何が起こってもおかしくないと言うか。

と言うのが率直な感想で、いくら実装面で CSS 2.1 がほぼ準拠されているとは言え、限りなく公式に近いデファクトスタンダードだと思います。
それが良い悪いの話じゃなく、現段階の仕様には可能な限り準拠した方が将来に対するリスクは少ないんじゃないかな、と感じるんです。もっとも、この話は実装面にも依存するので、何とも言えませんが。この辺はあっちのブログで書いたように、会社的な考えにもなるんですが。
もちろん必ずしも仕様準拠ありきとまでは言いませんが、でもそれを踏まえた上で（今ならば）選択する余地はあると思うんです。幅を明示するかしないかとか。

でも思えば (X)HTML 文書は HTML なのか XHTML なのか、HTML なら 4.01 なのか 5 なのか、XHTML なら 1.0 なのか 1.1 なのかって選択できますけど、CSS は選択できないんですよね（HTML 5 はまだ選択肢として無いけど、例みたいな感じで）。まあこれは別に問題があるわけじゃないからいいのかな。パッと思いつくほど CSS のバージョン宣言しなければならない仕様差異があるわけじゃないし。CSS 3 だとまた話は違ってくるだろうけど。

なんかタイトルに「の」が連続してるけどいいや。

「水平方向のナビゲーションの作り方」のはてなブックマーク見て、誰も float プロパティの使い方に疑問を抱いてないのを見て不安になった。

CSS 2 の仕様書内で float プロパティ（浮動体）は以下のように書かれています。

浮動ボックスは，明示的な幅をもたなければならない。明示的な幅は，置換要素の場合は，'width'特性, 又はその組込み幅によって割り当てられる。

ここである「width 特性」と「組込み幅」とはそれぞれ以下の意味となる。

width 特性とは

スタイルシートとの width プロパティを使用すること。
ちなみに「特性」は単に「プロパティ（Property）」を和訳した単語。

組込み幅とは

仕様書内では実寸法と表記されている。

実寸法 (Intrinsic dimensions)

環境によって決まるのではなく，要素自体によって定義される幅及び高さ。 CSS2では，すべての置換要素が, そして置換要素だけが, 実寸法で現われるとする。

組込み幅の定義をもっと具体的に表すと「img 要素・object 要素の width 属性もしくは画像やオブジェクト自体の幅、input 要素・select 要素の size 属性、textarea 要素の cols 属性」がこれに相当する。

なので、画像の回り込みに以下のような記述をすることは問題ない。

img {
    float: left;
    margin-right: 10px;
}

img 要素には幅があるので、スタイルシートで幅を与えることは（意図してその画像自身の幅と異なる大きさをしたいしたい場合以外であれば）無い。

ただし、幅を持たない要素は必ず width プロパティを使用する必要がある。
ここではリストを利用しているので、そのサンプルをそのまま使わせていただくが、通常であれば以下のように指定する。

HTML サンプルソース

<ul id="navigation">
  <li>編集</li>
  <li>削除</li>
  <li>追加</li>
</ul>

スタイルシートサンプルソース

#navigation {
  list-style: none;
}

#navigation li {
  width: 2em;
  float: left;
  background: transparent url(arrow.gif) no-repeat scroll left center;
  padding-left: 12px;
  margin-right: 15px;
}

もっとも、リストにある文字数によって幅を変える場合はかなり面倒なことをしないと行けないので、やはり display: inline; を使用するのが簡単と言えば簡単ですが。

全然関係ないですが、サンプルのソース上では「追加」になっているのに表示結果の画像では「新規追加」になっているのは直した方がいいと思います。

追記 2007年7月17日 11:04

CSS 2.1 では、と言う話を受けて別途エントリしました。そちらもご確認ください

• Re: float プロパティを使用する場合はその要素の幅の明示が必要

と思いつつもう1ヶ月が経ってしまったが、昨日から本格的に取り掛かり、何とか今日中にはできるかなぁ～。ってな感じで進めてた。

やはり無理でした。HTML はもう出来上がってるんですが、ここから Movable Type のテンプレートに起こさなければならないのでいろいろと面倒です。
一応時間を見ながらテンプレートを入れ替えていきます。作業中は何かと不都合が生じるかもしれませんが、とりあえずここ最近の PV 数の遷移を見る限りは問題ないかと（何

テンプレート書き直しと言っても、実際にはデザインが変わるんです。
今回はいろいろと挑戦してみました。

• div 要素完全廃止（ちょっとこれはやってみたかった）
• 画像なし（エントリ内にある写真はともかく、それ以外の装飾用の画像は完全撤廃）
• Firefox・Opera・Safari 対象（IE だといろいろ不都合が生じる箇所がありますが、多分問題ないと思う）
• header,footer が ID 属性ではなく class 属性（これはただの気まぐれ。実験的に採用してみただけです）
• wu さんの「デフォルトスタイルの差異を無くすCSS」を使ってみた（ほとんどこれに頼りっきり。仕事でも使ってます）
• きくちゃんの「99%CSSで作るプルダウンメニュー」を使ってみた（同じく仕事でも使っています。ありがたやー）

ってな感じです。デザイン自体は何も考えてない、その場でやっつけです。
作ってて思ったんですけど、やってることって例の「画像の使用を極力控えて（長いので略）大会」と同じなのでは？　と感じたけど、それはそれ。これはこれ。機会があれば大会の方にもチャレンジしてみます。

追記 2007年5月22日 17：48

やはり IE はメニュー部分がダメっぽい。IE7 も。
この辺直せれば直します。直せなければ放置か別の代替手段を考える。

あと、トップページとエントリページでそれぞれエントリタイトルの見出しレベルが違う（トップページだと h2 要素で エントリページだと h1 要素）んですが、追記や変更の見出しレベルは何にしたらいいんですかね？
この辺は動的に変えられるわけではないじゃないですか。そもそもエントリ内に見出しを書くこと自体が無理なんですが。

トップページの構造（簡潔に）

• double-team.org（h1）
  • エントリタイトル（h2）
    • エントリ内の見出し（h3）

エントリページの構造

• double-team.org（p）
• エントリタイトル（h1）
  • エントリ内の見出し（h2）

エントリ内の見出しは p 要素で記述するべきですかね？　でもそれだと見出しじゃないですもんねぇ。
追記や変更を見出しで記述すべきかどうかはともかく、エントリ内に見出しが記述できないのは問題なのかと思ってる。
（ちなみに h2 要素で記述するのはちと違う気がする。トップページだとエントリタイトルと並列になるし。）

Rusica さんの正しくHTMLを書こうと心がけている人に5つの質問に回答。

1. HTML文書を制作する際に使用しているプログラムをお答えください。（Webプログラムも含む）
2. 採用しているDTDとその理由をお答えください。
3. 何故正しくHTMLを書いているのですか？
4. W3CとWHATWG、どちらに期待してますか？
5. あなたにとってHTMLとは何ですか？

1. HTML文書を制作する際に使用しているプログラムをお答えください。（Webプログラムも含む）

仕事では Dreamweaver8 がメイン。細かい変更とかは Windows 付属のメモ帳とか秀丸。
プライベートではメモ帳か TeraPad か秀丸。
もしかして Firefox とかも答えるのかなぁこれ？
全部書き出すとこんな感じ

• Firefox1.5,2.0
• IE6,7
• Opera7-9
• NextFTP
• WinSCP
• Photoshop CS2
• UTF-8 TeraTerm Pro
• Movable Type
• Xoops（今はやってないけど昔はこれだった）

2. 採用しているDTDとその理由をお答えください。

状況に応じて HTML4.01 Traditional だったり XHTML1.0 Strict だったり。
個人的に良く使うのは XHTML1.0 Strict。
仕事で Movable Type のテンプレートを作るとかだと XHTML1.0 Traditional が多い。

3. 何故正しくHTMLを書いているのですか？

仕事だからです。（半分あってる）
そうじゃなくても、正しく書くのが当然だから。非 Valid な HTML をレンダリングするブラウザの方がおかしい。

4. W3CとWHATWG、どちらに期待してますか？

どちらに期待しても HTML5 は恐らく勧告されるだろうし、 XHTML2.0 は遅々として勧告されないだろうし、まあそーゆーことです（何

5. あなたにとってHTMLとは何ですか？

もっとも単純でもっとも複雑で最も利用されている言語。
そしてオレが生きている間に消滅するであろう言語。

昨日のアルコールが胃の中に残った状態で仕事場へ。若干気持ち悪い。近くのコンビニでマンゴージュースを買って洗浄。甘い。
日課である RSS を消化してたら今日が CSS Naked Day だったことを思い出す。これに自分もやるべきかどうするか多少迷ったが、良い機会なので乗ってみた。自戒も込めて。

で、今日1日スタイルシートを適用しないプレーンな XHTML 文書を晒すわけだけど、これを実行に移すにあたって考えられた手段が2つ。

• スタイルシートを呼び出している link 要素を削除もしくはコメント内にしてしまう
• スタイルシートを空のファイルにしてしまう

どっちかだろうなぁ。どっちがラクかなぁ。なんて思ったけど、XHTML 文書に手を加えるのはアレな感じだったので後者を選択した（何

このブログは相当な手抜きで構築したからあまり中身を見たくないのだが、また今後もこーゆーことが起こり得ると思うと再構築の意欲が出てくる。時間がかかるからかなり余裕がある時じゃないと実行に移れないのが難点。
なんせまだコメント部分とかトラックバック部分とかかなり適当だし、コメントの確認画面なんてそもそもテンプレート作ってないし、検索結果画面も恐ろしい。それ以前に全ページ h1 要素がブログ名の「double-team.org」なんだけど、まあ全体的に結構ヤバイ。

でもだからこそ今日のイベントにチャレンジしてみた。スタイルシートがあると分からないことが、今日みたいなひょんな出来事によって暴かれてしまう。ネタ提供。自己犠牲。でも自分は M じゃない（何

追記 2007年4月5日 12：32

関係ないっちゃ関係ないけど、見れば分かる通りこのブログでは hr 要素を使ってるよ！

ここ数日、いろんなブログで id,class 属性の議論が話題になってる。
個人的な結論から言ってしまえば、デファクトスタンダードに則ってやればいい。
この一言で終わるんですが、ダメですかね？

id="header" はデファクトスタンダードの典型

この議論でよく例に出されている id="header" ですけど、これこそデファクトスタンダードの典型なんじゃないかと思うわけです（良い悪いかはともかく）。
言ってしまえば「ロゴとかナビゲーションとか検索窓があるこのブロックをヘッダとして id 属性を付与して意味を与えればいんじゃない？」と言う風習、習慣、慣わし、デファクトスタンダードなのかと思う。
で、今は「それはおかしいんじゃないの？」と疑問が投げかけられてる。でも個人的にはヘッダはヘッダであって、唯一無二の固有性を持つ存在であるわけだから、それは id 属性であっても問題ないのでは？　と感じる。

と言うわけで、ヘッダやフッタ、他にあるとすればナビゲーションとかは

• id="header"
• id="footer"
• id="navigation"

と言うどこでもよく目にするこれはアリかと（多少の命名規則の違いは今は問わない）。
まあ別にこれらを class 属性に変えたところで実作業上、特に問題はないんですけどね。
ただ組織的にやる場合は各々のローカルルールがある程度存在すると思うので、その辺はそれを優先するにしても、そのローカルルールが存在しない組織ないし個人はデファクトスタンダードに則るのが無難だし、少なくとも作業上の間違いはない。

なんて思ってるんですが、他にもいろいろ言いたいことがあるけどそれはまたいつか話す機会があれば。

関連リンク

• CSS Nite Vol.18交流会「HTMLへの回帰」
• WEBTECH - メモ:classとid
• HTMLに於けるclass属性とid属性の真実 - 行動記録
• classとidの使い分けについて考えてみる | Blog hamashun.com
• id名、class名の最近の自分の傾向｜CSS HappyLife
• class属性とid属性に関する議論リンク集 - 徒委記

変更 2007年3月22日 21：05

リンク先修正

今日はとても面白い1日だった。いや別に仕事とかプライベートとかじゃなく、ガリガリ CSS 書いてて楽しかった。
なんとなく「できるかなー」と思ってグリグリ2時間くらい費やした甲斐があった。でもあとで調べたらいい感じの記事があって、「こっち参照でいいんじゃない？」とも思ったが、せっかくなので残しておく。

と言うわけでまたここからで申し訳ないんですが、パンくずリストがベストとは限らない | WWW WATCH を見て「link 要素を可視化させちゃえば（ちょっとだけ）解決できるんじゃない？」と思ってやってみた。

XHTML の記述を例えばこんな感じに。

<link rel="start" href="index.html" title="最初のページへ" />
<link rel="next" href="next/index.html" title="次のページへ" />
<link rel="prev" href="prev/index.html" title="前のページへ" />

で、CSS はこう。

head {
display: block;
}

link {
display: block;
width: 100%;
}

link::after {
content: attr(title);
}

• サンプルその1

最小で書くとたったこれだけで可視化は可能。一番重要なのは head 要素を可視化するのが必要。ここでは display プロパティの値を block にしているが、inline でも問題ない。あくまで表示するだけならば値を inline でも良いですが、link 要素の display プロパティの値が block になっているのと、ルートの html 直下にインライン要素が配置されるのは不自然なので、head 要素はブロック要素として扱うのが良いです。
ちなみに link 要素に疑似要素の ::after が付随しているので当然のことながら IE だと無理です。IE 対応しようと思ったら JavaScript でアレコレやらないと多分無理だと思います。

ただこれだとちょっと味気ないので、ちょっとだけ装飾してみる。

head {
display: block;
padding: 5px 5px 10px;
border-bottom: solid 1px #ccc;
}

link {
display: inline;
font-size: 80%;
color: black;
padding: 3px 5px;
border: double 3px #ccc;
border-color: #ccc #666 #666 #ccc;
}

link:hover
{
border-color: #666 #ccc #ccc #666;
}

link[rel="start"]::after {
content: "ホーム";
}

link[rel="next"]::after {
content: "次へ";
}

link[rel="prev"]::after {
content: "前へ";
}

• サンプルその2

title 属性をそのまま使わず、単語で分かりやすく表記してボタンっぽいデザインにするとそれらしく見える。

ただこれらの方法ではいくつか問題点がある。

• Opera だとリンクなしで表示される
• tab キーで選択できない
• head 要素内にあるのを無理矢理可視化させたので、ページ内のコンテンツと組み合わせるのが難しい
  • position プロパティを使ってアレコレやればできるけど、またブラウザの問題（CSS の解釈とかなんとか）が出てくる

Opera の問題ですが、否定疑似クラスを使うっぽいと思ってるけどあまり理解してないので今回は見送りです。本当に否定疑似クラスなのかさえ定かでない。。。
tab キーによる選択が出来ないのは致命的です。こればっかりは Firefox の実装の問題なのでお手上げ。
position: fixed; でブラウザの上部または下部に固定してしまうってやり方はアリだと思いますが、また IE が邪魔するわけですよ。
結局のところ、使える場面があるのか無いのかはっきりしないです。やろうと思えば出来るけどクロスブラウザじゃないよ、って感じでしょうか。

余談ですが、リンクタイプの rel 属性の値 netx と prev は ブログのテンプレート内に入れて今回のようなナビゲーションとして使うと便利かもしれません。Movable Type のテンプレートタグを使って

<MTEntryNext><link rel="next" href="<$MTEntryPermalink$>" title="<$MTEntryTitle remove_html="1"$>" /></MTEntryNext>
<MTEntryPrevious><link rel="prev" href="<$MTEntryPermalink$>" title="<$MTEntryTitle remove_html="1"$>" /></MTEntryPrevious>

なんて書くといいかもしれません。（たぶんデフォルトのテンプレートにこれが記述されていると思います。さっぱりそんなの忘れ去ったので確認できませんが。）

さらに余談ですが、大元の記事であるパンくずリスト（Topic Path）のマークアップに関して、番号（順序）付きリストでマークアップするのがベターなのかと思います。あと番号なし（箇条書き）リストではちょっと意味が違うかなぁ、とも思うけど、入れ子にしていくのもアリだと思う。ただ、段落でマークアップするのを否定するわけじゃないし、それはそれで解釈として正しいはず。
仕様の方に話が飛ぶのもアレだけど、手元にある素材（要素）で料理（マークアップ）するのに、必要状況下でその素材（要素）が無い、もしくは当てはまらないとなったら何かしらで代替を用意するしかない。けどだからと言ってパンくずリストのための要素を用意（仕様策定）するのは本末転倒。だから今あるものでやるしかないのです。正解があるわけじゃないかもしれないけど（日本語がおかしい）、自分が正解だと思えるやり方でいいと思います。だから自分は番号付きリストでやる。それだけです。

追記 2007年2月9日 23：00

記述ミス修正

追記 2007年2月14日 10：51

head 要素の取り扱いについて加筆修正

通常、(X)HTML + CSS で構築されたサイトはモバイル環境（i モードや Ez web とか）でも CSS を切り離された状態で閲覧されるのは周知の事実。一部 CSS 対応してるけど、本当にちょっとだけだし、実装もインラインの style 属性とか head 内に style 要素を記述する方法などがあるが、結局のところ外部 CSS には全く対応しておらず、ちょっとどころかかなりゲンナリする。
ただ、もし CSS に対応すると言うことになることになったら、キャリア側は CSS メディアタイプを screen ではなく handheld として実装して欲しい。フルブラウザがメディアタイプ screen 準拠していることによって、こうした状況が発生しているのは事実だし、スマートではない。

ただ、PC で閲覧する Web サイトとモバイルで閲覧する Web サイトは同じにすべきなのかどうかとされる議論もある。運営する側からすればコスト的にも同一にした方が良いのは当然だし、本来であればそうあるべき。しかしモバイル端末がそれに至っていないのは、クローズドなモバイルサイトが往々にして確立され、それが”正”だと思われているユーザ側が脱却できない点にもある。
そうしたクローズドな世界とオープンな世界のギャップを埋めるのは難しいし、もし可能になるとしてももっと先になると思う。

で、じゃあ技術的に何とか埋める方法は無いかと模索してみたが、あくまで見た目上の話だけをすればある程度は互換性を持たせることができるとは思う。ただし Valid でなければスマートでもない。あくまで互換性重視と言う意味合いで語るのであれば、完全な物理マークアップしかない。

この結論に至った経緯として、一番の課題は「(X)HTML + CSS ではモバイル端末で色・レイアウトが表現できない」ことである。ユーザ側からすると、見栄えはもっとも印象に残り、そのサイトの良し悪しの判断材料としても用いられるのは見て取れる。もちろんユーザビリティの点も重要だ。個人的に必須だと思うのは EZ-GREEに見るケータイサービス構築の重要なポイントにあるショートカット機能。つまり accesskey 属性。コンテンツの遷移を0 ～ 9と # * キーで制御するのは必須だと思う。ページの上部等へのアンカーリンクも同様。

ちょっとユーザビリティに関して偏ってしまったので話を戻すと、モバイルサイトでは未だに marquee 要素が平然と存在する。我々からすると想像を絶するような世界なのがこの要素だけで分かると思う。それだけ見栄えが重要視されている。そんな中でいかにして PC とモバイルを共存させるかを考えると、実装上の問題から物理マークアップするしかないのは致し方ないと思う。物理マークアップするにはいくつか条件が必要になる。

1. 文書型定義は HTML4.01 Trantisional（XHTML では非推奨要素は使用できない）
2. 文字の色、大きさは font 要素を使用
3. 行揃えは align 属性を使用
4. テーブルレイアウトではなく、通常の CSS レイアウト
5. PC で閲覧する場合は CSS で font 要素等のスタイルを消す
6. 文書構造は通常のマークアップ

簡単まとめるとこのようになる。もちろんこれが正とは思わないし、スマートだとは思わない。ただ、現状を省みるとそうせざるを得ない場面があるのは確か。
半ば強制的にモバイルと兼用させると言う考え方も問題なのかもしれないが、あくまで一例としての話なので。

ちなみに最大の問題点は画像サイズとファイルサイズだが、解決方法は無いに等しいし、あるとしればそれこそ XML 文書で作成して XSLT で UserAgent ごとに変えるとか何とかごにょごにょもあるけど、結局コストがかかると言う問題に行き当たるから意味が無い。
あと CSS でスタイルを消すと言うのは

<p align="center"><font color="#ff0000" size="+1">ほげほげ</font></p>

<p><font color="#00ff00" size="-1">ほげほげ</font></p>

この HTML に対して

font[colo]
{
color: black;
}

font[size]
{
font-size: 100%;
}

と CSS で消せばよいのだが、問題は IE では意味が無いと言うこと。なのでもっと簡略的に書いてしまえば

font
{
color: black;
font-size: 100%;
}

としてしまえばよい。

最後にもう一度言っておきますが、これは間違いであることを承知で書いています。モバイル側が互換性を無視して独自拡張を続けていくことに対して、こちら側が歩み寄った場合の話なので、運用面やコスト面重視で考えるとこうするのがベストでもベターでもないけど、解釈としてはアリなんじゃないかと思うわけです。実践するかしないかは任せますが、Perl や PHP で UserAgent 振り分けて動的にページを生成させるとか、そんなことするくらいならこっちの方がまだマシ、と言うのが自分の考えです。

関連リンク

• 作ろうiモードコンテンツ
• EZfactory
• SoftBank Developers Support Site

仕事の合間のエントリなので、思ったままのことを手短に書きます。

• そもそも CSS でデザインするためには (X)HTML が分からなければ意味がない。
  • div 要素が必要以上に発生したり、直接テキストが入るのはいかがなものか（せめて p 要素で括って欲しい）
  • 同じような現象として空 div や br 要素を使って float プロパティによる回り込み解除をするとか。
  • 上記2つは物理マークアップと大差ない
• W3C 信者や strict 厨になれとは言わないが、妥協すると言う風潮が広がることは後世にとってもよろしくない。
  • だけど W3C や WaSP の努力は認めるべき。
• 「CSS でレイアウトすればリデザインが簡単」と言えるあなたを私は信じられない。
  • 今のデザインで固まってしまった (X)HTML 文書を改修せずに、デザイナから上がってきたデザインをその通りに表現できますか？
    • (X)HTML 文書の構造が決まっているのに、それを無視したデザインを上げてくるデザイナを信用できますか？
    • デザイナはマークアップを知らなければ良いと思っていますか？
      • そしてデザイナは (X)HTML を知ろうとしましたか？
        • そのデザイナから上がってきたデザインを可能な限り再現しようと努力しましたか？
  • 本気で (X)HTML 文書を改修せずにリデザインをするためには css Zen Garden のようにしなければ高い柔軟性はない。
• (X)HTML 文書が妥当であるからこそ CSS レイアウトが可能であって、そうでなければただの見た目 CSS。
• 「テーブルを使ってはならない」と思ってるあなたこそテーブルを使ってくださいお願いします。
• 「(X)HTML ＜ CSS」ではない。
  • 「CSS で表現しなければならない」 と疑心暗鬼にかかってるのは問題。
  • ブラウザの表示がおかしいのは、あなたが9割原因であることに気づいてください。
    • 残りの1割は文法上、妥当・非妥当に関わらずほとんど回避できます。
      • それでも回避できない場合は JavaScript やテーブルなどを使ってください。

最近やたら CSS 関連のエントリを見かけるのですが、内容としてどうかと思うのが立て続けにあったので。

関係ないですけど、「(X)HTML + CSS は万能薬ではない」ってどっかで見た気がするんですが、オリジナルがあったら申し訳ないです。中の人とか。

WWW WATCH にて XHTML、CSS を学ぶ時の 6つの間違いがエントリされてるのをはてなブックマーク経由で見たんですが、概ね（と言うか完全に）同意できます。まあ最後のはオチとしては面白いんですが、そんな人が「XHTML とはー CSS とはー」と声高に叫ぶとは思えませんがね。本当にそんな人に教わったもしくは教わっている人は不幸すぎます。この業界で 1，2 を争うほどの。
ちょっと個人的にいろいろ言ってみる。あくまで「オレはこう」みたいな。うぜー。

個人的な意見ですが、「Dreamweaver」 を買うお金があるなら、最初はそのお金で 「Fireworks」 を買った方がいいんじゃないかなと思います。いや、別に Fireworks じゃなくてもいいんですけどね。Web サイト制作を始めるにあたって最初に購入するべきソフトとしては、きちんとした画像編集ソフトの方をオススメしますよということです。

最初はテキストエディタで手打ちしろと。そのかわりテキストエディタはきちんとしたソフトを用意しましょう。（個人的には Win なら 「秀丸エディタ」 がオススメですが）

「最初からオーサリングツールを使わずにテキストエディタを使え」と言うのはちょっとハードル高いけど、多分これしか対処法と言うか、勉強法は無いのかなとは個人的にも思う。Dreamweaver もそうだけど、良くも悪くもオーサリングツールはレンダリングエンジンを乗せてるから、その「見た目」を”正”とする傾向は初心者にはある。（経験談）
あくまで HTML 文書を記述するだけならテキストエディタでよいし、それがビジュアライズとして機能する必要性はないので。

あと個人的にオススメしたいテキストエディタは Windows 標準装備のメモ帳。ez-HTML でもいいですけどね。

でも仕様書は英語だし、、という人にオススメの書籍を挙げるとすれば、XHTML 関連では神崎正英氏の 「ユニバーサルHTML/XHTML」、益子貴寛氏の 「Web 標準の教科書」、CSS 関連では 「セオリー・オブ・スタイルシート」 あたりがよろしいかと。

それでも W3C の仕様書は必ず目を通しておくべきものですよ。

あー、「Web 標準の教科書」はかなりハードルが高いなぁ。それ以外の書籍は読んだことないですが・・・。確かに「Web 標準の教科書」は良い。(X)HTML と CSS の仕様書をそのまま書籍化したって感じが実にいい。しかもそれなりに解説もされてるので、あと数年は使える本だと思う。
ただ、如何せん難しすぎる。別に益子氏が悪いとかじゃなくて、各仕様が複雑すぎて理解できないと思う。それこそ HTML に関して何も前知識が無い人からしたら。（テーブルレイアウトだけしかできないマークアップエンジニアも同類です）ただまあ、これ以上ないってくらいの重要資料（すでに書籍扱いではない）なので、HTML と言う文書構造が多少なりとも分かったら読むべき本だと思う。

そして自分のオススメは「詳解 HTML & XHTML & CSS 辞典」です。(X)HTML の各要素や CSS のプロパティ別に対応ブラウザが掲載されているのと、DTD での要素定義が一覧で見られるのは重要。
あとこれは Web に関わる人全てに言えるけど、「ブラウザのしくみ」は読んでおくべきだと思う。Web の全てが載ってる（たぶん）ので、デザイナやマークアップエンジニア、プログラマなどの技術者もそうだし、ディレクタやマネジメントなどの管理職（と言ってしまっていいのか分からんけど）も知っておくことは多い。

これ、意外に理解していない人がいるのですが、XHTML がすべての基本です。CSS は XHTML で文書構造を定義されたものに対してスタイル （見た目） を定義するもので、どちらが主で、どちらが従かは明白です。

自分がこれに当たります。昔の話ですが。HTML はそこそこ知ってて、そこから CSS レイアウトに入ってしまったので、ちょっと遠回りしてしまった感はある。だから 2 年もかかったんですけどね。それがだいたい 6 年前。
でも当時からしてみたら、今は CSS に関するノウハウはすごい多いし、この環境で「CSS 勉強するの難しい」とか言ってるのは正直甘いと思う。関連書籍もたくさんあるし、ぐぐれば腐るほど出てくるし、それでレベルアップできないのはただ単に避けてるだけとしか思えない。なんだかなぁ。

とまあ、好き勝手書きましたが、最後にちょっとだけ。
こうした XHTML+CSS に関するエントリを見て「よし、自分もやってみよう」と思うのは大いに歓迎です。ただ 1 つだけ誤解して欲しくないのは、全てを CSS で表現しようと思わないことです。
確かに CSS で全ての表現を可能にします。だからと言って、無理に文書構造を当て、CSS で装飾するのはよろしくないと思います。
具体的には

• table 要素を使ってはいけない
  • （似たような意味で）代替として定義リストを使用する
• クリッカブルマップを敬遠する
• 無闇に画像置換をする
  • 同様に img 要素を敬遠する
• 必ず XHTML 文書でマークアップしなければならない

と言った誤解はして欲しくないです。そしてこれは (X)HTML+CSS を勉強する過程で恐らく必ずと言っていいほど起こる問題です。CSS で表現すべきところと (X)HTML 文書で実現すべきところの区分けは曖昧ではありますが、全部を全部 CSS 任せと言うのはどうなのかな、と思うので。（mixi の CSS テクニックのコミュニティを見てるとそう思わざるを得ないので）

ブックマークを漁って気まぐれで Interactive CSS Box Model Demo を見ようとしたら404を返されて「うあーこれってもう過去の遺産としても存在を認めてくれないんですがー」と叫んだ。

ボックスモデルを図解した良い資料だったんだけどなぁ。

Internet Archive で探したらあったことはあったけど、重要なボックスモデルを再現した Flash まで取得してるわけじゃないから意味ナス。

• Interactive CSS Box Model Demo - Internet Archive