昨日、CSS Holic 第3回勉強会に参加してきました。

サンプルのデザインをもとに、5名くらいでサイト構成やページのマークアップ方法などをグループディスカッションをしながら検討し、最後に発表という内容でした。自分では当たり前だと思っていたことが実はマイノリティだったことを知ったりしてともて有意義な時間を過ごせました。皆さん、お疲れさまでした。

さて、グループディスカッション終了後に、参加者の方からこんなことしたいんだけどどうするよ？と質問にあがった内容が、なかなか面白かったです。

質問内容

上図が質問にあがった内容のスクリーンショットです。ポイントは以下の2つですね。

• 右下に表示されている矢印は、マウスオーバー時に右下にずれるような感じ
• テキストの左側にある枠線ですが、テキストが複数行になった時でも1行目分の高さである

右下の矢印

サンプルを見る限り、枠線や矢印部分も含め、このエリア全体がクリッカブルなリンクとなるような感じですね。というわけで、この矢印はa要素なり、要素が足りないようであればa要素の中にさらにspan要素を入れ込むなどして、そいつにdisplay: block;を指定してやったあとに背景画像として表示してあげればOKでしょう。

左上を基点にして背景の位置を考えてしいますと、テキスト量によって高さが変化する部分ですので、矢印の位置が一定になりません。背景画像は要素の右下に表示し、マウスオーバー時の右下にずれるような感じは、余白までを含めて画像を切り出してしまうことで解決可能です。

テキストの左側にある枠線

次に、テキストの左側にある枠線です。枠線ということでCSSのborderプロパティが考えられますが、テキストが複数業になった場合にも1行目分の高さが保たれるというのが曲者ですね。inline要素のborderとした場合にも、テキストの左側を縦あわせしないとですので、なかなか難しいことになります（できるかどうか試してません）。

画像を埋め込んで解決しました

というわけでどうしたものかと悩んだのですが、img要素で画像を埋め込んでしまえばすんなり行きました。文字サイズが拡大された時に、画像の大きさもそれに追随してくれるように、画像の高さをCSSでem指定します。指定する値はテキストのline-height分の高さを指定してあげればOKでしょう。

その他、floatの指定などを細かく行いましたが、実際に指定を行ってみたサンプルを用意しましたので、ご興味がありましたらご確認ください。

僕以外の回答例

@debiruさんの回答：CSS Holic / sample1_rev2

address要素について

また、当日はaddress要素に関しましても若干議論がありました。改めてHTML4.01の邦訳を参照してみますと、以下のようにあります。

ADDRESS要素は、文書全体、あるいはフォームなど文書の主要部分に関する問い合せ先を示すのに用いられる。 たいてい、文書の冒頭か末尾に現れる。

こちらを読む限り、たいていの場合はサイト所有者の連絡先をマークアップするのに用いられるのがaddress要素ということになりますね。例外としましては、サイト所有者と違う組織・団体の方などの文書がサイト内にある場合などでしょう。そういった場合にはその違う組織・団体の方などの連絡先をaddress要素でマークアップすることになるということですね。

「ユーザーがその連絡先にサイトのミスを指摘すると編集を迅速に行えるのかどうか？」などが出ましたが、仕様にないことを考えだすとキリがなくなって来てしまいますので、仕様として決まっていることをそのままに受け止め、その情報が「文書全体、あるいはフォームなど文書の主要部分に関する問い合せ先」なのかどうか？だけを判断すればそれほど難しいことはないのではないでしょうか。

仕様書回りのことに関しましては、同日に開催された『日本ウェブ協会アカデミックプログラム Vol.7「HTML仕様書を読む」』の動画が公開されています。太田さんの話術だけでも結構おもしろいですので、一度ご覧になってみると良いと思います。

6月26日に高松で開催される、CSS Nite in TAKAMATSU, Vol.3 「CSS Nite ビギナーズ HTML+CSS編」に出演いたします。

僕は1日のちょうど真ん中くらいのセッションで「これだけはおさえておきたい、CSSレイアウトの基本」と題して、CSS Nite ビギナーズ（東京版）でお話したことに、ちょっとだけ最近の傾向なども交えてのセッションになる予定です。

東京、大阪で開催されたCSS Nite ビギナーズと違い、今回は話題のHTML5/CSS3のセッションも持たれています。(X)HTML+CSSのワークフローからjQueryのことまで、今制作現場でどのようなことが求められているのかを一通り確認しておきたいという方にもオススメですね。

すでに満員間近となっているようですので、ご興味のある方はお早めにお申し込みください。

許容できないくらいHTMLのエラーが出ていますのでもろもろご注意ください。

CSS Nite LP9 連動 第2回コーディングコンテストが開催されています。僕も応募しましたのですが、取り組んだ際の反省などを。

いろいろデカイこと言ってすみません

えーっといきなり謝ってしまいますが、「賞を狙っているんですよー」などと大きなことを言ってしまいすみませんでした。何名かの、すでに応募作品を公開されているを見る限り「あー、ここはこうやれば良かったのか」などなど反省点がわんさかありまして、柄にもなく自信をなくしました。

残念な点

• ページ上部の影ですが、body:afterなんかでやるのが一番スマートっぽいですね。気づかずにbodyにたいしてbox-shadow: insetを使ってます。さらにそうするとページの左右にもぼかしたぶんだけ影が出てしまったので強引に消したりしています。さらにその強引さがゆえに思いもかけないことが起こったりします。
• rgbaを利用する部分ですが、どの色をどれくらいの透明度にしたら思い通りの色になるのか良くわからなかったので、実際のデザインと比べると微妙に（大幅な部分もありますが）色が違ってたりします。
• HTML5からはtime要素があるんですね。知りませんでした。
• 一応メディアクエってiPhone用とか用意しておきましたが、僕のMacのiPhoneyではスクリーンサイズが大きいのでメディアクエった感じにはなりません。とりあえずスクリーン用のものを取り外して普通にlink要素でiPhone用を読み込んで調整しましたが、最終的にiPhoneでメディアクエリーが適用されているのかは未確認です。
• グローバルナビの四隅が若干ジャギっていますね。背景はすべてa要素に一括で指定しているのですが、liとaに分けた方が良かったのかなー。でもこの辺ってブラウザが悪いよねと思ってそのままに。

その他、マイクロフォーマットとか全然指定しないんですね、とかもあると思いますが、その辺は僕の仕様です。

結構気に入っている箇所

• Non JavaScript！つっても僕があまり得意ではないので使用していないだけなのですが。
• 画像拡大部分の「target-box」。Non JavaScriptということで拡大画像表示はtarget擬似クラスを利用してdisplayの値を切り替えています。ブラウザウィンドウが小さい方ですと、画像下部に配置した画像間のリンクと画像を閉じるリンクが見きれてしまいますので、画像自体にも画像を閉じるリンクを指定しています。で、最初はもっと一意な感じのIDを指定していたのですが、なんだかthickboxなんかに対抗するという意味でも、ライブラリみたいなクラス名を指定しておいたというのが自分的には一番グッと来ている部分だったりします。
• クリック出来る範囲は広い方が良いですよね。ということで、HTML5からaの中にいろいろ要素を持てますので、hnとpとかをまとめてaでククッている箇所が結構あります。便利だなーと思う反面、最後にNVDAで読み上げてみると、都度都度「リンク」と読み上げてから段落なんかが読み上げられるので、これはどうしたものかと今でも悩みどころでもあります。
  あ、クリック出来る範囲は広い方が良いですよねの精神のもと、お知らせセクションの「重要」などのアイコンっぽいのもaに入れてしまっているので、アイコンと後続の文字の間にもunderlineが引かれてたりしますが、デザイナーさんからダメだよ！って言われたらすぐに直します。
• Operaのスモールスクリーンモードが結構良い感じかなーと。ご確認ください。
• あ、あとIE用のCSSファイル名とか。IEさん、ごめんなさい。

こんな感じでしょう。最後に僕が応募したものを以下に置いておきます。

応募したもの

http://maboroshi.biz/clearskysource/cssnite-lp9-contest2/

注釈

サイト内検索を利用するとそのままsix apartさんのものを利用できるようになっていますのでご注意ください。

アクセス解析は当ブログのものを仕込んでいますが、応募したものではsix apartさんが利用しているサイトカタリストのものになっています。

スミマセン。このエントリーでroll属性とありますが、正確にはrole属性です。

ブログなどでプログレッシブ・エンハンスメントに関するエントリーを読みますと、そのほとんどがCSS3に関するテーマのお話ですよね。なんでHTMLだけのお話でプログレッシブ・エンハンスメントが語られることがほとんどない（まだ僕は聞いたことがない）のかなーと不思議に思ってたりします。

そもそもプログレッシブ・エンハンスメントってなんですか？

僕の中では、「互換性などもふまえてHTMLをしっかりと作りながら、より進んだ技術をサポートしているユーザーエージェント（以下、UA）にはよりよいユーザー体験を提供しましょうね」というのがプログレッシブ・エンハンスメントだと理解していますので、この前提にたってこのエントリーを書いています。

ですのでそもそもその前提が違ってますけど、という場合はご指摘ください。よろしくお願いいたします！

例えばroll属性を指定するだけでもプログレッシブ・エンハンスメントのような気がする

さて、ではどんな場合がHTMLだけでプログレッシブ・エンハンスメントを実現出来ると思ってるの？ということですが、例えばWAI-ARIAで策定が進んでいるroll属性を考えてみましょう。

4.3.6. ランドマークのロール（role）には、HTML文書に簡単に指定することができる値が用意されています。ざっくりと言ってしまえばページの中で、ここにはナビゲーションがあるよーとか、ここにサイト内検索があるよーということをHTMLに記述することが出来るわけですね。

で、なんでこれを指定するのがプログレッシブ・エンハンスメントなのかと言いますと、スクリーンリーダーの中ではJAWSのバージョン10からと、いつからかバージョンは覚えていませんがNVDAの最新版で、roll属性を認識して、見出しジャンプのようにページ内の主要な場所へとスキップできるという機能をサポートしています（これをランドマークジャンプと言ったりしますね）。

現状においては、roll属性を指定することで(X)HTMLはinvalidになりますが、メジャーなUAに何か迷惑をかけるということはありません。JAWSやNVDAを使用してブラウジングしている人にとっては、ランドマークジャンプを利用してサイト内検索やナビゲーションをすぐに発見することが可能になるわけですね。これってプログレッシブ・エンハンスメントじゃないのかなーと思うんですがどうでしょうか？

余談

なんかプログレッシブ・エンハンスメントっていう言葉が分かりづらいなーと思うんですよね。UAによって最適な実装をしましょう、ということであれば、「User Agent Optimization」でUAOとか良いかなーとか思いました。

いろいろ大きなことを言ってしまってスミマセン！

先日「まめことネコゼのどたばた会議」の収録模様がUSTREAMで配信されていました。収録も終わってまめこさんとネコゼさんがまったりとお話している中で、ネコゼさんが作っているモジュール一覧（とかコンポーネントコレクションとか言われているやつ）のお話になったときに、それっぽいのを公開しましょうか？とつぶやいてしまったのでこのエントリーを書いてます。

で、結論から書きますと、とても申し訳ないのですが、実際にクライアントさんに納品したものしかないため、なかなか公開は厳しい感じです。ただ、それではあまりにも申しわけなさ過ぎるので、弊社内でざーーーっくりと決めているコーディングのルールと、今まで他社さんが作ったものなんかも見てきた経験で、モジュール一覧ってこんな感じのことが書かれていますよねということを公開しますね。

株式会社まぼろしのちょっとした決まり

弊社ファイルサーバ内に入っている、コーディングのちょっとした決まりです。あまりにもざっくりというか、ほんのちょっとのことしか決めていません。おそらく、これを見てもほとんど何も参考にならないでしょう。

株式会社まぼろし：コーディングのちょっとした決まり（155キロバイト）

モジュール一覧に書かれている内容

モジュール一覧的なものを作るにあったってまず問題となるのは、それぞれのモジュールをどんなふうにグループ化するのか？って所だと思います。概ね以下のような感じに分ければどのモジュールもどこかに属することになるでしょう。

• レイアウトモジュール

  メインカラム内でさらに段組をするモジュールなんかがここに入ります。

• 見出しモジュール

  見出しが入ります。一口に見出しと言っても、例えば同じh2なんだけど、あるページではテキストで、あるページでは画像化文字で、あるページではキービジュアルとテキストの組み合わせで、など複数ある場合もありますね。

• 段落モジュール

  段落が入ります。単なる段落じゃないものですと、リード文の登場回数が多いですね。

• リストモジュール

  ul、ol、dlといったリストが入ります。よくある感じですと、注釈リストなんかありますね。他にもギャラリー系ページで登場するサムネイル写真一覧なんかもここに入れてます。

• 表モジュール

  表が入ります。HTMLで言えばtableでマークアップするモジュールたちですね。細かな部分ですと、tdに数値がはいるので右寄せにしたい場合には「num」ってclass付けてねとか、各列の幅を均等にする場合には「fixed」ってclass付けてねとか。

• ブロックモジュール

  メッセージエリアや、注意文言のエリア、「Adobe Readerをダウンロードしてね」などのプラグインエリア、お問い合わせ先が掲載されてるエリアなんかが入ってきます。難しいのが関連リンクをずらーっと並べるためのエリアですが、弊社の場合はだいたい「リンクモジュール」へ含めてしまいます。

• インラインモジュール

  emや、strongが入ります。もしかしたらcodeとか、supとかが入ってくるかもしれません。

• リンクモジュール

  ページ内リンクや、外部リンク、各種ファイルへのリンクなどが入ってきます。また、関連リンクや、ページの目次などのような、ナビゲーションが集まったエリアなんかも入ってきます。

• 画像モジュール

  装飾目的で文章の右や左に配置されている画像や、キャプション付き画像なんかが入ってきます。

だいたいこんな感じでしょう。例えばギャラリー系ページで登場するサムネイル写真一覧なんかは画像ではないのか？などのツッコミ所も満載なのですが、その辺は各社で暗黙のもとにルールが決まっていたりするでしょう。

さらに、それぞれのモジュールについてどのようなことが書かれているんだということですが、「実際のスクリーンショット」「サンプルソース」「適宜変更を必要とする箇所」「注意点」くらいですね。

その他にはどんなことが？

他に書かれていることとすれば、モジュール一覧を更新するときの注意点、更新情報、最終更新日、最終更新者、必要なファイルの場所など、いわゆる資料としてお決まりのものですね。

別に必要なければ作る必要ないと思います

と、いろいろ書いてきましたが、「コーディングは最初から最後、また運用になっても自分一人しかしない。」「複数で行う場合でもコミュニケーションが完璧にとれていて迷うことがない。」「クライアントにとっても資料の作成がなんのメリットにもならない。」などであれば、そもそも用意する必要はありません。

作るのであればディレクションから

資料を用意しようかとなったときなんですが、企画・設計やビジュアルデザインがすべて終わってあとはHTMLを実装するのみ、って所からいきなり作りましょうとなりますと、納期的にも、労力的にも結構キツイ思いをすることが多いですし、なんかただ作らされているだけであまり意味がないものになってしまうこともあります。

例えば、ビジュアルデザインもモジュールのカタマリごとに行うようにしておけば、デザイナーさんもマークアッパーさんもだいぶ楽になったりします。ですのでこういったこと（サイトをモジュールの集合体として考える事で制作効率あげることができるよねってこととか）は、実は現場のマークアッパーさんというよりは、ディレクション方面に携わる人にこそ、心に留めて置いて欲しいですね。

こもりまさあきさんのエントリー「TextMate+Zen-Codingで超速コーディング？」を発端にして、ブログやTwitterでZen-Codingに関する話題が熱くなっています。

こもりさんのエントリーではTextMateにZen-Codingを追加していますが、僕は持っていないのでDreamweaverに入れて使ってみました。

Dreamweaverへのインストール方法

zen codingは超便利！Dreamweaverで使ってみました。 | VIVID COLORS + BLOGを参考にインストールしましたので、ご参照ください。

これできないのかー、ということでちょっとカスタマイズ

こもりさんのエントリーを参考にいろいろと書いてみました。Dreamweaverのコードビューを良く使う自分にはたしかにめっちゃ便利ですね。ただインストールした段階ですとちょっと足りないなと思うこともあります。

table要素を記述している際に、th要素にscope属性を簡単に書ける方法ないのかなーと思ったのですが、デフォルトではないような、ないですよね？まちがってたらご指摘ください！で、ないなーと判断したので、例えばth:sなんかってうつと<th scope=""></th>って入ったら素敵じゃね？と思ったわけです。さらにいえば、th:scで<th scope="col"></th>、th:srで<th scope="row"></th>も入れて置いた方が便利でしょう。

カスタマイズ方法

僕のMacの場合ですと、「ユーザー名/ライブラリ/Application Support/Adobe/Dreamweaver9/Configuration/Commands/ZenCoding」内にある「zen_settings.js」をいじります。560行目付近から、個々の要素を記述するための指定がされていますので、どこか良い感じのところに以下を追加しておきました。

’th:s’: ’<th scope=""></th>’,
’th:sc’: ’<th scope="col"></th>’,
’th:sr’: ’<th scope="row"></th>’,

これで希望した記述が可能になります。

もっとカスタマイズしたいのですが、方法がわかりません。どなたか教えてください！

もっとカスタマイズしたら、個人的には便利になるなーと思ったのですが、方法がわからずに断念したのが以下2点です。どなたかわかる方いらっしゃいましたら教えていただければ嬉しいです！ビール1杯くらいならおごります！

• #hogeや、.hogeなどの利用して要素を記述した場合に、閉じタグの前に<! --#ID名.class名-- >というように（ID/class両方が指定された場合は両方が、片方の場合は片方の）コメントが入るようにしたい。
• タグの入れ子構造でインデントがかかるようになっているけど、インデントはなしにしたい。まぁ、Dreamweaverを使っているのであれば、全選択してからのShift+tabで一気にインデントを消せますが、最初から無いにこしたことはないということで。

特に1つ目、できたらめちゃめちゃ便利だと思うんですよねー。

先日、CSS Nite 4周年記念イベント（Vol.40 reprise）へ行ってきました。3名の方がそれぞれ違った角度からHTML5のことを語られていてとても面白かったです。当日の内容はCSS Niteの終了アナウンスページから感想のブログなどをご覧になれます。

個人的にもっとも興味深かったのは、最後の質問タイムでしたね。主催：鷹野さんの「会社の仕事で実際にHTML5を採用するとしたらいつですか？」という質問。株式会社ミツエーリンクスの矢倉さんはちょっと迷いながら「来年か再来年かでしょうか」と回答されておりました。矢倉さんのようなお立場の方からこういったことをお聞きできると、心強いと言いますか、なんだかホッとしました。

続：nav要素内に見出しがない

さて、以前かいた「nav要素内に見出しがない」ですが、わずかなブックマークを見る限りでも若干物議をかもし出しておりました。せっかくの場ですのでこちらに関してもいろいろお聞きしてみました。

セクション三箇条に関して

まず、セクション三箇条がnav要素にも及んでいるものなのか？ということですが、基本的には及んでいるものの、見出しのことを言及している箇条に関しては、そもそもnav要素内に自然な見出しをおけないことも容易に考えられるため、常にその通りではないということでした。

早くも結論

僕の先日の記事が、結構一方的な意見でしたので誤解を招いた部分もあったようですが、結論から言えば文法エラーという訳でもないのでおいても良いけど、適当な見出しを毎回見つけるのは厳しいですし、最終的にはどういう指針でサイト全体のマークアップをしているのかによるということになるでしょう。

じゃぁなんであなたは見出しをおくんですか？

上記のような結論もだしてはいるものの、僕自信に関して言えば、当面は見出しをおいていくことになるでしょう。じゃぁなんであなたは見出しをおいているんですか？ということですが、2年ちょっと前に見出しに関する議論がネット上で巻き起こっていました。で、僕の中では決定版とも言うべきエントリーを当時の森田雄さんがされたんですね。「Re: 見出し要素に関する議論」

そして当時森田さん的に旬であったサイトを実際に見てみると、div id="global-navi"の部分に見出しがありまして、「あー、こういう使い方もあるのかー」と感心しましてそれ以来はずっと置くようにしています。

まとめ

ということで、nav要素内に見出しがなくてもまったく問題ありません。

最近HTML5の話題があつくなってきていますねー。Google Insightsで「html5」の検索ボリュームを調べてみても、日本での盛り上がりが他国にまさっているのが伺えます。（Google Insights　for Search – ウェブ検索の人気度: html5」）

直近で言えば「CSS Nite in Ginza, Vol.40」や、「CSS Nite 4周年記念イベント（Vol.40 reprise）」が開催されます。前者は無料、後者は前者の拡大版ですが2,000円ととても安価なので興味がある方はご参加されてはと思いましたが、すでにCSS Nite in Ginza, Vol.40で当日席が空いているだけでした。これは！と思う方は早めに会場に向かって席を確保しましょう。

さてそんなHTML5なのですが、「HTML5 Gallery」などのギャラリーサイトを見ていると、nav要素に見出しがないものが多いんですよねー。仕様でnav要素には見出しを設けなくてはならないと決められているものでもありませんので、これが悪いと言うわけではないのですが、ちょっと気になります。

まず「sectionの使い方とセクション三箇条 – vantguarde – web:g」では「The section element | HTML5 Doctor」の邦訳としてセクション三箇条に関して以下のような説明があります。

• スタイルシートやスクリプトの都合には使わないこと。それらにはdivを使うこと。
• article, aside, navが適切な場合には、そちらを使こと。
• セクションの先頭に見出しが自然に存在してない場合には使わないこと。

さらにこの記事では、

sectionだけがセクションじゃない

なんのこっちゃって話ですが、section以外にもセクションを構成する要素は存在します。article, aside, navです。

ともあります。つまりは、sectionだけでなくてnavもセクションであり、「セクションの先頭に見出しが自然に存在してない場合には使わないこと。」という箇条を考えれば自然とnavの中には見出しが入ってくるでしょう、ということになります。

続けてWCAG2.0の側面から見てみましょう。以下の2項目が関係あると思われます。

ガイドライン 2.4 ナビゲーション可能： ユーザがナビゲートしたり、コンテンツを探し出したり、現在位置を確認するのを手助けする手段を提供する。

2.4.1 ブロック・スキップ： 複数のウェブページ上で繰り返されているコンテンツのブロックを通過できるメカニズムが利用可能である。（レベル A）

2.4.10 セクション見出し：セクションの見出しを用いてコンテンツを体系化している。（レベル AAA）

まず「2.4.1 ブロック・スキップ」ですが、具体的には複数のページで繰り返し出現するヘッダーなどのブロックはあっさりと通過して、ページの主題など、ユーザーが目的とする箇所へすぐにアクセスできるようにしようね、ということを言っています。これをページで実装しようとすると、スキップリンク（参考：http://tinyurl.com/yfj6294）のようにページ内リンクを設けるか、各ブロックに見出しを用意して見出しジャンプ機能（参考：http://tinyurl.com/ygfyx7g）を使えるようにするということが考えられます。

さて、話を「nav内に見出しがない」に戻しますと、Webを閲覧する中で、すばやくnavにアクセスしたいという需要もあるでしょうから、navの中に見出しがないというのはちょっと気になります。スキップリンクを設置しておけば良いじゃないかという意見もあるでしょうが、もしかしたらスキップリンクをサポートしていないが見出しジャンプ機能はサポートしているというユーザーエージェント（以下UA）もあるかもしれませんので、やはり見出しを容易しておくのがベターと言えます。しかも「2.4.1 ブロック・スキップ」に関しましては、レベルがシングルAとなっていますので、是が非でも対応しておきたいものでしょう。

次に「2.4.10 セクション見出し」を考えてみましょう。こちらはセクションには見出しをおきましょう、ということになりますので先のセクション三箇条の最後のものと同じことを、アクセシビリティの視点から言っているものと考えられます。レベルがトリプルAではありますが、セクション内に見出しをおくというのがそれほど難しいものとも思えませんので、しっかりと対応した方が良いでしょう。

まとめ

事件は現場でおこります。この先、HTML5をあたりまえのように利用するとなったときに、nav内に見出しがあるものとないものが混在しているとなると、現場が混乱することが容易に想像されます。最低でも現場で一定のルールを共有することが必要となるでしょう。極端に、nav内にはまったく見出しを設けないというルールがあったとするといかがでしょうか？アクセシビリティを担保してこそのマークアップエンジニアとしては、だいぶ疑問が残るものとなるでしょう。

どんな状況でも100%見出しを設けるべきということもありませんが、より多くのユーザーのためにより良いWebをと考えれば、おのずと答えが出てくるように思います。

その他備考

一時期流行した文字サイズ拡大ボタン。これはブラウザなど、UA側が実装すべきものであり、わざわざページ内に設置する必要はないという意見が目立ちます。同じようにnavに関してもUAがnavを認識して、ユーザーになんらかの形で提供すれば良いのではないか？という意見もあります。

IDEA*IDEAさんで紹介されていた「SlickMap CSS」というのが結構すごいですね。ただ、ファイルをダウンロードして「README.txt」を読んでも分かるように、完全にIE6を無視したCSSとなっています。

同じく「README.txt」の中には「SlickMap CSS is free of charge, free to share, and free to modify.」ともありましたので、なんとかIE6でも大丈夫なようにしてみました（どうしても第３階層のリンクにカーソルオンしたときに、その下にある第２階層のリンクが上下にガクガクしてしまうのが対応できませんでした。分かる方いらっしゃいましたらツッコミお願いします。）。
SlickmapCSS-forIE6.zip（39KB）

マツダさんからコメントいただきちょっとバージョンアップしました。少しデザインが変わっていますが、ガクガクするよりはこちらの方が良いでしょう。
SlickmapCSS-forIE6-v1.1.zip（39KB）

以下変更点です

• 透過PNGに対応するために「IE PNG Fix」を利用
• 「:first-child」「:last-child」疑似クラスを利用していたので、これらをクラスセレクタへ変更。HTMLでアナログにclassを付けても良かったのですが、面倒だったので「yuga.js」を利用。
• 「:before」疑似要素でa要素のhref属性（リンク先へのパス）を出していましたが、別にいらないなーということで削除。
• IE6用にmarginなどの調整。各a要素にハイライトとなるグラデーションの透過PNGが指定されていましたが、IE PNG Fixを利用して強引に対応しているからなのか、しっかりとハイライトが出なかったのでIE6では消してしまいました。また、角丸やシャドウはIE6では無視しました。

先に書いたガクガクしてしまう症状はどうにかしたいなーという思いですが、角丸やシャドウがFirefoxなどと違うのはまぁアリかなという印象です。今までプログレッシブ・エンハンスメントはどうかなーとか思っていましたが、このくらいはクライアントさんが納得してくれれば良いですよね？

09/04/24、さらに増刷となって計6刷となりました！ありがとうございます！

昨年11月に出版された「現場のプロから学ぶXHTML+CSS」。当ブログでも告知を行っておりましたが、その後毎月増刷となっておりまして、この度5刷り目となりました。多くの方に支持いただいているんだなーというのも改めて実感し、本書に関われたことをとてもありがたく思いました。

で、ふとAmazonを覗いてみたのですが、知らないうちにレビューが16件にもなっていたのですね。
レビューいただいた方、ありがとうございます。
良い機会でしたので、それぞれのレビューを読んでみましたら、皆さま思い思いに良い本だったよーということを書いていただいていて、なんだか感動すら覚えてしまいました。
WEBが広まってAmazonがなければ、今回のように読者の方の感想を知るというのはとても大変なことだったでしょう。まず、わざわざ読者の方が出版社なりに感想メッセージを送ることがハードル高いですし、お送りいただいたとしても出版社止まりになるかもしれませんからね。

今までは、自分にとってどの本が向いているのか？というのを知るために閲覧していたレビューですが、今回のように著者にとっても元気が出て、あー、あの本書いて良かったなーと思えるAmazonって素晴らしいサイトだなー、そしてやっぱりWEBって良いですね！と思った今日この頃です。