- Overview
- Site Summary (RDF)
- Update Info
- RSS 1.0 (RDF)
- RSS 2.0 (XML)
Web::Blogoscope
2005年12月
マクドナルド@宇都宮にて
昨日から実家に帰省中/実家で寄生虫。近くのマクドナルドがBBモバイルポイントに対応とのことで、さくっとインターネットに接続しています(実は設定に右往左往して15分ぐらいかかってしまったり)。
マクドナルドのおかげで、正月休みの間も毎日インターネットにつながる予定。
今年も今日で終わりです。いろいろとお世話になりました。
よいお年をお迎えください。
2005-12-31T12:48+09:00 | 身辺雑記 | 固定リンク | コメント (0) | トラックバック (4)
伊達巻フライング禁止令
おせち料理/食材のなかでも伊達巻が一番好きだ。世界中を敵に回しても、僕はきっと伊達巻を守る。なんだそりゃ。
正月休みの数日間、家族からどんなに伊達巻独占禁止法違反の罪を咎められようとも、ひとりで3本は食べる。普通に経済力のある大人になってしまった反作用からか、ここらへんの問題は金銭でつつがなく解決する。伊達巻3本ぐらいでガタガタ言うな以下略。いや、咎められるなんてことはなく、なくなったら自分で買いに走るんですけどね。ダッシュで。
スーパーはクリスマスが終わったら早々と正月向けに衣替えするわけで、伊達巻は紅白かまぼこなど練り物仲間とともにスペースの主要な一角を占める。ついカゴに入れてレジに並びたくなってしまうのだが、元日を迎える前に伊達巻を口にするのは完全なフライングであり決して許されない行為だ。
と、毎年この時期になると自分に言い聞かせ、じっと耐え忍ぶ。
2005-12-29T21:38+09:00 | 身辺雑記 | 固定リンク | コメント (0) | トラックバック (0)
矢野りんさんとコラボ企画
今日は矢野りんさんと上野で打ち合わせ。タイ料理を食べた後、喫茶店でお茶をしながら。多くの方がご存知でしょう、りんさんは 『Webレイアウト見本帳』 や 『Web制作演習Basic Studies』 などの著者で、『月刊 web creators』 の連載/記事でもお馴染みですね。
お互い長らく 『月刊 web creators』 で執筆していながら顔を合わせることがなかったのですが、今年の夏にお会いする機会があり、何かのかたちでコラボしましょうということで。その後、何度か打ち合わせをし、今日でおおよその中身が決まり。
来年の夏ぐらいに成果が出せればと思いつつ、少しずつ準備をはじめています。ぜひお楽しみに。
* * *
りんさんから、先日出たばかりの新刊 『Webレイアウト・セオリー・ブック─Webデザインのためのレイアウト基礎講座』 をプレゼントしていただきました。りんさんの本はどれもクオリティが高いのですが、本書も理論と実践がうまく融合した素晴らしい本です。
* * *
帰りしなアメ横に寄ったら、靴や洋服をウン万円ぶん衝動買いしてしまった。
ただでさえ出費が多い年の瀬なのに。
2005-12-22T23:59+09:00 | 身辺雑記 | 固定リンク | コメント (0) | トラックバック (0)
カニ総括 2005
そういえば、もう旬になってしばらく経つというのにカニのことを全く書いていなかった。誠に不徳の致すところであり、北海道、東北北部、北陸地方に向かって深くお詫び申し上げたい。
先日のXHTML+CSS集中講座の忘年会では、特別参加していただいた鷹野さんらとkHTML(Kani HTML。SafariやKonquerorに実装されているレンダリングエンジンとは全く別モノ)ですっかり盛り上がってしまい、帰りしな寒風吹きすさぶ駅のプラットフォームで、横歩きマークアップをさらに極めんと固く心に誓ったところである。
以下、今季に食べたカニを総括したい。
ゆでタラバガニ
やはり、北海道から取り寄せたタラバガニで今季をスタート。
シンプルに釜ゆで。堂々とした風貌は何度見ても惚れ惚れ。
タラバガニラーメン
ラーメンにタラバガニ脚2本を豪快に盛りつけた意欲作。
ズワイガニ鍋
ズワイガニは鍋で。最後に雑炊で〆。
ゆでタラバガニ脚
タラバガニ脚2kgをリーズナブルな価格で購入できた。
ゆでようか焼こうか迷ったが、ゆでて食べた。
まだ残っている分は焼いて食べよう。
番外編: 海鮮丼
カニと一緒に取り寄せた食材で海鮮丼を作った。
海の二大宝石「ウニ」と「イクラ」でノックアウト、セコンドから白タオル投入。
番外編: 「たらばかにカレー」
知人から北海道旅行のおみやげにもらった「たらばかにカレー」。
カニの香りがグイグイ攻め込んできて、カニ好きにはたまらない一品。
身がもう少し大きければ言うことナッシング。
「いただきました、星2つ半です」。
現在の貯カニ
冷凍庫にタラバガニ脚1kgとズワイガニ1匹。
カニ納会をするためにプールしている。
今後の内子(抱負)
集まってカニを食べるイベントをやりたい。
- カニ8耐
- Fight Crab
- 確カニ僕たちは恋をした
などなど、妙なネーミングを思い浮かべているうちに泡を吹いて入眠。
2005-12-21T02:07+09:00 | 身辺雑記 | 固定リンク | コメント (0) | トラックバック (1)
CSS Nite Vol.3/打ち上げ
昨日はApple Store銀座のCSS Nite Vol.3(19:00-20:15)に行ってきました。鷹野雅弘さん出演のマンスリーイベントで、毎月第3木曜日に好評開催中。
Vol.3は「Web標準時代のDreamweaverのテンプレート活用」というテーマで、第1部は鷹野さん、第2部はゲストの木達一仁さんによるプレゼンテーションでした。
会場で長谷川恭久さんとAll女性Xoops塾の大本あかねさんが立ち見しているのを発見。真ん中あたりの席に座っていたので動くこともできず、終了後に声をかけました。あと、毎日コミュニケーションズのKさんともお会いしたので、仕事の件で軽くプレッシャーをかけました。
その後、21:00から近くの日比谷バーで打ち上げ。鷹野さん、木達さん、長谷川さん、大本さん、Kさん、Aselaさん、そしてT-STUDIOの神森勉さん、シリコンカフェの森川眞行さん、伊藤学さん、イラストレーターのemicoさんなど、はじめてお会いする方も多く、楽しい宴となりました。
同じテーブルだった森川さん、神森さんとWeb制作ワークフローの件で意気投合&ワインがぶ飲み。森川さんからは娘さんとの共著 『おしえて!! FIREWORKS MX2004』 をいただきました。ありがとうございました。
帰りしな、長谷川さんと地下鉄銀座線に向かう途中、ちょっとトーク。鷹野さんや木達さんともぶっちゃけトーク(!?)がしたかったけど、またの機会ということでよろしくお願いします。
2005-12-16T23:30+09:00 | 身辺雑記 | 固定リンク | コメント (0) | トラックバック (4)
トラックワードのαブロガーに
トラックワード α版公開にご参加いただいたブロガーの中から、「- ブロガーが強い 検索キーワード -」の各ワードでトップになられた方を発表します。
#αブロガー・・・とは呼ばない、ですよね。。。でもご参加ありがとうございました&おめでとうございます!
とのこと。受賞キーワードは「Google サイトマップ」。先日のエントリーGoogleサイトマップ解説が何かよかったみたいです。こんな企画をやっていたなんて知らなかったんですけど。
賞金として、Amazonギフト券1,500円分がメールで送られてきました。
謹んでお受け取りいたします。
追記 ( 2005-12-16)
そうそう、知り合いの和田さんも「w zero3」で受賞されました。
おめでとうございます(21:20)。
2005-12-16T21:16+09:00 | ブログトレンド | 固定リンク | コメント (0) | トラックバック (1)
Web 2.0とライフスタイル
おおよそWeb 2.0のまとめ的な内容のRSSマーケティングガイド: インターネットこれまでの10年これからの10年【Syndicate SFレポート】を読んで。
多くの人がそう感じており、だからこそトレンドとしてこれだけ耳目を集め、私たちを高揚させるのだろうけど、Web 1.0からWeb 2.0へというベクトルは、社会構造の変化、引いては人間のライフスタイルの変化と大いに相通じるものがあるのではないかと。
上記エントリーでいえば、「デスクトップPC」から「複数のデバイス」へというのは、「ひとつの会社で全うする人生」から「組織横断的なスペシャリストや独立・起業など多様な生き方」へという文脈で考えられるし、その他の項目も何となく社会や組織の変化に、そして私たちのライフスタイルの変化に置き換えられるような気がする。
2005-12-14T00:50+09:00 | Webトレンド | 固定リンク | コメント (0) | トラックバック (0)
RSSとWebの関係を考える
すでに議論され尽くしてしまったのかもしれないけど、RSS/Atom(以下、RSSと総称)が一般的になり、ただ配信すればよいわけではなく「中身」が問われるようになってきている。また、RSSリーダーによるブラウジングが当たり前になることで、Webデザインにも変容が迫られるかもしれない。
といったことを、自分の頭の整理をかねて考えてみたい。
冒頭のみを提供すべきか、全文を提供すべきか
RSSリーダーにはさまざまなタイプがあり、画一的な状況を想定するのが難しいところだが、BloglinesやHeadline-Readerなど全文表示が可能なRSSリーダーのユーザーには、わざわざWebページにアクセスせずにRSSだけを読む人も少なくない。そういえば、ブログサービスも一時期こぞって全文提供に対応したような。
RSSで配信する文字数を冒頭100文字などに制限しているケースをよく見受けるが、RSSだけで全文を読みたいユーザーもいるのだから全文を提供したほうがよい、というのがメディア・パブ: RSSフィード論争,“抜粋 vs 記事全文”や結城浩の日記: RSSフィードに全文を入れるなどの意見だ。
私もRSSだけで全文を読みたい派なので、基本的にこの意見に賛成だ。全文提供によってトラフィックが増えてサーバに負荷がかかるかもしれないが、日本語全角文字(2バイト文字)は1,000字でも2,000バイト、おおよそ1.95KBであり、それほどの負荷ではない。ただ、サイト全体のトラフィックの総計がそれに耐えられないというケースもありうるので、「should」というよりは「may」だろう。
ひとつの解: RSSの形式によって全文提供か冒頭提供か変える
highbiscus: RSSに全文入れろ派は安易すぎると思う。では「全文提供はそもそもRSSの思想に合わない」という意見が述べられている。セマンティックWeb云々のくだりはちょっと違う気がするにしても、一理あると思う。確かに全文提供は「Summary」でも「Simple」でもないわけだ。
上記エントリーに対するはてなブックマークのリアクションにもあったが、たとえばRSS 1.0では全文提供、RSS 2.0では冒頭提供というように、形式によって提供内容を変える方法がひとつの解になるだろう。あるいは冒頭提供ではなく、長谷川恭久さんのブログのように、エントリーひとつひとつにきちんと概要文を書き、RSSで提供する方法もある(これが本来のRSSのあり方かもしれない。よい仕事だと思う)。
そう思って、本ブログでも一時期RSSの形式によって提供内容を変えていたのだが、やはりどの形式でも全文提供を望む声があって、結局すべての形式で全文提供にし、今日に至っている。つまり、この解は使っていない。なぜならこの解を使う場合は事前の説明が必要になってしまうからだ。
たとえばCNET JapanのようにRDFアイコン経由で説明ページに飛ばすのは、ユーザーを戸惑わせることになるのではないか。URLがダイレクトに取得できると思っているのにワンクッション置かれてしまうのは、何となく「裏切られ感」を覚えてしまう。
RSSリーダー vs. Webページ
RSSで全文を提供しており、RSSリーダー上のほうがむしろWebページよりも読みやすい場合、ユーザーはわざわざWebページにアクセスしない(RSSによる全文提供を望むのはこの理由が大きいのでは)。つまり、Webページのほうが読みやすいという前提がないと、デザインをあれこれと工夫することが返ってアクセスの倦厭につながってしまう。
たとえばRSSリーダー上では背景色が白、文字色が黒なのに、Webページはその逆というのでは、ユーザーはストレスに感じるかもしれない。フォントサイズが違いすぎるといったギャップもストレス要因となる。
コメントやトラックバックなどのコミュニティ面、ナビゲーションなどのインターフェイス面、人気エントリー表示などのサブコンテンツ面もアクセスのトリガーとなるのでこう単純には言い切れないが、今後ますますRSS配信が普及するとすれば、RSSリーダー上での表示を念頭においたWebデザインが求められるだろう。
これにより、Webデザインのシンプル化とコンテンツへのフォーカス、ある意味での原点回帰が進むかもしれないし、すでにそのような方向に進んでいると感じる。
PV数もUU数も当てにならなくなってきた
RSSリーダーによるブラウジングが一般的になってくると、PV数もUU数もあまり当てにならないことになる。トラフィックとPV/UU数が相関しなくなってきているのだ。
それゆえ、RSSでは冒頭のみを提供することで、Webページへのアクセスを促すという戦略的な判断がありうる。実際にそのように判断していると感じさせるサイトも少なくない。Webページの価値(またWebページ上の広告価値)を担保するのは、やはりPV/UU数だからだ。RSS埋め込み広告もそのようなやむにやまれぬ事情で生まれたのかもしれない。
サイトをCMSやブログベースにリビルドし、RSSを配信し出したらPV/UU数が落ちた、といった苦情がクライアントから寄せられるかもしれない。結果的にROIが向上したことが証明できればよいが、少なくとも初動段階ではこのような苦情がありうる。あらかじめクライアントに納得しておいてもらわなければならない点だろう。
追記 ( 2005-12-18)
Movable Typeで全文提供(かつマークアップを有効に)するには、RSS/Atomのなかの
<$MTEntryExcerpt encode_xml="1"$>
というタグを、
<$MTEntryBody encode_xml="1"$>
に変えればオーケー。もし追記(more)まで提供する場合は、
<$MTEntryBody encode_xml="1"$> <$MTEntryMore encode_xml="1"$>
とする(00:10)。
2005-12-12T01:24+09:00 | Webトレンド | 固定リンク | コメント (0) | トラックバック (0)
XHTMLの最適化手法
XHTML+CSSというと、どうしてもCSSのほうが強調されがちである。特にレイアウトテクニックを扱う場合、CSSが話題の中心になってしまう。
しかし、『月刊 web creators』 2006年1月号(Vol.49)の巻末特集にも書いたとおり、効率的なCSS設計には最適化されたXHTMLが欠かせない。このことは、CSSが一定レベルに達している人は薄々気づいているはずで、でも結局どうしたらよいかわからず放っておいてしまいがちなポイントである。
以下では、巻末特集の、また先日のXHTML+CSS集中講座(XHTML編)のアナザートラックとして、XHTMLの最適化手法を考えてみたい。
div/span要素を少なくする
div/span要素は固有の意味/役割をもたない無色透明な存在だ。そのニュートラルさゆえ、純粋なスタイルコンテナ(style container)として利用することができ、われわれも実際にCSSレイアウトでその恩恵に浴している。
しかし、div/span要素は構造的には不要な存在であることに変わりはない。次の2つのマークアップ例でいえば、グローバルナビゲーションを定義するのに、必ずしもdiv要素でul要素をラップする必要はなく、ul要素に直接idをつけたほうがよいわけだ。
[悪い例]
<div id="globalnav">
<ul>
<li><a href="...">項目1</a></li>
<li><a href="...">項目2</a></li>
<li><a href="...">項目3</a></li>
</ul>
</div>
[よい例]
<ul id="globalnav">
<li><a href="...">項目1</a></li>
<li><a href="...">項目2</a></li>
<li><a href="...">項目3</a></li>
</ul>
もちろん、デザインをちょっと複雑にしたい場合は、div要素でラップする必要があるかもしれない。しかし、不要なdiv要素はないに越したことはない、という意識が大切だ。
別のケースを考えてみよう。(X)HTMLとアフォーダンスで「div要素の直下にテキストやインライン要素を含めるのは正しくない(書式上は認められていても)」と書いた。次の2つのマークアップ例を見てみると、div要素という役割のない要素でマークアップせず、シンプルにp要素でマークアップしたほうがよい。
[悪い例]
div#navskip { display: none; }
:
:
<div id="navskip">
<a href="#maincontent">ナビゲーションをスキップする</a>
</div>
[よい例]
p#navskip { display: none; }
:
:
<p id="navskip">
<a href="#maincontent">ナビゲーションをスキップする</a>
</p>
一方、span要素はdiv要素ほど複雑ではない。まず意味的なインライン要素(em/strong要素など)でマークアップできないかどうか考え、どうしてもできない場合にだけspan要素を使う、というのが大原則である。
id/classを少なくする
id/classはdiv/span要素と組み合わせてスタイル適用のためのトリガーとして使う(スクリプトの参照先などにも利用するが、ここではひとまず置いておく)。id/classも少ないに越したことはない。
これは特に、効率的なCSS設計と関係する。id/classセレクタではなく子孫セレクタが利用できないか考えるのが、CSSの効率化に不可欠だからだ。なぜならid/classづけはCSSだけで完結する作業ではなく、XHTMLでid/class属性を追加・修正するという手間が発生するからである。
作業効率を考えると、CSSだけで作業が完結する子孫セレクタを利用したほうがよい。何よりXHTMLがクリーンになるというメリットもある。
次の2つの例を見てみよう。li要素にスタイルを適用する場合、classセレクタを利用するとli要素ひとつひとつにclass属性をつけなければならないが、子孫セレクタを使えばXHTML側での追加的な作業は全く必要ない。
[悪い例]
li.items { display: inline; ... }
:
:
<ul id="globalnav">
<li class="items"><a href="...">項目1</a></li>
<li class="items"><a href="...">項目2</a></li>
<li class="items"><a href="...">項目3</a></li>
</ul>
[よい例]
ul#globalnav li { display: inline; ... }
:
:
<ul id="globalnav">
<li><a href="...">項目1</a></li>
<li><a href="...">項目2</a></li>
<li><a href="...">項目3</a></li>
</ul>
ここで、「li.items」よりも「ul#globalnav li」のほうが長く、CSSのファイルサイズが大きくなってしまうと思う人もいるかもしれない。確かにそのとおりだが、何十何百とあるXHTMLのファイルサイズが小さくなることを考えれば、おそらくは取るに足らないぐらいのことである。
このような子孫セレクタの積極利用は、スケルトンの各部位(ページ内の主要パーツ)にidづけしておくことが前提だ。もちろん、そのidも少ないほうがよいが、これもトータルバランスで考えるべきである。スケルトンの各部位にidづけしておくことで、無駄なid/classの発生を結果的に防ぐことができるのだから、そのメリットを生かさない手はないだろう。
子孫セレクタには次のようなメリットもある。
- 子孫セレクタは個別性(specificity)がおのずと高くなる。たとえば「
li.items」は11ポイント、「ul#globalnav li」は102ポイントである。個別性は高ければよいというわけではないが、スタイルがバッティングした場合でも優先的に適用されることで、作業時の混乱/困惑を防げる。 - 子孫セレクタはXHTMLのツリー構造を頼りにするが、このことが制作者におのずとツリー構造を意識させるので、XHTMLのさらなる最適化を促す。
ちなみに、子セレクタも利用できればよいのだが、よく知られているようにWin IEが対応していないので仕方がない。
Strictな要素/属性であっても、視覚表現に関するものは使わない
文書構造と視覚表現の厳密な分離には、XHTML 1.0 Strict(またはXHTML 1.1)を採用し、そのボキャブラリの範囲でマークアップするのが基本だが、それだけでよいというわけではない。
まずマークアップの使い方の問題がある。最近ではほとんど見かけなくなったが、たとえばblockquote要素をインデント目的で使うのは書式上のエラーではなく使い方のエラーである。このへんはやはり(少なくとも現時点では)マシンには解析できない点であり、人間による適切な判断が必要とされる部分である。
当然、テーブルレイアウトの問題も絡んでくる。XHTML+CSSだがテーブルレイアウトを採用しているケース、つまり「ハイブリッドレイアウト」も書式上のエラーではなく使い方のエラーである。決められたボキャブラリと書式を守っていても、使い方が間違っていることになる。
次の問題は、XHTML 1.0 Strict(またはXHTML 1.1)で認められているボキャブラリのなかにも、まだ視覚表現に関する要素/属性が残されていることだ。具体的には次の要素/属性が該当する。
b、i、big、small、ttの各要素table要素のwidth、border、frame、rules、cellspacing、cellpaddingの各属性th/td要素のalign、valignの各属性
モダンブラウザで、これらの要素/属性を使わないことで支障が出るケースはほぼない。あるいは、ちょっとしたハックで対応可能だろう。XHTML 2.0草案(2005年5月27日改訂版)では、これらの要素/属性はすべて廃止されている。
なお、XHTML 1.1(また、その前提となるModularization of XHTML)では、b、i、big、small、ttに加えて、hr、sup、subの各要素がプレゼンテーションモジュール(Presentation Module)に分類されているが、これら3つの要素は構造的な意味を備えるため、使用しても問題ないだろう。
実際に、XHTML 2.0草案でも、hr要素は構造モジュール(Structural Module)のseparator要素として生まれ変わり、sup要素とsub要素はテキストモジュール(Text Module)に分類しなおされている。
まとめ
以上の説明は、ページ内のテキスト/パーツそれぞれに正しい役割が割り当てられているのが前提だ。それこそ何でもかんでもdiv要素でマークアップしているようなページは取り入れられる段階になく、まず正しいマークアップにリビルドしなければならない。
その次にスタイルの適用のためにdiv/span要素、id/classを利用し、最後にここで説明したような最適化を図る、というステップになるだろう。
余談: ベストプラクティスとマークアップルール
正しいマークアップというのは意外と難しい。シチュエーションによっては正解(ベストプラクティス)が2つも3つも存在するからだ。たとえばリストに見出しをつける方法で示したいくつかのプラクティスは、すべて正解といえる。
チームで作業をする際、複数のベストプラクティスが存在することでコンフリクトが生じる場合は、きちんとマークアップルールを決めておいたほうがよい。内部的なガイドラインでもよいし、制作仕様書に落とし込んでもよいだろう。
このへんはマークアップの人間臭さとでもいうべきもので、株主総会の想定問答集ではないが、コンフリクトが生じる(過去に生じた)シチュエーションについてはあらかじめルールを決めておく。一度決めてしまえば、ブラッシュアップはたびたび必要ながらも使い回しできる。
WCAGやWebコンテンツJISはアクセシビリティ基準であると同時に、ベストプラクティスを示している最良の資料だ。特にWCAGの下位資料であるHTML Tequniquesは大いに示唆に富んでいる。
拙著 『Web標準の教科書』 第2章ではXHTMLのマークアップ方法をトータルで説明しているが、ベストプラクティスに関してはところどころWCAGその他を引き合いに出している。(X)HTMLの仕様はいずれも、ベストプラクティスへの踏み込みが十分ではないからだ(そこまでの役割を果たすことが目的ではないという理由もあるだろう)。
それでもなお、ベストプラクティスについて意見の対立は生じる。だからこそ、企業や自治体は一般に認められたアクセシビリティ基準をもとに、富士通 ウェブ・アクセシビリティ指針や神奈川県 情報バリアフリーガイドラインといった独自のガイドラインを策定するわけだ。
したがって、繰り返しになるが、チーム内のベストプラクティスに関するコンフリクトを防ぐためにも、あらかじめマークアップルールを決めておいたほうがよい。加えて、上述したようなXHTMLの最適化手法や効率的なCSS設計も知識として共有し、ルール化しておきたいところである。
2005-12-07T15:11+09:00 | Web標準 | 固定リンク | コメント (0) | トラックバック (3)
個人もRSS配信の時代
ちょっと大げさなタイトルをつけてしまいましたが、本日よりオフィシャルな活動内容のRSS配信をスタートしました。RSS 2.0形式です。
- 益子貴寛の活動内容 (RSS 2.0)
- http://www.cybergarden.net/about/activities.xml
それ専用のブログを作ってもよいのですが、本ブログと内容がかぶるし、さっさとXMLを書いてXSLTで変換してビジュアライズしてしまったほうが早いので。
大いに備忘録という意味合いもあるんですけど。「過去の雑誌記事をトレースしたいんですけど」「最近どんな記事を書きましたか」というご質問がたまにあるので、そういう方にも役立つと思います。
2005-12-06T19:00+09:00 | Webトレンド | 固定リンク | コメント (0) | トラックバック (0)
(X)HTMLとアフォーダンス
アフォーダンス(affordance)は「物体が備える性質(形、色、材質など)が、物体自体をどう取り扱ったらよいかというメッセージをユーザーに対して発している(アフォードしている)」とする考え。
江島健太郎さんがXMLとアフォーダンスという記事を書かれているが、少し話の幅が広いので、ここでは(X)HTMLによるマークアップに絞って考えてみたい。
マークアップのアフォーダンス
たとえばb要素とstrong要素のどちらがよりアフォーダンスな存在か。b要素は「太字で扱ってくれ」と、strong要素は「強調として扱ってくれ」とアフォードするので同じだろう、というのは間違い。
strong要素には「他のテキストとの比較の上で」という文脈的なアフォーダンスが含まれるが、b要素にはない。したがって、strong要素のほうがアフォーダンスな存在である。さらにいえば、strong要素はem要素との比較というアフォーダンスも含まれる。
次にdiv要素について考えてみよう。個人的にはdiv要素の直下にテキストやインライン要素を含めるのは正しくない(書式上は認められていても)と思っているが、それはdiv要素が特定の役割をもたない透明な存在だからだ。これをアフォーダンスというキーワードを通して考えるとわかりやすい。
div要素は範囲をアフォードするが、ただそれだけであり、役割はアフォードしない。一方、h1~h6要素、p要素、ul要素、ol要素、dl要素、table要素、address要素などは範囲だけでなく役割もアフォードする。body要素内に存在するものはすべて(意味的なブロックレベル要素によって)役割が与えられているべきである。div要素の直下にテキストやインライン要素を含めてしまうと、それらは役割のない「宙ぶらりん」な存在になってしまう。
ボキャブラリの問題
もちろん、現在の(X)HTMLのボキャブラリは数が少なく、アフォードさせたい役割を与えるのが困難なケースが多々ある。そこで、消去法としてのp要素、つまりパラグラフという積極的な役割を与えるというよりは、意味的なブロックレベル要素のなかで最も汎用的なp要素でマークアップする方法が使われる。XHTMLでは名前空間やスキーマ、プロファイルを利用してボキャブラリを拡張できるが、ちょっと敷居が高いかもしれない。
XHTML 2.0(現在、草案)ではかなりボキャブラリが拡張される予定だ。しかし、HTML 5とも呼ばれるWeb Applications 1.0では、これまでの(X)HTMLも、またXHTML 2.0も、結局は文書コンテンツしか想定しておらず、非文書コンテンツ(non-document types of content)に関するボキャブラが著しく欠けているとして、さらなる拡張が提案されている。
このようなボキャブラリの拡張によって混乱が生まれるという意見もあるだろう。往年のブラウザベンダーの独自拡張を思い出す人もいるかもしれない。しかし、消去法としてのp要素や、div/span要素とid/classをレバレッジにしたボキャブラリの擬似拡張を、果たしてこのまま放っておいてよいのかという問題もある。
再び、アフォーダンス
アフォーダンスは行為を引き起こす刺激ではなく、行為によって探した結果わかるものである。ul要素があるからリストを作るのではなく、リストを作りたいと思ってボキャブラリのなかを探したらul要素があった、これがアフォーダンスだ。
ボキャブラリは人々のアフォーダンスを支える。現在の(X)HTMLがユーザー、制作者、開発者のアフォーダンスを支えきれていないとすれば、ボキャブラリを拡張したほうがよい。
視覚表現についてはCSSというボキャブラリがあり、CSS3ではモジュール化と相まって大幅な拡張がなされている。また、動的処理・操作の面ではDOMもAJAXもある。
構造面はどうか。私はXHTML 2.0を好意的に見てはいるが、人々のアフォーダンスを支えるにはボキャブラリが足りないと思う。上述したWeb Applications 1.0のXHTML 2.0に対する批判は、少なからぬ人々のニーズを反映したものだ。
これまでマークアップ言語は拡張と収斂を繰り返して発展してきた。制作者と開発者はその混乱に付き合わされてきたし、再度混乱が起こることを危惧する人もいるだろう。しかし、モジュール化という仕様設計が可能になり、そもそもWebのメディアとしての役割がここまで拡大しているのだから、旧来の枠組みでマークアップ言語のあり方を考えるのはやや時代錯誤な気がする。
アフォーダンスとリーダビリティ
ここで冒頭の例に戻ろう。ある人はstrong要素よりもb要素のほうがアフォーダンスな存在だと言うかもしれない。b要素は「太字」をアフォードするだけでなく、それこそ強調その他の意味をアフォードするという考えだ。
しかし、それは人間ゆえの類推であって、マシンはそのように類推できない。あるいは、目が見えない人は手触りで確認できない限り、太いか細いかはわからない。つまり、b要素は極めて限定的なリーダビリティしか備えていないわけだ。
マシンによる類推の仕組みはRDFSやOWLによって与えられているが、まだ汎用の段階にはない。また、視覚的に太いか細いか確認できない人はどうするのかという問題は解決できない。つまり、マークアップは「意味」をアフォードしなければならない。
なお、リーダブルあるいはリテラルという観点から見ると、あまりに短すぎる要素名は問題である。「p」よりも「paragraph」のほうが、「em」よりも「emphasis」のほうがリテラルだ。ただし、「em」は2バイトですむのに「emphasis」は8バイトというデータ効率の問題もあるから、何でもかんでもフルスペルで示せばよいというものではない。
また、多くの日本人にとっては、「p」よりも「段落」、「em」よりも「強調」のほうがリテラルだろう。実際に、XMLの初歩的な説明では、要素名に日本語を使っているケースをよく見かける。ただこれも、マシン処理の負荷や、日本語が理解できない人にはリテラルではないという問題がある。
このようにアフォーダンスは多分に状況依存的であり、状況を限定すればより強く、多様な状況を想定すれば弱くならざるをえない。Webはユニバーサルにアクセスできるものだから、自然と英語の使用が前提となり、場合によっては個々のボキャブラリがすべての人にアフォードするわけではないというのは、仕方がないのかもしれない。
2005-12-05T15:19+09:00 | Web標準 | 固定リンク | コメント (0) | トラックバック (0)
講義風景
昨日12月3日(土)は、東京・渋谷でXHTML+CSS集中講座(XHTML編)を開催しました。朝9:30から17:00まで丸一日みっちり。参加者の皆さん、お疲れさまでした。
ガチガチのXHTMLというよりは、
- Web 2.0、ブログ、マシンフレンドリーとXHTML
- 今の時代に求められるSEOとXHTML
- 効率的なCSS設計の前提としてのXHTML
などなど、トレンドとエッセンスを融合させた話ができたと思います。
最後に飛び入り参加&コラボ(!?)していただいた株式会社スイッチの鷹野雅弘さんに写真を撮っていただきましたので、ぺタッと貼りつけます。
![鷹野さん、Thanks!! [写真: 2005年12月3日 東京・渋谷 XHTML+CSS集中講座、撮影: 鷹野雅弘さん]](/blog/images2/lecture_scene.jpg)
追記 (2005-12-04)
XHTML+CSS集中講座(CSS編)は12月18日(日)の開催です。
まだ少し空きがあるようですので、CSSレイアウトの引き出しを増やしたい方、脱テーブル手法を身につけたい方は、この機会にぜひご参加ください(1:25)。
2005-12-04T15:25+09:00 | 話し仕事 | 固定リンク | コメント (0) | トラックバック (0)
あるいはありがちな悩み
茶髪にし続けるかどうか悩み中。茶髪にしたからといって生えてくる髪が茶色になるわけではないという当たり前の現実に直面して愕然。現在、もれなくプリン状態。カラメル、激しく増量中。
各方面から長崎皿うどんとか陸サーファーという褒め言葉をいただくにつけ何とか茶髪を続けようと考えるがそもそも自分のヘアスタイルなんてまあどうでもいいやと思う人間にとっては無理から著しくテンションを上げて美容室に行かなければならないという義務感が先に立って結局ほったらかしの投げっぱなしのロストコントロールで早4ヶ月。
そうこうしているうちに僕の髪が肩まで伸びて君と同じになって、「プリン」、「皿うどん」、そして「落ち武者」の和洋中三冠達成目前。何とか決断を下さなければ。
ごちゃごちゃ言ってないでさっさと行け、という話ではある。
...と、数日前にブログエントリー用にメモしたのだが、今日やっと美容室に行って髪を切って茶色に染めなおした(mixiの日記とネタがかぶってしまって申し訳ないです)。
2005-12-02T23:07+09:00 | 身辺雑記 | 固定リンク | コメント (0) | トラックバック (0)
Firefox 1.5と「outline」
Firefox 1.5ではoutline関連プロパティがサポートされたが、CSSで画像置換(image replacement、画像の代替表現)のテクニックを使っている場合、ちょっと注意が必要。
次のスクリーンショットを見てほしい。
![[スクリーンショット: Firefox 1.5の画面。outline関連プロパティがサポートされた影響で、タイトルロゴの左側に不自然な点線が表示されている]](/blog/images2/firefox15-outline.png)
タイトルロゴの左側に不自然な点線が表示されている。これはoutline関連プロパティのサポートの影響だ。text-indentプロパティでテキストを非表示化していて、そのテキストにリンク(a要素)を設定している場合、フォーカス時に点線が発生する。
この点線を発生させないためには、outline-widthプロパティまたはoutlineプロパティ(ショートハンド)で値に「0」と指定しておく。
div#header a {
display: block;
width: 717px;
height: 50px;
text-decoration: none;
outline-width: 0;
}
なお、outline関連プロパティの値は継承されないので、このようにa要素にダイレクトに指定する必要がある。
2005-12-01T20:43+09:00 | Webトレンド | 固定リンク | コメント (0) | トラックバック (0)
経県値&経県マップ
自分が47都道府県とどのぐらい深く関わってきたか。
それをマップ表示してくれるのが経県値&経県マップ。
私はまだ行ったことのない県がたくさんある。
四国か北陸にでも旅に出てみようかな。
2005-12-01T13:05+09:00 | 注目サイト/ソフト | 固定リンク | コメント (0) | トラックバック (1)
池袋占い
我ガ青春ノ街、池袋。週末はいつも「ロマンス通りのゲートを抜けると、そこはロサ会館であった」。学生時代も、そして今でも池袋によく行く。というか学生のときからずっと豊島区民ですから。
私を今もって豊島区に縛りつける要因のひとつに池袋がある。そんな人後に落ちないブクラーだけに、相応の覚悟をもって池袋占いをやってみた。
あなたは東京芸術劇場です!
喜ぶべきか悲しむべきか。周りから浮いているということか。
* * *
数日前、何の情報番組か忘れてしまったが、今日の星座占いか何かで「ハッピーアイテムは馬の手綱です」といわれて思いっきりズッコケた。うちに馬いませんから。
2005-12-01T00:53+09:00 | 注目サイト/ソフト | 固定リンク | コメント (0) | トラックバック (1)
![[写真: ゆでタラバ 全体]](/blog/images2/crabs/taraba_kani1.jpg)
![[写真: ゆでタラバ 殻をむいた脚]](/blog/images2/crabs/taraba_kani2.jpg)
![[写真: タラバガニラーメン 全体]](/blog/images2/crabs/taraba_kani_ramen1.jpg)
![[写真: タラバガニラーメン 麺と一緒にカニの身をほおばる]](/blog/images2/crabs/taraba_kani_ramen2.jpg)
![[写真: ズワイガニ鍋 全体]](/blog/images2/crabs/zuwai_kani_nabe.jpg)
![[写真: ズワイガニ鍋 雑炊]](/blog/images2/crabs/zuwai_kani_nabe_zousui.jpg)
![[写真: タラバガニ脚 冷凍状態]](/blog/images2/crabs/taraba_legs1.jpg)
![[写真: ゆでタラバガニ脚 全体]](/blog/images2/crabs/taraba_legs2.jpg)
![[写真: ゆでタラバガニ脚 殻をむいた脚]](/blog/images2/crabs/taraba_legs3.jpg)
![[写真: 海鮮丼 全体]](/blog/images2/crabs/kaisendon1.jpg)
![[写真: 海鮮丼 ウニ]](/blog/images2/crabs/kaisendon_uni.jpg)
![[写真: 海鮮丼 イクラ]](/blog/images2/crabs/kaisendon_ikura.jpg)
![[写真: 「たらばかにカレー」 パッケージ]](/blog/images2/crabs/kingcrabcurry1.jpg)
![[写真: 「たらばかにカレー」 全体]](/blog/images2/crabs/kingcrabcurry2.jpg)
![[写真: 「たらばかにカレー」 カニ]](/blog/images2/crabs/kingcrabcurry3.jpg)