MT のテンプレートを初期化した。いろいろ面倒になってきたし。でも MT3 のテンプレートって腐ってると改めて実感した。気が向いたら変えてみる。その前に MT4 にアップデートするかもだけど。

でもいい加減マークアップしながらブログ書くのは面倒だ。なんかもう、

1. テキストエディタに書く
2. Dreamweaver でマークアップ
3. 投稿

これでやろうか悩んでる。でもわざわざ DW 起動するの面倒くせー。はてな記法使えるようにしちゃおう。いつか今度やる気が150%くらいになったら。今20%くらい。

本題。

もう3日前の話です。アウトプット早くしないといけないなぁ、と思いつつ3日経ちました！
オレ死んでいい。

以下セミナーの覚え書き。内容に関してはネコゼさんや hamashun さんと併せて読むと補完されるかも。（特に対談部分）

第1部 マイクロフォーマットとは何か

定義

• 人間第一、機械は二の次
  • シンプルかつオープンなデータフォーマットの集合
• いま機能している物事を捨てるのではなく、マークアップやブログににおいて適用される

マイクロフォーマットが該当するのは

• データについての考え方
• フォーマットのデザイン原理
• 意味的なマークアップ
• 簡単・オープンなデータフォーマットにおける標準の集合
• 漸進的進歩
• 以上全て

該当しないのは

• 新しい言語でない
• 無限に拡張可能ではない
  • 特定の問題を解決するために生まれてきたのがマイクロフォーマット
• 異なる道具を使わせるわけではない
• 新しいアプローチではない
• 抽象化への万能薬ではない
• 全てを定義し尽くすことではない
• 以上全て

マイクロフォーマットの原理

• 特定の問題を解決する
• 可能なだけシンプルに
• 人間が第一・機械は二の次
  • 可読性の高さ
• 普及済みの標準を再利用
• モジュール化され、埋め込み可能
• 開発やコンテンツ、サービスの分散処理を可能にする

主なマイクロフォーマット

rel-license

• ライセンス情報のソースを示す
• a 要素の rel 属性に license 値を入れる
• 詳しい仕様

reltag

• タグ空間と結びつける
• a 要素の rel 属性に tag 値を入れる
• 詳しい仕様

relnofollow

• 検索エンジンに評価させない
• a 要素の rel 属性に nofollow 値を入れる
• 詳しい仕様

VoteLinks

• リンク先を賛成か反対を示す
• a 要素の rev 属性に voteagainst 値を入れると反対
• votefor 値を入れると賛成
• voteabstain 値を入れると保留
• 詳しい仕様

XFN

• XHTML Friends Network
• a 要素の rel 属性値に friend 値を入れると「友達」と評価
• met 値を入れると「会ったことある」と定義
• 詳しい仕様

geo

• 地理データを示す（緯度経度）
• class 属性に geo 値を入れ、title 属性に緯度経度をセミコロンを挟んで示す
• 詳しい仕様

adr

• geo とは違った地理データを示す方法
• 親要素に class 属性で adr 値を入れる
• 詳しい仕様

hCard

• 見出しを含めた住所情報を示す方法
• 詳しい仕様

hCalendar

• カレンダー（イベントなど）情報を示す方法
• 詳しい仕様

マイクロフォーマットの今後

今後の課題

• 一層の認知
  • 一部の人間しか利用していない
  • 啓蒙活動
• ブラウザ側の対応
  • IE8 に Web Slices を搭載（マイクロフォーマット的な情報を使える機能）
  • Firefox3 で API で利用可能
• 国際化・地域化への対応
• アクセシビリティ面での課題の解決

第2部 対談

現在取り組んでいるマイクロフォーマット関連は何？

• マイクロフォーマット関連に特化した製品開発
• マイクロフォーマットの情報発信
• マイクロフォーマットの質問に関する返答
• 企業からのアドバイス
• カンファレンスや企業に出向いてのスピーカー

日本に訪れた目的

• イベントの講演
  • マイクロフォーマット関連と各 Web デバイスにおけるデザインについて
• works corp. web expert
• 明日 CSS3 について講演（in アップルストア銀座）

Web Directions East について

• 今年後半に東京で開催予定（11月下旬）
• 5,6人海外からゲストを招待
  • 国内も同様に招待
• 同時通訳の導入
• 2日間に2つのトラックがある
• フロントエンド技術（XHTML,CSS,microformats,etc...）・JavaScript,Ajax etc...
• ワークショップも企画
• 土日がカンファレンス/月火がワークショップ
• SNS 作りの情報交換も企画

「ブラウザが対応するか、サービスが対応するか」の状況を脱していないとする見解について

• 鶏が先か卵が先か
• マイクロフォーマットが解釈するサービスが無かった
• 2,3年経ち、大きなサービスが対応して状況が改善の方向に
• 3つの要素が重要
  • コンテンツ発信者
  • コンテンツを使うサービス
  • コンテンツを作るツール
• Y!,ソーシャルブックマークなど、多くのサービスがマイクロフォーマットを実装している実績がある
• 対応アプリケーションが出てきた
• 注目に値するのがY!の対応
  • サーチモンキー
  • ユーザはその恩恵を受けることが出来る
• SEOを使うならマイクロフォーマットだよ！ｗ
  • 先行者利益が今後利いてくるのでは

ネイティブでサポートしているブラウザが無いけど？

• Firefox3 当初の予定では高いプライオリティが与えられていた
• サポートが見送られたのは残念
• 慎重に検討して実装することが重要
• 情報を再利用することは新しいことなので、現段階でネイティブサポートしなかったのは採用の判断だったのでは
• マイクロフォーマット対応・非対応のサイトでが存在する現状ではユーザが混乱するのでは
• JavaScript を使って API を利用することは非常に良い
• hCard を別ウィンドウにマッピングするツールを作成している（ブックマークレット）
  • ポップアップして出す

WebSlices について

• 期待している
  • なぜならユーザがマイクロフォーマットを知る良い機会であり体験になる
• マイクロフォーマット対応したブラウザはブラウザ2.0

アクセシビリティや国際化・地域化の課題について

• abbr 要素を使ったデザインパターンは難しい側面がある
• 過去数ヶ月、オンラインコミュニティでアクセシビリティについて感情的な議論があった
• マイクロフォーマットにとってチャレンジであることは重要
• 実際問題、どれだけアクセシビリティで問題があるのか
• HTML に関して言えば偉大な存在である
• 寿司＝洗練された存在＝HTML
  • イミフｗｗｗ
• 既存のコンテンツを壊すこと無くボキャブラリを増やしていくことが可能＝マイクロフォーマット
• HTML が持っている制約を壊すこと無く拡張していく
• 語彙を拡張した途端にアクセシビリテぃで問題が出る
  • 次のステップに行くためのチャレンジ

書籍について紹介

• 1冊でなんでも事足りることを目指した
  • 事例などを盛り込んだ
• 売れ行きは？
  • 出版社が教えてくれないｗ
  • 初版は完売
  • Amazon でトップになった
• 第二版はいつ？
  • 未定
  • 準備はしている
• 日本語版以外に出してる？
  • 今のところフランス語版が企画中
• 日本語版や読者への期待
  • マイクロフォーマット＝メタデータ
  • 言語の違いを超えてやり取りすることが可能
    • 翻訳サービスを介してもマイクロフォーマットを利用することが可能（違うかも。。。）
  • 日本でマイクロフォーマットが広まる先に国際化を乗り越えられるだろう

Q&A

• SNSでは何を当て込むのが適切か
  • クローズドな空間でも「誰が誰」と繋がってるかは抽出可能
  • ウローズドな空間だけでしか利用できないので相互利用が出来ない
• IE8 が WebSlices 搭載したが、中長期の観点からどうか
  • 心配してない
  • もし MS が作った仕様が広まってとしても嬉しい
• マイクロフォーマットをこれから使う人や使ってる人に向けての今後
  • 同じ情報構造に対して同じマークアップをして行く（テンプレートを持つ）

にしても当日は「誰々が来る」ってのは Skype のオープンチャットの方で知ってたけど、顔を知らないから誰が誰だか分かんねー、って話で。forest_k さんはあのイラスト通りの人だった（何

hamashun さんは「何となくあの人だろうなー」と思ってたけど、至る所で見る写真と「なんかちげー」と思って躊躇した。（本人だと確信したのは今回のエントリを見てから。今度会ったらきちんと挨拶しておく。commit）

最後に、John Allsopp 氏と木達さんお疲れさまでした。今回のような場を設けていただいたことにありがとうございました。

タイトル通りですが、Firefox3 のリリースを記念してギネスに挑戦しよう！と言うイベント。

• [Download Day 2008 24 時間最多ダウンロードソフトとして、ギネス世界記録へ挑戦！]

特設サイトでは Firefox3 ダウンロード当日にリマインダメールが届く＆ダウンロード確約ユーザが各国どれくらいいるかを示しています。

Firefox ユーザは早速登録してみるべし！

• ニコニコ動画キーワード検索
  • nico2-keyword-search.xml
• ニコニコ動画タグ検索
  • nico2-tag-search.xml

一応制約はあります。ログインしないと結果が見られないです（当然だけど）。それ以外は別段フツーの検索と変わりません。

不具合とかは無いはず。あったとしてもたぶんニコニコ動画側の問題だと思う。（責任転嫁ｗ）

と言うわけで irc://irc.freenode.net:6667#markupper にてみんなが待ってます！　来るといいよ！
結構テキトーだし、むしろオレ管理なんてやってないし、bot 常駐してないし、みんなの業務時間外（夜中）とか入ると誰もいない可能性アリだけど、その辺はこれから考える（だけで終わりそうｗ）

IRC 以外にも hiloki さんが Skype のオープンチャットを開設したので、こっちもどぞ！
（自分はまだ Skype を入れてないのでこれからダウンロードしに。。。）

追記 2008年4月4日 10:50

irc://irc.freenode.net は IRC クライアントの文字コードを UTF-8 に設定しないと文字化けします。（クライアントの初期値は ISO-2022-JP です）
設定方法は（クライアントによるけどここでは Limechat 限定）irc.freenode.net の「サーバのプロパティ」を開いて文字コードを「UTF-8」にしてクライアントを再起動すれば OK です。

全然関係ない話だけど、なんで irc.freenode.net を使うんだろうね（自分でここだと指定しておいてなんだけどｗ）
昔（7,8年前くらい）のオープンサーバと言えば藤沢とか奈良とかだったんだけど、今は違うのね。まあ当時のチャンネルも未だに残ってる（まだ30人以上いるとか意味が分からないw）から藤沢系のサーバが無くなったわけじゃないんだけど、なんとなく雰囲気と言うか、最近の流れ的に irc.freenode.net に移行する傾向が強いのかなぁ、と感じてる。理由がさっぱりだが。そんだけ。

• content プロパティ未サポート（β1 でまだ実装されてないってのはどうよ？）
• counter 系プロパティも同様
• float,clear,position プロパティの解釈が変わった？（退化したと思われる）
• data スキームサポート（ようやく！）
• Acid3 にかけると「This website wants to run the following add-on: 'MSXML 3.0 SP9' from 'Microsoft Corporation'. If you trust the website and the add-on and want to allow it to run. click here...」と出てアドオンを入れろと言われる
  • Acid3 の結果
• Acid2 にかけたらスマイリーが出た（！）

float,clear,position プロパティ云々は弊社の Web サイトを見て感じた。

以降追加して行く予定（時間があれば。。。）

• なにげに Developer Tool が標準装備？
• content プロパティはサポートされていた
  • ただし after,before の疑似要素の書き方として、コロンが2つ続くのはダメっぽい
  • そもそも疑似要素の場合、コロン2つ記述するのって CSS3 で定義されてるんでしたっけ？
• counter 系プロパティもサポートされてる

追記 2008年3月11日 16:00

疑似要素の表記でコロンが2つ続くのは確かに CSS3 からだけど、今のブラウザはこれに対応してるみたい。

• Lucky bag::blog: 疑似要素の表記法

やっぱり IE8 はこれにも対応するべきじゃないかしら。
いや別に必要じゃないって言えばそうだし、そもそも CSS3 のセレクタ はまだ Last call であるわけだから、勧告したら対応でもいいけどね。

• テストサンプルページ
• Firefox のスクリーンショット
• Safari のスクリーンショット
• Opera のスクリーンショット

恐らく問題は文書構造にあると思われ。
テストページでは div 要素でセグメント化されたパターンとされてないパターンの2通りが載っているが、問題はセグメント化された方で、自動カウンタ上でルートとなる要素（ここでは h1 要素）が div で個々が分離されている場合、正常にカウンタが動作しない。

HTML と CSS のソースコードも載っているので、分かる人は教えてください。
そもそも書き方が違うとか、これが仕様とか、むしろ Opera が間違ってるとか、Firefox のバグやねーとか、カウンタなんか使わねーよとか、IE 早くカウンタ以前に content プロパティサポートしろとか、そんな感じのことをお願いします。

正月三が日も終わり、4日から仕事が始まった人もいるでしょう。自分は期間限定のニコ厨な自宅警備員となっております。仕事は7日からです。この冬休みには1歩も外に出ていません。どんだけー。

それはともかく、去年は「さまざまな事があったなぁ」と思い返せるほどの思い出がないのはずっと仕事してたからでしょうか。
それなりにイベントにも行ったと思うのですが、それでも片手で数える程度ではないかと。
と思ったら「Web標準の日々」しか行ってなかった。相変わらずこっち方面の人たちとはほぼ交流が無いです。そんなもんなんでしょうか。こーゆーイベントとか関係なく、ざっくばらんに同業の人たちとただただ飲んでみたいものです。

でまあ、イベントには1つだけなんだけど、驚いたのがこっち方面の本を買ったのがたったの3冊だけ。

1. 実践Web Standards Design
2. はじめて読むXML—標準データ記述言語入門
3. 初めてのJavaScript

1冊目はみんな持ってる通称ホップ本。
2冊目は先の XML+XSLT Slideshow Tool を作る上で参考にした XML 入門書。「なんとなく XML ってこんな感じだよねー」って思う人向け。基本を知るには結構いい感じかと。
3冊目は冬休み突入後、すぐに購入した。プラコア CTO のたろさんから脅されて勧められたので。まだ読破できていません。わかんねー。

もともと本よりもネットから知識を得る方が多いので、そんなに買ったりしません。（マンガとかラノベとかはほぼ毎月買ってるけど。。。）

そうそう、去年は Mac Book を買ったんだった。これのおかげで UNIX の扱いにちょっとだけ慣れた。emacs にも慣れた。むしろ emacs 以外のエディタは無理ッス。

あとは イー・モバイル 契約して EM・ONE 買ったことかなぁ。ちなみに Windows Mobile 6 にアップデートされる前のバージョン。買って1ヶ月後にバージョンアップとか心の底から死んでくれと思った。
でも快適ネットライフは問題ないので、気が向いたらバージョンアップしてみようかと思う。有償だけど。いかほどー。

最後に家族の話をすると、上の娘も下の娘も元気です。嫁はわがままです。
上の娘は今年の5月で3歳になり、下の娘は今月末でようやく1歳に。思えば子供の成長って遅いと感じる。仕事上で去年1年間を振り返ると意外と短かったと感覚してる。この差はなんだろ。成長らしい成長が見えないって事なのだろうか。まあ成長してるようには思えないけど。未だに上の娘はちゃんと喋らないし。「ごめんなさい」が「サーセン」に聞こえるのはオレの耳がおかしいわけではないと信じたい。

ダラダラ〜と書きましたが、今年もダラダラ〜とブログに書いていきます。月イチでしょうが。
では、本年もよろしくお願いします。ユースケでした。

よく、「ページトップに戻る」と言うリンクがある。
例えばドコモの製品ページ。ここでは「このページのトップへ」と言う表記でページ内の #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の説明

導入にあたっての参考ページ

• はてなスターをブログに設置するには - はてなスター日記

まあ自分自身、はてなスターをポチポチ押すことは3日に1回くらいだからー。押す時は1日に20回以上ポチポチしたりするけど。

追記　2007年12月5日 10:37

星の位置がおかしかったのを直した。

さて以前 XHTML+CSS Slideshow Tool を作りましたが、今回は勉強も兼ねて XML と XSLT で構成してみました。

• XML+XSLT Slideshow Tool サンプル ファイル
• PDF 印刷したサンプル
• サンプル一式ダウンロード

XML+XSLT Slideshow Tool とは

XML と XSLT の組み合わせで PDF 印刷することを前提に作られたプレゼンテーションツールです。
基本姿勢は前回とほぼ同じです。使い方とか。

XSLT スタイルシートを書くこと自体はそれほど難しくもなく、ただの XML 整形式であれば障壁なんてなかったです。ただ、XML 文書であるため、要素の定義をきちんとしなければならないです。本来であれば XML Schema か DTD で定義したいところですが、それは次回の課題と言うことで。。。

と言うか、極論を言ってしまえば XSLT スタイルシートが無くてもこのツールは成り立ちます。XML 文書用に CSS を書けば済みますし。
その場合、XML 文書の <?xml-stylesheet type="text/xsl" href="xxst.xsl" ?> の部分を <?xml-stylesheet type="text/css" href="hoge.css" ?> とすればよいです。

以下今回のツールを作って思ったこと。

XML+XSLT と言う言葉自体がなんだか違和感を覚えるのはなぜだろう。
それはともかく、XSLT スタイルシートで文書を変換するパーサはブラウザに依るわけですが、やはり重いです。まだこの程度の文書量ですし、スタイルシートも大したことを書いてるわけでもないのでそこまででもないですが、HTML のレンダリングとは別にパーさが存在するので、どうしても1クッション分が重くなります。まあこの辺のロジックはよく分からないですが、実用性に耐えるものとはあまり思えず。。。

とは言え、これはこれで結構面白いです。本格的に XML を勉強したわけですが、これを作るのに本１冊で済みました。まあ見る人が見ればアレな中身でしょうが、取っ掛かりとしてはとりあえず、って感じで。

しかし要素名は何でも良いと言っても、XHTML で定義されているのをそのまま持ってくるのはさすがに気が引けたのでやめましたが、かと言って全て独自でやれと言うのも無茶な話で。改行とかどーしろとと思ったのでそこはそのまま br にしましたが。
XHTML のそのままでも良かったですけどね。XHTML の名前空間を使えば良いわけですし。

と言った感じで実用性がさらに下がったツールの紹介でした＞＜

他の拡張機能と競合してるのかと思い、いろいろ試してみたが結局アップデートした HTML Validator が悪さしてることが判明。配布ページに行ってダウングレードしようとしたら最新バージョンが 0.8.4.1 だった。なんぞそれ。最新バージョンをインストールしたら何も問題なく解決した。

大元のバグ報告は CSS/DHTMLバグ辞典スレッド【第５版】の324では Opera のみが対象となっているが、手元にあるブラウザ全てで調べてみた。
対象ブラウザは以下の通り。

Windows

• Mozilla Firefox 2.0.4
• Microsoft Internet Explorer 7
• Opera 7.02/7.52/8.01/9.01/9.10

MacOSX

• Mozilla Firefox 2.0.4
• Opera 7.52/8.01/9.23
• Safari 2.0/2.04

WinIE6 と MacIE は min-height をサポートしていないのでそもそも対象外にしています。

結果は以下の通り。

Windows

• Mozilla Firefox 2.0.4　発現せず
• Microsoft Internet Explorer 7　発現せず
• Opera 7.02/7.52/8.01/9.01/9.10　7.52 以降で発現

MacOSX

• Mozilla Firefox 2.0.4　発現せず
• Opera 7.52/8.01/9.23　発現
• Safari 2.0/2.04　発現

Opera では 7.02 では現象は確認できず、7.52 以降で確認できた。恐らく Opera 7.02 までは min-height をサポートされていないと推測。
Safari では 2.0 で現象が確認できたので、恐らく 2.0-2.04 間の全てでこの現象は起こると予測。

ちなみに Camino 1.5 では確認できず、シイラ 2.2 では発現した。これはそれぞれ Gecko エンジンと KHTML（Apple WebKit）のエンジンが Firefox・Safari と同等であるからである（と思う）。

しかし現象が確認できないユーザもいるようだが、何かしらの条件があるのだろうか？

• 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 要素とか偶然出てきたレベルだし。あとフレーム関連は一切知らない。
けどフォーム関連が全然思い出せなかったのは自己嫌悪。ダメだなぁ。

• 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 の仕組み

で、自身のエントリにレスを付けるのも変な話ですが、分かりやすいと思ってこうします。
「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 だとまた話は違ってくるだろうけど。