昨日、CSS Holic 第3回勉強会に参加してきました。

サンプルのデザインをもとに、5名くらいでサイト構成やページのマークアップ方法などをグループディスカッションをしながら検討し、最後に発表という内容でした。自分では当たり前だと思っていたことが実はマイノリティだったことを知ったりしてともて有意義な時間を過ごせました。皆さん、お疲れさまでした。

さて、グループディスカッション終了後に、参加者の方からこんなことしたいんだけどどうするよ？と質問にあがった内容が、なかなか面白かったです。

質問内容

上図が質問にあがった内容のスクリーンショットです。ポイントは以下の2つですね。

• 右下に表示されている矢印は、マウスオーバー時に右下にずれるような感じ
• テキストの左側にある枠線ですが、テキストが複数行になった時でも1行目分の高さである

右下の矢印

サンプルを見る限り、枠線や矢印部分も含め、このエリア全体がクリッカブルなリンクとなるような感じですね。というわけで、この矢印はa要素なり、要素が足りないようであればa要素の中にさらにspan要素を入れ込むなどして、そいつにdisplay: block;を指定してやったあとに背景画像として表示してあげればOKでしょう。

左上を基点にして背景の位置を考えてしいますと、テキスト量によって高さが変化する部分ですので、矢印の位置が一定になりません。背景画像は要素の右下に表示し、マウスオーバー時の右下にずれるような感じは、余白までを含めて画像を切り出してしまうことで解決可能です。

テキストの左側にある枠線

次に、テキストの左側にある枠線です。枠線ということでCSSのborderプロパティが考えられますが、テキストが複数業になった場合にも1行目分の高さが保たれるというのが曲者ですね。inline要素のborderとした場合にも、テキストの左側を縦あわせしないとですので、なかなか難しいことになります（できるかどうか試してません）。

画像を埋め込んで解決しました

というわけでどうしたものかと悩んだのですが、img要素で画像を埋め込んでしまえばすんなり行きました。文字サイズが拡大された時に、画像の大きさもそれに追随してくれるように、画像の高さをCSSでem指定します。指定する値はテキストのline-height分の高さを指定してあげればOKでしょう。

その他、floatの指定などを細かく行いましたが、実際に指定を行ってみたサンプルを用意しましたので、ご興味がありましたらご確認ください。

僕以外の回答例

@debiruさんの回答：CSS Holic / sample1_rev2

address要素について

また、当日はaddress要素に関しましても若干議論がありました。改めてHTML4.01の邦訳を参照してみますと、以下のようにあります。

ADDRESS要素は、文書全体、あるいはフォームなど文書の主要部分に関する問い合せ先を示すのに用いられる。 たいてい、文書の冒頭か末尾に現れる。

こちらを読む限り、たいていの場合はサイト所有者の連絡先をマークアップするのに用いられるのがaddress要素ということになりますね。例外としましては、サイト所有者と違う組織・団体の方などの文書がサイト内にある場合などでしょう。そういった場合にはその違う組織・団体の方などの連絡先をaddress要素でマークアップすることになるということですね。

「ユーザーがその連絡先にサイトのミスを指摘すると編集を迅速に行えるのかどうか？」などが出ましたが、仕様にないことを考えだすとキリがなくなって来てしまいますので、仕様として決まっていることをそのままに受け止め、その情報が「文書全体、あるいはフォームなど文書の主要部分に関する問い合せ先」なのかどうか？だけを判断すればそれほど難しいことはないのではないでしょうか。

仕様書回りのことに関しましては、同日に開催された『日本ウェブ協会アカデミックプログラム Vol.7「HTML仕様書を読む」』の動画が公開されています。太田さんの話術だけでも結構おもしろいですので、一度ご覧になってみると良いと思います。

6月26日に高松で開催される、CSS Nite in TAKAMATSU, Vol.3 「CSS Nite ビギナーズ HTML+CSS編」に出演いたします。

僕は1日のちょうど真ん中くらいのセッションで「これだけはおさえておきたい、CSSレイアウトの基本」と題して、CSS Nite ビギナーズ（東京版）でお話したことに、ちょっとだけ最近の傾向なども交えてのセッションになる予定です。

東京、大阪で開催されたCSS Nite ビギナーズと違い、今回は話題のHTML5/CSS3のセッションも持たれています。(X)HTML+CSSのワークフローからjQueryのことまで、今制作現場でどのようなことが求められているのかを一通り確認しておきたいという方にもオススメですね。

すでに満員間近となっているようですので、ご興味のある方はお早めにお申し込みください。

IE9のベータ版が公開されて間もありませんが、すでにいろいろとCSSハックが解明されていますね。

• Firefox3.6以降のCSSハック
• IE9へのCSSハック

いやー、こういうの見つけ出しちゃう方ってすごいですね。ChoromeとかOperaなんかもドンドン見つけてしまってください！

と、思うのですが、なんだか実装者が面倒になる一方ですよね。こういうの。

そろそろ特定のブラウザだけにCSSを指定する方法を準備してもらいたい

各ブラウザのW3C仕様への準拠がドドドーっと進んできていますので、これからはもうCSSハックとかはいらなかなーとか思ったりもします。実際に、PC用のサイトをコーディングして、最近FirefoxやSafariへのハックを使った記憶がありません。

ただ、今後僕たちが担保しなきゃいけないデバイスがめっちゃ増えていった時のことを考えると、今のうちから何かしらの対策を練っておいて欲しいなと思うんですよね。

例えば、冷蔵庫に普通にブラウザが搭載されたとしましょう。ワンソースマルチユースの精神のもと、PC向けと、冷蔵庫向けのHTMLを一緒にした場合に、「あー、最近結構売れている、東芝の○○○だけはどうしても表示がおかしくなっちゃうなー」などがあるかもしれません。

たとえwebkitを採用してくれたとしても、素のwebkitから先は各社のエンジニアさんに託されるわけでして、そんなときはむしろwebkitであるがゆえにハックがしずらくでウザイなんとことにもなりかねないなーと思います。

というわけで、例えばですが、

@[メーカ名]-[機種名]-[バージョン番号] {
	[セレクタ] {
		[プロパティ]: [値];
	}
}

なんてふうに書くと、特定のヤツだけに簡単にスタイルを指定できるみたいなのを各社の方々が用意しておくとか、なにかしら簡単なヤツが欲しいなと思っています！

と、こうなってくるとIEのコンディショナル・コメントってすげー優れた機能ですね！

許容できないくらいHTMLのエラーが出ていますのでもろもろご注意ください。

CSS Nite LP9 連動 第2回コーディングコンテストが開催されています。僕も応募しましたのですが、取り組んだ際の反省などを。

いろいろデカイこと言ってすみません

えーっといきなり謝ってしまいますが、「賞を狙っているんですよー」などと大きなことを言ってしまいすみませんでした。何名かの、すでに応募作品を公開されているを見る限り「あー、ここはこうやれば良かったのか」などなど反省点がわんさかありまして、柄にもなく自信をなくしました。

残念な点

• ページ上部の影ですが、body:afterなんかでやるのが一番スマートっぽいですね。気づかずにbodyにたいしてbox-shadow: insetを使ってます。さらにそうするとページの左右にもぼかしたぶんだけ影が出てしまったので強引に消したりしています。さらにその強引さがゆえに思いもかけないことが起こったりします。
• rgbaを利用する部分ですが、どの色をどれくらいの透明度にしたら思い通りの色になるのか良くわからなかったので、実際のデザインと比べると微妙に（大幅な部分もありますが）色が違ってたりします。
• HTML5からはtime要素があるんですね。知りませんでした。
• 一応メディアクエってiPhone用とか用意しておきましたが、僕のMacのiPhoneyではスクリーンサイズが大きいのでメディアクエった感じにはなりません。とりあえずスクリーン用のものを取り外して普通にlink要素でiPhone用を読み込んで調整しましたが、最終的にiPhoneでメディアクエリーが適用されているのかは未確認です。
• グローバルナビの四隅が若干ジャギっていますね。背景はすべてa要素に一括で指定しているのですが、liとaに分けた方が良かったのかなー。でもこの辺ってブラウザが悪いよねと思ってそのままに。

その他、マイクロフォーマットとか全然指定しないんですね、とかもあると思いますが、その辺は僕の仕様です。

結構気に入っている箇所

• Non JavaScript！つっても僕があまり得意ではないので使用していないだけなのですが。
• 画像拡大部分の「target-box」。Non JavaScriptということで拡大画像表示はtarget擬似クラスを利用してdisplayの値を切り替えています。ブラウザウィンドウが小さい方ですと、画像下部に配置した画像間のリンクと画像を閉じるリンクが見きれてしまいますので、画像自体にも画像を閉じるリンクを指定しています。で、最初はもっと一意な感じのIDを指定していたのですが、なんだかthickboxなんかに対抗するという意味でも、ライブラリみたいなクラス名を指定しておいたというのが自分的には一番グッと来ている部分だったりします。
• クリック出来る範囲は広い方が良いですよね。ということで、HTML5からaの中にいろいろ要素を持てますので、hnとpとかをまとめてaでククッている箇所が結構あります。便利だなーと思う反面、最後にNVDAで読み上げてみると、都度都度「リンク」と読み上げてから段落なんかが読み上げられるので、これはどうしたものかと今でも悩みどころでもあります。
  あ、クリック出来る範囲は広い方が良いですよねの精神のもと、お知らせセクションの「重要」などのアイコンっぽいのもaに入れてしまっているので、アイコンと後続の文字の間にもunderlineが引かれてたりしますが、デザイナーさんからダメだよ！って言われたらすぐに直します。
• Operaのスモールスクリーンモードが結構良い感じかなーと。ご確認ください。
• あ、あとIE用のCSSファイル名とか。IEさん、ごめんなさい。

こんな感じでしょう。最後に僕が応募したものを以下に置いておきます。

応募したもの

http://maboroshi.biz/clearskysource/cssnite-lp9-contest2/

注釈

サイト内検索を利用するとそのままsix apartさんのものを利用できるようになっていますのでご注意ください。

アクセス解析は当ブログのものを仕込んでいますが、応募したものではsix apartさんが利用しているサイトカタリストのものになっています。

唐突ですが、「clear sky source」というブログ名に関しまして。

「clear sky」というのは、からりと晴れた、昼間であれば満点の青空を意味しています。そのようなsourceということで、とても見渡しの良いキレイなソースを書いていくぞ！という意気込みをあらわしております。

と、なんだか共感を得そうなキレイごとを言っておりますが、そもそもの発端は、ブログを作るとなったときにCSSが好きだったので、略してCSSになる、なにか適当な英語はないかなと思っていた所、良い感じのものがあるじゃないかということで決めただけでした。

ちょいちょいご説明していますので、ご存知の方も少なからずいらっしゃいますが改めまして。

スミマセン。このエントリーでroll属性とありますが、正確にはrole属性です。

ブログなどでプログレッシブ・エンハンスメントに関するエントリーを読みますと、そのほとんどがCSS3に関するテーマのお話ですよね。なんでHTMLだけのお話でプログレッシブ・エンハンスメントが語られることがほとんどない（まだ僕は聞いたことがない）のかなーと不思議に思ってたりします。

そもそもプログレッシブ・エンハンスメントってなんですか？

僕の中では、「互換性などもふまえてHTMLをしっかりと作りながら、より進んだ技術をサポートしているユーザーエージェント（以下、UA）にはよりよいユーザー体験を提供しましょうね」というのがプログレッシブ・エンハンスメントだと理解していますので、この前提にたってこのエントリーを書いています。

ですのでそもそもその前提が違ってますけど、という場合はご指摘ください。よろしくお願いいたします！

例えばroll属性を指定するだけでもプログレッシブ・エンハンスメントのような気がする

さて、ではどんな場合がHTMLだけでプログレッシブ・エンハンスメントを実現出来ると思ってるの？ということですが、例えばWAI-ARIAで策定が進んでいるroll属性を考えてみましょう。

4.3.6. ランドマークのロール（role）には、HTML文書に簡単に指定することができる値が用意されています。ざっくりと言ってしまえばページの中で、ここにはナビゲーションがあるよーとか、ここにサイト内検索があるよーということをHTMLに記述することが出来るわけですね。

で、なんでこれを指定するのがプログレッシブ・エンハンスメントなのかと言いますと、スクリーンリーダーの中ではJAWSのバージョン10からと、いつからかバージョンは覚えていませんがNVDAの最新版で、roll属性を認識して、見出しジャンプのようにページ内の主要な場所へとスキップできるという機能をサポートしています（これをランドマークジャンプと言ったりしますね）。

現状においては、roll属性を指定することで(X)HTMLはinvalidになりますが、メジャーなUAに何か迷惑をかけるということはありません。JAWSやNVDAを使用してブラウジングしている人にとっては、ランドマークジャンプを利用してサイト内検索やナビゲーションをすぐに発見することが可能になるわけですね。これってプログレッシブ・エンハンスメントじゃないのかなーと思うんですがどうでしょうか？

余談

なんかプログレッシブ・エンハンスメントっていう言葉が分かりづらいなーと思うんですよね。UAによって最適な実装をしましょう、ということであれば、「User Agent Optimization」でUAOとか良いかなーとか思いました。

いろいろ大きなことを言ってしまってスミマセン！

先日「まめことネコゼのどたばた会議」の収録模様がUSTREAMで配信されていました。収録も終わってまめこさんとネコゼさんがまったりとお話している中で、ネコゼさんが作っているモジュール一覧（とかコンポーネントコレクションとか言われているやつ）のお話になったときに、それっぽいのを公開しましょうか？とつぶやいてしまったのでこのエントリーを書いてます。

で、結論から書きますと、とても申し訳ないのですが、実際にクライアントさんに納品したものしかないため、なかなか公開は厳しい感じです。ただ、それではあまりにも申しわけなさ過ぎるので、弊社内でざーーーっくりと決めているコーディングのルールと、今まで他社さんが作ったものなんかも見てきた経験で、モジュール一覧ってこんな感じのことが書かれていますよねということを公開しますね。

株式会社まぼろしのちょっとした決まり

弊社ファイルサーバ内に入っている、コーディングのちょっとした決まりです。あまりにもざっくりというか、ほんのちょっとのことしか決めていません。おそらく、これを見てもほとんど何も参考にならないでしょう。

株式会社まぼろし：コーディングのちょっとした決まり（155キロバイト）

モジュール一覧に書かれている内容

モジュール一覧的なものを作るにあったってまず問題となるのは、それぞれのモジュールをどんなふうにグループ化するのか？って所だと思います。概ね以下のような感じに分ければどのモジュールもどこかに属することになるでしょう。

• レイアウトモジュール

  メインカラム内でさらに段組をするモジュールなんかがここに入ります。

• 見出しモジュール

  見出しが入ります。一口に見出しと言っても、例えば同じh2なんだけど、あるページではテキストで、あるページでは画像化文字で、あるページではキービジュアルとテキストの組み合わせで、など複数ある場合もありますね。

• 段落モジュール

  段落が入ります。単なる段落じゃないものですと、リード文の登場回数が多いですね。

• リストモジュール

  ul、ol、dlといったリストが入ります。よくある感じですと、注釈リストなんかありますね。他にもギャラリー系ページで登場するサムネイル写真一覧なんかもここに入れてます。

• 表モジュール

  表が入ります。HTMLで言えばtableでマークアップするモジュールたちですね。細かな部分ですと、tdに数値がはいるので右寄せにしたい場合には「num」ってclass付けてねとか、各列の幅を均等にする場合には「fixed」ってclass付けてねとか。

• ブロックモジュール

  メッセージエリアや、注意文言のエリア、「Adobe Readerをダウンロードしてね」などのプラグインエリア、お問い合わせ先が掲載されてるエリアなんかが入ってきます。難しいのが関連リンクをずらーっと並べるためのエリアですが、弊社の場合はだいたい「リンクモジュール」へ含めてしまいます。

• インラインモジュール

  emや、strongが入ります。もしかしたらcodeとか、supとかが入ってくるかもしれません。

• リンクモジュール

  ページ内リンクや、外部リンク、各種ファイルへのリンクなどが入ってきます。また、関連リンクや、ページの目次などのような、ナビゲーションが集まったエリアなんかも入ってきます。

• 画像モジュール

  装飾目的で文章の右や左に配置されている画像や、キャプション付き画像なんかが入ってきます。

だいたいこんな感じでしょう。例えばギャラリー系ページで登場するサムネイル写真一覧なんかは画像ではないのか？などのツッコミ所も満載なのですが、その辺は各社で暗黙のもとにルールが決まっていたりするでしょう。

さらに、それぞれのモジュールについてどのようなことが書かれているんだということですが、「実際のスクリーンショット」「サンプルソース」「適宜変更を必要とする箇所」「注意点」くらいですね。

その他にはどんなことが？

他に書かれていることとすれば、モジュール一覧を更新するときの注意点、更新情報、最終更新日、最終更新者、必要なファイルの場所など、いわゆる資料としてお決まりのものですね。

別に必要なければ作る必要ないと思います

と、いろいろ書いてきましたが、「コーディングは最初から最後、また運用になっても自分一人しかしない。」「複数で行う場合でもコミュニケーションが完璧にとれていて迷うことがない。」「クライアントにとっても資料の作成がなんのメリットにもならない。」などであれば、そもそも用意する必要はありません。

作るのであればディレクションから

資料を用意しようかとなったときなんですが、企画・設計やビジュアルデザインがすべて終わってあとはHTMLを実装するのみ、って所からいきなり作りましょうとなりますと、納期的にも、労力的にも結構キツイ思いをすることが多いですし、なんかただ作らされているだけであまり意味がないものになってしまうこともあります。

例えば、ビジュアルデザインもモジュールのカタマリごとに行うようにしておけば、デザイナーさんもマークアッパーさんもだいぶ楽になったりします。ですのでこういったこと（サイトをモジュールの集合体として考える事で制作効率あげることができるよねってこととか）は、実は現場のマークアッパーさんというよりは、ディレクション方面に携わる人にこそ、心に留めて置いて欲しいですね。

こもりまさあきさんのエントリー「TextMate+Zen-Codingで超速コーディング？」を発端にして、ブログやTwitterでZen-Codingに関する話題が熱くなっています。

こもりさんのエントリーではTextMateにZen-Codingを追加していますが、僕は持っていないのでDreamweaverに入れて使ってみました。

Dreamweaverへのインストール方法

zen codingは超便利！Dreamweaverで使ってみました。 | VIVID COLORS + BLOGを参考にインストールしましたので、ご参照ください。

これできないのかー、ということでちょっとカスタマイズ

こもりさんのエントリーを参考にいろいろと書いてみました。Dreamweaverのコードビューを良く使う自分にはたしかにめっちゃ便利ですね。ただインストールした段階ですとちょっと足りないなと思うこともあります。

table要素を記述している際に、th要素にscope属性を簡単に書ける方法ないのかなーと思ったのですが、デフォルトではないような、ないですよね？まちがってたらご指摘ください！で、ないなーと判断したので、例えばth:sなんかってうつと<th scope=""></th>って入ったら素敵じゃね？と思ったわけです。さらにいえば、th:scで<th scope="col"></th>、th:srで<th scope="row"></th>も入れて置いた方が便利でしょう。

カスタマイズ方法

僕のMacの場合ですと、「ユーザー名/ライブラリ/Application Support/Adobe/Dreamweaver9/Configuration/Commands/ZenCoding」内にある「zen_settings.js」をいじります。560行目付近から、個々の要素を記述するための指定がされていますので、どこか良い感じのところに以下を追加しておきました。

’th:s’: ’<th scope=""></th>’,
’th:sc’: ’<th scope="col"></th>’,
’th:sr’: ’<th scope="row"></th>’,

これで希望した記述が可能になります。

もっとカスタマイズしたいのですが、方法がわかりません。どなたか教えてください！

もっとカスタマイズしたら、個人的には便利になるなーと思ったのですが、方法がわからずに断念したのが以下2点です。どなたかわかる方いらっしゃいましたら教えていただければ嬉しいです！ビール1杯くらいならおごります！

• #hogeや、.hogeなどの利用して要素を記述した場合に、閉じタグの前に<! --#ID名.class名-- >というように（ID/class両方が指定された場合は両方が、片方の場合は片方の）コメントが入るようにしたい。
• タグの入れ子構造でインデントがかかるようになっているけど、インデントはなしにしたい。まぁ、Dreamweaverを使っているのであれば、全選択してからのShift+tabで一気にインデントを消せますが、最初から無いにこしたことはないということで。

特に1つ目、できたらめちゃめちゃ便利だと思うんですよねー。

CSSには:focus擬似クラスというものがあります。ちょっと前ですとフォーカスされているフォームコントロールの見栄えを指定するネタがにぎわったので覚えている方も多いことでしょう。例えばこんな感じです。「フォーカスのあるフォームの装飾を変化させる – スタイルシートTIPS ふぁくとりー」。

さて、:focus擬似クラスはinput要素だけに指定するためのものではないんですよね。ページを閲覧している方が、何かの要素にフォーカスを合わせている状態の装飾を行うことが可能です。例えば、a要素には必ず:hover擬似クラスを指定して、リンク項目にカーソルがあたったことを分かりやすくするようにしている、という方も多いでしょう。そんな方は、必ず:focus擬似クラスもセットで指定してみてはいかがでしょうか？

:hover擬似クラスと:focus擬似クラスをセットで指定することで、キーボードのみでページを閲覧している方なんかがいらっしゃった場合には、どこにフォーカスがあたっているのかが視覚的にも分かりやすくなります（ユーザーさんの環境にもよります）のでオススメです。

:hover擬似クラスや:focus擬似クラスは、指定する順序も重要なのですが、弊社の場合ですとおおむね以下のような感じで指定しています。

a {
	スタイル
	}
a:visited {
	スタイル
	}
a:hover,
a:active,
a:focus {
	スタイル
	}

ということで、今まであまり日の目を見ていない:focus擬似クラスがかわいそうですので、もっと積極的に利用していきましょう。

マークアップ界隈でとりわけ海外の先駆者の方々は、クロスブラウザのためのCSSハックを嫌い、IEにだけコンディショナルコメントを利用する傾向にあるなーと感じます。

今月号で100号をむかえたWeb Designingの中で、日本における(X)HTML/CSSの先駆者である大藤幹さんもこの辺の記事を書いておりました。

全体的にコンディショナルコメントを推奨する方の意見としましては、「文法エラーになるようなCSSハックはするべきでない」「前方互換性を考えたときに現在利用出来るハックがそのまま通用する保証がない」などがあり、確かにおっしゃることはわかります、と感じます。

さて、ではそもそもコンディショナルコメント自体はどうなんでしょうか？マイクロソフトからの最新の正式発表で変わっているのか定かではありませんが、CSS Nite Vol.18において、マイクロソフト：Windows開発統括部の五寳匡郎さんは以下のようなことを言っておられました。

「IE開発チームとしては、コンディショナルコメントの使用を強くオススメはしない。あくまで最後の救済手段としてのもの。」

さらにこれは「五寳さんによる個人的な見解というわけではなく、マイクロソフトの公式コメントということですよね？」ということをCSS Nite主催：鷹野さんが確認し、「その通りです。」というような回答をしていたのを覚えております。

ということで、僕の中でコンディショナルコメントはあくまで最終的な救済手段でありまして、概ねスターハック（* html セレクタ { … }）や、*:first-child+html セレクタ { … }を利用してIE対応をしております。

とはいえ最近では、コンディショナルコメントを利用しているサイトも多いので「その後マイクロソフトから新たな見解が出たのかなー？」と興味津々なのですがいかがでしょうか？ご存知の方がいらっしゃいましたら教えていただければ幸いです。よろしくお願いいたします！