ついカッとなって、
「日本のコーダーは、CSSのfont-family指定にメイリオとヒラギノ角ゴのどっちを優先しているのか」
という問題を本気で調べることにしました。

主な調査資料は、CSS Nite LP9 連動 第2回コーディングコンテストの応募作品です。
上位入賞者と、参加作品のNo.1〜20、それにCSS NiteLP9 / 9.2の一部出演者のサイトのfont-family指定を抜粋し、私も含めて計45人のコーダーの統計を取りました。

現場でコーディングをしている人ばかりなので、かなり信憑性のあるデータなのではないかと思いますが…
結果は追記以降で。

はい結果どーん。

圧倒的にメイリオが多い |||orz

コンテスト入賞者、出演者のfont-family指定の詳細は、別途まとめています。

資料：日本のコーダーのfont-family指定

※CSSのソースに著作権はないものと考えていますが、問題があればご指摘ください

font-familyを指定しなかった場合、MacOSのSafariは明朝体になってしまいます。
また、もう過去の話になりつつありますが、MacIEでは日本語フォントの指定がないと、input要素などで不具合が起こるバグがあります。
このため、指定なしの人はほとんどいませんでした。

私のように「MacにOfficeを入れた環境だとメイリオになってしまうのが気になる」という人は、ヒラギノ角ゴを優先にしているのかもしれません。
WindowsXPにヒラギノが入っていると、もっと見栄えが悪くなるのですが…

細かい優先度、指定しているフォントに関しては、定石やトレンドと言うものがほぼなく、完全に個々のコーディングポリシーにゆだねられているようです。
英語圏のアクセスを想定してか、Vistaの英字フォントである「Segoe UI」やMac OSの「Lucida Grande」を優先している人も見受けられました。

結局のところ、OfficeがMac OSのフォントに介入してくる現状がある限り、コーダー側としては自己判断するか、JSなどで判定して、OSがMacだったら別途CSSを読ませる…などの対応をするしかないと思われます。

この辺り、各コーダーの皆さんが何故最終的にこの形になったのか、というのをブログや勉強会などで発表しあうと、より良いトレンドができるのではないでしょうか。

「clean」だけ何のフォントなのかわからないのですが…教えて偉い人！

Twitterで記事を紹介して下さい（-人-）

昨日（4/17）は東京で「CSS Nite LP, Disk 9」がありました。
WEBコーダーの最新技術にフォーカスしたイベントで、Web制作・jQuery・CSS3・HTML5とかなり幅広いテーマとなっています。

私も参加したかったのですが都合が付かなかったので、Twitterのハッシュタグ「#cssnitelp9」をお仕事しながらチェックしてました。

その中で、牧野工房の大杉さんと、ドーガの石本さんのコーディングスタイルの違いに関する呟きに興味を持ちました。
少なくとも、CSSの扱いに関しては全然違うようです。

necozeさんも参加されてたんですねー＾＾

牧野工房はサイト内のCSSをコンテンツ毎に分割して、importで一括管理するスタイルなので、石本さんがhttpリクエストを節約する方針で制作しているのであれば、真逆になるはずです。

これはどっちが正しいとかではなく、
「ボリュームのあるサイトを早く正確に作成する」ことを業態としている大杉さんと
「パフォーマンスの高いサイトを作成して長期的効果をアピールする」のを追求している石本さんでは
同じコーダーでも「求められている要素」が違うのだ思います。

私のようなフリーのコーダーになると、協業先の方針や案件の状況によって「今回求められている要素は何か」を判断する必要が出てきます。

制作会社との協業の場合は先述したような、早さか、正確さか、パフォーマンスかという話になってきますが、それとは別に
「Webデザイナーとしての技術的なサポート」を求められることもあります。

依頼先が小規模団体や、DTPデザイナーしかいない制作会社だった場合、カンプの文字サイズ・マージン・パディングなどは適当ですし、Webページに起こすとどうなるかなどはあまり考えられていません。
その辺りの補完を制作側がまかされるわけです。

常に一定のワークフローで進められないのはけっこう大変なのですが、ポリシーがないのもポリシーですよということで、いろいろな協業先の良いところを吸収していきたいと思っています。

そんな私は6/5の「CSS Nite LP, Disk 9.2（reprise）」に参加予定です。
再演版ではCSS3や、HTML5にさらにフォーカスした内容になっているようです。

内地のコーダーの皆様、会場でうぇびんを見かけたときはいじめないでください。
宜しくお願いいたします。

Twitterで記事を紹介して下さい（-人-）

新しい技術を得ることも大切ですが、今の作業、ブラッシュアップできてますか？

iPhoneアプリ「HTML/XHTMLタグ辞典」が人気の、大藤幹先生の新刊「XHTML&CSS超高速コーディング術」の出版記念セミナーが、アップルストア札幌で開かれました。

今回は「コーディング＝カンプを元にHTMLとCSSを作成する業務」を専門に扱う制作会社「牧野工房」の協力を受け、短時間で正確、かつ美しいコーディングを行うための、牧野工房の実践的なノウハウが紹介されています。

コーディング専門の牧野工房
スキルパートナーズ株式会社

本のPRになると思うのでNDAに反しない範囲で書きますと、私はこの牧野工房さんとお仕事をさせていただいたことがあります。

その際にワークフローの一部を拝見することになったのですが、とにかく驚いたのが、書籍の協力者である、大杉さんのコーディング技術と、徹底した作業工程の管理体制でした。
ルールが厳しいのはもちろんですが、それら全てに理由付があり、しかもコーディングスキルの向上につながります。
セミナー内で大杉さん自身が
「牧野工房のルールに従っていれば、IE6でも問題は発生しない」
と断言されていますが、大げさな話ではありませんでした。

そのような経緯で、私自身も牧野工房のコーディングルールの影響を大きく受けています。
今回の書籍が出版となったのも、大藤先生がハンズオンセミナーを通して大杉さんのスキルに感心したからなのだそうです。

セミナーでの紹介によると、テーマは「手戻りをなくすこと」。

1. 基本をしっかり守る
2. 手順に沿って進める
3. 情報をしっかり管理する

という、当たり前のように見えてずさんになりがちな、牧野工房の実践テクニックが公開されています。

牧野工房が使用している工程管理表・テンプレートが同梱されていたり、大杉さん考案の「シャドーコーディング」(いきなり書くのではなく事前に構造をイメージする)についても触れられていますので、WEBデザイナー・コーダーの方は是非ご一読を。

何故私がこんなに薦めているのかというと、良いコーディングルールの普及・共通化は業界全体のワークフローの改善につながっていくからです。

私のようにフリーランスでやっていると、様々な会社のコーディングをお手伝いすることになります。既にコーディングを終えた静的コンテンツのCMS埋め込みなどもすることがあります。
私が全て作業する案件ならいいのですが、普段行っているものと違う（場合によっては効率の悪い）ソースコードに合わせるのはなかなか厳しいものがありますし、工程にもムダが出てしまいます。

HTML5の仕様が発表され、つい新しい技術に目が行ってしまいがちですが、基本をしっかり守り、ブラッシュアップすることを忘れないようにしたいものです。

Twitterで記事を紹介して下さい（-人-）

MovableTypeで運営している本サイトを、a-blogcmsに切り替えたいと思っているので、移行の練習も兼ねて、本サイトを今回の実験台としてみます。

テーマファイルの設定

まずは現状の本サイトの主要ページ（トップページ・個別ページ・404等）を、静的HTMLに変換したものを用意しました。
普通のXHTMLベースのコンテンツです。

このセットが入ったフォルダに「webbing0908」と適当な名前を付け、
[a-blogcmsの設置ディレクトリ]/themes/
以下に放り込みます。

既に「system」「plain」「company1」というディレクトリができていますが、これらはa-blogcmsの基本テーマです。消さないで置いておきます。

それから管理メニューに入り（サイトと同じデザインでない内部ページです）、
「コンフィグ一覧」→「テーマ設定」で…

• どのフォルダを表示用テンプレートとするのか
• フォルダ内のどのファイルを
  • トップページにするか
  • アーカイブページにするか
  • 個別ページにするか

を、ファイル名を入力して指定していきます。
このうち、「管理ページ」「ログインページ」は、初期設定のままにしておくと「system」テーマに入っている基本のデザインがオーバーライドされるので（webbing0908に同名のファイルがないと自動的にsysytemから探す）、特に変更の必要はないと思います。
また、「エントリー編集ページ」は「詳細ページ」と同じ方が楽です。

ここまでやってブログトップへ戻ると

」ﾟ口ﾟ)」　あらもう反映されてますわよ奥様。

「webbing0908」フォルダのサイト構成が、そのままブログトップを起点に反映されます。
現時点ではブログと連動していないので、静的ページのサイトをアップしているのと全く変わりません。とりあえずこの時点で静的サイトとしてアップしておいて、段階的にa-blog cmsと連動することも可能です。

※今回は相対パスで動作を確認しています。スラッシュからの絶対パスでうまくいくかどうかは未検証ですが、たぶん対応しているんじゃないかと思います。

a-blog cmsとの関連付け

私のサイトと、a-blog cmsのデフォルトサイトで同じ役割を持っているのは「Information」と、下の「参加予定のイベント（正方形のバナー）」です。
なので、これらを「webbing0908」テーマに結び付けてみます。

「company1」テーマの「index.html」から、それらしい記事表示部分のコードをかっぱらってきて、「webbing0908」テーマの「index.html」の該当個所に埋め込んでいきます。

※現状サイトでは、バナー部分はHTMLを手入力しています。MovableTypeで動的にするのがめんどくさかったのです＾＾；

HTMLのコメントを使った独自タグは、宣言用のブロックタグが多くてちょっと鬱陶しい印象。MTと同じくらいのボリュームかな。Dreamweaverのスニペット併用は必須かと思います。

個別ページに関しては、どこから手を付けていいかわからないくらい独自タグが書かれているので、「company1」テーマの「main.html」の本文枠をガサッと突っ込みます。

これで「index.html」を上書きアップロードすればOK…と思ったのですがうまくいきません。
HTMLはきちんと動的になったのですが、「ログイン中のメニューボタン」や「記事の投稿・編集フォーム」が崩れてしまいます。

いろいろソースコードを調べて、「システム用のCSSとJSを追加しなければならない」ことがわかりました。

記事投稿画面のデザイン調整

※ここから先の手順は、もっと確実な方法があるのかもしれません。その場合は後日訂正します。

「webbing0908」テーマの<head>の最後に「ログインしているときだけ管理画面用のCSS・JSを読み込ませる」コードを追加します。
「plain」か「company1」テーマからそのまま持ってきます。

これだけでもいいのですが、まだ崩れが出たり、グレーベースの投稿画面がサイトに合わない場合はCSSの上書きが必要になります。

「system」テーマに入っている、以下の３つのCSSを自分のテーマディレクトリの同じ階層（css）にコピーすると、テーマ専用に記事中のタグ・投稿画面のスタイルを指定することができます。

style.css

フォーム枠のクリアフィックス、本文枠のデザイン全般のスタイルが書かれています。ディレクトリに入れるだけではなく他のCSSと一緒に読み込みます。

adminBtn.css

ログイン・ログアウトのボタンセット用CSSです。ボタンを横一列に揃えたりするスタイルが書かれています。ディレクトリに入れるだけで反映されます。

entryForm.css

記事投稿・編集時のフォームのスタイルが書かれています。ディレクトリに入れるだけで反映されます。

あとは、各CSSの説明を参考に、該当する部分を探してスタイルの調整をしていきます。
私はせっかくなので、グレーベースだった投稿フォームを自分のサイトに合わせてみました。
テーマファイルにないものをデフォルトのテーマから反映しようとする挙動（オーバーライド）は、WordPressに似ている印象です。

投稿フォームをブラウザで表示させながら微調整していった方が早いので、Firefoxのプラグイン「FireBug」か「Webdeveloper」があると楽です。
これが使えない場合は、ログイン状態のHTMLをローカルに落として、Dreamweaverで調整することになります。

いずれにしても、「オリジナルデザインのサイトに複雑なフォームを突っ込む」という作業は、カスタマイズの経験がないと難しいです。
また、フォームや段落ののマージン・パディングをリセットしていることを前提にCSSが組まれているので、元のHTMLが後方互換モードだったり、リセットCSSが入っていないと、手数が増えることが予想されます。

そういう意味では、a-blog cmsは最初のテーマ導入は非常に楽ですが、その後の工程はやや熟練者向けと言えます。
これは、ウェブサイトのデザインをそのまま編集画面にできるCMSが抱えている、共通の弱点でもありますね。

そんなこんなで、a-blog cmsのデータを、本サイトのデザインに反映することができました。

バナーの差し替えなんかもしてみたり。ちゃんと管理画面の「バナーの設定」で管理できるようになりました。

もちろん、私のサイトは新着情報以外にもコンテンツがありますし、このブログとデータを共有している個所もあるので、まだまだ作業はあります。
カスタムフィールドの追加や、カテゴリーごとにデザインを変更する「ルール設定」も必要になります。

配布サイトにはマニュアルもありますし、だいたい勝手がわかってきたので、またいろいろいじってみます。

Twitterで記事を紹介して下さい（-人-）

全然ロックがわからないのに、
ライジングサンロックフェスティバルのチケットを買ってしまいました。

→Pia-no-jaC←とスガシカオのステージが観たいのです。渋さ知らズやスカパラも観たいです。
ひとりで参加するtwitterのfollowerさんにテントサイトを使わせてもらえそうなので、お世話になる予定です。

「ライジングさんおひとり様の集い」を開催することになりました。当日はお気軽に声をかけてください。
http://twitter.g.hatena.ne.jp/webbingstudio/20090725

で、これだとただの日記です。
カテゴリー、「Webdesign」になってますよね？

表題の通り、本題はライジングサン公式サイトの話です。
エリアマップやタイムテーブルを印刷できないのです。

「RISING SUN ROCK FESTIVAL」は日本屈指のライブフェスです。
サイトは皆がワクワクするような、オサレでグルーヴしてるデザインじゃなければいけません。

今年のサイトを担当した制作会社は技術力が高いようで、個性的なデザイン、透過PNG・JavaScriptを駆使した演出、論理的なコーディングと、デスクトップで閲覧する分には充分なサイトです。
参加してみたくなるワクワク感いっぱいです。

なのですが…いざチケットを買って、情報を集めようとすると問題が出てきます。

↓これ、エリアマップです。

グロカワデザインに突っ込みどころ満載ですが、それは置いといてw

エリアマップはFlashで作成されており、IEの仕様に対する対策としてスクリプトで呼び出されています。
なので、スクリーンショットを撮らないと印刷ができません。

また、各スポットに関する説明は「マウスオーバー」に反応するため（昨年のエリアマップもそうです）、例えスクリーンショットを撮っても詳しい情報までは紙に写りません。

↓で、タイムテーブルの方ですが

今年のRSRのタイムテーブルは、2分を1pxに見立てて、div要素に時間分のheightやmarginを指定することで生成しています。デスクトップで見る分にはステージの時間軸が分かりやすいですし、おそらくCMSでの作成・変更がしやすいものと思います。

ですが、ブラウザの印刷ではテーブルが崩れてしまいます。
しかも全部ベタ塗りなので紙はインクでブヨブヨですw

高度なCSSレイアウトを正しく印刷するには、専用のソフトが必要です。
フジロックのタイムテーブル（tableとrowspanを使ったオーソドックスなスタイルです）もやっぱり印刷できないし仕方ないですが、それだったらPDFを用意してもらえると助かるってものです。コンビニやWESで紙のパンフを配ってるので、それを貰ってきた方が良さそうです。

印刷以外でも、違う立場だと感じる不便があったりします。

例えば、先日会った友人は
「アーティスト紹介が暗くなって詳細が出るのだけど、閉じ方がしばらくわからなかった」
と言っていました。

アーティスト紹介のモーダルポップアップにはThickboxが使われていますが、これのインターフェースは一般の人がイメージする「端に×がある」形式ではなく、英文で書かれています。
画面外をクリックしても閉じられるのですが、その説明はありません。
そんなにWEBサービスを利用しない人だと迷ってしまうのです。

私も最近はyuga.jsに含まれているThickboxを使っているのですが、ただ「かっこいい演出」を取りいれるのではなく、実際に使ったときのことを考慮しなくちゃいけないのだなあと、またひとつ勉強になりました。

インパクト重視のサイトデザインは、ライジングサンの伝統のようです。
「History」のページでは過去11回の公式サイトが全てアーカイブされていて、WEBデザインの歴史をリアルに語る貴重な資料となっています。

http://rsr.wess.co.jp/2009/guideline/history/

なかなか面白いので、デザイナーコーダーの方はいちど見てみてください。

Twitterで記事を紹介して下さい（-人-）

Discover Shiretoko – 世界自然遺産「知床」と Web ブラウザ「Firefox」の物語

美しい。
流石はWEB標準の先端をゆくMozilla Firefoxのサイトです。
しかも、コードネームに我らが世界遺産、「Shiretoko」を選んでくれて嬉しいですー。
北海道を愛する方も、フォクすけを愛する方も、俺はOpera一筋だ馬鹿野郎という方も、是非訪問してみてください。

このサイトではWEBデザインの美しいテクニックがあちこちに使われています。
全ては紹介できませんが、取り急ぎ目立つものだけ。

WEBデザインの可能性を広げる、透過PNG

このサイトには「透過設定」を行ったPNG画像が多用され、Flash並のグラフィカルな演出を実現しています。
PNG32形式はファイルサイズが大きくなる欠点がありますが、近年のADSL、光回線の普及で使いやすくなりました。

ですが…
あのクソ忌々しいInternetExplorer6はこれに対応しておらず、足を引っ張り続けています。
このIE6でも透過PNGの表示を可能にするのが、「PNGFix」と呼ばれるJavaScriptライブラリです。
「Discover Shiretoko」はjQueryライブラリを使用しているので、jquery.pngFix.jsを採用しています。

jquery.pngFix.js – PNG-Transparency for Windows IE 5.5 & 6

衝撃のGlider.js

いや、これはびっくりしました。
てっきり知床→Firefox間でページを移動するのだろうと思っていましたから。
このダイナミックな横スライドは、日本人が作成したjQueryライブラリ「Glider.js」を採用しています。

Glider.jsを作ってみた。 – Ho-KAGO After School

Firefoxユーザーのなかには、「No Script」プラグインでJavaScriptをオフにしている方も少なくありませんが、このライブラリはdivでグルーピングされたHTMLに対し演出を加えるものなので、内容が読めなくなることはありません。
でも、できればこのサイトくらいはJavaScriptオンで見てあげてください…

一部が重なっているナビゲーション

本文最後尾のナビゲーションは、矢印の一部が重なっています。
四角ベースのCSSレイアウトでこれを実現するには、各ボタンを透過画像で作成し（ここは透明度はあまり関係ないのでgifです）、さらにフロートで横に整列したボタンに対し「ネガティブマージン」や「position:relative（相対配置）」で矢印の一部が重なるように位置ずらしをすることで実現できます。

説明記事がネット上にいろいろあったのだが見つからない…汗

尚、ボタンの重なっている部分は「HTMLで後に書かれている要素」が優先されます。なので、重なりは最小限に抑える必要があります。

トップ専用CSSによるデザインの上書き

「Discover Shiretoko」はトップ以外のデザインでは、共通の背景画像が使われています。
半島のすみっこにくまさんがいるやつです。
ですが、トップページのみ「top.css」を後から読み込ませることにより、導入部をよりダイナミックな構成に変更しています。
こうすることで、作業量を最小限にしつつ、ページ毎の演出を調整することができます。

これはWEBデザイナーの間では割と常套手段なんですが、CSS勉強中の方も自分のサイトやブログなどでお試しください。楽しいですよ。

他にもレイヤー配置など、たくさんのテクニックが使われていますが、この辺で。ノシ

何故ここまで高度なテクニックを多用したのか。その答えははっきりしています。

「Mozilla Firefox」が最先端のレンダリング、スクリプト処理に対応できるブラウザであることを、自らのサイトで証明するため。

「Discover Shiretoko」は、制作チームの自信の現れなのです。

Twitterで記事を紹介して下さい（-人-）

告知記事
第2回XHTML&CSSコーディング勉強会

その後のまとめ
第2回XHTML&CSSコーディング勉強会

ポピュラーなテーマなだけあって、参加者の皆さんの顔触れも
私のような専業のコーダーから、独学の学生、
制作会社のデザイナー、デザイン面も習熟したいプログラマ、
仕事で自社サイト管理を担当している方など、様々でした。

「職場のコーディングがレガシーなので、スキルを磨いて最新のコーディングにスイッチするよう説得したい」

という切実な方も…＾＾；

詳しい内容・完成データは非公開ですが、今回のお題はこんなサイトでした。

一般企業によく採用される、左右2カラム・横型ナビゲーションです。

うぬうかっこいいぞ。

包括ブロック（外側を囲んでるdivとか）に画像や罫線がないため、CSSレイアウトとしては難易度低めです。
しかし、floatによる段組みが複数個所で使用されているので、「どのようにリスト要素またはdivでマークアップ・idを付与するか」がポイントになります。

描画依存によるCSSコーディングスタイル

私の場合、何度も触れているレイアウトだったので、
「通常と違うCSSコーディングスタイルで記述する」というハンデをかけて挑戦してみました。

一般には「HTMLの文書の要素に直結＝構造依存」のスタイルで書かれるCSSですが、
作業効率や、オブジェクト指向で捉えると、他にもいろいろな記述方式が考えられるそうです。

R流 CSS Coding Styles :: R-STYLES.NET

R-STYLEさんがいろいろ挙げられている中から、構造依存の次に使われることが多いと思われる「描画依存」形式を意識して書いてみました。
（改装中の自分のサイトでも、既に挑戦中です）

/* boxmodel
======================================= */

#wrapper {
	width: 960px;
	margin: 0 auto;
}

#wrapper #header {
	padding: 45px 0 0;
}

#wrapper #header #site-title {
	width: 204px;
	float: left;
	margin: 0 0 10px;
}

・・・中略

/* position, layer
======================================= */

#wrapper #header {
	position: relative;
}

#wrapper #header ul#sub-navi {
	position: absolute;
	top: 75px;
	right: 0;
}

/* background
======================================= */

#wrapper #header ul#sub-navi {
	background-image: url(../images/snavi_line.gif);
	background-repeat: no-repeat;
	background-position: 100% 50%;
}

#wrapper #header ul#sub-navi li {
	background-image: url(../images/snavi_line.gif);
	background-repeat: no-repeat;
	background-position: 0 50%;
}

・・・以下略

実際に書いてみての感想としては、ひとつのCSS定義の単位が短く、かつ描画スタイルごとに段落分けされているので、CSSコードの見通しがききます。
CSSプロパティに習熟したコーダーが、テキストで手入力するには良い方法だなーと思いました。

ですが、Dreamweaverの機能を使って制作している場合は、簡単にいきません。
DreamweaverのCSS編集機能は「構造依存」に対応する形で作られているので、ひとつの要素に多数のCSS定義があると、どこの定義に追加・修正したらいいのかすぐにわからないのです。

実際、自分のサイトの方はそれで難儀してます。
慣れるのにはまだまだ時間がかかりそうです。

トップダウンとボトムアップ

勉強会の中で、h2hamさんがHTMLの記述方式＝「トップダウン方式」「ボトムアップ方式」について説明されていました。

トップダウン方式とは
「包括する要素等を記述してから内部構造を入れ込んでいく」手法で、
ボトムアップ方式とは
「内部構造を入れ込んでから包括要素を記述する」手法だそうです。

トップダウン方式は技量がいりますが、タグの間違いを最小限に抑えて記述でき、全体の構造をつかみやすいです。実際、私もCMS構築等でテキストエディタを多用する場合はこちらの方法で書いています。

ボトムアップ方式は、論理的なマークアップに慣れていない人の、一般的な手順です。
また、私もDreamweaverを使って制作する場合は、こちらを使用します。
Dreamweaverのデザインモードは仕様上、空のdivタグに内部要素を入れ込むのが難しく、
ざっくり書いたp要素を選択してdiv要素で包括したり、リスト化した方が失敗が少ないからです。

トップダウン方式で確実に作業するには、どのようにマークアップするかをあらかじめ理解している必要があります。
h2hamさんも勧めておられましたが、デザインを作る段階で頭にイメージしたり、紙などに構造図をまとめてからはじめると、効率がいいし、習熟も早いと思います。

左右二段組リストのレイアウト

今回の勉強会で、いちばん難しいのではないかと思ったのが、この「TOPICS」部分です。

よく見かけるレイアウト方法なのですが、HTML・CSSともいろいろなマークアップが考えられます。
しかも、floatを使用すると文字増減に対応するのが難しく、使った要素によってはIEでバグが出ます。

こだわりがなければ、テーブルでマークアップしてしまっても全く問題がないと思いますが
リスト要素にした方が、今後の制作での使い回しが効きます。

h2hamさんは、下罫線を確実に表示することを重視されたのか
下のようなul・dlを入れ子にしたマークアップでした。

5/25追記：
h2hamさんから勉強会のフォローアップメールが来ました。
このようにマークアップするとIE6のみ崩れるので、その例示が目的だそうです。

<ul>
  <li>
    <dl>
      <dt>2009.05.23</dt>
      <dd>ダミーテキストですダミーテキストです</dd>
    </dl>
  </li>

  <li>
    <dl>
      <dt>2009.05.23</dt>
      <dd>ダミーテキストですダミーテキストです</dd>
    </dl>
  </li>

  <li>
    <dl>
      <dt>2009.05.23</dt>
      <dd>ダミーテキストですダミーテキストです</dd>
    </dl>
  </li>
</ul>

私はというと、dl要素でマークアップして

<dl>
  <dt>2009.05.23</dt>
  <dd>ダミーテキストですダミーテキストです</dd>
  <dt>2009.05.23</dt>
  <dd>ダミーテキストですダミーテキストです</dd>
  <dt>2009.05.23</dt>
  <dd>ダミーテキストですダミーテキストです</dd>
</dl>

dt要素のみに、floatとwidthを指定する方法を取りました。
こうすると、後続するdd要素の外枠だけがdt要素を囲むように伸びきり
中のテキストは右に回り込むことになります。

#wrapper #main #topic dl {
	margin: 0 0 1.5em 12px;
}

#wrapper #main #topic dl dt {
	float: left;
	display: inline;
	width: 5em;
	margin: 0 15px 0.5em 0;
	padding: 0 0 0.3em;
	line-height: 1.3;
}

#wrapper #main #topic dl dd {
	margin: 0 0 0.5em;
	padding: 0 0 0.3em;
	line-height: 1.3;
	border-bottom: 1px dotted #333333;
}

このとき、line-heightとmargin・paddingの値は同一にしないとずれてしまいます。

floatの仕様に沿ったレンダリングがされることが前提のコーディングなので、
IE5.5以前では崩れる可能性があるのが難点です。
また、dd要素が三行を超えるとdt要素の下に流れてしまいます＞＜

他の参加者の皆さんが
この部分をどのようにコーディングしたのか、とても興味があります。

class・idの命名規則

Webデザインをはじめた頃から今も迷っているのが、各パーツのclass・idの命名規則です。
とりあえず、ある程度の法則性を持たせ、HTMLの情報内容が変わっても違和感が出ない命名を心がけているのですが、今回のデザインのように多数のナビゲーションが出てくると迷ってしまいます。

大まかなブロック以外で、今回命名したのはこんな感じです。
私は略記法ではなく、ハイフンでつなぐ方法を使うので、少し冗長です。

ロゴ部分　・・・　#site-title
グローバルナビ　・・・　#global-navi
右上の小さなナビ　・・・　#sub-navi
本文枠TOPICS　・・・　#topic
本文枠ABOUT US　・・・　#about
右バナー群　・・・　#banners　（特に自信がない）
フッターナビ　・・・　#foot-navi
W3Cバナー　・・・　#valid　（特に自信がない）
コピーライト　・・・　#copy

この命名の部分に関しても、他の皆さんがどうしてるのか、是非知りたいところです。

コーディングは独学で身につけた人が多い分、奥が深いジャンルです。
今日も「フッターナビは表と解釈しても問題ないのではないか」
という話でひとしきり盛り上がりました。

こういった、コーディングに関する情報交換に、もっと参加したいものです。
h2hamさん、どうもありがとうございました！

Twitterで記事を紹介して下さい（-人-）

HTMLを衆目に晒すことで、改めてHTML構造の意義を考え直そうという、CSSデザイナーならではイベントなのですが…

このブログ、今HTMLが自前じゃないんですよね＞＜
ほとんど、Sandboxがベースになっています。
本サイトでやったら、CSS Naked Dayを知らないお客様にびっくりされるし…

時間がとれたらコーディングし直そうと思って、はや三ヶ月。
美しい構文を書くことも大事ですが、まめなバージョンアップをすることも大切だと痛感した、今年のCSS Naked Dayでした。

Twitterで記事を紹介して下さい（-人-）

静的なウェブサイトの場合、大抵はコーディングの時点で中に入る文章が確定していますが、私の場合ブログやレンタルカートやCMSがベースなので、通常テキスト部分に何を書きこまれるのか予想がつきません。
この点を踏まえて、どんな感じで気を付けているのかご紹介します。
熟練のコーダーさんには、今更な内容も多いですが…＾＾；

↓このようなサイトのコーディングをしたとして、以降の話を進めます。

あ、これオリジナルです。クライアントさんの原画使ったら拳で殴られます。
※写真素材：素材辞典フォトバイブル20000（ロイヤリティーフリーです）

右に画像があるときはwidthかpaddingを明示する

先程のサイトは、ロゴの下のサイト説明文が余白内に一行で納まっています。

この場合、普通にロゴと説明文の間にmarginを指定すればいいのですが、もしここに長い文言を書き込まれた場合、右の女性のヘッダ画像に文字がかぶってしまいます。

静的なサイトだったとしても、クライアント側からの変更指示はよくあることです。 なので、はじめからこの部分にwidthか、右paddingを明示しておきます。

できるだけ縦の伸びに対応する

前項のヘッダに関連して、ブラウザの文字サイズ変更で、サイト説明文を猛烈に大きな文字にしても、崩れず読めるようにコーディングをします。

これはデザインの影響を受けるので、どんなサイトでもできるわけではないのですが、サンプルだと下の画像のように、女性の画像をbackground-positionで下寄せに、かつロゴを透過gifかpngにすれば崩れず表示できます。

エントリー枠の最後を必ずclearする

ブログやCMSの場合、本文内に更新担当者が画像を貼ることができます。
このとき「左右の配置」も指定できるのですが、
画像の高さより本文の行数が少なかった場合を想定しておかないと、後続する要素（この場合次の記事かページナビゲーション）がfloatに巻き込まれ、実にアクロバティックなページになります。

この対策として、エントリー内にフッタ要素があればclear:bothを指定してfloatを終了させるか、本文枠をdivで包括してclearfixを指定しておきます。

.entry-body {
	height: 100%;
}
.entry-body:after {
	content: "."; display: block; clear: both; height: 0px; visibility: hidden; font-size: 1px;
}

「そんなの当たり前じゃん」と突っ込む人もいるかと思いますが、
これに対応していないテンプレート・テーマ・スキンは、レンタルブログの公式テーマなんかでも結構多いです＞＜

本文枠に背景画像があるときはmin-heightを指定する

前の画像を見て、気付かれたでしょうか。
背景の化粧瓶の写真が欠けています。

本文枠の背景にこのような背景画像があるときは、例え文章が一行しか入らなくても、背景画像の高さ分を最低確保しておく必要があります。
この場合、私はmin-heightで対応しています。

.entry-body {
	height: auto !important; /* for Modern Browser */
	height: 155px; /* for IE */
	min-height: 155px; /* for Modern Browser */
}

本文のline-heightの値に単位を付けない

line-heightの記述方法はいろいろありますが、このときに「150%」や「1.5em」とすると、標準の文字サイズを基準に行の高さが指定されます。
これだと、途中でfontやspanで文字サイズを大きくしたときに、行の上が詰まってしまいます。

ここで、line-heightに単位を付けずに数値だけにすると
行内の各々のインライン要素を基準に行の高さが指定され（この辺りのCSS仕様にはあまり詳しくないのですが…）、文字を大きくした個所には少し多めの行間が自動で入ります。

table要素をリセットしない

テーブルはブラウザ間で微妙にレンダリングが異なります。
なので、コーディングの最初にborder-collapseやborder-spacingを指定することもあるのですが、ブログやCMSを扱うときは、table関連の要素には直接スタイル指定を行わないようにしています。

更新担当者がCSSレイアウトに習熟しているとは限らないからです。
というより、これまでの経験では担当者の人はほぼ100%、テーブルで表を書いたり段組みをしたりします。

このときにborder-collapse:collapseとしていると、table要素のcellspacing属性が有効になりません。
どうせ、コーディングをする私は、レイアウトにtableを使うことはほとんどないですし…
ここは「顧客満足度」重視で＾＾；

ただ、このままでは表を書くのが大変です。
なので、更新担当者が表を多用する可能性がある場合は、以下のようにCSSを組んでおき、

.entry-body table.hyo {
	margin: 1em 0 2em;
	border-collapse: collapse;
	border-spacing: 0px;
	border-top: 1px solid #CCCCCC;
	border-left: 1px solid #CCCCCC;
}

.entry-body table.hyo th {
	padding: 7px;
	text-align: center;
	line-height: 1.2;
	border-bottom: 1px solid #CCCCCC;
	border-right: 1px solid #CCCCCC;
	background-color: #EEEEEE;
}

.entry-body table.hyo td {
	padding: 7px;
	text-align: center;
	line-height: 1.4;
	border-bottom: 1px solid #CCCCCC;
	border-right: 1px solid #CCCCCC;
}

「<table class="hyo">と書くと、サイトに合わせた表組みが自動でできますよ」
とメールやPDFマニュアルなどでお知らせしたりします。

コーディングは、そのサイトのデザインや、どのように納品するかで千差万別です。
個人の方と一対一でお仕事をするときと、制作会社を通してコーディングのお仕事をもらうときでも考えることが違います。

もちろん、完璧なコーディングが理想ではありますが、最後にサイトを手にするのはあくまでお客様、ということは、念頭に置くようにしています。

Twitterで記事を紹介して下さい（-人-）

RSSリーダーは、Sage-Tooを使っています。
私は大変な面倒くさがりなので、オンラインサービスのRSSリーダーだとろくにチェックしなくなってしまいます。
高機能だったりアラートが出たりするものより、ブラウザ連動の方がいいのです。

で、これの表示画面には自作のCSSを当てています。
目に負担をかけずに記事を見渡せるように、エラスティックレイアウトで融通がきくように、RSSの記事表示の様々なパターンに対応できるように…と、いろいろ改良を加えてます。

Sageを使っている方は少ないと思いますが、良かったらお持ち帰りください。
ユーザースタイルシート（Sage-Too用）

どんな風に見えるかは追記以下で。

北海道Webコンソーシアムの、ハムさんのブログはこんな感じ。
jQueryの研究をされてるので、ときどき読みに行ってます。
THE HAM MEDIA

THE HAM MEDIAを表示した場合

RSSに画像が含まれる、百式さんだとこんな感じ。
http://www.100shiki.com/

百式を表示した場合

はてブのホッテントリだと、Sageの仕様でblockquoteに入っているcite属性も出てきます。
タイトル長いのが多いので、overflow: hiddenを使って三行目でカットしてます。

はてなブックマークを表示した場合

背景がベージュ主体になっているのは、輝度が低く、私には落ち着いて読めるからです。
文字が載っている部分も完全な白ではなく、紙の白にしています。
コーダーには悪評高いメイリオも、これくらいシンプルだと読みやすいです。

まぁ、記事を書いている人たちのブログを直接観に行くので、RSSリーダーだけで記事を読むのは忙しいときくらいなんですけどね（笑）

Web用のユーザースタイルシートも、だいたいこれと同じデザインで、ワンカラムのものを使ってます。
FC2ブログにいたときに配布したことがありますが、だいぶバージョンアップしたのでまた今度配布しますね。

Twitterで記事を紹介して下さい（-人-）