クラスは束になってもIDに勝てない

CSSの詳細度について僕がしていた勘違い。それは、「クラスも10個以上になればIDに勝てる」という思いこみです。ほかにもそういう風に思っている方がいらっしゃるかもしれません。

CSS2の仕様書の詳細度の算出例をみると次のように書かれています。

*             {}  /* a=0 b=0 c=0 -> specificity =   0 */
LI            {}  /* a=0 b=0 c=1 -> specificity =   1 */
UL LI         {}  /* a=0 b=0 c=2 -> specificity =   2 */
UL OL+LI      {}  /* a=0 b=0 c=3 -> specificity =   3 */
H1 + *[REL=up]{}  /* a=0 b=1 c=1 -> specificity =  11 */
UL OL LI.red  {}  /* a=0 b=1 c=3 -> specificity =  13 */ 
LI.red.level  {}  /* a=0 b=2 c=1 -> specificity =  21 */
#x34y         {}  /* a=1 b=0 c=0 -> specificity = 100 */ 

導き出されたspecificityの値をみると、21や100といったようになっているので、IDはひとつ100点、それ以外の属性や擬似クラスはひとつ10点、要素名はひとつ1点という具合に考えてしまって、単純にそれらの値を足し算すれば良いものかと思っていました。

ただこれですと、「クラスが10個集まったら10*10=100だからIDひとつと並ぶのか」、「11個のクラスならひとつのIDに勝てるのか」といったように考えてしまいがちです。

実際には、クラスは所詮クラスということで、いくら束になったところでIDひとつに勝てません。同様に、いくら要素名を書き連ねたところで、それはクラスひとつに勝てません。

よく使われる「詳細度=a*100+b*10+c*1」といった計算式が成り立つのは、あくまでそれぞれの数が10未満の場合というわけです。

CSS2.1では詳細度の算出例が次のように変わっていました。

 *             {}  /* a=0 b=0 c=0 d=0 -> specificity = 0,0,0,0 */
 li            {}  /* a=0 b=0 c=0 d=1 -> specificity = 0,0,0,1 */
 li:first-line {}  /* a=0 b=0 c=0 d=2 -> specificity = 0,0,0,2 */
 ul li         {}  /* a=0 b=0 c=0 d=2 -> specificity = 0,0,0,2 */
 ul ol+li      {}  /* a=0 b=0 c=0 d=3 -> specificity = 0,0,0,3 */
 h1 + *[rel=up]{}  /* a=0 b=0 c=1 d=1 -> specificity = 0,0,1,1 */
 ul ol li.red  {}  /* a=0 b=0 c=1 d=3 -> specificity = 0,0,1,3 */
 li.red.level  {}  /* a=0 b=0 c=2 d=1 -> specificity = 0,0,2,1 */
 #x34y         {}  /* a=0 b=1 c=0 d=0 -> specificity = 0,1,0,0 */
 style=""          /* a=1 b=0 c=0 d=0 -> specificity = 1,0,0,0 */

aの部分をstyle属性が使っているので、アルファベットが合計4つになったほか、算出された詳細度が「0,1,0,0」といったように、なにやら「,（カンマ）」で区切られています。もしかすると先のような誤解を生まないよう配慮しているのかもしれません。ただ、こうして数字を区切ってしまうと、そもそも四つを連結して並べる必要性がよくわからないし、その値もちょっと意味不明な感じになってしまっています。

詳細度は、点数にして覚えるよりも、優先順位をつける流れをしっかり頭にたたき込んでおくほうがわかりやすい気がします。例えばCSS2.1ならば次のような具合です。

1. まずstyle属性が最優先
2. 次にセレクタ内のIDセレクタの合計が多い方を優先
3. IDセレクタの数が同じなら、クラスセレクタ、属性セレクタ、擬似クラスの合計が多い方を優先
4. それも数が同じならば、要素セレクタ、擬似要素の合計が多い方を優先
5. さらにそれも数が同じならば、詳細度による順位付けはあきらめて、宣言の位置によって優先するほうを決定

これならば「クラスが10個集まったら・・・」なんて発想をそもそもしなくて済みます。

それからCSSの仕様書で、アルファベットをa-b-cといったように横に並べて十進数に見立てる意図は一体何なのでしょうか。そのせいで随分とややこしくなっている気がします。

社内勉強会

定期的に行っている社内勉強会。今日は「CSSのカスケード処理」と題して3回目の発表をさせてもらいました。

プレゼンはおおむね無事に済んで安心していたのですが、気づくとなにやら胃が痛い。

どうやら緊張のために胃酸がたくさん放出され、自分の胃壁を溶かしてしまったようなのです。でも発表したことで自分が勘違いしていた間違いにも気づけたので、その代償ということで納得しています。

テキストの上に生まれる余白

例えば（唐突）、とある段落の行送りを18pxに、そのフォントサイズを12pxに設定したデザインがあったとします。これをCSSで設定する場合、おおよそ次のように書くことになると思います。

p {
font-size: 12px;
line-height: 1.5;
}

CSSの仕様上、テキストは行ボックスの垂直方向に対して中央に位置することになります。つまり上の場合、行ボックスの高さが18pxとなり、ここからフォントサイズの12pxを引いた6pxを、文字の上下で分け合うようなかたちになります。

そして何かのCSSを書くたびに、これを厄介に思っているのです。だって、デザイン的には開始行の文字の上辺と、その横の写真などの上辺を水平に揃えたいことが多いから。

上の例だと、段落の上方向に余分な3pxの空白ができてしまい、段落の開始行の位置が少し下がってしまいます。

この誤差をなくして、なるだけ正確にデザインカンプの表示を再現しようと思うと、面倒な計算が必要となり、スタイルの指定が難しくなっていくのです。

なにかスマートな解決策がないか、ずっと模索中。

CSS Layout 達人的階梯

CSS Layout 達人的階梯

以前書いた本「スタイルシート上級レイアウト」の中国語版が発売されるようです。その名も「CSS Layout 達人的階梯」—。

今日手元に届いた本を眺めていたのですが、サンプルデザインのなかにある日本語まで、すべて中国語（たぶん台湾語？）に翻訳されるという徹底ぷり。元のデザインデータを渡したわけではないので、大変な手間だったのではないかと思います。

ウェブスタンダードは「網頁標準規格」、テーブルレイアウトは「表格式設計」と記されていました。

CSS本の紹介でFlash

突っ込まれそうとは思いつつ、CSS本の紹介ページにFlashを使っていて、やはり「なんでFlashなの？」っといった意見をいくつか頂いています。

ただFlashって、CSSと相反するものでもないということでご勘弁ください。例えばCSSでタイポグラフィを施さず、画像化文字（GIFなど）に表現を委ねるといった手法と、程度の差こそあれ根本的には同じことだと思います。

ワンランク上を目指す CSSクリエイティブ・デザイン

「ワンランク上を目指す CSSクリエイティブ・デザイン」という本を書きました。技術評論社から7月25日発売ですので、近いうち本屋さんにも並び始めるかと思います。

内容を簡単に紹介しますと、デザインとコードの関係性をテーマに、より効果的にCSSを実装するためのヒントやアイディアを合計7つのサンプルとともに学べる本です。ビジュアルデザインの知識や、JavaScriptを組み合わせた動的なページの作成など、CSS以外のポイントにも焦点を当てています。特に後半は、僕が仕事で関わった実際の案件を扱うことで、より現実に即した、実戦的な内容となっています。

詳細な目次などが一覧できるページを用意したので、興味をもたれた方は以下をご覧になってみてください。
「ワンランク上を目指す CSSクリエイティブ・デザイン」のご紹介

#この本の企画が決まったのが去年の夏でしたから、およそ1年近くも書いていたことになります。当初はもうすこし早く発売される見込みだったのですが、途中僕の進捗が芳しくない時期があったりして、なんだかんだで遅れてしまいました。編集者の方をはじめとした関係者の方々にはご苦労をおかけしました。この場を借りて深謝申し上げます。

「両方がh1」というのはh1要素が複数という意味

またまた見出しの話ですが、「最近見かける「見出し」関係の話題へのリアクション」より言及を頂きました。

<h1>omega</h1>...<h1>見出しレベル</h1>...という事でしょうか？　それとも、<h1>omega　見出しレベル</h1>...という事でしょうか？　前者の場合、それは二つの内容が一つの文書に同居している、という事になるんじゃないでしょうか。だったら文書を二つに分ければ良い話。で、後者の場合、ああこういう大見出しなんだな、と思うだけです。

僕が両方をh1にと書いたのは、要素自体を複数にするという意味のほうです。また、二つの内容が一つの文書に同居の「内容」というのが何を示すかわからなかったのですが、並列な関係の情報がふたつあるとか、そういうことではなくて、異なるレイヤーの情報が重なってひとつを成しているイメージです。これを二つに分けてしまうと、誰がその情報を伝えているのかが即座にわからないなど、ページの文脈がどう伝わるかに影響するので、そう簡単に分けられない（分けたくない）のです。仮に分けるとすれば、マークアップ以前のフローから変えて行かなくてはならず、かなり大袈裟というか本末転倒です。そもそも、こういう前提があるからこそ、h1をどうするかみたいな話がときおり浮上するのではないでしょうか。

例で挙げられている「omega」というのが何なのか最初わからなかったのですが、おそらくサイト名のような感じかと思いました。前のエントリーでも触れたように、そのページにサイト名や、カテゴリ名といった分類情報がそもそもなかったり、少なくとも明らかに見出しではない登場の仕方だったら、割り切れるのです。ですが現実的には、それらの情報をhead要素内に記述しとけばいいじゃん、といった選択肢は採用しづらいものです。

僕は、h1が複数あるのはありだと思っています。本文の領域以外にh2要素などを振り分けること、例えばローカルナビゲーションのカテゴリ名にh2やh3を振り分けるのと、やっていることに大差ないと思うからです。そして、これらも文書を複数に分けるとすると、やはりマークアップ以前の話になります。

見出しレベルに絶対的な正解は考えづらいので、回り巡ってたどりつくところは結局、「同サイト内でその考え方に一貫性を保つことのほうにこそ重点を置いていきたい」というものです。

このブログの見出し

「はてなブックマーク - カラクリエイト：何をもって「重要」とするか」で、このブログ自体の見出しレベルについて、コメントをいただきました。

たしかに、このブログの場合、「カラクリエイト」というサイト名じゃなくて、本文の見出しでもなくて、「最新エントリー」だとか「カテゴリー」といった分類にh1を割り当てています。変な感じはしますが、これはこれで別にいいんです。サイト名をh1にしたって、視点を変えたらやはり気持ち悪いことに変わりないので。

だから普段仕事でサイトを組む時には、少なくとも同サイト内で見出しレベルの考え方に一貫性を保つことのほうに重点を置いて、振り分けを考えています。

それから、もしこのブログの見出しレベルを変更するとしたら、HTMLだけ修正するのではなくて、そもそもの構造をもう一度見直し、デザインと一緒に変えようと思います。（2年以上デザインがこのままだし、茶坊主をFlashで四方八方に歩かせるという試みも放置されて久しいので・・・）

何をもって「重要」とするか

「h1要素は最も重要な見出し」というのは、その通りだと思うのですが、じゃあ何をもって「重要」とするんだろう、ってところで、僕の場合やっぱりぶつかります。「そのページで最も伝えたいこと」だから「重要」とするのか、「構造上抜け落ちてはならない」から「重要」とするのかなど。本文内容の見出しがh1でないのも気持ち悪いけど、サイト名がh1でないのも、見出し構造の頭をどこかにもっていかれちゃった気がしてこれまた違和感を抱いたり（サイト名が文書の頭にないのであれば、もう割り切れるのですが）。どうも、同じレイヤーでは比べられないですね。

ビジュアルデザインにおける構造の捉え方(※)とも、ある程度整合性をとっていきたかったりもするので、お仕事では「僕はこれでいく！！」といった答えを求めてしまうよりは、状況に応じてやり方を調整するようにしています。

あと、視点にどこに置くかによってどちらも一番重要な見出しとなり得るので、サイト名と本文エリア内の見出しの両方をh1にすることもあります。

※このあたりの話はサイト名に限らずカテゴリ名なんかでも当てはまります。例えばこんな見出し。

あきらかに、そのページを作成する意味だとか、伝えたいことの重要さでは「CSS Nite LP3を終えて」という見出しのほうが上なんだけど・・・

LP3で使用したコーディングデータ

CSS Nite LP, Disk 3で使用したコーディングデータを以下にアップしました。

HappyLifeCompany
HappyLifeマシン｜製品情報｜HappyLifeCompany

一式ダウンロード（ZIP）

Liveコーディング時に補足できなかった点だけ書いておきます。

ディレクトリ

/shared/に画像、CSS、JSファイルなどまとめて格納しています。さらに背景に指定する画像については、/shared/img/bg/に格納し、img要素の画像と区別して管理しています。

画像はカテゴリごとに別途ディレクトリを作成して管理することが多いのですが（例えば「製品情報」で使う画像だったら/products/img/といったように）、今回はどの画像をどのカテゴリで使い回すか、デザインの2枚だけでは判断しにくかったので、とりあえずひとつにまとめておきました。

clear.css

clear.cssはいつも作るわけではないのです。今回デザインを見て、段組風のデザインが多そうだなと思ったので、煩雑にならないよう別ファイルにまとめてみました。

それと、セレクタを随時追加していくのではなく、場合によっては<div class="section01 clearfix">といったように、一定のクラスを付与して回り込みの解除を行う場合もあります。これは例えば、汎用的に使われるsection01のボックスの最後で、毎回必ずしも回り込みの解除を行っても良いとは限らなかったりするためです。

フォーム

コンテストでは定義リストの方が多かったのですが、僕はレイアウトしやすさも考慮してテーブルを使ってマークアップしておきました。あと、デザイン上右側にあるはずの「（全角カタカナ）」とかのテキストはひとまず削除しました。位置が良くないのと、全角/半角などはサーバー側で変換してあげられる範囲のことも多いので、作業する前に要確認ということにしときます。

見出しレベル

「製品情報」のほうは、「HappyLifeマシン」のページだと思われるので、ここをh1としたい気もするのですが、その前にカテゴリ名である「製品情報」という見出しもあるわけで。そもそもページの情報構成が妙なんですよね。そのため、ページを量産する段階で破綻しないよう、どのページも常にサイト名から順に見出しレベルを振り分ける想定にしています。

HTMLのコメント（2007/5/17追記）

終了タグの直前に入れるルールにしています。実はこれまで、人になんと言われようと終了タグの直後に入れるポリシー（要素の終了を示すという感覚）を頑なに守り続けていたのです。ですが、IE7のセレクタのバグに遭遇するというのが最近発覚したため、今後のことを考えてやむなく内側に入れるという方針に変更したのが今回からです。

そのほか、もっと書くべきポイントがある気もしますが、思いついたらまた追加いたします。ひとまずデータ公開までに。

CSS Nite LP, Disk 3を終えて

CSS Nite LP, Disk 3でLiveコーディングをやってきました。

お客さん300人＋両脇にはbAのお二方というありえない状況下のLiveで極度の緊張状態での作業となりましたが、小久保さんと太田さんに的確な解説をいれていただけたこと、頭は回らなくても手が勝手に動いてくれたことが救いでした。

写真掲載しておきます。この必至さが伝わるでしょうか。

［撮影：岡田陽一］

また前半でLiveをされた神森さんとは同じツールを使いながらも制作過程が対照的だったようで、良い比較になったのでは、と思います。

あとフォントサイズは大きくしたつもりでしたが、遠くに座られた方は見えづらかったようですね。あとマイクの音量も。配慮が至らず申し訳なかったです。

CSS Nite LP, Disk 3

CSS Nite LP, Disk 3 "Coder's High" 開催要項

2007年5月12日（土）に「CSS Nite LP, Disk 3」というイベントが開催されます。このイベントに「LIVEコーディング」というかたちで僕も参加させて頂くことになりました。

リアルタイムに人前でコードを書くなんて、滝汗かいて手がぶるぶる震えている自分が想像できますが、しっかり役目は努めさせて頂きます。

参加予定の皆さま、どうぞよろしくお願いいたします。

すぐに使えるCSSデザインテクニック第8回と第9回

しばらくお知らせをサボっていましたが、web creators連載第8回と9回がとっくに発売しています。

第8回はPNGのアルファチャンネルや、ボックスの透明度指定といったあたりがテーマです。GIFでは不可能なことをなんとかデザインに落とし込まねばならなかったため、なんかすごいことになってしまいました。PNGの透過処理は便利とはいえ、使わねばならないとなるとかえって難しかったりします。

9回はテキストに関するプロパティをテーマとしています。テキストはフォント環境しかり、OSやブラウザによる表示の差異が大きいので、サンプル制作にはなかなか苦労させられました。

すぐに使えるCSSデザインテクニック第7回

web creators連載第7回が出てます。これを作っていた頃が秋だったので、デザインに季節感が反映されたのか、なんとなく侘びしい感じです。

記事では最大幅・最小幅を設定した可変レイアウトについて、メリットや注意点を踏まえて解説しています。

すぐに使えるCSSデザインテクニック第6回

おそくなりましたが、web creators連載第6回が出てます。サンプルは今までのものの中で一番普通っぽい感じのデザイン。

記事では、同じ情報のブロックを複数並べる際のfloatを使った効率化や、ボックス同士の下辺ラインを擬似的に揃えるテクニックなどを、たっぷりの図解入りで解説しています。

CSS Zen Garden Book

毎日コミュニケーションズから出版された「CSS Zen Garden Book」を読了しました。2005年に出版された「The Zen of CSS Design」の邦訳版です。僕の投稿した作品「Japanese Garden」もChapter4「イメージの作成と配置」で画像フォーマットについて学ぶ題材として取り上げられています。もともと原著のほうを持ってはいましたが、英語が不得手なために満足に内容を理解できてはいませんでした。今回邦訳版が出版されたおかげで、ようやく自分の作品だけでなく、その他の素晴らしい作品の数々がどのように紹介、解説されているのかを知ることが出来ました。関係者の方々には本当に感謝です。

日本語で内容を読み、あらためて思ったのは、本書はCSSの技術そのものに着目しているだけではなく、ひとつのデザインが完成するまでに隠されている思考のプロセスにこそ、多くの焦点が当てられてた本だということです（だからCSSの入門書だと思って買うと肩透かしを食らうかもしれません）。CSSはプレゼンテーションのための技術であるにも関わらず、そのベースとなる視覚的なデザインの解説にも力を入れた解説書というのはあまり見かけないように思います。ブラウザ上に再現したいデザインがあって、それをどう構築するかだけを学ぶのではなく、同時にそのデザインにはどのような意図・工夫がなされているのか、この二つをセットで学べる解説書というのはとても貴重です。

Chapter1「ソースを見る」では、Zen Gardenの立ち上げの経緯を知ることが出来ます。Dave Shea氏が、今ではあまりにも有名になっている画像置換（Image Replacement）のテクニックを知る前に作成したZen Gardenのプロトタイプ、デザインに柔軟性を持たせるために、ベースとなるHTMLにどのような工夫が隠されているか、といった記述は知られざる苦労を垣間見られた気がして、とても興味深く読ませていただきました。

Chapter2〜7はZen Gardenに投稿された個々の作品に対して、「デザイン」「レイアウト」「イメージの作成と配置」「タイポグラフィ」「エフェクトの使用」「デザインの再構築」という6つにカテゴリ分けして解説がなされています。最初の「デザイン」の章では、ほとんどCSSのコードは登場せず、デザインの意図やプロセスの解説に特化しています。逆に最後の「デザインの再構築」では、ひとつのデザインが組み立てられるまでの流れをステップ式に解説するなど、章を追うごとに徐々に具体的な技術面の解説も多くなっていきます。

全体を通していえるのは、単に事務的にコードを掲載して、簡単に説明をつけたら終わりというのではなく、そのひとつひとつになぜその方法を用いるかといった深い考察がなされていることです。僕の作品を本に掲載したいとDave Shea氏からメールを頂いたとき、僕は自分の作品に対して簡単なデザインの説明を数行送ったくらいで、技術面の具体的な説明は一切伝えませんでした。著者自らの作品もなかにはありますが、ほとんどは世界中のデザイナーが思い思いに制作した作品です。そのなかのテクニックのひとつひとつを分解し、意図を汲み取り、解説に落とし込んでいった著者の努力には本当に頭が下がる思いです。

多くの人がCSSを学ぶきっかけとなったCSS Zen Gardenが、Web上だけでなく、書籍というメディアでも影響力を発揮していること、さらにはその邦訳版まで登場したことを純粋に嬉しく思っています。実際CSS Zen Gardenというサイトを知らなければ、僕もCSSに取り組んではいなかったかもしれません。本書に掲載されている僕の作品は、Zen Garden処女作であり、同時にフルCSSレイアウト処女作でもあります。自分の作品の前後に掲載されている作品などと比べると、自分のデザインの稚拙さが浮き彫りになって恥ずかしい気持ちもありますが、自分にとってとても思い出深い作品を、多くの素晴らしい作品とともに掲載して頂けたことを、とても誇りに思っています。

すぐに使えるCSSデザインテクニック第5回

第5回のサンプルです。今回はデータテーブル。デザインが質素な割には、組むのに意外と頭を使い苦労しました。

記事では、こうしたよくあるデータテーブルについて、ボーダーの結合・分離モデルといった部分にも着目しながらそのレイアウト方法を解説しています。

すぐに使えるCSSデザインテクニック第4回

第4回のサンプルです。新しく購入したMac Bookの記念すべき最初のお仕事がこれです。奇をてらってヘッダーのあたりが変なかたちをしていますね。

記事では、こうした横並びのナビゲーションについて、そのマークアップの考え方からはじまり、テキストを使った場合と画像を使った場合の、それぞれの具体的な実装方法がまとめられています。

本のレビューを頂きました

kazuさんに、拙作「速習Webテクニック スタイルシート 上級レイアウト」のレビューをいただきました。ありがとうございます。

本書の「上級」という名前についてですが、これは当初、どのレベルからみての「上級」なのか判断しにくいかも、という懸念がありました。ですが、編集者の方と相談させて頂いたうえで、（これを執筆時の頃の）類書との比較を踏まえると、やはり上級のかんむりがあったほうが良いだろうという判断に至りました。

ただ、kazuさんのレビューにもあるように、HTMLやCSSの基礎的な知識さえあれば、そう苦労なく読み進められるよう配慮していますので、初心者の方も含め、より多くの方々に読んでいただけたらと思っています。

コメント欄に僕の年齢について触れられていますが、あらたさんのおっしゃるように、今、僕は24歳、どうやら大厄（人生で最も注意が必要といわれている年）のようです。

すぐに使えるCSSデザインテクニック第3回

連載の第1回、第2回は続けてお花の写真でしたので、今回は建物っぽいやつをセレクトしました。DOMを使い、コンテンツの表示を切り替えるJavaScriptと、それに伴うCSSの書き方を解説しています。

このサンプルは「Web標準の日」のセッションのなかで、JavaScriptの章のサンプルとして紹介したものです。HTMLやCSSの知識を活かしつつ、次はJavaScriptを組み合わせて学んでみたいと考えている方々（僕もそうです）に、特にオススメしておきます。

Web標準の日にお越しいただきありがとうございました

撮影：飯田昌之

少々エントリーを書くのが遅くなりましたが、「Web標準の日」、無事に終了しました。当日は本当にたくさんの方にお越しいただきました（スタッフ等のぞいて498人だそうで）。

Kyosukeさんと僕のセッション名は「すぐに役立つWeb標準テクノロジーの効率化テクニック」。制作業務の効率化に向けて、フロントエンドを構築する3つの中心技術、(X)HTML、CSS、JavaScriptをどのように組み合わせ活用していくのが良いかをテーマにお話させていただきました。

これほど多くの方に向けてプレゼンを行うのははじめてなもので、特に最初の10分間くらいはとても緊張してしまいました。聞きづらい点やわかりづらい点などあったかと思います。それでも、プレゼン終了後に「良かったですよー」とか、「ためになりました」とか声を掛けて頂ける方がいたことを大変うれしく思っています。反省点や今後に向けての課題点は多くありますが、今はとりあえず無事終えられたことにほっと胸をなで下ろしています。

関係者の方々をはじめ、話を聞いてくださった皆さん、本当にありがとうございました。

すぐに使えるCSSデザインテクニック第2回

「すぐに使えるCSSデザインテクニック」の連載サンプルです。前回に引き続き、またお花のビジュアルです。今回はこういうよくある入力フォームのマークアップ方法から、そのレイアウト、ユーザーの操作に反応する仕組みを作るところまでを、実際の制作フローに沿って解説しています。

すぐに使えるCSSデザインテクニック

月刊[web creators]にて、これまで40回続いた神森勉さんの「いますぐはじめるCSSデザイン」の後を引き継がせて頂くかたちで、7月号から「すぐに使えるCSSデザインテクニック」という新連載が始まりました。文をKyosukeさんが担当、サンプル制作を僕が担当というかたちで進めてまいります。

書店でみかけましたら、どうぞよろしくお願いします。

書いてよかった

僕が書いた本がとても参考になったと感想をくれた読者の方の個人サイトを見に行ってみたら、きれいなXHTMLと、とても見通しの良いCSSで記述されていることにとても驚かされました。

以前訪れたときは、そのほとんどがテーブルレイアウトで組まれていたのを覚えていて、感想を頂いたときに「いずれCSSでリニューアルするつもり」という旨は聞いていたのですが、まさか短期間のうちにここまで立派なリニューアルを遂げるとは・・！

IDやクラスの名前、それからCSSの書き方やコメントのつけ方まで、僕が本で好んで用いたものによく似ていることから想像するに、本当に細かいところまでじっくりと読み、そして実践してくれたのだと思います。久しぶりに心底嬉しいという感情が湧きました。本当にありがとうございます。

本の正誤表

速習Webテクニック　スタイルシート　上級レイアウト 補足情報

本の正誤表を掲載してもらいました。

もし増刷となった際には、上で挙げている点と、その他また見つかればそれも含め修正したいと思います。

CSS Liteの資料

「IE7とCSS」のスライド資料

CSS Niteというイベントの後に行われたCSS Liteというイベントのほうで、10分ばかりプレゼンっぽいことをしてきました。一応スライドをアップしておきます。

さて、そのCSS Lite、計5人で順番にプレゼンという感じだったのですが、てっきりmixiのイベント告知に書いてあった順番になるのだろうなあ、と勝手に思っていたら、僕が一番最後。。それまでにビールをがぶがぶと飲んでしまっていたので、自分の番がきたときには、もう酔っ払い状態でした。

それで、僕がはじめたときにはすでに終了時刻が迫っていたらしく、まいて、まいて、いきました。本当は、IE7で対応したプロパティを絡めて、本のサンプルからもう少しデモをする予定だったのだけど、だいぶ端折ってなんとか終わらせたという感じ。案の定、滝汗状態で緊張しまくって、酒のせいなのか、緊張のせいなのか、とにかくろれつが回らなくなったあげく、終いには「Microsoftの回し者っぽかったよー」なんてみんなに言われてしまう始末なのでした。

そんなこんなでしたが、振り返ってみれば、いろいろ実りのある一日になったなあ、と思います。上ノ郷谷さんともはじめてお会いできたし。

本の見本が届きました

技術評論社さんより、「速習Webテクニック スタイルシート 上級レイアウト」の見本を送っていただきました。カバーのタイトル部分がピカピカ光っています。

実際に手にとって見ると、完成してよかったあ！という思いがこみ上げてきました。

関連エントリー：速習Webテクニック スタイルシート 上級レイアウト

速習Webテクニック スタイルシート 上級レイアウト

「速習Webテクニック スタイルシート 上級レイアウト」という本を書きました。

僕自身まだ見本を手にしておりませんが、3月29日に技術評論社より発売予定ですので、もうそろそろ製本され始める頃かと思います。

全体的な流れを簡単に紹介させていただきますと、前半で、段組や見出し、ナビゲーションといった基本的なレイアウトを、ポイントや注意点を交えて解説。中盤で、それまで学んだテクニックを元に、ひとつのレイアウトをフローに沿って構築。後半に入り、企業サイトやブログといったテーマ別のサンプルレイアウトを示し、それらがどのような組み合わせで構成されているかをエリアごとに詳解。最後に、実在するサイトのレイアウトを例に、さらにステップアップを図るための足がかりを探るといった感じです。

(X)HTMLやCSSの基礎知識をある程度前提としたことと、辞典のような網羅性を求めなかったこともあり、本書では実践的に役立つレイアウトテクニックに特化して解説できました。CSSの入門書を読んだ方の、次のステップアップにオススメしたいと思います。

また今回、僕の執筆や校正作業の遅れもあり、編集者の方やDTPの方をはじめ、関係者の方々には多大なご苦労をおかけしました。この場を借りて、深謝申し上げます。ありがとうございました。

Layout Gala

Layout Gala: a collection of 40 CSS layouts based on the same markup and ready for download!

とりあえず、一通りの段組パターンを揃えてみたというところかな。

IE7beta2とAlternate Box Model Hacks

IE7beta2が公開されましたが、Alternate Box Model Hacksを用いたページはとてもやばい感じに表示されます。

width: 100px !important;
width /**/: 150px;

なんて記述をしていたわけですが、IE7はbeta2の段階では、IE6と同様、同宣言内の!important規則を無視して扱っているようですので、単純に後に記述したほうの値を優先しようとします。

IE6（標準準拠モード時）の場合、ここで「 /**/（空白文字＋コメント）」のハックを記述することで、IE5用の値を読み込まないよう防いでいました。ですが、IE7beta2においては、このコメントハックも無効となった模様でして。つまり、IE7の場合、!importantもコメントハックも無きものとして扱い、結果的には、

width: 100px;
width: 150px;

こう書いたのと同じことになってしまうというわけです。

IE7では!important規則の実装不備は修正されるものと思い込んでいたのですが（もちろん正式公開時のバージョンでは修正されるかもしれないものの）、今後このハックを用いるのは控えたほうがよさげ。IE用のハックは例えばバージョン5用に留め、条件付コメントで振り分けるとかって対処を考えようと思います。

追記：「IE7の!important宣言の解釈は今後のリリースで修正」（原文）によるとbeta2より後のバージョンでは、正しく!important規則を解釈するとかで、ひとまずほっとしておいて良いかもしれません。というか、修正してくれないと、僕が仕事で作ったサイトに関してもほとんど崩れますので、本当によろしくおねがいします。そもそもIE6まで対象にしたボックスモデルハックを使っている時点で、今思えば「危ないハック」ではあったのですが。

Faux Columnsは意識してただろうか

Faux Columnsってそれを意識して使ったことないような気がする、とか改めて思いました。はじめてCSSでpositionプロパティを使った段組を作ったとき、特になんにも考えずbodyに背景画像を敷いたと思うんです。といっても僕がCSSで段組を作ったのなんて、ずいぶんノウハウが普及してからのことなので、知らず知らずのうちに体得していたのかもしれませんが。

さておき、こうやってちゃんと記事になってFaux Columnsっていう名称が付けられたということが、案外重要なのかもしれないとか思いました。「さて、ここでFaux Columnsを使って・・・」って説明できるから（違

（もちろんそれなりに認知されていればですけども）

Dreamweaver8に感服

いやあ。遅ればせながら、Dreamweaver8の完成度の高さには、全く感服の至りです。もうMX2004には戻れません。素晴らしいソフトだ。

とかく全称セレクタでの指定や、overflowプロパティ回りのモダンブラウザの挙動など諸々、しっかりデザインビューに反映するようになった点が気に入っています。ズームやルーラー機能はあまり使っていませんが、細かいところを確認するには便利だと思います。

がしかし、Studio 8をインストールしたらば、Firefoxのフォント設定がぐちゃぐちゃに弄られてしまい、これにはマイリマシタ。Flashが悪さをしているとかいう話ですが、どうなんでしょう。僕はFlashはやらない（挫折済みな）ので、Flashだけ除外してインストールすれば良かったなあ、と思っています。

さて、次はどこかに売ってるらしい「Web2.0」なるものを買えば、まさに鬼に金棒というわけだ（違

MSNとSamurai

MSN Japan

少し前から、すごく気になっていたのですが、MSN JapanのCSSでは、クラス名のほとんどに「Samurai_～」という命名がされていまして、はて、このSamuraiというのはつまり「お侍さん」のことか知らん、と。

.Samurai_searchとか.Samurai_fortuneとか、.Samurai_Blowoutとか。なんだかちょっぴし可笑しい響きです。すごくどうでもいいことではありますが、なんでわざわざこんな名前にしたのだろう、とか思い始めると、ナゾは深まるばかりなのです。

floatしたボックスを含む親ボックスの高さの算出

子にフロートボックスを含む時の親ボックスの背景 - 徒書

この背景色（画像）現象は僕も頻繁に遭遇するものでした。後続の要素で回り込みを解除してやれば良いわけですが、clearプロパティを指定するボックスが、floatプロパティを指定したボックスと同じ親ボックスに包括されていない場合には、解決に至りません。

例えば、

#parent { width: 500px; background: #000; padding: 10px; }
#box1 { float: left; width: 200px; background: #ccc; }
#box2 { float: right; width: 200px; background: #ccc; }
#box3 { clear: both; }

上記のスタイルを前提に、以下のようにHTMLを記述した場合には問題ありません。

<div id="parent">
  <div id="box1">左にfloat</div>
  <div id="box2">右にfloat</div>
  <div id="box3">回り込みの解除</div>
</div>

ですが、次の例ではダメだということになります。

<div id="parent">
  <div id="box1">左にfloat</div>
  <div id="box2">右にfloat</div>
</div>
<div id="box3">回り込みの解除</div>

前者の場合、#parent内に回り込みを解除できる#box3のような適当な要素がない場合には困ってしまいます。そんなときは、徒書でも示されているように、:after擬似要素とcontentプロパティを用いて、親ボックスの最後に、（ここでいうところの#box3の代わりとなる）内容を生成してやり、それに対してclearプロパティを指定する方法が特に有効だと思います。

後者の場合、回り込みは解除できているものの、clearプロパティを指定したボックス#box3が、#parent内にないので、うまく背景が反映しないわけですが、この場合、#parentにoverflow: auto;とスタイルを追加してやることで、問題を解決できるようです。ただ、この記述をすることで、なぜ#parentの背景が反映するのか（#parentの高さがfloatプロパティを指定した#box1と#box2の最下辺まで及ぶのか）、その仕組みはつかめていません。

また徒書では、上の現象はFirefoxで主に発生するものとして、Operaの場合、IE拠り（#parent内に#box3がなくても背景が反映する）としていますが、Operaのバージョン7とバージョン8では、挙動が異なりまして、バージョン7ではIE拠り、最新のバージョン8ではFirefox拠りの表示を行います。

さらに、SafariやMacIEの場合も、FirefoxやOperaバージョン8拠りの挙動のようです。（ちなみに、#parentにoverflow: auto;と指定することで、Safari、MacIE、Operaバージョン8でも同様に問題を解決できます。）

WinIEとその他のブラウザで、どちらが仕様上正しいのかは、残念ながら僕もはっきりとはわからず終いです。「WinIE以外がそうだから多数決でそっちが正しい！」というのは乱暴ですが、Operaがバージョンアップとともに、わざわざ他のモダンブラウザに合わせて挙動を変更してきたということは、何かしらの根拠があるのではないかな、と思えます。

関係ありそうなところとしては、CSS level2仕様書のfloatの項に

Since a float is not in the flow, non-positioned block boxes created before and after the float box flow vertically as if the float didn't exist.

とありまして、該当する日本語訳を読むと、

浮動体は流れの中にないので，浮動ボックスの前後で生成される位置決めされないブロックボックスは，浮動体が存在しないものとして，上下方向に流し込まれる。

となっているところ。このあたりのブラウザによる解釈の差が、親ボックスの高さの算出にも影響しているのかな、とも思っています。

※追記：やっとわかった。ちゃんと書いてありました。以下邦訳版から引用します。

要素がブロックレベルの子供をもつ場合は，高さは，最上部ブロックレベルの子ボックスの境界上辺から，最下部ブロックレベルの子ボックスの境界下辺までとする。考慮するのは通常のフローにおける子供に限る。すなわち，浮動ボックス及び絶対位置決めボックスは無視され，相対位置決めされたボックスは，位置指定がないものとして考慮される。

※さらに追記：overflowプロパティを指定して、親ボックスの高さがフロートの子ボックスの下辺まで及ぶのは、CSS2.1の勧告候補に基づいているようです。CSS2.1では、浮動ボックスが無視されるのは、Block-level non-replaced elements in normal flow when 'overflow' computes to 'visible'とあるように、overflowプロパティの値にvisibleである場合に限定されていました。

ブログのテーマ

NapdaysのNovuさんが公開しているWordPress 用テーマ、「KASANE」を見ていて、さっそく影響されたのか、僕もブログのテンプレートを作って公開してみようかな、と思っています。

「HINAGATA」のように大々的にやるのも良いかと思ったんですが、ひっそり公開するのもまた趣があって、なお良しという感じがするので・・・。というのは嘘で、ただ単にカタチから入ると、後が続かず失敗するケースばかりだという過去の反省を活かし、とりあえずここでひっそりと配布してみようかと思った次第です。

使ってくれる人が果たしているのかという疑問がまず生まれますが、ひとまず、目標は1年以内に5人、いや、1人でもダウンロードして使ってくれたとしたらば、それで満足します。つまるところちょっと配布してみたいというマスターベーションに過ぎませんので。

僕はWordPressは使ったことないので、ここはやっぱりMovabletype用にしようかと思っているのですが、より汎用的なものをよりさまざまなブログのニーズに適応させるためには、少なくとも、

1. アーカイブページ
2. スタイルシート
3. メインページ
4. カテゴリーアーカイブ
5. 個別エントリーアーカイブ
6. 日付アーカイブ
7. コメント・リスト
8. コメント・プレビュー
9. コメント・エラー
10. コメント・保留
11. トラックバック・リスト

このくらいは用意しなくてはならないということになります。うお。

自分でブログを作るときはコメント・リストやコメント・保留、トラックバック・リストなんぞのテンプレートは絶対作らないものなあ。やっぱり結構しんどいことになってきそうな気配もしています。

さあ、めざせ年内！

さらに自分のだと意味不明なデザインもOKだけど、人に使ってもらうとなると、カスタマイズにも耐えられるような汎用的なものにしたいから、難しいですね。例えば左にいる茶坊主みたいのは、真っ先に却下されるテイストだと思います。

firefoxでborderがうまいこと表示されない現象にハマりました

上はfirefox1.0.6でborderがうまく表示されない現象のサンプルです。どうやら背景画像との組み合わせなどによって発生するようですが、font-sizeの値を変えるとうまいこと表示されるなど、挙動が怪しく、原因がさっぱりわからず終いでした。

参考までにお粗末ながらサンプルページを用意しました。

li要素に指定したborder-bottomが途中で途切れたりしています。IEやsafariなどではこのような現象はおきませんでした。

li要素にheightを明示してあげると、うまいこと表示されます。ですが、そうしてしまうと、文字が折り返したり、ブラウザ側でサイズを拡大したりした際に、firefoxなどでは背景画像が途切れてしまったり、文字が重なってしまったりするので、にっちもさっちも行かず困ってしまいます。

a要素のほうにborderをつけたり、端からboder付きの背景画像を用意して位置をbottom left などとしたりなんだり、いろいろ弄りましたが、どれもうまくいきませんでした。結局のところ原因がわからないので代替案として、li要素の最後に

#nav li:after { content: url(/images/border_ccc.gif); }

といった感じでborder用の画像を配置してあげて、:afterに対応していないIE用には

* html #nav li { border-bottom: 1px solid #ccc; }

として、逃げ腰な方法でとりあえずの解決を迎えています。

すべてのfirefoxのバージョンでこの現象が起こるものかはわかりません。僕が確認したのはfirefox1.0.6だけです。

※上の解決策は例えばIEがバージョンして:afterに対応したり、もしくは「* html」のような記述を無視するようになれば、再度対応を迫られることになりかねませんので、要注意かもしれません。またsafariでは:afterで指定したスタイルを解釈できるものの、意図しない位置に画像を配置してしまうようので、結局どっちつかずだということも判明しました。ということで、僕はもうJSでUAを振り分けてスタイルを上書きすることにしました。が、ここはひとつギブアップするというのも、場合によってはひとつの手ではないかと思います。

※その後、font-sizeのさじ加減が大きく影響していそうだと、ご指南頂きました。例えば上のサンプルだったら、font-size: small; を font-size: 12px; とすると治ったりするようです。

※Firefox1.5のバージョンアップに伴い、上の不具合は修正された模様です。

2冊ほどお買い物

普段HTMLやCSSの解説本はめったに購入しないのですが、今日は『スタイルシート・スタンダード・デザインガイド』と『スタイルシートによるレイアウトデザイン見本帖』の2冊を買ってきました。

『スタイルシート・スタンダード・デザインガイド』は単にレイアウトの本というよりは、サブタイトルにもあるようにSEO／ユーザビリティ／アクセシビリティの観点を切り口に、どのように実践するとよいのか、各パーツに分けてわかりやすく記述してあります。Tipsなどで躓きやすいポイントなどをしっかり取り上げており、体系的な学習を促すという意味でも他書とは一線を記す良書だと思います。

『スタイルシートによるレイアウトデザイン見本帖』については本の役割が単純明快で、実践レベルの知識が集約されたサンプルソースを、書面上ですべて見せてしまい、各所ポイント的に具体的な説明を記してあるというスタイル。サンプルのデザインの完成度に重きを置いていることも特徴だと思います。

最近はamazonなどでいろんな本を調べていたのですが、こうして手にとって目次なんかをじっくり眺めると、本の対象や意図がなんとなく読み取れて、本それぞれの役割というか、存在意義を見出すためにいろいろ工夫しているんだなあ、と改めて感心させられてしまいました。（というか、感心してる場合じゃないのですが）

逆に駄本だと思うのは、「なに？」「なぜ？」がしっかり記されていないもの。「こう書くと、こういう見た目になるよ」では「わずかに違うけど似たような状況」というのに遭遇したとき躓きます。理由付けがしっかり成されていることが重要なのだと感じています。

丸付き数字のマッピング

ある文字が「機種依存文字」か否かということは、それがメーカー独自拡張の文字のことをそう呼ぶのか、そうでなくとも実際に文字化ける危険性の高いものを単純にそう呼ぶのかに依ると思います。

どういうことかというと、例えば丸付き数字（①②③④⑤⑥⑦⑧⑨⑩）の類の場合、Shift_JISの場合は数値文字参照で置き換えないと、Macでは「」のように化けて表示されてしまうことがありそうで、つまりその意味では「機種依存文字」だともいえるのですが、JIS X 0213で非漢字一覧に仲間入りしているという意味では「機種依存文字」ではないといえるのではないかということです。

まあ名称は別にどうでもよかったりもするのですが、Shift_JISで丸付き数字を使ったときの挙動はどんなもんだというわけで、10進数と16進数でそれぞれ数値文字参照したものと、素直に「まるいち」と打ち込んで変換したものとを、文字コードをShift_JISにしてMacで表示してみることにしました。

まずMac OS TigerのSafari2.0とIE5.2で、フォントをOsakaと設定して表示してみると、あらまあちゃんと3つとも「①」と表示されてましたよ。ほう。まあ数値文字参照したものがちゃんと表示されるのはそう然るべきというか、前々からそうだったと思うのですが、そのまま打ち込んでもいけるとは思いませんでした。いつの間に。はじめから？

次にMac OS PantherのSafari1.0とIE5.2で同フォントを使用して表示してみると、今度はSafariの場合3つとも正常に表示されたのですが、IEの場合「」のように文字化けて表示されてしまいました。

というわけで、環境によっては文字化けるのは確かなので、現段階でもShift_JISの場合数値文字参照せずに使用することは控えたほうが良さそうだというのは変わらないのですが、果たしてどういう仕組みでこの差がでるのだろうというのが問題です。

今回試してみた環境の差でいえば、OSの違いと、Safariのバージョンの違いの2つがあります。逆にIEはバージョンアップしていないはずなので両環境のIEはブラウザ単位でいえば基本的には同じものだと考えられます。

とするとTigerのIEが化けることなく表示できたのに、PantherのIEでは化けてしまったということは、やはりOSのバージョンアップに伴い丸付き文字のような文字表示に対応がなされたと考えるのが筋かと思うのです。

しかし、Safariの場合どちらの環境でも問題なく表示されるのですから不思議だったわけですが、おそらくPanther時代以前からSafariは先行(?)してこの点に対応済みであったのではないかと思います。

「丸付き数字をそのまま打ち込むと意味自体が変わっちゃうから気をつけろ」なんてのは、昔からの慣わしかのように言い伝えられていた既知の問題だったでしょうから、Safariのように上手いこと問題を避ける補完がアプリケーション単位で実装されるというのは当然の流れでしょうか。

次にエンコーディングをUTF-8に変更して、Shift_JISだと化けてしまったPantherのIE5.2で表示してみると、意図したとおり丸付き数字で表示してくれたので、やっぱりそうかなるほど、なんて納得していたわけです。

ところがです。今度はそのUTF-8でエンコーディングした丸付き文字をMacのFirefox1.0で表示してみると・・・。数値文字参照したところも含めて3つとも「！」と表示されてしまいました。それはShift_JISに戻してあげても同じこと。ただフォントがヒラギノ角ゴW3になっていたようで、これをOsakaにしてやると今度は問題なく表示されたのです。

なるほど、わけわかんなくてビビったけど、ヒラギノだと文字コードに関係なく単に丸付き数字自体に対応されてないのか、と一時は安易に納得したのですが、IE5.2やSafari2.0で試すとヒラギノでも問題なく表示される模様。これはいったいどういうことなんでしょう。なんか文字コード、OS、ブラウザ、フォントセットとがそれぞれ複雑に絡んでいるような予感がしています。

とりあえず今の状態ではどこがどう影響しているのか、もはや意味不明な状態になってしまい、考えるのもダルくなってしまいました。

というわけで一旦終了ですが、暇を見つけて引き続き調べてみようかと思っています。

参考：機種依存文字の歴史

img要素のlongdesc属性とイメージマップ

Firefoxでブラウズ中、ページ上で右クリックして「プロパティ」を選択すると、「要素のプロパティ」というウインドウが開きます。

これをgifやjpegといった画像の上で開くと、URL、幅、高さ、代替テキストといった「画像のプロパティ」が参照できますが、どうやらimg要素にlongdesc属性の値で指定したURIもここで確認ができるようになっているようでした。ほー、これまで全然気づかなかったですよ。
できればクリックで飛べるようになっていたらもっと良かったのかもしれませんけども、そこまでの必要もないですか。

img要素のlongdesc属性は、イメージマップを使用している場合、特にサーバーサイド・イメージマップであればなおさら、その内容を示す文書へアクセスできることが好ましいとされています。
サーバーサイド・イメージマップは各項目の代替テキストや、そのリンク先のURIを明示できないからなのでしょう。まぁ最近はサーバーサイド・イメージマップ自体をあまり見かけなくなった気もします。map要素を使ったクライアントサイド・イメージマップのほうが主流となっていますね。

ところでそのクライアントサイド・イメージマップですが、XHTML1.1の仕様書にあるA. Changes from XHTML 1.0 Strictを見てみると、

On the a and map elements, the name attribute has been removed in favor of the id attribute

とあります。

つまりXHTML1.0では

<img src="img00_.jpg" alt="" usemap="#map01" />

<map name="map01" id="map01">
略
</map>

のように記していたものでも、XHTML1.1の場合name属性は使えませんので

<img src="img00_.jpg" alt="" usemap="map01" />

<map id="map01">
略
</map>

としなければならなくなるというわけでしょう。ふむふむ。

というわけでちゃんとそれで機能するか試してみたのですが、残念なことに今のところFirefoxを除く主要ブラウザはこれをサポートしていないようです。
つまり現実問題として（現段階では）XHTML1.1でクライアントサイド・イメージマップは使えないというか、使わないほうが無難だと考えられると思います。

日々の暮らしを便利にするJavaScript作りはどうなったのか

ちょっと業務が落ち着いた隙にと思って、JavaScriptマスターへの道を志したは良いのですが、相変わらず3日坊主でとてもダメです。

金曜の夜なんかは、さあ週末はJS祭りだ、なんて決め込んでいるのに、いざ休みモードに入ると、だらだら邦画なんぞを3本も4本も見てしまっているわけで、一向にマスターへなる気配がないのです。

リファレンス読んで、ただサンプルどおりに作っているだけでは、やらされている感が強く学習意欲も湧かないのではと思い、なにか自分で実現したい機能を考えてそれに向けて努力するほうが良いだろうと着想したところまでは問題なかったはずなのですが。

具体的には、HTMLコーダーの「日々の暮らしを便利にするJavaScript集」なるものを作りたいと思いつき、第1弾としてひとつ実現したい機能を設定し目標を立てたものの、なんだこれどう書くのかわかんないとか思い、さっそく人にお任せ状態なのは当然ながらダメ人間のすることなのでしょう。

しっかり気持ちを身締めて、まずは自分にできること、できないことを見極めないといつまでも何もしなさそうです。

というわけで猛省しますよ。その第1歩としてネーミングばっかり考えるのに時間を割くのをやめようと思います。

JavaScript-enhanced image replacementを試してみた

clagnutで公開されているJavaScript-enhanced image replacement。

従来のImage Replacementの問題点は、CSSでテキストを画面外へ隠し背景画像に置き換えるという手法ゆえ、CSSが有効で画像が無効な環境下では代替テキストが表示されないため、それはアクセシビリティ的にどうか、という話もありました。（mezzoblueのRevised Image Replacementという記事は、この類におけるさまざまな手法を比較検討しているようです）

CSSが有効で画像が無効な環境のユーザーというのが現在どれほどの規模いるものかはわかりません。ただ僕もつい1年と半年ほど前までは、自宅ではバリバリの（?!）ダイヤルアッパーだったわけで、その頃は画像をオフにしてブラウズしていることも多々ありました。

普通にIMG要素を置けばこういった問題も発生しないので、それでいいじゃないかという気がします。しかし同時に、例えばmedia="handheld"として携帯端末用のCSSも用意し、同じHTMLでそのまま２次利用(?)しようなどと企んだサイトであれば、img要素は多用しないほうが良い場合もあるとも思えるのです。

JavaScript-enhanced image replacementにおける「JSで画像が読み込まれているか判定し、読み込まれていない場合、テキストを表示させる」という手法はそのあたりにひとつ妥協点を落としてくれそうな気がします。

僕は正直JSとか毎回用意するのは手間に思うし、携帯電話などに同じHTMLを読み込ませるのは、今のところもういいやっていう感もあるので、今後本気で導入するかどうかは怪しいですが、例によって一度くらい試してみたくなったのでサンプルをひとつ作ってみました。

下の画像はCSSの背景で設定しテキストは隠していますが、画像をオフにすると、今度はテキストが表示されるはずです。※WinIEの場合怪しい

これを実践するにあたってですが、僕はIDなどを公開されているスクリプトのものと合わせて、スクリプト自体はほとんど変更せずそのまま使用しました。（まぁ変えたしても数箇所ですが）

function checkImages() {
if (document.getElementById) {
var x = document.getElementById('logoimg').offsetWidth;
if (x != '167') {
document.getElementById('heading').style.textIndent = "0";
}
}
}

window.onload = checkImages;

JSと英語が良くわかってないのでやや不安な解釈ですが、動作としてはlogoimgというIDをもった要素の幅を見に行き、返ってきた値が一致しない場合（つまり画像が読み込まれていないと判断される場合）、text-indentの値を0とし、あらかじめtext-Indent: -1000px;などとして画面外に追い出しておいたテキストの開始位置を元に戻してやる感じでしょうか。

画像表示がオンかオフかの判定に使われるlogoimgというIDを持ったimg要素はサイト全体で使用しているものが望ましげですので、ここではページ左に配置してあるイラストにその役目を担わせています。

<img src="http://www.extype.com/karakuri/images/logo.gif" alt="カラクリエイト" id="logoimg" />

上のJSにある167という数字はこのイラスト（GIF画像）自体のwidthと同じにしておく必要があります。

実際に画像を表示させる部分のHTMLとそのスタイルは次のようになります。

<div id="heading">カラクリエイト</div>

#heading {
width: 200px;
height: 109px;
background: #fefefe url(/karakuri/images/enh_rep.gif) no-repeat;
text-indent: -1000px;
font: bold 100%/1 "\FF2D\FF33\20\FF30\30B4\30B7\30C3\30AF";
}

当然ながらJSが無効の環境ではテキストを元に戻す動作も発動しないので、従来のImage Replacementと同じ問題点が付きまとってしまうわけですが。

まぁ結局は何を優先させるかということに落ち着く話だとは思いますが、ひとつこういう手法もあるのかという勉強にはなりました。

追記：WinIEの場合一度キャッシュされると、その後画像をオフにしてもそのwidthとheightは保有したままになるとかで、その場合正しい判定が行えず、画像をオフにしてもテキストが表示がされなくなってしまいます。これはclagnut/sandboxのサンプルにあるKnown issuesでも記されている既知の問題のようです。

新緑会

mixiで管理人を務めているCSS系コミュ(!?)の飲み会に参加してして参りました。参加したというより、一応僕が幹事なわけです。

はて、どのくらい来るのかなと思ったらば、参加者は自分を含めて男性3人＋女性4人で計7人。あらｗ
4000人近いコミュなのにさ、まぁそんなものなのかな。CSSの飲み会とかいってなんかちょっとマニアックですしね。幹事としては人数が少ないことでとても気が楽でして、妙な緊張もすることなくとても楽しませていただきました。

そしてとにかく料理がうまかったです。カニ、お刺身、寿司、焼き魚といった魚介類、それと串焼きや地鶏のから揚げといった肉類、ピザやチヂミといったデブ味系･･･。堪能させていただきました。

会話も盛り上がったし、映画見れて（何故）ひとまず成功だったと勝手に思っています。

まぁコミュの趣旨（CSS）に沿った話なんて一切でなかったわけですがｗ

XHTML2.0におけるp要素（パラグラフ）の考え方

先日「p要素はブロックレベル要素だけど内容にはインライン要素しか含めることはできないんですよー」って話をしてて、それは例えば

<p>いいサイトを作るには、
<ul>
<li>アイデア</li>
<li>技術</li>
<li>根気</li>
</ul>
が必要になります。</p>

と書くのは文法違反で、正しくは、

<p>いいサイトを作るには、</p>
<ul>
<li>アイデア</li>
<li>技術</li>
<li>根気</li>
</ul>
<p>が必要になります。</p>

と書かなければダメだわって話だったわけですが、mixiのとあるコミュニティをなんとなくのぞいてたら「XHTML2.0のドラフトではいくつかのブロック要素を含むことができる」みたいなことをおっしゃっている方がいたのでちょっと調べてみました。

たしかにXHTML2.0のドラフトのp要素の箇所をみると、

In comparison with earlier versions of HTML, where a paragraph could only contain inline text, XHTML2's paragraphs represent the conceptual idea of a paragraph, and so may contain lists, blockquotes, pre's and tables as well as inline text.

とありまして、慣れない英語を判読してみると、「以前のバージョンのHTMLではインラインテキストしか内包できないが、XHTML2ではリスト、blockquote、pre、tableをインラインテキストと同様に内包できる」っぽい感じのことが書いてあるんですね。represent the conceptual idea of a paragraphの英訳がいまいち自信ないですが、「段落の概念を表す」という感じなんでしょうか。じゃあ今までは段落の概念を表してたんじゃなかったのかと新たな疑問が沸きましたがｗ

とりあえずこのドラフトのまま勧告されれば、先に挙げた書き方のどちらでもXHTML2.0なら違反じゃなくなるというわけです。うん。

MacIE5のoverflowプロパティの挙動が無念

「CSSバグ辞典スレッド」でも報告されているoverflowプロパティにvisible以外の値が指定された要素が表示されない(5.x)というMacIEのバグ。本当に泣かされてしまいます。

hoge { overflow: auto; width: 200px; height: 100px; }といったスタイルを、例えばdiv要素に指定したときと、pre要素に指定したときとでは、挙動が異なります。前者は問題がないのですが、後者の場合、その内容がまったく表示されなくなってしまうんですね。

例えば「インデックスだけ組み込み完了」のエントリーのようにpreタグを使ってソースを囲ったときなんかに、とても無念なことになってしまいます。

内容がまったく表示されないよりはレイアウトの崩れを許すほうがまだマシかと思いますのでpre { overflow: visible; /*\*/overflow: auto; /**/ width: 200px; height: 100px; }のようにしてMacIEのハックをするのが無難なところでしょうか。まだグッとくる他の改善策は発見できてません。

それとまだ検証があまいので断定はできないのですが、このプロパティに対するSafariの実装もなんか変な予感がしてます。overflow: hidden; としてはみ出た部分を隠したとしても、そのはみ出た分の幅の分だけブラウザに横スクロールが発生しちゃってるような気がするのです。僕の場合これはpre要素にoverflow: hidden;、もしくはoverflow: auto;にした場合にこの現象に陥りました。もう少しいろいろやってみないとなんともいえないのですが。

• Underworld 来日公演
• コアラ
• 旅行行きたい
• 4月1日
• trfこそ至高。
• シドニー
• Beauty!★Beauty!
• チェンジリング
• 星蓮船ハード
• すべては海になる

• (X)HTML+CSS (44)
• WWW (11)
• その他 (74)
• アプリケーション (10)
• ウェブサイト (34)
• カラクリエイト (14)
• グルメ (20)
• ゲーム (8)
• デザイン (13)
• ニコニコ (4)
• マトリョーシカ (4)
• 仕事 (6)
• 写真 (3)
• 告知 (5)
• 旅 (9)
• 映画 (14)
• 水泳 (6)
• 読書 (11)
• 音楽 (20)

• August 2010 (1)
• May 2010 (1)
• April 2010 (2)
• December 2009 (1)
• November 2009 (3)
• October 2009 (4)
• August 2009 (2)
• July 2009 (5)
• May 2009 (5)
• April 2009 (2)
• March 2009 (5)
• February 2009 (6)
• December 2008 (1)
• November 2008 (1)
• October 2008 (1)
• September 2008 (3)
• August 2008 (4)
• July 2008 (8)
• June 2008 (9)
• May 2008 (5)
• April 2008 (4)
• March 2008 (5)
• February 2008 (6)
• January 2008 (14)
• December 2007 (9)
• November 2007 (4)
• October 2007 (4)
• August 2007 (1)
• July 2007 (9)
• June 2007 (3)
• May 2007 (4)
• April 2007 (5)
• March 2007 (5)
• February 2007 (2)
• January 2007 (2)
• December 2006 (5)
• November 2006 (6)
• October 2006 (5)
• September 2006 (8)
• August 2006 (6)
• July 2006 (2)
• June 2006 (3)
• May 2006 (7)
• April 2006 (2)
• March 2006 (9)
• February 2006 (5)
• January 2006 (2)
• December 2005 (4)
• November 2005 (8)
• October 2005 (5)
• September 2005 (11)
• August 2005 (18)
• July 2005 (10)
• June 2005 (25)
• May 2005 (23)

• Going Faster
• 物欲とその仲間たちの記録
• MOREWORKS