我的春秋

links for 2007-07-26

ゆう — 2007-07-27T08:29:55+09:00

System Administrator's Handbook

Opera の各種設定ファイルの在処やコマンドラインオプションの説明など。

(tags: Opera browser CSS preferences official document)
Safari 3 CSS Support » CSS, JavaScript and XHTML Explained

Safari3 で実装されている CSS セレクタとプロパティ。

(tags: Safari CSS CSS3 selectors properties reference)
HTML elements index – Jens Meiert

HTML 3.2, 4.01, 5 および XHTML 1.0, 1.1, 2.0 でそれぞれ定義されている要素の対照表。文書型選択の参考に。

(tags: HTML HTML4 HTML5 XHTML XHTML1 XHTML1.1 XHTML2 element comparison reference)
Default style sheet for HTML 4

UA側で実装が推奨される HTML4 の各要素のデフォルトスタイル。（※CSS 2.1 勧告候補文書）

(tags: CSS W3C documentation UA browser HTML HTML4 reference)

主要ブラウザのデフォルトCSS

ゆう — 2007-07-26T13:11:19+09:00

久々の CSS ネタにも関わらず、メモ程度の備忘録ですが、W3C CSS 2.1 勧告候補の Appendix にある、HTML 4 の推奨デフォルトスタイルと、現時点で僕が把握している主要ブラウザのデフォルトCSS の在りかのリストです。ネタ元は Accessify Forum: list of browsers' default CSS（via e-luck さんのブックマーク）です。

（※ Mac OS X 10.4、Windows 2000 で確認していますので、10.3 + IE 5 や Vista + IE 7 はチェックできていません。XP + IE 7 はそのうち実家の端末で確認する予定。）

locations of default stylesheets
browser	OS	mode	path
（W3C CSS 2.1 CR）	-	HTML4	http://www.w3.org/TR/CSS21/sample.html
Firefox2	Windows	HTML4	C:¥Program Files¥Mozilla Firefox¥res¥html.css
	Windows	quirks	C:¥Program Files¥Mozilla Firefox¥res¥quirks.css
	MacOSX	HTML4	/Applications/Firefox.app/Contents/MacOS/res/html.css
	MacOSX	quirks	/Applications/Firefox.app/Contents/MacOS/res/quirks.css
IE6	Windows	-	dll ?
IE7	Windows	-	not checked（dll ?）
IE5	MacOSX	-	not checked
Opera9	Windows	-	dll ? ~~(C:¥Program Files¥Opera9¥styles¥*.css ?)~~
Opera9	MacOSX	-	- ~~(/Applications/Opera.app/Contents/Resources/Styles/*.css ?)~~
Safari3	MacOSX	HTML4	/sw/share/apps/khtml/css/html4.css
	MacOSX	quirks	/sw/share/apps/khtml/css/html4.css
	Windows	HTML4	（dll ?）
	Windows	quirks	（dll ?）

HTML の見出しをめぐる議論

ゆう — 2007-07-11T00:16:41+09:00

先週は数日にわたって頭痛がひどくて、意識的に電脳から距離を取るようにしていたんですが、この周辺の話題については、色々な意見が出ていて楽しく拝見してました。

ただ、ひとつ気になったのは、思った以上に多くの方々が、現有の...ないし自分の周辺で目にするモデルの枠内だけで仕様書の内容を捉えてしまっているところ。

色んな可能性や考え方に応えられてこそ標準

徳保隆夫さんが多様な価値観を認める仕様でなければ、世間に通用しない。（HTML に装飾要素は必要）と指摘されているように、標準規格というのは、本来可能な限り、あらゆるユースケースを（需要の小さいユースケースや、例外的なユースケースをも）極力踏まえて、多様な需要にたえうるモデルに組み上げることが求められます。どちらかというと、モデルは需要の高い要求よりも、需要の低い要求によって、その輪郭や柔軟性が決まってきます。

ですから、石川一靖さんの「見出しは有っても無くても良いような物」だろうか（h1要素は文書のタイトルその2：メモランダム）というのも、少し違って、おそらくは見出しのない文書も "ありえなくはない"だろうという想定の元に、ゆるめに定義しているんじゃないかと僕などは考えてます。

現行の事例はあくまで一つの応用のカタチ

個人的に、いちばんしっくり来たのは、森田雄さんの以下のご指摘。

そもそも、サイト名だの何だのいっても、サイトっていう括り（縛り）が厳格に存在しているわけじゃなくて、ページ単位がリンクで繋がってはいるものの、結局のところは個々に存在しているわけでしょう。

securecat's exblog : Re: 見出し要素に関する議論より

見出しの議論も、「HTML文書には、すべからくサイト名とページ名がある」という前提が（無意識のうちに）先にあって、仕様書を読み解く時に、それ以外の可能性に思い至らないケースが多いようですが、あまり今ある Web ページの形だけを元に、「こうでなくてはならない」的な縛りをつけることはないのではないかと思います。

もちろん、1ページに複数の h1 要素もアリ

かくいう僕も、一時期、h1 は 1ページにつき 1つが理想と考えていた時期があります。今でもその考えのすべてを捨てたわけではなく、より現実的な形に考えを変えた（もしくは状況に応じて、最適解を分けるようになった）わけですが、それでも河内正紀さんが例示しているような、1ページ内に複数の h1要素を容認する方法はアリだと思ってます。

ちなみに、僕だったら異なるレイヤーの情報が重なってひとつを成しているイメージ（カラクリエイト：「両方がh1」というのはh1要素が複数という意味）は、自分の中でイメージするだけなく、以下のように具体的に class を使って明示的にレイヤーの違いをマークアップしちゃいます。こうしておけば、レイヤーの違いを他人と共有することもできるようになりますから。（class の挿入場所は、文書構造によっては、必ずしも hn 要素にするとは限りません。）

<h1 class="site">我的春秋</h1>
<h1 class="page">HTML の見出しをめぐる議論について</h1>

何にせよ、いたずらに仕様書の定義の解釈を狭めて、折角の仕様の柔軟性を損なうのは避けたいな思う今日この頃です。

Twitter ハジメマシタ

ゆう — 2007-06-07T11:39:36+09:00

follow _yu_ at http://twitter.com

激しく今さらな感じもしますが、Twitter を始めました。

といっても、まだサービスの特徴を探ったり試したりしてる段階で、全然環境も整えてないので、しばらくの間はレスポンスが悪いと思います。(^ ^;)

それにしても、乗り遅れたツケといわんばかりに、Web で検索をかけると、おびただしい数の Twitter 関係のエントリーやツールがあって、ちょっと混乱状態...。こればかりは、もうやれやれって気分です。（lomo さんトコとか、基本的なところはザッと目を通したんですけど、選択肢が増え過ぎちゃって..。）

そんなわけで、もし（Intel）Mac な環境ならコレは必須じゃない？というツールを教えていただける奇特な方がいましたら、ゼヒ、コメントもしくはトラバをいただけるとウレシイです。ちなみに OS は Tiger、デフォルトブラウザは Firefox（Tweetbar は導入済み）、メーラーは Thunderbird、IM は特に使ってませんけど、ものすごくイイのがあれば導入を真剣に検討します。あと、携帯は au + EzWeb もしくは Mobile Opera 7.60 です。

ひと区切りついたら、僕も手を広げにいくと思いますので、見かけたらどうぞよしなに。

Fell free to add me!

境祐司さんと対談

ゆう — 2007-06-07T10:59:47+09:00

昨日の午後、新宿で Monkeyish Studio の境祐司さんと対談してきました。（境さん、お疲れさまでした＋ありがとうございました。）

テーマは「知識共有」ですが、話題を派生するにまかせた雑談形式をとってます。早くももう、境さんの PodCast: 日刊徒然音声雑記にアップされているようなので、興味のある方はゼヒどうぞ。

日刊徒然音声雑記: ［file-262］対談〜ベテランの経験知（暗黙知）は共有できるのか？［1］

境さんから色々なネタ振りがあったり、興味深い事例をうかがうことができて、インスピレーションを刺激されまくりで、僕自身、とっても有意義な午後になりました。刺激されすぎて、今日以降アップされる予定の後半部分は、ちょっと頭の中が混沌としてました。（あらためて、自分の頭のキャパシティの少なさを実感。(- -;ゞ）自分でも何を話したか覚えてなかったりするので、変なことを口走ってたらご容赦。(^v^;;ゞ

Re: XHTML+CSS (r)evolution, 3rdの内容は信ずるに値するか?

ゆう — 2007-06-03T22:31:28+09:00

Kuruma さんが、先日の XHTML+CSS (r)evolution, 3nd に対する、とっても良いレポートと論評をアップしていて、参加者された方には是非とも一読をオススメしたいのですが、いくつか気づいた点がでてきたので蛇足気味ではありますが、一応、書き留めておきます。

フロントエンドデザインだけで完結できてしまう人には、（CSS や DOM はともかく）次世代 HTML によって実感できる恩恵はすごく少ないため、class や id との差も実感しにくいのかも...なんて思いました。（でも、少なくとも次世代の Web を担う因子としては、CSS 3 なんかよりもはるかに重要。）
次世代規格（X/HTML5 や XHTML2）に何らかの抵抗がある人は、現行の規格（HTML4 や XHTML1）をそのまま継続利用すれば良く、無理に次世代規格にシフトする必要はないと思います。（ブラウザベンダーが既存の HTML文書に対するサポートを切り捨てるとは考えにくいでしょう。）
X/HTML5 と XHTML2 の利点・欠点については、X/HTML 5 Versus XHTML 2 がとても要領よくまとめています。気持ちに余裕があったら、訳してみようかな..。
個人的に気になるのは、どういうケースが記述できるようになって、どういうケースが記述できなくなるのか？といったあたりでしょうか。これは追々、僕も検討してみようと思います。
X/HTML5 の dialog要素とdl要素の重要な相違点として、それが順序つき関係リストであるか、順不同関係リスト（The dl element introduces an unordered association list）であるかの違いがあります。（dl 要素の項目を参照。）
「classやidによる拡張は可能だが、それは共有することが困難な拡張だ。はじめから多くの人が似たようなものを必要とするのであれば、それははじめから定義されていた方がよい」という Kuruma さんの見解は、基本的には同意なんですが、僕の考えとしては、普遍性の極めて高い "固い" モデルと、単に利用頻度の高いモデルとは区別されるべきだと思います。前者に比べ、後者は柔軟性や変化への耐性が低いため、新要素・新属性の追加やモデルの見直しが迫られるリスクが増大します。僕は、こういうケースこそ、Microformats のような、民間有志のコミュニティーによる、より緩い下位標準に委ねた方がいいのではないかと思ってます。

本日はこれまで。

論理構造を文脈に読み換えながら class 名を考える

ゆう — 2007-05-30T08:52:19+09:00

最近、一部で話題に上がっている POSH にも、"Use good semantic-class-names" という実践項目がありますが、今日はその class 名のつけ方について、最近、思い至ったことから。

POSH encapsulates the best practices of using semantic HTML to author web pages. Semantic HTML is the subset of HTML 4.01 (or XHTML 1.0) elements and attributes that are semantic rather than presentational.

posh - Microformatsより

基本的にはより論理構造を意識した class名をつけることが、今日のお話の目的なんですが、semantic-class-names のリンク先にない新味は、論理構造を文脈に読み換えながら class 名を考えるという点。（ただし、普段から意識的に文書全体の構造に照らして class名をつけている方には、それほど新味はないかも。）

例によって、あくまで試案であり、選択肢です。（というか、そもそも僕自身が試行錯誤の最中。）是非や取捨は各自でご判断ください。

まずは従来型との実践例の比較

イメージが湧きにくいでしょうから、まずは実例を出してみますね。

よく目にする従来型の class 名

header
- description
- information
- global-nav
body
- contents
  - hot-topics
  - hot-products
- sidebar
  - sub-nav
  - banners
footer
- credit

今回提案する class名の一例

site
- description
- information
- navigation
page
- recent
  - information
  - products
- related
  - navigation
  - services
publication
- credit

より論理構造を意識した class名を

具体的には、上に示した例のようにclass 名を上層から下層へと並べてみたときに、論理的なつながりや一貫性が保たれるようにします。ひとつの目安として、class 名を自然文に読み換えてみて、不自然じゃないかどうかをチェックしてみると良いかもしれません。

これまでは、どちらかというと個別のブロックごとの特性を抽象化して命名し、一本一本の枝の文脈を踏まえるというようなことは、あまり考えられないことが多かったと思います。

でも、どう考えても .header .description 領域のコンテンツは、「サイトに関する説明文」であって、「ヘッダに関する説明文」ではありませんよね？ここに、論理的な違和感を感じるようになったのが、この手法にたどり着いたそもそものきっかけです。

site - description: サイト共通の説明文
site - information: サイト共通の情報
site - navigation: サイト共通の案内
page - navigation: ページ固有の案内
page - recent - information: ページ固有の最近の情報
page - recent - products: ページ固有の最近の製品
related - services: 関連する - サービス

header や (main-)contents, body, footer などは、Web ページを作成する時に好んで使われる class 名（もしくは id 名）ですが、通常、"header" class相当の場所にはサイト共通のメタレベルコンテンツが、また "body" class 相当の場所には、そのページ固有のオリジナルコンテンツが盛り込まれることが多いはず。そこで、今回の実践例では、サイト共通の情報とページ固有の情報を区別するという意味で、header class 相当を "site"、body（もしくは (main-)contents）class 相当を "page" という class 名にしてみました。

もし「ページ固有の最近の情報」という文脈が気に入らなければ、ourCompany - recent - product（「我が社の最近の製品」）などとする手もあります。この辺は、状況や目的に応じて、適切に論理構造を抽象化した名前をつけてみるといいでしょう。

論理的に同類のものには、意識的に同じ class名をつける

#header #global-nav → .site .navigation
#body #local-nav → .page .navigation

論理的に同類のものには、積極的に同じ class名をつけるようにします。たとえば、global-nav とか、local-navigation のような id, class名はやめて、最終的な見栄えの差異に関わらず、ナビゲーションメニューはサイトグローバルなものも、ページローカルなものも、一括して統一した class 名にします。

.navigation { ... } /* ナビゲーション全般共通スタイル */

.site .navigation { ... } /* グローバルナビゲーション用スタイル */
.page .navigation { ... } /* ローカルナビゲーション用スタイル */

CSS でグローバルナビゲーションとローカルナビゲーションを区別したい時には、このように、論理構造の違いをセレクタに記述することで区別させられます。この方が各ナビゲーションをいつでも簡単に区別したり、同一視したり使い分けられるため、柔軟性が向上するというわけです。（詳細度の差も特別意識することなく自然な形で取り込むことができます。）

ついでに、今回提案するモデルだとセレクタをそのまま自然文（というか名詞句？）として読み上げてみても、どういった集合を指しているか、初めてソースを覗く人でも理解・区別しやすいはず。ここも重要なポイントです。

従来型モデルでも構わないんですが...

生業としてたくさんの Web ページを作っているクリエイターさんが、どうしても見栄え本位で、マークアップを施してしまうのも、実は個人的に理解できなくもなかったりします。Web ページの見せ方に、ある種のデザインパターンみたいなものがあって、その中で特に再起性の高いモデルをコンポーネント化したくなるというのは、ごくごく自然な行動だと思います。

とはいえ、もう少し構造本位な（POSH な）マークアップに歩み寄る余地もあるような気がしてならない今日この頃です。というわけで、今回は日々の試行錯誤からのネタを取り上げてみました。

定義リストの違和感（続）

ゆう — 2007-05-28T02:09:26+09:00

前回の続きです。

念のため DTD を見直してたら（チェックしたのは HTML 4.01 Strict の DTD）、なんか激しく不安をかき立てられるような記述が..。

...あれ？

<!ELEMENT DL - - (DT|DD)+ -- definition list -->

この (DT|DD)+ って、「dt要素かdd要素が 1回以上出現すること」ですよね（もちろん、両方出てくるのはOK）？ってことは、極端な話、以下のようなコードも valid なんですよね？（実際に The W3C Markup Validation Service はパスします。）

<dl>

</dl>

<dl>

</dl>

現行モデルじゃ、術語（dt）と定義文（dd）を関連づけできない？

がーん。実は定義文（dd）なしの術語（dt）とか、術語（dt）なしの定義文（dd）が許容されていたんですね。（もちろん、推奨・非推奨は別。少なくとも禁止はされてないという意味で。）

ということは、これって、術語（dt）と定義文（dd）の対応関係を関連づける根拠が根本的にないんじゃ..。ひょっとして、この定義リストの記述モデルって、構造化モデルとしてかなり問題があったりします？(^o^;)

定義リストの違和感

ゆう — 2007-05-26T19:04:03+09:00

実は前々から定義リストの記述モデルって、どうにも気持ち悪いなと感じてます。

他所さまであまり突っ込んでいるのを見かけないので、僕の知識不足か誤解から来ているのかな..と、ずっと口にするのを避けてたんですが、HTML WG が発足して、HTML のモデルに関する議論が（少なくとも欧米では）盛んになってきていることもあるので、恥をかくのを覚悟で、書き留めておきます。

何かご存知の方は、是非、ご教示を。

HTML 4.01 の定義リスト

仕様書の説明

Definition lists vary only slightly from other types of lists in that list items consist of two parts: a term and a description. The term is given by the DT element and is restricted to inline content. The description is given with a DD element that contains block-level content.

Lists in HTML documentsより

（定義リスト（dl）は、インライン要素のみを内包できる術語（dt）と、ブロック要素も内包できる説明文（dd）から成るというような主旨。）

仕様書に示されている用例

まずは、ごく一般的なユースケース。

<DL>

<DT>Dweeb
<DD>young excitable person who may mature
into a <EM>Nerd</EM> or <EM>Geek</EM>

<DT>Hacker
<DD>a clever programmer

<DT>Nerd
<DD>technically bright but socially inept person

</DL>

そして注目して欲しい方の用例。術語・説明文が同時に複数存在するケース。

<DL>

<DT>Center
<DT>Centre
<DD> A point equidistant from all points on the surface of a sphere.
<DD> In some field sports, the player who holds the middle position on the field, court, or forward line.

</DL>

要するに術語と説明文の対応関係は、必ずしも 1対1 の関係にはならず、1対n、n対1、n対n になることすら許容されています。

素人くさい疑問でなんですけど、そういえば、プログラム言語で n対n の連想配列を記述できるモデルってあるのかな？

記述モデルの背景にある（と思われる）もの

2007年5月28日追記:: DTD をチェックしていたら、定義文（dd）なしの術語（dt）や、術語（dt）なしの定義文（dd）が許容されているという、重要なポイントを見落としていたことに気づきました。詳しくは定義リストの違和感（続）を参照してください。

構文的には、「連続する1つ以上の dt要素と、その直後の連続する 1つ以上の dd要素」を一群と見なせば良いことなので、少なくとも実装上は、n対n の関係であっても術語と説明文を対応づけることは可能でしょう。

~~この構文ルールが明確だからこそ、HTML では dt要素も dd要素も終了タグを省略できるわけですし（もちろん XHTML では省略不可です。念のため）、~~おそらく、なるべくシンプルで人間に優しい省エネな記述モデルを志向したことが、この定義リストの記述モデルを生み出した大きな理由のひとつなんじゃないかとも思います。（あくまで想像ですけど。でも、これはこれで、実は HTML の普及を支える重要な因子ともいえそう。）

気持ち悪さの原因

でも、個人的にはどうしても複数ある同義語と、多義語の説明文をグループ化するための中間的な要素が欲しい気がします。DOM で処理するにせよ CSS をあてるにせよ、実装が中途半端だと、エラーの原因にもなりますし、なにより構造化文書的に、このフラットさは気持ち悪くないですか？(^o^;)

XHTML 2.0 では、それに相当するもの（術語と説明文のグループ化のための要素）として、di 要素が提案されていますが、HTML 5 の方では、今のところ、それと同等の存在はないようです。

<dl>

<di>

<dt>Dweeb</dt>
<dd>young excitable person who may mature into a <em>Nerd</em> or <em>Geek</em></dd>

</di>

<di>

<dt>Hacker</dt>
<dd>a clever programmer</dd>

</di>

<di>

<dt>Nerd</dt>
<dd>technically bright but socially inept person</dd>

</di>

</dl>

このブログの読者の皆さんはどう思います？似たような感覚をお持ちになったことってありませんか？

CSS Nite LP Disk 3 観戦記 - 補

ゆう — 2007-05-18T06:59:05+09:00

もう一週間近く経過してしまいましたけど、CSS Nite LP, Disk 3 の雑感です。

重要なことは概ね連載の方に書いたつもりですけど、端折った部分などを少しだけ、散発的に補足です。

CSS Nite LP, Disk 3 "Coder's High" 観戦記（一歩先のWeb標準 ♯2 | withD）

「Web は唯一ユニバーサルデザインを実現しうる媒体」

まずは小久保浩大郎さんのセッションから、見出しに掲げた一言について。「Web 標準」同様、「ユニバーサルデザイン」という箱書きにとらわれると、一瞬、「どういうこと？」と戸惑うんですが、冷静に考えてみると「なるほど」と納得させられる一言です。

ひらたくいえば、Web って、文書作成者以外のあらゆる人までもが、オリジナルの文書を自由にコントロールできる媒体だといったところでしょうか。

文書作成者が用意した代替スタイルシートとか、そういう狭い選択肢の話ではなく、エンドユーザーレベルでいえば、閲覧する媒体や形態（視覚メディア・聴覚メディア・紙メディア）を選べたり、ユーザースタイルやユーザースクリプトを使って内容やデザインを自在に変えてみたりできる。

また、その間を仲介する、検索サービスや、ソーシャルメディア、マッシュアップサービスなんかも、オリジナルの文書（HTML）を収集・再構築して、まったく新たな付加価値を生み出したりできます。（もちろん、エンドユーザーでも DOM や XSLT などを駆使して、似たようなことを実現することが可能です。）

僕自身、すごく似たような理由でここ最近、HTML に関心を持ち続けてきたので、何かと共感させられるところの多いセッションでした。

勇気ある提言

小久保さんのセッションで個人的に感銘を受けたのは、「キャッチーな話はしません」とか、「すぐには役に立たない話かも」とか、「自分で考えてください」とか、聴講者を突き放したようなことを、躊躇なく断言されていたことです。（「勇気あるなぁ」と苦笑しながら聴いてました。）

実際、他人に答えを教えられるのと、自分で答えにたどり着くのとでは、理解度も応用力も段違いなんですよね。

「知ってる」「分かってる」と口にするのは簡単なことですが、それが見聞きしたことがあるという程度なのか、知識として頭で理解している水準なのか、スキルとして身に染みついて自在に駆使できる境地なのか、人によって習熟度にかなり差があるものです。

本当に使える知識は、日頃から自分自身に問い続けて、実践と試行錯誤を重ねてこそ得られるもの。その意味で、この辺に絡む、小久保さんの突き放した姿勢にも納得でした。

（以下、2007年5月29日追記）同様の意味で感銘を受けたのが、神森さんと河内さんの Live Coding です。それこそ、「日頃から自分自身に問い続けて、実践と試行錯誤を重ね」てないと、出てき得ない要素が随所に散らばってました。目的を達成しうる複数の選択肢の中で、なぜその手段を選んだのかを、ひとつひとつ口頭で説明できているのが、その何よりの証でしょう。あれは、僕自身も本当に勉強になりました。

「デザインからロジックを読み取る」

神森さんと河内さんの Live Coding の内容が濃かったせいで、ついつい、見落としてしまいそうになりましたけど、本来ならロジックからデザインを設計するのであって、「デザインからロジックを読み取る」というプロセスは本末転倒なんですよね。

もちろん、他人のデザインを解析する時には「デザインからロジックを読み取る」ことが必要になる場面もありえますし（リニューアル案件とか）、そもそも今回は、この形態自体もコーディングコンテストのお題の一部になっているのだから、決して問題だと言ってるわけではありません。

でも、今回の形態にとらわれて、ロジックとデザインの主従関係を見失わないようには自戒したいです。

改行・インデントの適切な案配

益子さんは、かなりこまめに改行を挿入される方のようで、CSS ならプロパティの値ごと、一部の HTML 要素も属性ごとに改行を挿入されているとのこと。

「益子方式」による改行とインデンテーション
CSS	XHTML
body { background: #ffffff url(/images/bcg̲body.gif) repeat‒x left top; color: #000000; font‒size: small; }	<input type="text" size="50" id="yourname" name="yourname" value="" />

個人的にはルールが共有・履行されてさえいれば、問題ないと思ってますし、益子さんの書き方も、すごく見やすいと思います。

でも、その一方で、これだと改行がこまめすぎて、ソースコードが横に長くなるかわりに、今度は縦に長くなってしまう気がします。特にスタイルをひとつのファイルにまとめて記述してしまう場合は、全体像を把握したり捜し物をする時に、逆に不便な場面も出てくるでしょう。せめて、たとえば識別子として使われる name と id 属性や、background(-position)プロパティの left と top 値など、同種の属性や値は同一行にまとめてしまう方がいいかも...なんて思いました。そのあたりは、僕も自分なりにほどよい案配を模索してみようと思ってます。

限られた条件の中でベストなものを

もう一つ、益子さんのセッションから。終わりの方は散発的に益子さんのポリシーを、標語的に披露されていましたが、その中で、ひとつ僕自身考えさせられたのは、「与えられた時間の範囲内でベストを尽くそう」という点。

理想を追求することは際限がありませんが、一方で時間や予算といった資源は有限です。この意味で、益子さんのこのご指摘は、もう少し踏み込んで検討する価値があるように思いました。「妥協」という後ろ向きな形ではなく、「目前の条件と目的に応じた最適解の模索」という前向きな見方をしてもいいんじゃないかと。

Yahoo! Japan を W3C の HTML バリデータにかけると...

太田さんのセッションで、Yahoo! Japan を W3C の HTML バリデータにかけたら、エラーが 404個所出てきたとスライドに出てきて、最初、HTTP のステータスコードとして "404"（「ファイルが見つからない」）を返してきたのかと、一瞬、びっくりしました。(^o^;)

いや、もちろん、この数にもビックリですけど..。すみません。ゴミのようなコメントで。(- -;;)

それにしても、つくづく、bA って、優秀な人ばかりですねぇ。

Re: ドメイン名の由来を書いてみる

ゆう — 2007-05-09T05:16:20+09:00

なんだか、めっきり疲れやすくなっちゃった感のある今日この頃。(- -;;)

ちょっと遅くなってしまいましたけど、上之郷谷さんの企画に、乗っかってみました。

サイト名の由来

実はこのブログは、匿名で好き勝手なことを書きつづって、逃避がてら仕事のストレスを発散させるのが元々の目的だったんです。こことは別に、実名で運営している自分のサイトも持っていたんですけど、ちょっと更新すると「おっ、なんかアイツ、まだ余裕がありそうだね」って感じで、狙ったように雑用依頼（ほとんどは無償）が降りてくる状態だったので（なんか色んな人に監視されているような感覚）、そちらは次第に更新が滞っていくようになりました。そんな事情で始めたブログだから、名前なんて、それほど真剣に考えてませんでした。

「我的春秋」。「我的」は現代中国語の「私の」。「春秋」は、「歴史書」とか「年齢」とか「一年」とか、とにかく時間との結びつきの強い言葉です。ただ、現代中国語というよりもクロニクル（年代記）という古漢語的な意味合いの方をここでは意識しています。要するに、「私のブログ」をほんの少しひねっただけの、いい加減な命名なんです。

始めた当初は、まさか今のようになるなんて想像もしていなかったから、ブログも「適当にどこかフリーのブログサービスでいいや！」ってノリで、勢いで決めちゃってましたし、話題も初期の頃は、飲食店や、スポーツ、音楽に、時折時事を挟むといったような感じで、今とは随分毛色が違ってました。(^ ^;)

ドメイン名の由来

「我的春秋」をそのまま現代中国語のピンイン表記（wo de chunqiu）にしてしまうと、わかりにくいかなと思って、「我的」だけを "my" にしたものです。今から考えてみれば、まだしも "my-chronicle" のようにしておいけば良かった...なんて、よく後悔してます。名前って、一度定着しちゃうと、変えづらいですよね。ま、「名正しからざれば、則（すなわ）ち言順（したが）わず。言順わざれば、則ち事成らず」ともいいますし、いずれ、ちゃんと内容に則した名前とドメイン名をつけなおすつもりです。

追記: HN の由来

「ゆう」というハンドルネームは、実名とは無関係です。いつも汲々としていた自分を、なかば皮肉って、「もっとゆとりを持とうぜ！」とばかりにつけた名前です。要するに「かくありたい」という欲求や願望に由来してます。

むかしは「悠」と漢字で書いてたんですが、漢字よりも平仮名の方が「ゆとり」のイメージが強くなると思って、数年前から平仮名に改めました。（もとの本業で、365日×360° 漢字漬けだったのに辟易したからだという説もありますが..。）

hr要素は改名して、インライン要素とするのが活路かも

ゆう — 2007-04-30T04:57:09+09:00

なんだか br要素の話が賑やかなようなので便乗。(^ ^;)

ここで改行ったら改行（カナかな団首領の自転車置き場）
br 要素（カナかな団首領の自転車置き場）
私はbr要素が好きじゃない（der Gegenwart）
br要素は好きじゃない（sky line blog）
br 要素問題は CSS2.1 で解決か!?

どちらかというと現行規格ではなく、次世代規格の話になるので、少なくとも批判とかじゃありません。平たくいえば「br, hr 要素を論理セパレータとして見なすとこんな感じかな？」「その特性を活かすなら、仕様をこう変えた方がいい気がする」的な話です。

ちょっと小難しそうな感じがする方は、前置きはスルーして、ユースケースとサンプルコードだけ眺めてもらって、まったく支障ありません。っていうか、次世代規格の話だし、需要自体もそんなにたくさんあるようなネタでもないし、いっそ、全部まるごとスルーしてもいいかも。(笑)

構造本位か見栄え本位かは文脈や用法次第

まず <br/>, <hr/>, <seperator/>要素が構造か見栄えかの問題ですが、結論だけいってしまえば、僕はこれは文脈や用法次第だと思います。どちらにもなりうる、と。たとえば、「第3章の4段落目」と「56ページの16行目」は、それぞれ対象が文章にあるのか、書籍媒体にあるのかの違いがあるだけで、両方とも構造を示してますよね。もちろん、ホワイトスペースの調整のための見栄え本位な改行だってありえるでしょうし。

（そういえば、大学で編集の雑用をしていた時分、テキストファイルや Word 文書の行末に、ご丁寧にも毎行、改行を入れてくれる人が後を絶たなかったのを思い出しました。(^ ^;) ）

<br/>, <hr/>, <seperator/>要素の特性

ちなみに、これらの要素だからこそできる、構造化や意味づけの用法として、どんなものがあるかなんですが、鍵となるのは、おそらく空要素タグという性質になるかと思います。

ならば、空要素タグの性質とは何か？

真っ先に思い浮かぶのは、それは構造を持てない（＝子孫や内容を持てない）という性質。この性質は一般に空要素タグの短所や限界として捉えられることが多いんですけど、実は裏を返せば、ツリー構造（もしくは入れ子構造）を成していなければならないという、SGML or XML系マークアップ言語の制約に影響される部分が少なくなることも意味しています。

この辺に絡むこととして、表題のようなことを前々から考えてたので、ちょっとまとめてみました。動機が上掲の議論とは別のところからきているので、はたして参考に値するかどうかはわかりませんけど。

論理セパレータとしての hr, seperator 要素（+ br 要素）

(補: deprecate HR; replace with LS (logical seperator).) so that authors can attach meaningful title text, such as "page 21" as well as orientational info; this is a powerful but underutilized tool...

deprecate HR; replace with LS (logical seperator) from Gregory J. Rosmaita on 2007-04-02 (public-html@w3.org from April 2007)より

これは、hr要素を "logical seperator"（論理セパレータ）として重視している人の投稿の一節で、hr 要素が実はページ区切りなどの効果的な論理セパレータとなりうるにも関わらず等閑視されていると指摘されています。（なお、"ls"要素への改名という提案に関しては、結局、HTML5 では、後方互換性の観点から "hr" という要素名を保持しているという話になってます。→ 2007年4月2日: Anne van Kesteren の Reply 投稿）

とっても興味深い指摘なんですが、いかんせん、現行の hr要素はもとより、X/HTML5 の hr要素も XHTML2 の seperator要素もブロック要素扱いとなっていて、たとえば p要素（段落）内への挿入を認めていないんですよね（テキストノードの間に、こうした論理セパレータをはさむことができない）。

XHTML2: Content model of p element: (PCDATA | Text | List | blockcode | blockquote | pre | table )*
X/HTML5: p elements can contain a mixture of strictly inline-level content, such as text, images, hyperlinks, etc, and structured inline-level elements, such as lists, tables, and block quotes. p elements must not be empty. → hr要素はブロックレベル要素になるので内包できず。

あちこちで指摘されているように、ブロックレベルでの区切りは、基本的に div 要素などでマークアップすることができるので、僕は、この論理セパレータはインライン要素として使えるようになって、はじめて威力を発揮できるようになるんじゃないかと感じてます。（del, ins要素のように、ブロックレベル・インラインレベルのどちらでも使える要素にすると、さらにいいのかも。）

こんな抽象的な言い方をしても、イメージが湧かないでしょうから、とにかく具体的なユースケースをひとつ出してみますね。

use case: 文書の論理構造と組版情報を混在させる

想定される用途:: 書籍の内容を HTML文書化する場合など。（書籍と連動させたい教材とかで需要があるかも。）
解決すべき問題:: 章・節・段落といった文書構造と、ページ数・行数といった書籍媒体上の組版情報が混在すると、入れ子構造（またはツリー構造）が保持できなくなる。
解法となる候補案:: インライン要素の論理セパレータを、本文（テキストノード）中にはさむ。すでに長く利用されている br 要素を使えば、行の頭出しもできるようになる。（XHTML 2.0 なら状況に応じてl要素と使い分ける。）

サンプルコード（XHTML 2.0 もどき）

<p>章・節・段落といった文書構造と、ページ数・行数といった書籍媒体上の組版情報が混在すると、入れ子構造が保持できなくなるので、改頁する場所に空要素タグの論理セパレータを挿入します。こうす<seperator class="pageBreak" id="page-31" />ることで、文書構造と組版情報を両方とも保持することができますし、文章の流れを損なわずに、ページの頭出しもできるようになります。（<cite href="#page-31">本文 31ページ</cite>を参照。）</p>

余談: 要素名はやっぱり変えるべき

もしインライン要素化する場合は、名前についてはモチロン hr ではなく、seperator なり sep なり ls なり、何か別のより妥当な名称に変えるべきでしょうね。よく目にするパイプ（" | "）や日本の中黒（"・"）なんかは、インラインで使われる論理セパレータともいうべき符号ですが、ご覧の通り、インラインじゃ horizon（"水平"線）にはなりませんもんね。誤用のもとにもなるので、やはりインライン要素化する場合は変えた方がいいかもしれません。

…とまぁ、以上のようなことを英文にしてみるのに腰が重くて、こうしてウジウジしてました。(^ ^;;)（英文にするとしても、その前にもう一度、過去の議論を漁ってみないと..。(- -;) ）

ちなみに、この空要素タグで改頁をマークアップするという発想は、TEI という XML ベースの規格の pb要素のモデルからきています。

追記:

改ページのための構造？それは文書構造よりも機能構造なんじゃないかなあ。それだったら、ページメディア用のスタイル言語に任せられないのかなあ。（vantguardeさん@はてブ）

コメント、ありがとうございます！"書籍媒体の"機能構造という点はおそらくおっしゃる通りなんじゃないかと思います。ただ、この場合は紙媒体書籍の「ページ数」（別に巻数でも、行数でもいいんですが）というメタ情報をマークアップする場合の話なので、Webページやプリントアウト時の見栄えレベルでどう処理するかとは、まったく別のレイヤーの話です。

とはいえ、このレベルのメタ情報をマークアップするのに HTML を使うかなぁ？とは、自分でも思わないでもありません。(^ ^;;) ま、「空要素タグな論理セパレータだからこそできること」の例として、少々特殊なユースケースになってしまいましたけど、探せばもっと良い例があるんでしょうね、きっと。

Web媒体では見出し毎に移動する方がわかりやすいので、書籍の内容をHTML化するにしても組版情報を残す必要はないと思う。（dede-sukeさん@はてブ）

少し特殊なユースケースの話をしているので、おっしゃるように処理されるのが、普通だと思います。（よほどのことがない限り、僕もやっぱりそうします。）ただ、紙媒体の読み物の場合、1章、1節、1段落が長いこともしばしばです。そういう時、本文中に「P.24 の 3行目参照」なんて出てきたら、探すのイヤになっちゃいますよね。もしかしたら、そこに需要が発生することがあるかもしれない、と思った次第です。

見栄えと論理構造の分離が一番の旗印なのに『文書の論理構造と組版情報を混在』というのは混乱しているのでは？SGMLのplatform independencyからもほど遠いし。（beatakさん@del.icio.us コメント）

うーん、"SGMLのplatform independency" って、こういうことを言ってるんでしょうか？

書誌情報や組版情報と Web ページの見栄えは区別すべきものだと思いますし、ページ数や行数といった情報の捉え方も、時と場合に応じて変わります。たとえば、プログラムのソースコード中のある場所を指定する時に、そのソースコードの行数を示すのは見栄えでしょうか？「行数」というメタデータとしても捉えられませんか？もちろん「ページ数」も同様。

hrをインライン要素とすべき根拠としては、ユースケースが特殊過ぎるのでは。/ 意味的な区切りにしたいのか、レイアウトのための区切りにしたいのかで混乱があるような北村さん@はてブ

ほかの追記でも書いてますが、否定はしません（というか僕自身、そう思ってる面があるので）。(^ ^;) 混乱についても、起こりうるからこそ、"hr" という名前を別なものに変えた方がいいと思うわけですけど、後方互換を考えると、むしろ hr 要素は hr 要素として現状のまま残った方がいいのかな..とも思ったり思わなかったり。

"書籍の内容を HTML文書化"するのに、組版情報を残す必要性は少ないような……hr要素が仮にインライン要素になった場合、ブラウザデフォルトのスタイルって？（木達さん@del.icio.us コメント）

これも、「必要性」とか「需要」とかいう話でいえば、このユースケースでは確かに薄いといわざるを得ません。（やはり例が悪い..。(- -;) ）デフォルトスタイルについては考えてませんでしたけど、ブロック要素として使うなら水平線、インライン要素なら垂直線（パイプっぽいもの）？(^ ^;)

それにしても、この話題で、こんなに反響を（しかも具体的に踏み込んだコメントまで）いただけるとは思いませんでした。ちょっと意外。みなさま、ありがとうございます。m( _ _)m

Firefox メインでも、ひそかに Opera 好きのユーザー

ゆう — 2007-04-29T02:00:08+09:00

lomo さんのエントリーで、

コメント・トラックバック・ソーシャルブックマークのコメント・Twitter…なんでもいいのでOperaに対するご意見を聞けたらなって考えています。

Operaのよいところってどこですか?（caramel*vanilla）より

という話が出ていたので、僕もひとつ。ちなみに僕は Mac | Win2K + Firefox 2(5) : Win2K + IE 6(2) : Mac + Safari (1) : Mac | 携帯 + Opera (2) の割合で使い分けてる、わりと節操のないユーザーです。(^ ^;)

Opera でいいなと思う点

IE や Safari と違ってクロスプラットホーム。（Windows・MacOS X・Linux etc..）
しかも、Firefox と違っていろいろなデバイスで使える。（携帯・PDA・Wii・NintendoDS etc..）
手元の携帯（W41CA）用の Opera が PC 向け IE 7 よりも CSS をちゃんと解釈してくれるのを見てると、なんだか IE がとっても可哀想な存在に思えてくる。(^ ^;)
（Opera 9 になって少し重くなったような感じもするけど）基本的にすごく軽い。
Fixed layout（固定幅レイアウト）なサイト用にズーム機能が実装されている。（IE 7 でも実装されたけど、こちらが本家本元。）
CSS media queries を使えば、一枚の HTML 文書と Opera の 4つの表示モード切替で 4度美味しい使い方も可能。
（PC スクリーン用のウィンドウ幅モード、小型携帯端末向けのスモールスクリーンモード、プレゼンテーション向けのフルスクリーンモード（Opera Show）、紙媒体用の印刷プレビューモード）
IE や Firefox などに比べて、独自規格や次世代規格の先行実装よりも、現行規格の実装を先にキチンとするという姿勢が見え隠れしていて、個人的に好感がもてる。
Windows 版なら英語ページの音声読み上げ機能がついてて、英語ページをブラウザに読ませながら、別の作業ができる！（これは、是非、Mac 版でも実装して欲しい！Firefox にも、FireVox という拡張があるけど、それより遥かにエレガントに読み上げてくれる。）
細かいところで何気に UI の使い勝手がイイ。（たとえば、level さん@えむもじらが取り上げてたリンク文字列選択とか、アドレスバーの「貼り付けて移動」とか。）

「一歩先のWeb標準」連載開始

ゆう — 2007-04-27T13:23:13+09:00

デジタルスケープさんの WithD にて今月から連載を持たせていただくことになりました。（ネタもそうですが、文章が堅くて、編集の方にご迷惑をお掛けしたと思いますが。(- -;;ゞ）

マークアップのmust, should, may - 一歩先のWeb標準 ♯1（WithD）

奇しくも「勘違い甚だしいstrict HTMLの解説」（sky line blog）なんてエントリーが出た直後で、なんだかタイムリーになってしまいましたけど（文章の核になる部分は 1か月以上前から用意してたものなので、単なる偶然なんですが）、書かれている内容は、このブログ内の過去のエントリーとも関連してます。

要するに僕の場合、must ではなく、may の話が多いので、「しなければならない」みたいな文脈で受け取らないでくださいねって、ことわり書きみたいなもんです。たとえば僕の (X)HTML の話なんて、マークアップがライトウェイトかヘビーウェイトかの違いでしかないわけで、別に body 内が h1〜h6 と p だけで構成されてたって、全く問題ないんですよね。

ついでにいえば、HTML か XHTML かだって同様。あくまで僕個人は、そんなに大した問題じゃないと思ってます。だって、再利用したり再構築したりするとしても、おそらくそれを行うのは検索サービスだったり、ソーシャルメディアだったり、CMS だったりで文書作成者以外の第三者のことが大半なわけですし、いうなれば自由意志でつける、見えない付加価値みたいなもんです。（なんだか料理の隠し味みたいですけど。）

それでも、あえて付加価値をつけたり、未来の Web が少しでも便利なるように、"自分自身ができること" を模索してみたい...という方に向けた連載です。（このブログも基本的には同じ路線ですが。）たとえ万人向けの内容でなくとも、ごく少数の方でもお気に召していただけることがあれば、それだけでとってもうれしいです。

CSS Nite Shuffle レポート

ゆう — 2007-04-17T19:25:48+09:00

日刊徒然音声雑記などでお馴染みの境祐司さんのご招待で CSS Nite Shuffle に行ってきました。（境さん、ありがとうございました！）

境さんとは、知識共有や暗黙知まわりでお話することができましたが、このあたりはまたいずれ（必ず）。

天気は冬に逆戻りしたかのような冷たい雨。会場は、渋谷のラブホテル街の中にある、ライブハウスということで、なんだか妖しくも不思議な気分でした。(笑)

Special Contents

ライブハウスならでの演出があるとは聴いていましたけど、まさか弦楽四重奏とは思いませんでした。境さんとなぜか最前列の真ん中の席に座ったこともあって、ちょっとしたサロンみたいで贅沢な気分になれました。特に奏者（4人とも女性）の紹介がなかったところを察するに、アマチュアの方でしょうか？曲目は全部は覚えてませんけど、モーツァルトのアイネ・クライネ・ナハトムジーク、バッハの G線上のアリア、ヘンデルの水上の音楽、星に願いをなど、有名曲の抜粋もしくは編曲版といったラインナップでした。

さすがに最前列で、あれだけ至近距離にいると、各声部が驚くほどはっきり聞き分けられて、予想外に刺激的でした。

長谷川恭久: エコなWebデザイナーになろう。

いきなり裸足でご登場。

僕も司会の鷹野さん同様、「エコな」演出かと思いきや、雨で濡れた靴だと音がうるさいから脱いだとのこと。しかも、おもむろにデジカメを取り出して、ギャラリー側を撮影されたりして、気持ちいいくらいの砕けっぷりでした。むしろ、最前列に座ってた僕の方が緊張してたくらい。(笑)

CSS Nite 大阪での同名のプレゼンの焼き増しという話でしたけど、拝聴して再演したのも納得しました。内容は、コード・画像・システム・言葉（テキスト）の節約と再利用性の向上が中心で、目新しい点こそありませんでしたが、各種 SPAM や冗長で汚いコードの垂れ流しなどを、環境汚染に見立ててリソースの節約とリサイクルを説く...というメタファは、Web 標準コーディングの啓蒙には案外有効かもしれないと感じさせられました。（ほかに共有や実践の推奨という話も。）

余談ですが、この時境さんとお話してたのは、リッチコンテンツラインナップの前にエコな話を持ってくるのはいいんだろうか？という点。(笑) でも、Adobe/Apollo vs Microsoft/WPF という適度な対立軸があった方が、見る側には刺激が増すのかもしれません。（少なくとも現段階では、厳密には競合しないでしょうけど。）

太田禎一: ついに出たApolloのパブリックベータ、インストールから向かうビジョンまで

春日井良隆: そもそもWPFとは？WPFで何ができるのか？

続いては、Adobe Japan（Macromedia 出身）の太田禎一さんと、Microsoft（実は Adobe Japan 出身）の春日井良隆さんによる、最新のデスクトップアプリケーション絡みのセッション。この日の目玉ともいうべきセッションで、これを楽しみにいらしてた方も多いのではないでしょうか。それぞれのアピールポイントは概ね以下の通り。

Apollo（Adobe）: Web系開発者がすでに身につけている Web のスキルを利用して、クロスプラットホームに対応したデスクトップアプリケーションが手軽に開発できる。
WPF（Microsoft）: 3D レンダリングや ClearType による、フォントのアンチエイリアシングを軸に、視覚的な表現力に強い。

結論からいえば、amachang さんも質疑応答で「それって普通に JavaScript 書くのと、どう違うの？」的な質問をされていましたけど、かえって疑問が浮き彫りになったような印象が拭えませんでした。（僕も amachang さんのように事前に質問を準備してくれば良かったかも。問題点の整理だけで手一杯で、とても質問どころじゃなありませんでした。）

脱ブラウザ化のメリットがとても不鮮明。
（「既存の Web 制作スキルで開発可能」と「脱ブラウザ」というアピールポイントが思いっきり衝突してしまっているのが原因。）
デスクトップアプリ ←→ ブラウザ間のウィンドウ遷移が煩わしそう。
（たとえば、デスクトップアプリケーションのサンプルイメージとして上がっていた FlickrUploadr にしても、Web ベースのアップローダーの UI の使い勝手が向上すれば、ユーザーがどちらの選択肢をチョイスするかは微妙だと思う。）
多数のデスクトップアプリがローカルに氾濫するのは、再利用性やリソースの節約という「エコ」な考え方に逆行するような気がする。
このままでは、むしろ、すべてブラウザ内で解決できてしまった方が便利という印象が拭えない。（もちろん、従来型の Web コンテンツの利便性を上げることは、常に実装の複雑さやセキュリティ・アクセシビリティなどとのドレードオフがつきまとうことも、我々は念頭に置いておくべきなんでしょうけど。）

さらに WPF についても、根本的な疑問が。

結局、環境依存。（Windows。それも Vista と XP のみ。）
3D 処理が重すぎて、少なくとも現時点では、あまり現実的な選択肢とは考えにくい。

（WPF は、WF、WCF、WCS などと共に、Microsoft の .NET Framework 3.0 を構成する要素のひとつなので、本当は WPF 単体で評価を下すのはフェアではないのかもしれませんが、どのみち、.NET Framework 3.0 全体で評価したところで、そんなに結論が変わるとも思えないので、ここは他の構成要素は無視しておきます。）

WPF に関連して、昨日発表された、クロスプラットホーム、クロスブラウザなプラグイン "SilverLight" の話も出てましたが、ひとまず割愛。（一日経った今でも、まだ頭の中がぐちゃぐちゃなので。）

CSS Nite Shuffle に行ってきた（IT戦記）
.NET Framework 3.0 の紹介（msdn）
.NET Framework 3.0がソフトウェア開発にもたらす価値とは？（＠IT）

北村健・松岡清一: リッチコンテンツ制作に求められるセンスとスキル

BAPE.COM における .exe 形式の EC サイトビューワーや、証券会社の入力フォームのログ解析と実装に関する話とデモが中心。前の Adobe とMicrosoft のセッションを、具体的な実装のアイディア面から補完してくれるような位置づけになると思うんですが、やはり（少なくとも僕には）デスクトップアプリケーションのメリットを見出すには至りませんでした。ただ、いくつか鍵になりそうな発言もチラホラ。こちらも、まだ頭の中がぐちゃぐちゃで整理しきれてないので、今はひとまず、その鍵になりそうな発言内容と、そこから感じたことのリストで勘弁してください。（メモが追いつかなかったので、間違っていたら指摘してください。考えごとをしながらメモを取ってるから、どっちつかずになるんでしょうね、まったく..。）

「（A Bathing Ape で）デスクトップをジャックしよう！」: マーケティングツール・ブランディングツールとしてのデスクトップアプリという考え方は、なるほどと思った反面、細かい目的に特化したアプリケーションが（まして EC サイトごとのアプリが）ローカルディスク内に氾濫するという未来像は、あまり想像したくありません。きっと遠からず、デスクトップアプリを管理・検索するツールが出てくるんでしょうね。あるいはアプリケーションランチャーのようなもの、もしくはアプリケーションランチャーそのものかもしれません。（ちなみに僕は、アプリケーションランチャーは Mac では Quicksilver、Windows ではちょっと古いですが Moonlight を使ってます。）
「BAPE さんにとって、（Web ブラウザは）余計な UI ばかり」: 目的に特化・最適化された UI の提供は、確かにデスクトップアプリの有利な点かもしれませんね。これは確かに一理あります。Web ブラウザのメニューバーやツールバーくらいは、意に介するに値しないという意見も、もちろんありうるとは思いますが。
「SSL 通信への対応」: Apollo や WPF ではこのあたりを期待しているとのこと。iTunes のような、EC 型ネットワークアプリには必須要素ですよね。この話が出て初めて気づきましたけど、EC という視点でデスクトップアプリを掘り下げた話をあまり聴かない気がします（僕が知らないだけでしょうけど）。Amazon あたりがデスクトップアプリを出してきたら、迷わず使ってみるところなんですが...。
「入力フォーム（セッション）のタイムアウト」に対して「途中まで入力したデータをローカルに保存」できるようになる？: レジューム機能のようなものが実装できるようになってストレスが軽減されるなら、それ自体はうれしいことですけど、やはり実装やセキュリティとのトレードオフはついてまわりそうな気はします。
「エコ」: 冒頭のヤスヒサさんとの絡みの発言。ここを聞き逃したのが、この日、イチバンの痛恨でした（半分パニックに）。Flash や Ajax、動画コンテンツといったリッチメディアとエコって、一見、相性が悪そうですけど、そこに敢えてアクセシビリティやエコな考え方を持ち込むことは、大いにアリだと個人的には思います。Ac+C'04 アワードでも、「アクセシブルな Flash 」という観点からの採点が入ってましたけど、これだけで立派に一分野になるんじゃないかと。Shuffle 終了後に、同じエコでも、サーバーサイドにとってのエコと、クライアントサイドにとってのエコは別個に考えた方がいいのかなぁ...なんてことを考えながら帰路につきました。

BAPE.COM | A BATHING APE OFFICIAL SITE

Re: 正しくHTMLを書こうと心がけている人に5つの質問

ゆう — 2007-04-10T02:03:41+09:00

Rusica さん＠der Gegenwart の正しくHTMLを書こうと心がけている人に5つの質問に何となく反応してみました。

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

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

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

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

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

正しくHTMLを書こうと心がけている人に5つの質問より

テキストエディタ追記: （状況に応じて、割と節操なく変えてます。Windows: EmEditor, Crescent Eve | MacOS X: skEdit, JEditX, Smultron, Carbon Emacs+PSGML, mi | IDE: Aptana, Oxygen）, Web Developer（Firefox 拡張）, Total Validator（Firefox 拡張）, Firebug（Firefox 拡張）, 追記: Copy URL+（Firefox 拡張）
普段は XHTML 1.0 Strict。ただし、状況に応じて XHTML 1.1 や XHTML 1.0 Transitional, HTML 4.01 Transitional を選択することもあります。追記: 前方後方どちらの規格にも対応しやすい Strict を軸に、使用要素や更新作業者が誰になるかといった種々の条件によって、最適なものを選択。
第一にメンテナンス性と分業効率のため。第二に機械処理のしやすさ（されやすさ）のため。
どちらも。というか、相乗効果を期待してます。追記: 特に要素にするか属性にするかをめぐる議論（time 要素と datetime 属性 etc.）とか。
Web 文書フォーマットの現実的な落としどころ。