hamashun.com

超々有名人である上ノ郷谷さんややまざきさん が、CSSを記述する際のガイドラインを書いてらしたので、マネしてみようかと思います。
以下は最も新しい制作物である、このサイトでの記述方法です。

昨日は、CSS Nite Vol.11に行ってきました。
今回は第1部がロクナナの中村享介さんによる、『優雅なWeb制作』。
第2部がお馴染みスイッチの鷹野雅弘さんの、『クロスブラウザを実現するCSSファイル管理』でした。
（現在第2部が、CSS Niteのサイトにフォローアップ掲載されています）

今日は、CSSのテクニック的な事を書こうと思います。
ネタはたくさんあるのですけど、いざWebに公開するとなると中々勇気が持てなくて、これまで余りそういった事は書きませんでした。
でもそれじゃあ折角Blogを公開している意味が無いので、今日からモリモリ書こうと思います。 へっぽこですけど、どうぞお付き合いください。

MacIE5.xに対するCSS Hackで、バックスラッシュハックという物があります。
例えば、

.div {
	color:#f00;
	/*\*/ color:#00f; /* */
 }

と、このように記述する事で、MacIE5.xは文字色が赤になり、それ以外のブラウザでは青になります。
今日は、その仕組みについて考えてみました。
やっぱり、特殊な技術を使うなら、『なぜそうなるのか』を知っておきたいと思うので。

ブログにコードを貼り付ける方法で悩むの巻
pre要素へのスタイル指定
Re: i d e a * i d e a - ブログにコードを貼り付ける方法で悩むの巻
ソースを貼付ける50の方法
pre 要素のスタイル定義とマークアップ

Blogにコードを貼り付ける際のアレコレが、あちこちで話題に上っています。
これまでに余り情報を見つけられなかったので、とても参考になりました
折角なので、僕もひとつ書いてみたいと思います。

昨日のDaily Linkでもご紹介しましたTouchUpWeb プロジェクトですが、各所で物議を醸しているようです。
このプロジェクトを簡単に説明すると、
「あーもー、いつまで経ってもWeb標準普及しねえよ！ IEでしかまともに表示できないとか、それってどうなんだ！ えーいもうこうなったら力技で勝手に直してやる！」
という感じでしょうか。
少し難しく説明すると、
「Firefoxの拡張機能を使って、崩れているデザインを、専用のサーバからスクリプトを送信して正しく表示する」
となりますか。

そんな一見すると、中々面白そうなプロジェクトですけど、色んな方のBlogを見た所、現在は賛否両論様子見が入り混じっている印象です。

今回は、テーブル風のデザインを、テーブルを使わないで実現する方法を紹介します。
ただ、ここで断っておきたいのは、僕は「全てのテーブルを認めない」、とは思わないという事です。
例えば、価格の一覧表や電車の時刻表など、表として使う分には書式上でも構造上でも、全く問題が無いからです。

ではなぜ、テーブルを使わないテーブル風デザインを紹介するかと言うと、表としての意味は持たないけど表っぽいデザインにしたい場合の為です。
例として上げると、このサイトのWorkをSanctuaryデザイン（footerのリンクで切り替え可能です）で見て貰えば解りやすいかと思います。
では、実際にどのようなコードなのか解説したいと思います。

CSS Nite Vol.12に行ってきました。
今回はVOX、WordPress、Fireworks 8と、盛りだくさんの内容でした。
以下長文です。 まとめ能力の欠如が見られます。

• Class名とID名の命名規則(1)
• Class名とID名の命名規則(2)

Class名やID名を付ける時、それも2単語以上で構成される名前を付ける時には、どんな規則で付けていますか？
今日は、Class名とID名の命名規則に関して書いてみようと思います。

CSSを利用してテキストを隠し、代わりに画像を配置するテクニックを一般に画像置換と呼びます。
このサイトのナビゲーション部分もそれを利用しています。
でも、このテクニックには、注意するべき点がいくつかあります。
それはSEOスパムの問題であったり、画像を表示しない設定をしている環境での問題であったりするのですけど、今回は見た目の問題を取り上げてみたいと思います。

具体的にどういった問題なのかと言うと、いろいろなサイトを、特にFirefoxで見ていると、ナビゲーションをクリックした瞬間に、謎の点線が横（多くの場合左方向です）に延びているのに気づいた事はないでしょうか？
これは決して見栄えが良いとは言えません。
この問題は、CSSとXHtmlに数行追加するだけで解決する事ができます。

• CSS Nite LP, Disk 1に行ってきました（1）
• CSS Nite LP, Disk 1に行ってきました（2）
• CSS Nite LP, Disk 1に行ってきました（3）

昨日の続きです。
会場では青山ブックセンターが出店してて、講演される方の著書などを置いていました。
パラパラっと見てみたのですけど、やっぱり買う時は本腰を入れてチェックしたいので、特に買い物はありませんでした。

他にも、FirefoxやOperaの人がブースを出していました。
ニンテンドーDSのOperaは触ってみたかったのですけど、時間が無くて断念。 残念。

• CSS Nite LP, Disk 1に行ってきました（その1）
• CSS Nite LP, Disk 1に行ってきました（その2）
• CSS Nite LP, Disk 1に行ってきました（その3）

3日間もかけたレポートも、いよいよ最後です。
って言うか引き伸ばしすぎです。 ごめんなさい。

時間が結構押していたので、休憩時間は当初の予定から大幅に短縮されて約15分でした。
お腹が空くと眩暈がする体質の僕は、全力疾走で近場のコンビニへ行って、肉まんを胃に詰め込みました。
そして戻ったら、サービスで用意されたタリーズコーヒーが完売していました。 ショック。

mixi内の記事で申し訳無いのですけど、Webデザインコミュニティ内のタグ・用語 何て読んでます？？というトピックが中々に面白いです。
これはhrefとかpngとか、人によって読み方が違いそうな単語の、自己流の読み方を晒すトピックなのです。

僕もトピ内で一度書いてるのですけど、今日はマイナーなタグも探して、まとめ直してみようと思います。

• Class名とID名の命名規則(1)
• Class名とID名の命名規則(2)

前回のエントリでは、IDやClass名に使用する文字について書きました。
今回は、主にID名に関する内容です。

最近の傾向として、CSSを理解しない昔のブラウザは、何の対策もしないで放置するという流れがあるようです。
確かに今更IE3やNN4を使っている人は相当少ないですから、それもアリと言えばアリかもしれません。

でも、ほんの少しの手間で保険がかけられると思えば、やっておいて損は無いと思うんですよね。
デメリットも殆ど無いですし。
と言う訳で、今回は昔のブラウザを対象にしたCSS対策です。

先日の旧式ブラウザのCSS対策というエントリでは、Ver,4世代以前のブラウザでは、全ての外部CSSをカットするという手法を載せました。
しかし、真っ白い背景に真っ黒い文字だけというのは、さすがに寂しすぎると感じる事もあります。
そんな時は、Ver,4世代のブラウザのみを対象にして、最低限のスタイルを指定してみませう。

2007 05 15 修正および追記

子要素（ここでは画像）をfloatさせると、親BOX（ここではグレーの部分）の高さは親BOXの内容（ここではテキスト）に沿ったサイズになります。
その結果、このスクリーンショットのようになってしまいます。
子要素（画像）の下部にまで背景色を表示させたい場合などに不都合が生じてしまいますので、これを解決する方法を3種類ご紹介します。

なお、この現象はバグではなく、CSS2の仕様上で正しい動作となっています。

text-indentや他の方法でテキストを追いやって、代わりに画像を配置するテクニック、いわゆる画像置換やFIRと呼ばれるテクニックがあります。
これは音声ブラウザにおいても情報が読み上げられる事から、高いアクセシビリティを持つテクニックとされています。
主にナビゲーションなどで利用されていますが、最近では徐々に使われなくなってきているとか。
恐らくその理由は、CSSが有効で画像がオフの場合に、何も表示されないという点からだと思います。
まあ、そんな環境がどれだけあるのかは分かりませんけれど。

今回は、極力アクセシビリティを高めつつも、それなりにデザインを保てる方法をご紹介します。

Operaって、妙な所で妙な動きをしたりしませんか？
お前の技術が未熟だ、と言われればそれまでなんですけど、日本ではシェアも低くて情報も少ないかなあ、なんて。

そこで今回はOperaに使えるCSS Hackをご紹介したいと思います。
ただし、書式上は正しくない物なので、ご利用の際は用法容量を守ってお使いください。

WWW WATCHさんの角丸に関するあれこれを見ていて、そういえばcontentプロパティを使う方法があったなーと思い出したのでエントリします。
この方法を使えば、XHtml側に余計な要素を追加しないで、かつCSSのみで角丸が可能になります。

XHTMLやCSSに限った話ではありませんが、専門用語というのは難しいものです。
同じ意味を持つ単語でも、人によって英語を使ったり日本語を使ったりするので、CSSの勉強を始めた頃はよく混乱しました。

そこで今回は、その辺りを再確認も含めてまとめなおしてみました。
別にクリスマスイブが暇だった訳じゃありませんよ。 決して！

主に自分の為のメモ。
CSSのmarginでわかりにくいのが、縦方向の解釈。 上下に隣接するBOX同士でどう処理されるか、という部分ではないでしょうか。
CSSでサイトをコーディングしていると、あれっと思う事もしばしば。

もう、class名やid名で悩まないんだからっ！！｜CSS HappyLifeとRED LINE:class名、id名の付け方に触発されて、また丁度良いタイミングで職場の話題にも上っていたので調べてみました。
古いブラウザが_（アンダースコア）の付いたclass名、id名を認識しないのはなぜか？ という話です。

font-sizeプロパティの値にsmallなどキーワードを指定すると、ブラウザによって扱いが異なる場合があります。
具体的には、同じ値を指定していても、WinIE5.xやIE6の互換モードでは、FirefoxやIE6の標準モードよりも大きい表示になってしまいます。

今日はその辺りを調べてみました。
サンプルを交えた解説と、例によってウンチクもありますｗ

ふと気になって、バックスラッシュハックでググッたら、以前書いたエントリが一番目に出てきました。 やったね！
なので調子に乗って、関連した記事を書いてみようと思います。 The・2匹目のドジョウ。

内容は、バックスラッシュハックのバックスラッシュハックたる所以でもある、バックスラッシュエスケープです。
そうです。 ウンチクです（またかよ）。
いやでも、技術を使うなら、「なぜそうなるのか」という理由は知っておいた方が良いと思うんですよね。

CSSレイアウトが崩れている時に試す10の処方箋::::::STOPN' LISTEN::::::to the silence:::::::が非常に便利だと感じたので、Shun流の処方箋もメモしてみます。
・・・・・・とか言っておきながら、STOPN' LISTENさんと重複している箇所もあったり。

滅多に見かけないプロパティに、directionプロパティというものがあります。
テキストの表記方向を、左から右に。 もしかは右から左に指定する際に使用します。

「おいおいボーヤ、テキストは左から右に書くに決まっているだろう？」と思うかもしれません。
しかし世界は広いもので、アラビア文字なんかは右から左に書くのです。
縦書きだったら、日本語も右から左ですね。

まあ確かに、殆ど使う機会の無いプロパティだと思います。
でも先日、とあるWebアプリで使われているのを見つけてしまったので、今回ネタにしようと思いました。

class名はどのようにして付けるべきか？
現在は「見た目ではなく内容に沿って付ける」という意見が一般的なようです。
ところが昨日、class は要素の分類 - Weblogという記事を目にしました。

そういう考え方もあるのかー、と思いつつ、この件についてちょっと視点を変えて考えてみました。

CSSハックとしても、かなり古い部類に属するTantek Box Model Hack。
バリデータを通過していながらも、近頃はIE5用の指定をまとめて別ファイルに移す、いわゆるPass Filterにお株を奪われていました。
しかし、そのPass Filterがバリデータを通らない事から、今再び見直してみたいと思います。

シェアがかなり少なくなってきたとは言え、規模の大きなサイトではまだまだ求められるのがMacIE5の対応。
確かに、iMacを買ってそのまま使い続けているライトユーザーなんかは、未だにIEなのかもしれません。

しかし、フルCSSでサイトを制作する際には壁となるのも事実。
今回は、就職してから今日までの一ヶ月で分かってきた事をメモしておきます。

行ってきましたXHTML+CSS (r)evolution, 2ndに！
最近はCSS niteにも行けてなかったので、久しぶりのイベント参加です。

XHTML+CSS (r)evolutionの講演は、名著Web標準の教科書を執筆された益子さんです。
Web標準の教科書（以下コロコロコミック）や雑誌Web creatorsの連載には、いつもかなりお世話になっているだけに期待も大です。

今回のお題はCSS3のカタチとナカミ。
CSS3の情報で日本語の物はまだまだ少ないので、これはかなり嬉しいです。

関連リンク

そろそろCSSハックの良し悪しについて考えてみる（書式編）

そろそろCSSハックの良し悪しについて考えてみる（管理編） おまけ付き

Re:CSS の用途をわざわざ (X)HTML に限ることはない

スターハックに端を発するアレコレ

スターハックに端を発するアレコレ まとめ編

フルCSSでサイトを制作する際に、まだまだ避けては通れないのがCSSハックです。
巷には色んなハックが溢れていますが、今回は良いハックと悪いハックを『書式』をキーにして考えてみたいと思います。

なお、ハックはあくまで最終手段であり、使わないにこした事は無いという事を、事前に書いておきたいと思います。
また、一部CSSハックと呼ぶには語弊があるテクニックもありますが、ブラウザ実装の差異に対する技術、といった意味合いで、この記事ではハックで統一しています。

関連リンク

そろそろCSSハックの良し悪しについて考えてみる（書式編）

そろそろCSSハックの良し悪しについて考えてみる（管理編） おまけ付き

Re:CSS の用途をわざわざ (X)HTML に限ることはない

スターハックに端を発するアレコレ

スターハックに端を発するアレコレ まとめ編

前回のそろそろCSSハックの良し悪しについて考えてみる（書式編）では、正しい書式である事に重点を置いて考えてみました。

しかし、実際の業務、それも複数人が関わる際には、そればかりを重視してもいられないというのが実情だと思います。
そこで今回は、管理のしやすさを中心に考えてみます。
なお、今回もハックと呼ぶと違和感を感じる部分があるかもしれません。
ブラウザ実装の差異に対する技術、といった意味合いで、この記事でもハックで統一しています。

関連リンク

そろそろCSSハックの良し悪しについて考えてみる（書式編）

そろそろCSSハックの良し悪しについて考えてみる（管理編） おまけ付き

Re:CSS の用途をわざわざ (X)HTML に限ることはない

スターハックに端を発するアレコレ

スターハックに端を発するアレコレ まとめ編

zcxv.netの松澤さんからそろそろCSSハックの良し悪しについて考えてみる（書式編）に対する言及トラバをいただきました！ ありがとうございます！
若干浮かれつつも緊張しております。 粗相のないようにしないと。
CSS の用途をわざわざ (X)HTML に限ることはない - Scribble - zcxv.net

関連リンク

そろそろCSSハックの良し悪しについて考えてみる（書式編）

そろそろCSSハックの良し悪しについて考えてみる（管理編） おまけ付き

Re:CSS の用途をわざわざ (X)HTML に限ることはない

スターハックに端を発するアレコレ

スターハックに端を発するアレコレ まとめ編

kuruman.orgのKurumaさんからCSSはHTMLだけのものじゃない (kuruman.org > Kuruman Memo)というツッコミを頂きました。 ありがとうございます！
非常に勉強になった反面、新たな疑問も生じたのでエントリ。

ここでのポイントは、Kurumaさんの記事タイトル通り、CSSはHTMLだけのものじゃないという事。

関連リンク

そろそろCSSハックの良し悪しについて考えてみる（書式編）

そろそろCSSハックの良し悪しについて考えてみる（管理編） おまけ付き

Re:CSS の用途をわざわざ (X)HTML に限ることはない

スターハックに端を発するアレコレ

スターハックに端を発するアレコレ まとめ編

Kurumaさんに再ツッコミ頂きました！ 飲み込みの悪い子でホントすみません。
おかげさまで何とか理解できました（できたはず）。

今回のエントリは、割と自分用のまとめ記事です。
文章化すると、再確認になっていいってじっちゃが言ってた。

サイトリニューアルについて色々と考えています。
目的というか目標をいくつか設定しているんですけど、その中の一つが「読みやすいデザイン」という事。
やっぱりBlogがメインコンテンツですしね。

と言う訳で、BlogやWebサイトの、テキストの読みやすさについて考えてみました。 文章の素人なりに。
素人の言う事ですから、あんまり真に受けない方が良いです。 多分。

Vistaの発売に伴って、font-familyにメイリオを追加しているサイトをいくつか見かけます。
でも、XPのFirefoxなんかで見ると、アンチエイリアスが効いてなくてジャギジャギに表示されてたりするんですよね。

他にも、font-familyの値としてメイリオとMeiryoなど、指定の仕方もサイトによってまちまちだったりします。
これはどういう事なのかな、と思ったので、少し調べてみました。

メモ的エントリ。
スタンドアローン版IE5.5で、CSSのコメントが一部位置にあると、そのブロックが無視されるぽいです。

.hoge,/* コメント */
.huga {
 color: red;
}

具体的にはこんな感じ。
セレクタをカンマで区切って複数指定する際に、カンマの直後にコメントを入れると発生するようです。
制作途中にちょっとしたメモを書いている時に発生しました。

ただ、何しろスタンドアローン版での問題なので、PC環境などによる物かもしれません。

Daily Link

Note:

今日は会社の新人さん歓迎会があったんですけど、そこで先輩から「最近のキミのBlog、はてブを意識しすぎてるんじゃないか？」とツッコまれました。

え！？ 自分では割とナチュラルって言うかむしろ、ちょっとビビッてるくらいっス･･････！
と思った所で、逆にそっち側に意識しちゃってたのかなー、なんて思ってみたり。 いやん。

ちなみに、飲み会はつつがなく終了しました。

概要

Conditional Comments（条件付きコメント）は、IEのHTMLサイドの独自拡張です。
独自拡張、と聞くと眉をひそめる人も多いですけど、まあちょっと聞いてください。 使いようによっては便利かもしれません。

使い方は簡単。 コメント内に、IEの振り分け用キーワードを記述するだけです。
該当のバージョンのIEはその内容をコメントではなく通常のデータとして解釈し、それ以外のブラウザは単なるコメントとして扱います。

単なるコメントとして扱うという事は、バリデータに通るという事です。
ですが、独自拡張という呼び方から誤解されがちです。

使いどころ

head要素内でCSSの振り分けに使われる事が多いのですが、あくまでコメントなのでbody要素内でも使えます。
サンプル
まあ、メインの用途はCSSの振り分けでしょうし、この記事でもそれを主に想定しています。
ただ、知識として一応。

メリットを考えてみる

• バリデータに通る
• CSSファイルを汚さずにブラウザの振り分けができる
• 対応ブラウザから外す場合も比較的ラク（ページ数などによる）

バリデータに通るのは、使う時の理由（言い訳）としては中々です。
CSSファイルはIE用のハックで汚れがちなので、それらをまとめて別ファイルにできるのも良い感じ。

デメリットを考えてみる

• メンテナンス性が心配
• HTMLが汚れる
• 独自拡張ってどうなん？
• つーか ピー なブラウザを作ってる奴に従いたくない

こんな感じでしょうか。
一つ目のメンテナンス性というのは、（特に）ページ数の多いサイトの場合、条件を変更したり、あるいはConditional Comments自体を削除する時が面倒という物です。
これはphpやTemplate Toolkitでincludeさせれば、わりと解決できます。
残りの3つは気持ち的な問題だと思います。 HTMLが汚れるとは言ってもバリデータは通過する訳で。
バックスラッシュハックがアリなら、Conditional Commentsもアリかな、と最近思っています。

スタンドアローン版IEでの対応状況

スタンドアローン版IEだとConditional Commentsは無視される、という話を聞くんですけど、何故か自宅の環境だと認識されます。
うーん、環境の違いでしょうか。
ソースは Lucky bag::blog: IE7 と CSS ハックと条件付コメント です。

まとめみたいなもの

こうして見てみると、こだわりや思想を別にすれば「案外良いかも」と思えてきます。
IE開発チームもハックよりConditional Commentsを使うべしとしているので、将来的にも一応安心。 一応。

とは言え、CSSハックもそうなんですけど、ブラウザの振り分けは最終手段にしたいですね。
それにしても、どうせならCSS側でも同じような事ができればいいのになあ（候補にはあったらしい？）。

補足：

サンプルページのConditional Commentsは、条件付コメント(Conditional Comments)実験ページを参考にしました。

デザイン的にフォントサイズを小さくしたいんだけど、そうするとクリック領域が小さくなって困る･･････。 そんな時に使えるTipsをご紹介します。

サンプル

まあ、仕組みは超簡単で、a要素にpaddingを指定するだけです。
同時に:hoverに背景色（background）を指定しておくと、視覚的に分かりやすくて良いかもです。

何故かSafari2でピーカブー・バグのような物が発生したのでメモ。
詳しい発生条件は不明なものの、やはりfloatが関係している模様。

IEと同じく、floatしている要素にposition: relative;を指定する事で修正できました。

CSS HappyLifeさんで、コーディング大会みたいなのやりたいなぁ～というエントリが公開されてから、物凄い勢いで反響が集まっています。
自分の実力を試せるのはもちろん、他の人のコーディングを見られるのも凄く勉強になりそうですよね。

これから仕事が忙しくなりそうな予感がしますけど、「なあに、かえって耐性が付く」という心意気で是非参加したいでっす。

CSS Nite Vol.18の懇親会で行われたiwaimさんのプレゼンで、headerの部分は本当にidでいいの？という問いかけがありました。
多分、多くの人が行っているclassとidの使い分けは、複数回登場するかしないかだと思うんですけど、それはどうやら間違った基準なようです。

仕様書は？

そもそも、仕様書の定義としては、二つの違いはどうなっているのでしょうか。

id = name [CS]
この属性は、要素に名前を割り当てる。この名前は文書中で一意でなければならない。
class = cdata-list [CS]
この属性は、ある要素に1つのクラス名を割り当てるか、または複数のクラス名を設定する。幾つの要素に対してでも、同じクラス名あるいはクラス名群が割り当てできる。複数のクラス名については、空白文字によって区切らねばならない。

The global structure of an HTML document (ja)（HTML 4.01 仕様書邦訳）には、このようにあります（英語版は本人が読めないから勘弁な！）。
また、次のようにも書いてあります。

一方のclass属性は、ある要素について1つ以上のクラス名を割り当て、この要素が当該クラス/クラス群に属することが示され得る。

つまり、idは一意な名前を付ける場合に使います。
classがちょっとややこしい書き方（仕様書ってどうして解りにくい書き方なんだろう！）なんですけど、2つめの引用部分を見ると（そしてiwaimさんのプレゼンを見ると）、要素を分類する為に使える属性である事が解ります。

一意の名前と要素の分類。 これがclassとidの違いのようです。
わかりやすい例としてiwaimさんのスライドにも引用されていた、徳保 隆夫さんのTips/WebPage/class と id の違いとは？より引用します。

あなたの家で飼っている犬を、より細かな分類で雑種犬と呼ぶか、唯一無二の名前でポチと呼ぶか、そういう違いなのです。

あー、なるほど。 っていう感じです。
コーダーはclassでShunはid。 スターバックスはclassでスターバックスラテはid。 そういう事なようです。

となるとheaderは？

そう言われると、headerはclassな気がしてきます。 て言うか、そうなるとcontainerやmainColumnもclassになるような雰囲気です。
文書ツリーで親要素っぽい物にはidを振りがちですけど、むしろそれは逆なのではと。

header
│
│
├───h1
│
│
├───description
│
│
└───nav
　　　　├Home
　　　　├Blog
　　　　└Link

mainColumn
│
│
（略）

こんなツリーがあった場合には、「headerという分類に属するh1」とか、「headerに属するnavに属するBlog」という感じになるのかな。
つまり、idはこまかーい所まで突き詰めた名前で、classは大雑把な部分での名前とでも言いますか。

あ。 今ちょっと解りやすい例を思いついたかも。
classという袋の中に、idという品物が入っているみたいな？
これをheaderという袋の中に、h1やdescriptionなど各コンテンツという品物が入っていると置き換えれば･･････ほら！

ただしその他の点では？

ここまでは文書としてのclassとidの使い分けを考えてみました。
でも、特にidは文書としてだけではなく、プログラムで操作する時やアンカーを貼る時にもよく使います。
そうなると、headerにページ内リンクを貼る時にはちょっと困った事になります。

まあでも、idにせんが為に文書を変えたりするのは本末転倒だと思いますし、この辺りはアンカー用としてheaderにclassとidの両方を指定しても問題無いんじゃないかな、と思います。

ちなみに、Shunさんの職場ではidはプログラマの物。 classはコーダーの物。という区分けになっています。 これは業務を円滑にする為の判断なようです。
ただ、昨日のちょっとしたMTGでは「言ってくれれば状況によっては対応するよ」という話もありましたし、これが絶対という訳ではないようです。

まとめ

という訳で、一意の要素にはidを、グループ化する要素にはclassを。
更にWebサイトの機能として必要な部分にはidを、というのが一つの答えかな、と思いました。

おまけ

でもま、headerにidが間違いかと言うと、必ずしもそうとは言えないかと思います。
文書によっては一意かグループ化か、判断が難しい（人によって異なる）事もあるかと思いますし（例えば、ニュース記事での『東京都渋谷区に住む男性（無職 38才）』や『バールのような物』など、その記事内では一意な気もするけど、視野を広げるとグループとも取れる）。

実際の業務でどこまで追求するのか、という話もありますね。
経営側からすると、「どっちでも良いから早く仕事しる」って感じかもしれませんし。

どんなはてブコメントでもポジティブに受け取れるユーザーCSSを作ってみました！
昼食のたらもピザパンを食べながら！

この辺で試してみるとわかりやすかもしれません！

IEは未対応です！
苦情は受け付けません！ もちろん良い意味で。

Shunさんが働いているlivedoorは、「デザイン」、「マークアップ＆CSS」、「プログラム」がほぼ完全に分業されているので、それぞれの作業に集中する事ができます。
ただ、それにはデメリットもあると感じています。 他者の分野について触れる機会が少なくなってしまうんですよね。

コーダー改めマークアップエンジニア通称MEの視点からちょっと思ったのは、Blogのデザインを、もうちょっと遊んだら面白そうだなー、とか。
CSSだけでできるちょっとしたデザイン要素とか、CSSを使う立場じゃないと逆に思いつかなかったりするのかも？ と思ったりも。
なので今日は、そんなちょっとしたTipsをご紹介します。

リンクの下線をデザインする

サンプル
リンクの下線と言えば、良く見る直線が一般的ですけど、実は点線なんかも使えます。
これの仕組みはデフォルトの下線を消して、新たにborderプロパティで点線を指定するというもの。

もちろん、点線以外の線も使えますし、そもそも線以外のデザインもできます。 画像や背景色を使っても面白いかも。
その辺りの詳細は、実際にCSSを書く人と相談してみるのが良いと思います。 やっぱり良いモノって、良いコミュニケーショから生まれますよねｗ

フォームをフォーカスした時のデザイン

サンプル
このBlogのコメントフォームでもそうなんですけど、入力欄をクリックすると色が付きます。
このサイトはIEにも対応させるために（へっぽこな）JavaScriptを使っているんですけど、すみません使ってませんでしたorzIEを無視していいならCSSだけでもできます。

使うのは:focus擬似クラス。 コレをIE様は無視されあそばす訳ですね。
input要素やtextarea要素に、:focus擬似クラスでデザインを指定すればOKです。
これを工夫すれば、MacのSafari風のデザインを真似する事もできます。

ちなみに、Safariは「デフォルトのデザインが最も美しい」という自負があるからか（？）フォームパーツのデザインが効かない事が多いです。
これはこれで困ったちゃんですけど、確かにフォームに関しては、ユーザーが使い慣れたデザインがベストではあります。 デザインしすぎもよく無いんですね。

あとがき

今回はこの二つをご紹介しました。 タイトルに「その1」と付いていますけど、その2は思いついたり思い出したら、また書きますｗ

何やら偉そうにデザイナーさんへ提案のようなモノをしてしまいましたけど、逆に僕も他の分野の勉強もしないとなー、と思います。
IAやUIにも興味ありますし、簡単なJavaScriptを書けるようになったり単純なBBSを作れるようにはなりたい･･････。
うーん、1日が48時間あればいいんですけれどｗ

関連リンク

複数のclassをセレクタに指定する方法

複数のclassをセレクタに指定する際のメモ書き

複数のclassをセレクタに指定した際のIEのバグ

HTMLに複数のclassを指定する事、ありますよね。

<div class="sample code">

こんな感じの。
んで、CSS側で「sampleとcode、両方のclassに適合する要素」というセレクタを書くには、

div.sample.code {
 color: red;
}

こんな感じにすればOK。 もちろん仕様書にも書いてあります。
意外と見かけないから書いてみました。

関連リンク

複数のclassをセレクタに指定する方法

複数のclassをセレクタに指定する際のメモ書き

複数のclassをセレクタに指定した際のIEのバグ

先日の記事、複数のclassをセレクタに指定する方法の追記エントリです。
ちょっと条件が不明瞭なので、メモ書き程度にとどめておきます。
新たに判明した事実があったら、この記事を編集・追記します。

HTML

<div class="sample code">～</div>

CSS

div.code.sample {
 color: red;
}

このように、HTMLに書いたclassの順番とCSSで指定したclassの順番が異なると、IE6以下で指定がうまく適用されない事があるぽい。
ただし、サンプルのためのシンプルなファイルで試したら再現できなかったので、他にも条件があるのかも？

そもそも、現象が発生したのがスタンドアローン版のIEだったので、オフィシャル版でも同様なのか不明。

まあでも、HTMLの順番に習ってCSSを記述していった方が、可読性とかの意味でも無難だと思います。

関連リンク

複数のclassをセレクタに指定する方法

複数のclassをセレクタに指定する際のメモ書き

複数のclassをセレクタに指定した際のIEのバグ

複数のclassをセレクタに指定する方法でぴんどめさんからコメント頂いた件ですが、その後ぴんどめさんからサンプルファイルを送って頂けて、どうやら判明しました！
ぴんどめさん、わざわざありがとうございました！

HTML

<div class="sample code test">～</div>

CSS

div.hoge.test {
 color: red;
}

こんなソースがあった時に、本来ならば文字色は変わらないはずです。 現にFirefoxやOperaではそのように表示されます。
しかし、なんとびっくりIE様は文字色を赤にしてしまうのです！ なんてこった！

どうやらIE様は、複数のclassを使うセレクタは、最後の一つのclassしか見ていないようです。 ドジッ娘属性にも程がある。

なお、この現象はIE5.0 IE5.5 IE6（全てスタンドアローン版）で確認されました。
IE7とSleipnir2.5.10では確認されませんでした。
プニルって、IE7のエンジンなのかな･･････。 公式をざっと見ても分らなかったので、その辺今度調べたいです。

何にせよ、現段階では、他の手段でセレクタを指定した方が良さそうですね。

おまけ

と言う事は、IE様とそれ以外のブラウザの振り分けに使えない事もないのかな。 激しく分りづらいですけどｗ
あ、あともちろん、その際は文書に沿ったclassで。

前に作ったやつを、体裁を整えてuserstyles.orgで公開してみたっす。 相変わらずネタです。
nowaで、ざっくりと使い方を説明しています。

いつものようにuserstyle.orgに登録しました。
今回はマジメな内容です。

いやー、何かを作って発表するのって凄く楽しいですね。
エンジニアさん達の気持ちが、ちょびっとだけ分かるような気がします。

僕もnowaで一度経験していて、さっき斜め前の人も普通のBlogでハマっていたので、情報共有の意味も込めてエントリ。

Blogだけに限った話ではないんですけど、CGMサービスを作る時には、デフォルトスタイルシートのリセットには気をつけた方が良いです。

* {
 margin: 0;
 padding: 0;
 font-size: 100%;
 font-style: normal;
 font-weight: normal;
 text-decoration: none;
}

いつもの習慣とかでこんな指定にしてしまうと、ユーザーが<small>要素や<u>要素を使った場合に不都合が起きます（この辺の要素の是非はここでは置いといて）。
とは言えもちろん、要素セレクタを使って指定しなおせば問題ありません。
その際はul要素のmarginが意外と盲点なので、気をつけたい所です。

userstyles.orgからどうぞ。
タイトル通りです。 て言うか、DL数的に初見な人も多い気がしたりしなかったり。

やってる事

• トップページでコメントのあるクリップはハイライト表示
• ユーザーページでナンバリング
• ユーザーページは偶数と奇数で背景色を分ける
• タグクラウドにhoverスタイルを適用
• ページングリンクのホットスポットを広く
• レートにhoverした時のカーソルの形状を変更
• その他色んな所のhoverスタイル

大体こんな感じです。 細かい事をたくさん。
自分が使っていて、「もうちょっとこうだったらいいのにな」と思った部分を書いてみました。

なお、コードが一部しょんぼりした感じなのは触れない方向でお願いします。

昨日の記事で、livedoorクリップのユーザーCSSを更新した事をお伝えしました。
するとonkさんからはてブコメントをいただきました。 曰く、

おおおおお，hover とかがえらく変わってる！ページング部分はどうせ AutoPagerize で移動するから使いづらさは感じていなかったなぁ．

と言う訳でAutoPagerizeフラグが立ったので、対応しました。
livedoor Clip CSS | userstyles.orgのUpdateボタンから更新してください。

やっている事

• AutoPagerizeを使用した際にくずれていた問題を修正
• 「page」表示とhrの罫線が地味だったのでスタイルを指定
• AutoPagerize部分のcounter-incrementができなかったので、とりあえず適当な文言を入れた。 後日また挑戦
• その他細かい部分の調整とかいろいろ
• ついでにソースを整理した

残念ながら偶数行と奇数行で別々の背景色を指定するのは、AutoPagerize部分では難しいぽいです。
li class="clip"の部分をli class="clip clip-odd"とli class="clip clip-even"とか、なんかそんな感じにしてくれたらもの凄く楽なんだけどなー。 と呟いてみる。 ついでにSkype送っておこう。

でも、グリモンに挑戦する良いチャンスかも。 なんて。

ブラウザのデフォルトスタイルをリセットする際にユニバーサルセレクタを使用すると、読み込みが遅くなるとか言う話があるんですけど、具体的にどれくらい遅くなるのかという話は聞いた事がありません。
なので、調べてみました。

ソース

使用したソースは以下の2種類です。
なお、2番目のソースはYUIで公開されている物を使用しました。

* {
 margin: 0;
 padding: 0;
}

body,div,dl,dt,dd,ul,ol,li,h1,h2,h3,h4,h5,h6,pre,form,fieldset,input,textarea,p,blockquote,th,td {
 margin:0; 
 padding:0; 
} 

それぞれを当サイトのcssファイルに書いて、Firebugでcssファイルの読み込み時間を100回づつ計測しました。
計測したのは、2007年9月2日の夜23時頃、ADSL回線の自宅からです。
その結果のcsvファイルをアップしておきます。

結果

両者の読み込み時間の平均値を計算しました。 単位はmsです。

ユニバーサルセレクタ平均値

151.76

タイプセレクタ平均値

197.36

あれ？

なぜかユニバーサルセレクタの方が軽いという結果になってしまいました。
100回だと足りなかったのかも。 て言うか、こういうのって何回くらい計測する物なんでしょうか。 1000回くらい？

読み込みが遅くなるという話はどこから出た？

そもそも誰が言い出したんでしょうか？ よく引き合いに出されるのはEric Meyer氏だったりしますけど、全称セレクタを用いたスタイルの正規化 | Web標準Blog | ミツエーリンクスを読むと、

彼が全称セレクタを用いない理由として挙げているのは負荷云々ではなく、正規化の影響がフォームコントロールに属する要素にまで及ぶのを避けるため、としています。

とあります。 これは主にborderの事を言ってると思うんですけど、確かに、ユニバーサルセレクタでborderまでリセットしてしまうとのはどうかな、と思います。 フォームパーツとか、逆に手間が増える感じ。

個人的な意見

僕個人は、デフォルトスタイルをまとめてリセットをするのは基本的にはmarginとpaddingのみです。 場合によっては、font-sizeやline-heightなどが加わります。
borderをリセットする必要があるのはimg要素とfieldset要素くらい？

て言うか、もし読み込み云々という理由でユニバーサルセレクタを使わないのであれば、YUIやいわゆるリセット用CSSをそのまま使いまわすというのも違うんじゃないかなと思います。 そのサイトで使っている要素のみを書くべきで。
でもそうなると、更新の時とか面倒な気が。

あるいは、*{ margin : 0 }はもう古い！？ - Emotional Webでのコメント欄のやり取りも興味深いです。 今後、そういったブラウザが登場するかはさておき、考え方として。

結論

borderをリセットしなければ、ユニバーサルセレクタで問題無いのでは。

おまけ

ここまで書いて気づいたんですけど、Firebugが計測してるのって、「ファイル読み込み→ほげほげする→実際の描画」までの時間でいいのだろうか。
もしもファイルの読み込みのみだったら、この記事はだいぶ意味無い事に。。。

何にしても重箱の隅すぎる･･････ｗ

1. hidedenのわ！ - 新nowaトップについて。
2. hamashun nowa - nowaのポータルTOPをXGAの人に優しくするユーザーCSS
3. --- 地球で働く日本人のブログ --- - nowaトップをハマシュン専用にするGMスクリプト
4. キリンノワ - nowaでもっとみんなのブログを読みたくなるスタイルシート
5. hidedenのわ！ - nowaいじり。

という流れ。 正直、楽しかった。 でも、やっぱりネタ度でグリモンに負けちゃうなあ。
なので、自分の中のグリモン熱が上昇中。

IE5.xやIE6の互換モードがidやclass名の大文字小文字を区別しないのは、わりと知られています。
これとラクダ式id、class名を使えば、cssの振り分けができるなーとか思いつきました。

ちなみにラクダ式とは、「mainContent」や「subNavi」など2単語以上からなるid、class名を、ハイフンではなく2単語目を大文字にして可読性を上げる書き方の事です。
camelと英語で呼ぶ人もいるとか。 個人的には結構好き。

HTMLとCSSのソース

/* for modern brow */
#sampleA {
 color: blue;
}

/* for IE5 6 */
#samplea {
 color: red;
}


<p id="sampleA">ほげほげ</p>

これで、IE5.xとIE6互換モードでは文字が赤に、Firefoxなどでは青になります。
なお、他の人が見ると何をやっているのか分かりづらいので、コメントを残しておくといいと思います。

ご注意

この記事は、「考え方」を紹介する物です。
「サンプルソースをコピペして使いまわせる！」という類の物ではありませんので、ご注意ください。

魔の角丸

マークアッパーの頭を悩ませるデザインの一つに、角丸があります。 ただの角丸ならまだいいんですが、グラデーションがかかっていて可変幅だったりすると途端に厄介な存在になります。

安直に考えたスライス

厄介さの原因は、画像の枚数の多さです。
グラデ角丸＋可変幅の場合、通常であれば8枚の画像をスライスする事になります。 CSS2.1では1つの要素に指定できる背景画像は1枚だけなので、要素も8つ必要になります。
もちろんdivを8個使ってしまえば実現は容易ですが、その手法は躊躇するべきです。 文書の意味付けにならないdivを増やす事になるので。

考え方とサンプル

ではどうするかと言うと、その文書に元から存在する要素を活用するのがいいと思います。
サンプルを用意しました。 IE5.5以上、Firefox、Opera、Safari、MacIE5.2で確認しています。
ソースがかなり複雑ですが、ここで全部を理解する必要はありません。 まずは画像のスライスを解説します。

工夫したスライス

左上、右上、左中、右中、左下、右下、の計6つです。 ここでのポイントは、上下の画像を片方ずつ長めにスライスしている事です（サンプルの画像を「背景画像を表示」などで見てみると解りやすいと思います）。
ここで気付いた人もいるかもしれませんが、左上と右上の画像は重なるように指定しています。 ホチキスの芯ケースって言うかスライド式ケータイって言うか。
左下と右下も同様ですが（サンプルは左右の長短が逆になっています）、左中と右中は小さな画像になっています。 角丸の中央部分は、background-colorプロパティで指定すればよいので。

存在する要素に画像を割り充てる

スライスが終わったら、どの要素にどの画像を指定するかを決めます。
まず最初に決めるのは左中と右中の2つです。 これは縦方向の可変性を保つために、大外にある2つのdivに指定します（本当はdivも1つにしたかったのですが今回は断念しました）。

そして、記事の見出し部分が左上、日付部分が右上、「Tags」が左下、「Tags example Test」を囲うdl要素に右下の画像をそれぞれ指定しています。
もちろん、画像を指定しただけでは角丸の見た目にならないので、サンプルのソースのようになんやかんやして、うまい事成形します。 恐らく、ここが一番難航すると思います。

なんだか自分で書いてて解りにくいなと思ったので、それぞれの画像の色を変えたサンプルを用意してみました。 こちらだと感覚的に掴みやすいかも。

まとめ

つまる所言いたいのは、「むやみにdivを増やさないでもそこにある要素でやりくりすれば、ある程度はなんとかなる」という事です。
今回のサンプルはBlogぽいデザインだったので、見出しなどに画像を指定しました。 違うデザインなら、指定する要素も当然変わってきます。

ここまで解説してきてなんですが、divを1つ減らす労力・時間・人件費とその恩恵を比べると、必ずしもやるべきだとは断言できません。 でも、「そういうやり方がある」事を知っておいたり、「できるようになっておく」事は大事だと思います。
あるいは、そういう心構えでいるかどうかが、コーダーと（いわゆる）マークアップエンジニアの違いの一つかもしれません。

サンプルDL

サンプルをzipにした物を用意しました。

次回予告

次回はもっと変態的な組み方をご紹介する予定です。 殆どネタです。

ご注意

この記事は、実用度は余り高くないような気がします。 わりとネタ的？

4つの要素でグラデーション角丸＋リキッドレイアウト

前回の記事では、6つの画像と要素を使って、グラデ角丸＋可変幅を存在する要素を駆使して実現する、という考え方を書いてみました。
今回はそこから更に踏み込んで、1枚の画像と4つの要素で同じデザインを実現してみたいと思います。

今回もサンプルを用意しました。 対応ブラウザはIE5.5以上・Firefox・Opera・Safariで、MacIEはdl付近がちょっと怪しいかもしれないので、週明けに会社で確認します（自宅にMac無いんす）。　あとIEで幅を極端に狭めると、文字の折り返しが若干おかしいです。
HTMLは前回とほぼ同じ物ですが、余計なdivが1つ減っています。

コンテキストメニューなどから背景画像表示すると分かるんですが、一枚の大きな画像を用意しています。 これを4つの要素で四隅に指定しています。
やはり、ただ指定しただけではちゃんと表示されないので、あれこれ工夫する必要があります。 コツはWrapしている要素に下部の画像を指定する事でしょうか。

メリットとデメリット

無駄な要素を減らせるのは利点なのですが、縦方向の幅に限界があるので、例えばBlogの外枠に採用するのは難しいかもしれません（画像のサイズとか気にしなければまた別ですけど）。
小さめなコラムとかに使ってみるといいかもしれないです。

サンプルDL

やっぱりDLしてさわれた方が解りやすいと思ったので、サンプルをzipにした物を用意しました。
なお、前回の記事にも追加しましたので、そちらもどうぞ。

次回予告

次回は、まだ勉強中の分野ではありますが、jQueryを使ってグラデーション角丸＋リキッドレイアウトを作ってみます。

JavaScriptとかjQueryとか勉強中なので、勘違いしている部分があるかもしれません。 もし誤りがあったら、ご指摘頂けると嬉しいです。

4つの要素でグラデーション角丸＋リキッドレイアウト

前回と前々回では、CSSで半ば無理やりグラデーション角丸＋リキッドレイアウトを組んでみました。 この種類の角丸デザインはCSSを書く上で必要な要素の数が多くなってしまうので厄介、というのがこれまでのあらすじ。
今回はCSSだけにこだわらず、スクリプトを使ってみたいと思います。

jQuery使用

jQueryを使います。 jQueryの特徴は色々あるんですが、ノードの取得にCSSセレクタみたいな書き方ができるのがとても気に入っています。 普段CSSを書いている人にはとても使いやすいです。
今回のサンプルでは使ってないですけど、jQuery越しにCSS3のセレクタが使えたりするのも魅力です。 しかもIE5.5以上に対応。

サンプル

今回もサンプルを用意しました。 対応ブラウザはIE5.5以上、Firefox2、Opera、Safariです。 MacIEはjQuery自体が対応していないみたいです。
例によってDL版も用意しましたので、こねくりまわしてみてください。

jQuery便利すぎる

サンプルのJSソースはとてもシンプルです。
jQueryは、wrap()メソッドを使うとその要素をWrap（包むの意味。ちなみにサランラップのラップもこれ）してくれます。 例を挙げると、

$("div.entrytWrap").wrap('<div class="wrap1"></div>');

は、「<div class="entrytWrap">を<div class="wrap1">でwrapせよ（囲え）」という命令になります。 その結果、

<div class="wrap1">
 <div class="entrytWrap">
 </div>
</div>

こんな結果になります。 これでdivが一つ増えました。 あとはこの繰り返しでdivを増やして、その増やした要素に対してCSSで背景画像を指定するだけです。

サンプルの解説

サンプルでは少し工夫した書き方にしていて、量を減らしてあります（多分、工夫の余地はもっとあるんでしょうけど）。
ノードの取得はCSSのセレクタのように、カンマ区切りで複数指定が可能です（DL版に入っているkadomaru.jsのdiv.hogehogeって辺りがそれです）。

ちなみに、JavaScriptをオフにしている環境などを考えて、その場合はborderで囲われるようにしてあります。

それってどうなの？

「JSで要素を増やすんなら、HTMLに直接書いても同じじゃん」と思う人がいるかもしれません。 しかし、HTMLに直接記述するのとDOMを操作して要素を追加するのでは意味が違うと思います。
DOMを操作して追加した要素は、（例えばJavaScriptでもって行ったなら）JavaScriptがオフの場合は現れません。 HTML文書単体として見ればその要素は追加されていないと言うか、HTMLは（余計なdivによって）汚されない。
サンプルのclass名がわりと適当な感じなのも同様の理由です（見栄えを考えるとそれっぽい名前にした方がいいかもしれませんけど）。

DOMの仕様書にその辺りの説明（DOM操作によって追加されたノードの扱い、みたいな）があるかなと思って探したんですけど、見つけられませんでした（見落としてるのかな）。

とは言え、本来CSSが担当するべき「デザイン（表現）」をスクリプトで補っているのは確かで、そこはちょっとどうかなと思う所ではあります。 ただまあ、デザインを再現する際に文書上必要な要素のみで行うのが難しい（事がままある）現状では、手段の一つとして覚えておいてもよいのではないでしょうか。

おまけ

JavaScript楽しい！ これまでのHTML+CSSでは難しかった事が簡単にできたりします。 とは言ってもまだDOMごにょごにょぐらいしかできないから、「JSはDOMだけじゃ無いからね」って会社の人達にまた言われそう。
今回のサンプルもミスターjQueryのabuiさんに手伝ってもらって完成できたしなあ。

つまり何が言いたいかと言うと、hamashun.comはRoppongi.JSに超期待してるって事です！＞＜
参考：UNIXに触り初めて一応7年・・・だけど・・・。 - devlog.holy-grail.jp

2manjiのユーザーCSSを書きました。 投稿の際の改行を反映して表示します。

2manji凄いなあ。 「これからはシンプルなサービスだ」とは言われてましたけど、接し方がシンプルなのに内容は濃くなりうるのが凄い。
インタビューって言われると、ついつい人生観とか書きたくなっちゃうんですよね。 …って、なんだか年々説教臭くなってきてる気もしますが＞＜

• Interview with hamashun
• 2manjiのユーザーCSS

ご注意

CSSハックの使いすぎはあなたのコーディング能力を低下させる原因になります。 用法容量を守って正しくお使いください。

XML宣言の有無で変わる解釈

Webtech WalkerさんでIE7用のハック（*+html body）で指定したスタイルがOperaにも適用されるという記事が公開されていました。
Webtech WalkerさんではWindows版のみの検証だったようなので、Mac版と現在β1である9.50でも検証してみました。

結果は、Mac版Opera9.23では適用され、Windows版Opera9.50β1では適用されませんでした。

もし *+html 形式のCSSハックを使っていたら、（9.50に移行すれば影響が無いとは言え）余裕があればIE7のみに適用されるCSSハックに書き換えておいた方がよさそうですね。

余談

IE7のCSSバグとOpera CSS Hack | F+R (FplusR)の記事は、XML宣言ありの状態が前提だったんですね。 ずっと疑問だったんですがやっと解りました。

原因とかよく解らないんですが、IE6とIE7で謎の挙動に悩まされたのでメモ的にエントリしておきます。

症状

IEでウィンドサイズの変更を行うと、position: relative;を使用した要素がズレます。 お気に入りバーを出しても同様。

CSS

div {
 position: relative;
 width: 300px;
 margin: 0 auto;
 
 height: 300px; /* 見やすくするための指定 */
 background: skyblue; /* 見やすくするための指定 */
}

h1 {
 position: relative;
 top: 10px;
 left: 20px;
}

HTML

<div>
<h1>Test Title</h1>
<p>hogehogehogehoge</p>
</div>

ウィンドサイズ変更前

ウィンドサイズ変更後

例えば上記のコードで表示されたブラウザの画面サイズを変更すると、ブラウザウィンドの端からdivまでの長さが変更される…はずが、何故かh1のみ取り残されたようになります。

発生条件

いまいち不明＞＜ 単純にこのサンプルコードを使用しても再現できません。 なので、スクリーンショットは編集したイメージ画像です。

修正方法

body要素にposition: relative;を指定すれば他のブラウザと同じ表示になります。 原因が解らなくて腑に落ちませんけど＞＜

CSS Nite in Ginza, Vol.23に行ってきました。 今回のゲストはあの大藤幹さん。 大藤さんの名著CSSプロフェッショナル・スタイルは、コーディングの勉強を始めたばっかりの頃に買って物凄く役に立った本だった事もあって、かなり期待していました。

開演前

19時開演なので18時30分に到着したんですが、既に座席は満員でした。 さすがに凄い人気です。

テーマ

大藤さんは雑誌Web Designingに『CSS Analysis』という連載をしていて、その内容は世界のWebサイトを取りあげて色んなテクニックを紹介するという物。
今回のテーマはそれの特別版みたいな感じで、『CSS Analysis Live!』でした。
なお、内容はあくまで解析したサイトの結果であり、それが正しいとか、或いは大藤さんの意見である、という訳では必ずしもないようでした。

アジェンダ

• この1年間の流れ
• トピックと事例
• これからのCSS

この1年間の流れ

新しいネタが減ってきた

CSSネタは成熟した感があるのでは。 ブラウザごとの特徴や対策や組み方のTipsなど、大抵の情報は出揃ってしまった。

（hamashun注：以前書いたんですけど、僕も同じような事を感じていました）

ハックを使わないサイトが登場した

CSSハックを全く使っていないサイトを取り上げてから、1年経っている。 しかしハックを使わないサイトは使っているサイトにあらゆる点で勝っている訳ではなく、例えばブラウザによる若干の差異などのデメリットが存在する。

世代交代で繰り返す歴史

画像置換の問題が顕著（後述）。

英語圏以外の国のサイトが増えた

連載当初は英語圏が100%だったが、最近ではドイツ、ブラジル、ルーマニア、チェコ、フランス、イタリアなど多岐に渡っている。
ちなみに取り上げる際は言語は考慮していなく、単にソースコードを見て決めているとの事。

言語圏の違いで制作スタイルの差が出てきた

昔は英語圏がNo,1だったが、最近はそうでもなくなってきている。 ドイツは追いつき追い越している印象。 そういえば思い返すと、2003年のW3Cサイトのリニューアルコンテストで優勝したのはドイツの人だった。
日本も結構イケてる。

トピックと実例

CSSハックの現状

• * html といういわゆるスターハックを殆ど見かけなくなった。
• clearfixも以前より減っている
• CSSハックを一切使わないサイトも登場した

世代交代による画像置換問題

画像置換そのものが悪という風潮で、使われない時期があった。 しかし、最近は普通に使われている。
その手法も、以前は古いブラウザに対応する為にtext-indent: -9999px;などとしていたが、最近は古いブラウザは無視したコードが増えている。 これらは若い製作者に多い傾向な模様。

古いブラウザの対応

英語圏では切り捨て傾向にある。 ドイツやオーストリアでは、IE5.0、IE5.5なども対応している事が多い。

（hamashun注：まあ、この辺はその国ごとのビジネス的、リテラシ的な事情にもよりそうですし、一概に優劣は決められないのではと思います）

CSSファイルの分割について

一時期、非常に細かく分けているサイトがあったが、最近はかなりシンプルな分け方が多い。 例として紹介された分け方で印象に残ったのは、いわゆるLiteboxなどのライブラリ用CSSを別ファイルに分けている事だった（弊社だと開発しちゃう事もあるので同じファイルに記述する事も）。
また、ブラウザの振り分けにはコンディショナルコメントを使っているサイトが多い（hamashun注：スターハックが減った理由も恐らくここにあるのでは）。

リセットCSS

最近は見かけない（！）。 連載で取り上げたサイトでは、英語圏以外では1年前くらいからゼロ件。 ただしこれは、一括してリセットしていないという意味で、marginとpaddingだけはリセットしたり、必要な箇所だけでリセットしているサイトはあるとの事。
でも、本当に全くリセットしていないサイトもあって、そのサイトはブラウザによって若干の表示差異はあるとの事。

（hamashun注：個人的にはこれには結構驚きました。 現状でmarginとpaddingのリセットをしないメリットはあるんでしょうか。
なお、この記事の最初にも書きましたが、この講演はあくまで事例を紹介する物であり、それが必ずしも優れているという訳ではないので注意してください）

ページの上部が大きな画像になっているサイト

ヘッダー部分を大きくとって、そこに大きな画像を配置するサイトが増えた。 これによって文字サイズを極端に変更してもサイトのイメージが損なわれない。

超大きい画像を使ったサイト

3000pxとかの大きな画像を使ったサイトも増えてきた。

（hamashun注：nowaのヘッダ画像も、リキッドレイアウトに対応するために大きな物が多いです。 2000pxとか。 max-widthプロパティと合わせて大きなヘッダ画像を使う方法がわかりやすいのでは）

エラスティックレイアウトの登場

2回取り上げた。 国はイギリスとアメリカ。 最近は余り見かけない。
これは_blankによる別窓問題と似た問題を引き起こす可能性があって、便利だと思う人もいれば迷惑に思う人もいるかもしれない。

これからのCSS

足すコーディングから引くコーディングへ

追加修正などのたびに足せば足すほど、または（ファイルを）分ければ分けるほど問題が増えるのではないか。 例えば、

• 何か問題が起きたらハックを使う
• 何でもかんでもデフォルトスタイルリセット
• CSSファイル自体も分けまくる

これらによって問題が発生する可能性がある。

ドイツ式シンプルコーディング

ドイツのコーディングはシンプルでキレイらしい。 余計な事はせず、見通しのいいCSS.
キレイなソースなどと聞くと「それが何の得になるの？」と言う人がいるが、そういう人はコーディング自体が目的になってしまっている。
コーディングとはあくまで目的を達成するための手段であり、短くキレイに書いておけば、その後の作業もラクになる。

（hamashun注：ここがちょっとピンとこない人もいるかもしれませんが、つまりコーディングが目的になっているというのはその場のコーディングを終わらせる事が目的になっていて、運用を考えていない状態なのではと思います。
自分の書いたコードを半年ぶりに編集する事を考えたら、キレイなコードの方がいいですよね）

プロパティの降順

連載でとりあげた最近のサイトは、結構バラバラ。 でも読みづらくはない。 プロパティは降順よりは数が読みやすさに影響するようだ。
また、重要なプロパティを上の方に持ってくるサイトもあった。

質問コーナー

Q:ドイツはCSSがキレイだというけど、HTMLはどうなんですか？

A:HTMLもキレイ。 というか、この連載はHTMLがキレイである事がまず前提。 そこから更にCSSを見ている。
基準のひとつとなるエピソードは、css Zen Gardenを取り上げようと思ったが、HTMLがアレだったのでやめたというもの。

Q:コンディショナルコメントの是非

A:最近増えている理由は不明。 使っている人が多くなってきたから他の人も使う、という循環かも？
ただし、Microsoftの中の人的には「使わないで」と言っていた。

Q:CSSファイルを分割しないWebサイトの規模は？

A:個人Blogが多い。
余談ながら森田雄さんは「分割するとセッションが増えるからそういう手法を紹介しないでほしい」と言っていたそう（読み込みのロスが増えるという事）。
益子さんはガンガン使う派らしい。

最後に

情報に翻弄されない事が大事。

• 今回の講演に影響を受けて手法を変えても、他の情報でまた変えたくなるかもしれない
• 自分の仕事がラクになるようにしよう
• 労力とメリットをよく考える
• 定番手法はそれだけ多くの人のノウハウが詰まっている
• 最後は自分で考えるべし。 自分の道を行け

感想

久しぶりにガチなCSSネタを聞けて楽しかったです。 業務に使えそうな部分もありました。
お会いするまではなんとなくもっと固い感じの方なのかと思っていたんですが、全然そんな事はなくて打ち上げでも気さくで優しい方でした。

最初に結論

ブラウザの差異を最小限だけリセットするCSSって浅漬けCSSって感じじゃない？

きっかけはTwitter

昨日、@reaさんがTwitterにポストした一言がきっかけです。

最近、ぬか味噌 CSS を使わなくなった。デメリットの方が多い気がする。

それに対する@hamashun（僕）の反応がこんな感じです。

@rea 実はぬかみそ的な CSS は使った事がなかったりします。　必要な要素への margin と padding のリセットと、あとは border 消したり、とかは大抵毎回使いますけどもー。　浅漬け CSS 。

ちなみにここでのborderを消す、というのはimg要素にリンクをした時に表示されるborderについてです。 フォームのborderとかは消していないです。
Twitterのログだけだと説明不足だったのでここで追記。

@reaさんから頂いた更なる反応。

@hamashun 自分も最近はそんな感じです。浅漬け CSS いいですね！

そもそもぬか味噌CSSとは

@reaさんのポストが解りやすいです。

@hamashun ぬか味噌はデフォルトスタイルをできる限り統一しよう、っていう考えですよね。

「ぬか味噌」というネーミングは、上ノ郷谷さんのエントリ、スタイルシートを分けて管理する方法をまとめるが恐らく初出です。
上ノ郷谷さんのサイト、2xup.orgのぬか味噌CSSを見てみると、実際にどのような指定をしているのかが分かります。

言うなれば「オレオレデフォルトスタイル」って感じですね。
（もし誤解されると困るので念の為に書いておくと、この「オレオレ」にネガティブな意図はありません）

浅漬けCSSについて色々

浅漬けCSSの定義

必要な要素へのmarginとpaddingのリセット程度を記述した、シンプルなCSSファイルやソースコードを浅漬けCSSと呼びます。
サイトによって記述する内容が変わる事もあります。

ぬか味噌CSSと浅漬けCSSは、どっちが優れているの？

優劣はありません。 慣れやサイトの種類によって使い分けるといいと思います。

サンプルコード

div,span,h1 ...(必要な要素が並ぶ)... p {
 margin: 0;
 padding: 0;
}

a img {
 border: none;
}

謝辞的な

Twitterで言及くださった皆様（非公開にしている人は表示されません）

最近はアルファチャンネルを含むPNG画像を利用したサイトが増えてきたように感じます。
2008年9月号のWeb Designing誌でも特集が組まれたりと、関心も高まっているようです。

ただ、そこで問題となるのはIE6のアルファチャンネル問題。 何らかの手段でこれを解決する必要があります。
少し前の仕事でこの問題を解決する必要があり、いくつかのライブラリを試してみたので、それをまとめてみます。
なお、img要素ではなく、CSSの背景画像で使用する場合として検証しました。 img要素にだけ適用したい場合には、もっとシンプルな方法があるかもしれません。

概ね共通する事

標準準拠のCSSのみでは不可能

IEの独自拡張の、filterプロパティを使う必要があります。
CSS内に記述する方法やhtcファイルを使う方法、JavaScriptを使う方法でも、結果的にはこのfilterプロパティのAlphaImageLoaderフィルタを使用しています。

IE PNG Fix 2.0などを除いてbackground-positionとbackground-repeatは使えない

多くのライブラリでは、背景画像の繰り返しと位置指定ができません。
この問題はかなり深刻な悩みの種でしたが、IE PNG Fix 2.0の登場でひとまず解決したと言えそうです。

A Better IE 5.5 and 6 PNG Fixのライブラリについて

Post Production ? A Better IE 5.5 and 6 PNG Fixという記事に掲載されているライブラリでも繰り返しと位置指定ができるとの事ですが、試したところうまく動かせませんでした。
サンプルが無く、全文が英語なので僕の使い方が間違っていたのだと思いますが、導入はIE PNG Fix 2.0の方が簡単だと思います。

謎の文字列が登場する

filterプロパティのAlphaImageLoaderフィルタを使っているので、見慣れない構文が登場します。
詳細はとみのホームページ内のAlphaImageLoaderに詳しく載っています。

CSSに直接filterプロパティを記述する方法

サンプルコード

div {
  background: url(alpha.png);
}

* html div {
  background: none;
  filter:progid:DXImageTransform.Microsoft.AlphaImageLoader(sizingMethod=crop,src=http://example.com/img/ie.png);
}

* html div a {
  position: relative;
}

コード解説

一つめの規則集合はIE6以外のブラウザに対するものです。

二つめの規則集合はIE6用のものです。 ここではスターハックを使って振り分けましたが、方法はなんでもよいです。
backgroundプロパティをnoneとしているのは、filterプロパティで表示される画像はbackgroundプロパティで表示された画像とは違う物だからです。

三つめの規則集合もIE6用のものです。 ここでのスターハックは必須ではありません。 また、この宣言自体も必須ではありません。
この宣言が必要になるのは、指定した要素の子要素にa要素やonclick属性、onmouse属性などが含まれる場合です。もちろんセレクタの a は当該要素に合わせたものになります。

メリット

• 記述自体はシンプル
• IE6とそれ以外のブラウザで、別々の画像を指定する事ができる（繰り返し表示できない件の対策として巨大な画像を使う場合など）

デメリット

• 画像の指定はHTMLを基準に考える必要があるので、絶対パスでの指定が現実的になる
• 独自拡張のプロパティを使用する
• 記述が多くなると面倒

雑感

実装の際には数行のコードを加えるだけなので、手軽に使えます。 反面、適用したい画像の枚数が増えると比例して規則集合が増えてしまいます。
また、パスの指定にクセがあったり背景画像のようには扱えないなど、backgroundプロパティの感覚で記述すると思い通りにならない事があります。

ヨモツネットの手法

この方法は、CSS ファイルだけで IE 6 の背景に設定した png のアルファチャンネルを有効にする | ヨモツネットで紹介されたものです。
behaviorプロパティ自体については、古い記事ですがTime Off for Good Behavior: Internet Explorer 5における DHTML Behaviorで概要を掴めます。

サンプルコード

div {
  background: url(alpha.png);
}

* html div {
behavior: expression(
this.style.behavior || (
this.style.filter = "progid:DXImageTransform.Microsoft.AlphaImageLoader(sizingMethod=crop,src='"+this.currentStyle.getAttribute("backgroundImage").slice(5,-2)+"')",
this.style.backgroundImage = "none",
this.style.behavior = "none"
)
);
}

* html div a {
  position: relative;
}

コード解説

メリット・デメリットと合わせて元記事で詳しく解説されているので、そちらをご参照ください。

雑感

メリットは元記事で紹介されていますが、相対パスで記述できる事によりHTMLのディレクトリ構成に影響されないので、背景画像で使う際には特に便利だと思います。

ただ、IE6とそれ以外のブラウザで同じ画像を使う事になるので、繰り返し表示ができない為に大きめの画像を用意する場合には、Firefoxなどにもその画像が読み込まれてしまう事になります。

JavaScriptを使う方法

色々あるようなのですが、今回は試す範囲に含めませんでした。

IE PNG Fix v2.0を使う方法

IE PNG Fix v2.0は2008年9月現在で開発中のライブラリです。 Ver,UPに伴い記事と異なる部分が出る可能性があります。

サンプルコード

<style type="text/css">* html div.sample { behavior: url(iepngfix.htc); }</style>
<!--[if lte IE 6]><script type="text/javascript" src="iepngfix_tilebg.js"></script><![endif]-->

コード解説

style要素を使っているのは解説用コードだからで、CSSファイルに記述する事ができます。
また、条件付コメントを使ってIE6にのみJSファイルを読ませていますが、他の方法でも問題ありません。

独自拡張のbehaviorプロパティを使って、htcファイルを読み込んでいます。
iepngfix_tilebg.jsも合わせて読み込む事によって、background-positionプロパティやbackground-repeatプロパティと同様の効果を得られます。

注意点として、background-positionプロパティとbackground-repeatプロパティの効果を得たい場合には、iepngfix_tilebg.jsを読み込ませて、当該要素に任意のclass属性かid属性を付ける必要があります。 大事な事なので二度言いますが、この属性値には任意の値が付けられます。

もし位置指定や繰り返し表示を必要としないなら、iepngfix_tilebg.jsを読み込ませる必要はありません（Ver,1がそれにあたります）。

メリット

• 今回紹介した中で唯一、background-positonプロパティとbackground-repeatプロパティ相当の機能がある
• 繰り返し表示ができるので、画像を分ける必要がない
• ライブラリを読み込むだけの簡単さ

デメリット

• 独自拡張を使う必要がある
• 何らかのclass属性かid属性が必要
• 若干重い？ 使用数が多いとそれだけ重くなってしまう
• 他のJSに影響が及ぶ可能性がある

雑感

個人的に現在最もアツイ方法。 これまで不可能とされていた背景画像の位置指定と繰り返し表示ができます。
しかも、何がしかのclass属性かid属性が必要とは言え、機能の為の値を強制され無い事がHTML的にとてもCoolです。
また、a要素などへの指定が必要ない点も便利です。

ライブラリ入手先

Ver,1.xはIE PNG Fix - TwinHelixから、Ver,2.x(のテストバージョン)はBeta Testing Area - TwinHelixからダウンロードできます。
Ver,2が正式版になったら、現在のVer,1と同じ場所に移動すると思われます。

ライセンスについて

iepngfix.htc内のライセンスについて書かれている部分は以下のようになっています。

This is licensed under the GNU LGPL, version 2.1 or later.

英語2のhamashunが超頑張って翻訳すると、多分、「このライブラリは GNU LGPL バージョン2.1（以降） の元に配布されています」みたいな感じ、だと思います。 たぶん！
（意味的に誤解を与えてしまう訳だったら、ツッコミいただけるとありがたいです）

LGPLについて参考になりそうなページ

• GNU Lesser General Public License - Wikipedia
• LGPL 「GNU LGPL」 エルジーピーエルとは： - IT用語辞典バイナリ

おまけ：IE6にはGIF画像を使う方法

サンプルコード

div {
  background: url(alpha.png);
}

* html div {
  background: url(ie.gif);
}

コード解説

スターハックを使ってIE6にはGIF画像を読み込ませています。

雑感

IE6にはPNG画像を使わない、というMOSe的な発想です。 参考：MOSeのススメ - Go my way
IE6では若干見栄えが落ちますが、スクリプトによって重くなる心配がありません。

自分のプロパティの書き順とか｜CSS HappyLifeとかRedLine Magazine : 自分もプロパティの書き順とかとかを読んだので僕も書いてみます。

プロパティの降順

1. clear
2. float
3. position
4. display
5. width
6. height
7. min-height
8. margin
9. padding
10. border
11. あとは概ねアルファベット順

わりとアバウトだった件。 テンションによって微妙に入れ替わってたりしそう。

CSSのコードの書き方

<div>
  <ul>
    <li><a href="/">hoge</a></li>
    <li><a href="/">huga</a></li>
    <li><a href="/">foo</a></li>
    <li><a href="/">bar</a></li>
  </ul>
</div>

例えばこんなHTMLだったら、

div {
  width: 500px;
}

  div ul {
    margin-left: 30px;
  }

    div ul li {
      list-style-type: none;
    }

こんな風にインデントしたりします。
ただ、「必ずする」としてしまうとインデントしすぎたり色々面倒なので、適宜インデント、くらいの空気感。

ショートハンドは、

div {
  background: skyblue url(hoge.png) no-repeat left top;
  border: solid 1px lime;
}

など。

その他

あとは目次や見出し的なコメントを入れたりしてます。
エディタはローカルがezhtmlで、サーバがvimです。 vimの設定は殆どさわってないです。
": ;"とか"{ }"とかをタイピングするのが面倒なので、簡単なAutoHotKeyスクリプトを書いて簡略化しています。