まず、よく知られた画像置換のテクニックとしていわゆるファーク式がありました:

/* Phark method */

.ir {
    height: 100px;
    width: 400px;
    background: url(image.png) no-repeat 0 0;
    text-indent: -9999px;
}

このテクニックは長らく利用され続けてきましたが、その代替として、パフォーマンス面でより良いとされる Scott Kellum さんのテクニック (ケラム式) が Jeffrey Zeldman さんの記事 で紹介されました:

/* Kellum method */

.ir {
    height: 100px;
    width: 400px;
    background: url(image.png) no-repeat 0 0;
    text-indent: 100%;
    white-space: nowrap;
    overflow: hidden;
}

そしてこのケラム式が HTML5 Boilerplate のチームによって検討される 過程で もうひとつのテクニック (H5BP 式) が 提案 されます:

/* H5BP method */

.ir {
    height: 100px;
    width: 400px;
    background: url(image.png) no-repeat 0 0;
    font: 0/0 a;
    text-shadow: none;
    color: transparent;
}

ただしこの H5BP 式は、該当する要素で em 単位が使えない、コードが短さを優先したためややトリッキーでわかりづらい、IE6 でテキストが消えずゴマ粒のように残ってしまう、などの欠点があります。

さらに、ケラム式と H5BP 式ともに IE7 でバグ があります。

そしてこれはとくに重要な点ですが、以上 3 つのテクニックはいずれも、CSS が有効かつ画像が無効 (読み込みに失敗した場合や非表示に設定している場合など) という状況では何も表示されなくなってしまうという、アクセシビリティ上の問題があります。

というわけで、疑似要素を利用した ナッシュ式 に IE7 以下向けのフォールバックとしてファーク式を加えたものが比較的ましな画像置換かな、というのが僕の見解です:

/* Nash method + fallback */

.ir {
    height: 100px;
    width: 400px;
    overflow: hidden;
    *text-indent: -9999px; /* for IE7/6 */
    *background: url(image.png) no-repeat 0 0; /* for IE7/6 */
}

.ir:before {
    content: url(image.png);
    display: inline-block;
    font-size: 0;
    line-height: 0;
}

IE8 以上であれば CSS 有効/画像無効の場合でもテキストが表示されるのは大きいですね。ちなみに画像置換の歴史は CSS-Tricks の記事 に詳しいです。

これを応用して、テーブル以外の要素でも display: table-cell を指定すれば、横に並べたフォントサイズの異なる異なるボックスのベースラインを揃えることができます。

<article>
    <header>
        <time>April 12, 2012</time>
        <h1>The Rise and Fall of...</h1>
    </header>
    ...
</article>

たとえばこのようなマークアップがあり、記事の日付とタイトルを横に並べたい場合、

h1, time {
    display: table-cell;
    /* vertical-align: baseline; */
    ...
}

h1 { font-size: 1.5em; ... }

time { font-size: 0.75em; ... }

このように指定すれば、フォントサイズの異なる h1 と time のベースラインはきれいに揃います。vertical-align の初期値は baseline なので、多くの場合はわざわざ指定する必要がないはずです。もしどちらか一方のテキストが複数行にわたっても、ベースラインは最初の行をもとに決定されます。

もしこれと同じレイアウトを display: table-cell ではなくフロートなどでやろうとした場合、2 つの要素の font-size と line-height の値をもとにマージンやパディングを調整しなければならずかなり面倒なので、けっこううれしい挙動だと思うんですがどうでしょう。逆に、ベースラインではなくボックスの上端で揃えたい場合は vertical-align: top などのスタイルを追加する必要があります。

なんか書いてるうちにそんなん当たり前だろ何を今さらって言われそうな気がしてきましたが。

よく見かけるのは以下のようなマークアップで、うちもリデザイン前はだいたいこんな感じでした:

<section class="articleExcerptList">

    <h1>Recent articles</h1>

    <article>
        <h2><a href="...">ブログ記事リストのマークアップ</a></h2>
        <time datetime="...">April 10, 2012</time>
        <p><!-- 概要・抜粋 --></p>
        <a href="...">Continue reading</a>
    </article>

    <article>
        <h2><a href="...">リデザインしました!</a></h2>
        <time datetime="...">April 8, 2012</time>
        <p><!-- 概要・抜粋 --></p>
        <a href="...">Continue reading</a>
    </article>

    . . .

</section>

各アイテムが記事ごとのタイトル、メタデータ (日付やタグなど)、適当な長さの概要・抜粋、「続きを読む」リンクといったものから構成されていて、それぞれが article 要素、というかたちです。よく見かけるというか、ざっと調べたところかなりの割合のブログがこうでしたね。

で、これって article でいいんだろうか、というのが気になったわけです。

article 要素について 仕様 にはこう書かれています:

The article element represents a self-contained composition in a document, page, application, or site and that is, in principle, independently distributable or reusable, e.g. in syndication. This could be a forum post, a magazine or newspaper article, a blog entry, a user-submitted comment, an interactive widget or gadget, or any other independent item of content.

「article 要素は、ドキュメント、ページ、アプリケーション、またはサイトにおいてそれだけで機能する構成要素を表すもので、それは原理的にはたとえばフィードなどで独立して共有されたり再利用されたりすることが可能なものです。フォーラムの発言、雑誌や新聞の記事、ブログのエントリー、ユーザーの投稿したコメント、インタラクティヴなウィジェットやガジェット、そのほか独立した内容を持つアイテムがこれにあたるでしょう」といったところですね (オレオレ翻訳)。

リストの各項目の内容はたしかに “blog entry” のデータなので article 要素で間違いはないようにも思えますが、“self-contained composition in a document” かというとちょっと違う気がします。それぞれのリンク先の記事そのものは self-contained ですが、リストを含むドキュメント (たとえばホームページ) においてそれらはあくまで別のドキュメントの概要や抜粋であり、それだけで機能するとは言いがたいと思うのです。概要や抜粋のリストはいわば「目次」のようなものであり、記事そのものではありません。逆に、複数の記事が並んでいてもそれぞれ全文を掲載していれば article でもいいかなと思います。

というわけで、これらは article ではなく section のほうが良いのではないだろうか、と思うのですがどうでしょう:

<section class="articleExcerptList">

    <h1>Recent articles</h1>

    <section>
        <h2><a href="...">ブログ記事リストのマークアップ</a></h2>
        <time datetime="...">April 10, 2012</time>
        <p><!-- 概要・抜粋 --></p>
        <a href="...">Continue reading</a>
    </section>

    <section>
        <h2><a href="...">リデザインしました!</a></h2>
        <time datetime="...">April 8, 2012</time>
        <p><!-- 概要・抜粋 --></p>
        <a href="...">Continue reading</a>
    </section>

    . . .

</section>

また、概要などがなく、タイトルと日付ぐらいのリストなら ul がいいかなと思います:

<ul class="articleList">

    <li>
        <a href="...">ブログ記事リストのマークアップ</a>
        <time datetime="2012-04-09">April 9, 2012</time>
    </li>

    <li>
        <a href="...">リデザインしました!</a>
        <time datetime="2012-04-08">April 8, 2012</time>
    </li>

    . . .

</ul>

HTML5 のセクショニングの基本的な考え方として、見出しがある (あるいはあってもおかしくない) ものはとりあえず section として、中身が (major な) ナビゲーションなら nav、それだけで機能するようなものなら article、本文とあんまり関係なければ aside、みたいな感じに考えるといいかなと思ってます最近は。

label[for="foo"] {
    background-color: yellow;
}

この場合 for="foo" という属性を持つ label 要素の背景が黄色になるはずですが、IE7 では無視されてしまいます。これはどうやら for というキーワードが DOM の予約語であることに由来するバグのようです (参考: Attribute Selector (CSS selector) – SitePoint CSS Reference)。そのかわり、IE7 では htmlFor という属性名を利用すればスタイルが有効になります。

label[htmlFor="foo"] {
    background-color: yellow;
}

ただこれだと IE8 以降やほかのブラウザが解釈してくれないので、htmlFor と for によるセレクタを並べます。

label[htmlFor="foo"],
label[for="foo"] {
    background-color: yellow;
}

これで属性セレクタを解釈するすべてのブラウザでスタイルが有効になります。

• Demo: [for] attribute selectors in IE7

ちょっとわかりにくいタイトルになってしまいましたが、つまり Wikipedia のやつ (Fig 1) みたいに、「画像 (またはビデオなどの埋め込みコンテンツ) の下にキャプションをレイアウトするとき、キャプションが複数行にわたる場合は画像の幅に合わせて折り返したい (ただし画像の幅はバラバラ)」というのをシンプルかつ汎用的なかたちで実現する CSS を考えてみました。というか、このブログのレイアウト用にけっこう長いことあれこれ考えてたもののこれといった手が思いつかなくて放置していたんですが、上手い解決を Stack Overflow でみつけた のでパクった、という話です。

<figure>
    <img src="/img/photo.jpg">
    <figcaption>Lorem ipsum dolor sit amet</figcaption>
</figure>

ここではこのマークアップをもとに考えてみます。スタイルの要件をまとめると以下のとおり:

• figure の幅は img の幅に合わせたい
• img の幅は不確定
• figcaption は存在しない場合もあり、もし存在すればテキスト量は不確定で、幅は figure の幅に合わせ、複数行にわたる場合はなりゆきで折り返したい

考えられるアプローチのひとつとして、figure の幅についてあらかじめいくつかのパターンを決めておくというものがあります。img は figure の幅に合わせて書き出してもいいし、大きめに作っておいてブラウザで縮めてもいいでしょう。シンプルなグリッドがきっちり決まってる場合なんかはいいかもしれませんが、マークアップの class 属性や data-* 属性などを指定する必要があり、あまり汎用的とは言えないかもしれません。

figure.small   { width: 160px; }
figure.mideium { width: 240px; }
figure.large   { width: 320px; }

figure img { max-width: 100%; }

あるいは JavaScript で img の幅を取得して figure の幅を操作するという手もあります。これならかなり汎用性も高いです。ただ、JavaScript で画像のサイズの取得をエラー処理やなんかも含めてきっちりやるのって、けっこうたいへんですよね? 僕は何度か挫折しました…

あとは CMS とかのシステム側でうまいことやってもらうって感じですかね。画像のアップロード時に、その幅に応じて style 属性を自動的にかますような。Wikipedia なんかはそんな感じ でしょうし、WordPress のプラグインなんかでもそんなのありそう (調べてない)。

というわけで、やはり CSS だけでなんとかしたいなーというのが以下のコード。前述の Stack Overflow で見つけたやつに少しアレンジを加えたものです:

figure {
    display: table;
    width: 160px; /* minimum width */
    *width: auto; /* for IE7 and below */
}

これだけ。figure はテーブルのように振る舞うので、img の幅が figure に指定した幅を超えた場合はその幅に合わせて広がります。またもし img の幅が figure に指定した幅に満たない場合でもつねにその幅が確保されます。figcaption は横に広がろうとしますが、figure の制限をうけてぴったりの幅に収まります。ちなみにここでは figure と figcaption ですが、div と span やなんかでも同じです。デモを用意したのでどうぞ:

• Demo: Shrink-to-fit figcaption

Stack Overflow のバージョンだと width の値が 1px なんですが、それだと img の幅がごく小さいときに figcaption がせまくなり過ぎて読みづらいので、サイトのグリッド構成などに応じて最低限これだけの幅はほしいという値を指定しておくのがいいと思います。ちなみにその場合、img は左に寄せず中央に置くと座りがいいです。

同じく Stack Overflow バージョンは img と figcaption に対して display: table-row を指定していますが、それは必要ない気がします。検証した限りとくに不都合はないのでたぶん大丈夫だと思うんですが…

また、もし img に max-width: 100% というスタイルが指定されていると figure の幅に縮められてしまうので注意が必要です。レスポンシヴなデザインでよく使われるスタイルだと思いますが。

display: table をサポートしていない IE7 以下では figure の幅が width の値のとおりに解釈され、結果として縦にひしゃげたかたちになりキャプションが読みづらくなってしまうので、width: auto で上書きしています。とは言えこれで IE8 以上と同じレイアウトになるわけではなく、ただボックスが横に広がるだけです。IE7 では figure と img に max-width を指定すればある程度はコントロールできます (Fig 3) が、もし同じレイアウトでということになると、前述のような JavaScript を用いたり幅を固定したりといった手法が必要でしょう。

Web コンテンツがスマートフォンやタブレットといった多様なデバイスで閲覧される機会が増え、canvas や SVG といった手法も広まってきたいま、「画像」をいかに取り扱うかというのはあらためて考えなければいけない課題のひとつです。今回ここで紹介したのはレイアウトに関するちょっとしたテクニックに過ぎないですが、将来に向けてできる限りシンプルで汎用性の高い手法を模索していきたい、と考えた結果でもあります。

あけましておめでとうございます!

Normalize.css は「新手の CSS リセット」ではありません。CSS を「リセット」するのではなく「ノーマライズ」する、という新しい考え方です。CSS リセットとノーマライズはどちらも、ブラウザ間で CSS の実装に差異があることを前提にそれらを吸収しようとする、という同じ目的を持っています。ただ、リセットはすべてをまっさらな「さら地」にしようとするのに対し、ノーマライズは使える部分は残しつつ手を入れる必要のある部分だけを整える、という違いがあります。「ブラウザ間の CSS 実装に差異がある」とは言っても、それぞれのブラウザが勝手にてんでバラバラの方向を向いているわけではないので、歩調のあってるとこまでわざわざ殺さず、活かせるものはそのまま活かして、という発想です。

Normalize.css によって具体的にどんなスタイルになるかは デモ をご覧いただくのが手っ取り早いと思います。シンプルなサイトなら、ここにちょっとしたレイアウトのスタイルを追加すればそのまま完成するような、汎用性の高いスタイルです。

とは言え、長いことリセットという手法が一般的であったため、たとえばブロックレベル要素のマージンやリストのマーカーがデフォルトのままだったりすると扱いづらいという場合も多いんじゃないでしょうか。一から自分でコントロールできる新規プロジェクトならいいですが、チームでメンテナンスしていたり、運用・管理を他の人に移譲するものの場合、ある程度はコモンセンスというか浸透している手法でないと採用が難しい、というところもあると思います。とくにリセットもノーマライズもスタイルの基盤を作るもので、その後の CSS 設計のすべてに大きく影響するものなのでなおさらです。

というわけで、ノーマライズの考え方を取り入れつつも影響の大きそうな部分はリセットしておくという、新しいリセットのアプローチを模索しています。以下はそうやって出来た「俺の CSS リセット: 2011 冬」です。Normalize.css については GitHub の Wiki に詳しい解説があるのでそちらも参照してみてください。そこには先人たちの様々な CSS テクニックが盛り込まれており、そのまま採用しないにしても読むだけで得られるものは少なくないと思います。

/*!
 * CSS Reset 2011-12-25
 * https://gist.github.com/1360380
 *
 * Author:  Takeru Suzuki, http://terkel.jp/
 * License: Public domain
 *
 * Inspired by Normalize.css: http://necolas.github.com/normalize.css/
 */



/* HTML5 display definitions */

section, nav, article, aside, hgroup,
header, footer, figure, figcaption, details {
    display: block;
}

video, audio, canvas {
    display: inline-block;
    *display: inline;
    *zoom: 1;
}

audio:not([controls]) {
    display: none;
}

[hidden] {
    display: none;
}



/* The root element */

html {
    font-size: 100%;
    overflow-y: scroll;
    -webkit-text-size-adjust: 100%;
        -ms-text-size-adjust: 100%;
}



/* Sections */

body {
    font-family: sans-serif;
    margin: 0;
}

h1, h2, h3, h4, h5, h6 {
    font-size: 1em;
    margin: 0;
}



/* Grouping content */

p, blockquote, dl, dd, figure {
    margin: 0;
}

hr {
    color: inherit;
    height: auto;
    -moz-box-sizing: content-box;
         box-sizing: content-box;
}

pre {
    font-family: monospace, sans-serif;
    white-space: pre-wrap;
    word-wrap: break-word;
    margin: 0;
}

ol, ul {
    padding: 0;
    margin: 0;
}

li {
    list-style: none;
}



/* Text-level semantics */

a:focus {
    outline: thin dotted;
}

a:hover, a:active {
    outline: 0;
}

strong, b {
    font-weight: bold;
}

small {
    font-size: 0.83em;
}

q {
    quotes: none;
}

abbr[title] {
    border-bottom: 1px dotted;
}

code, samp, kbd {
    font-family: monospace, sans-serif;
}

mark {
    color: black;
    background-color: yellow;
}

sub, sup {
    font-size: 0.83em;
    line-height: 0;
    vertical-align: baseline;
    position: relative;
}

sub {
    bottom: -0.25em;
}

sup {
    top: -0.5em;
}

br {
    letter-spacing: 0;
}



/* Embedded content */

img {
    border: 0;
    -ms-interpolation-mode: bicubic;
}

svg:not(:root) {
    overflow: hidden;
}



/* Tabular data */

table {
    border-collapse: collapse;
    border-spacing: 0;
}

caption {
    padding: 0;
    text-align: left;
}

th, td {
    text-align: left;
    vertical-align: baseline;
    padding: 0;
}



/* Forms */

form {
    margin: 0;
}

fieldset {
    border: 0;
    padding: 0;
    margin: 0;
}

legend {
    border: 0;
    *margin-left: -7px;
}

input, button, select, textarea {
    font-family: inherit;
    font-size: 1em;
    color: inherit;
    margin: 0;
}

input, button {
    line-height: normal;
    vertical-align: inherit;
    *vertical-align: middle;
}

input::-moz-focus-inner,
button::-moz-focus-inner {
    border: 0;
    padding: 0;
}

input[type="search"] {
    -webkit-appearance: textfield;
    -webkit-box-sizing: content-box;
       -moz-box-sizing: content-box;
            box-sizing: content-box;
}

input[type="search"]:focus {
    outline-offset: -2px;
}

input[type="search"]::-webkit-search-decoration {
    -webkit-appearance: none;
}

input[type="checkbox"],
input[type="radio"] {
    box-sizing: border-box;
    padding: 0;
}

input[type="submit"],
input[type="reset"],
input[type="button"],
button {
    cursor: pointer;
    -webkit-appearance: button;
    *overflow: visible;
}

select {
    background-color: inherit;
    line-height: normal;
}

textarea {
    vertical-align: top;
    overflow: auto;
    *font-family: sans-serif;
}

section, nav, article, aside, hgroup,
header, footer, figure, figcaption, details {
    display: block;
}

video, audio, canvas {
    display: inline-block;
    *display: inline;
    *zoom: 1;
}

audio:not([controls]) {
    display: none;
}

[hidden] {
    display: none;
}

html {
    font-size: 100%;
    overflow-y: scroll;
    -webkit-text-size-adjust: 100%;
        -ms-text-size-adjust: 100%;
}

body {
    font-family: sans-serif;
    margin: 0;
}

h1, h2, h3, h4, h5, h6 {
    font-size: 1em;
    margin: 0;
}

p, blockquote, dl, dd, figure {
    margin: 0;
}

hr {
    color: inherit;
    height: auto;
    -moz-box-sizing: content-box;
         box-sizing: content-box;
}

pre {
    font-family: monospace, sans-serif;
    white-space: pre-wrap;
    word-wrap: break-word;
    margin: 0;
}

ol, ul {
    padding: 0;
    margin: 0;
}

li {
    list-style: none;
}

a:focus {
    outline: thin dotted;
}

a:hover, a:active {
    outline: 0;
}

strong, b {
    font-weight: bold;
}

small {
    font-size: 0.83em;
}

q {
    quotes: none;
}

abbr[title] {
    border-bottom: 1px dotted;
}

code, samp, kbd {
    font-family: monospace, sans-serif;
}

mark {
    color: black;
    background-color: yellow;
}

sub, sup {
    font-size: 0.83em;
    line-height: 0;
    vertical-align: baseline;
    position: relative;
}

sub {
    bottom: -0.25em;
}

sup {
    top: -0.5em;
}

br {
    *letter-spacing: 0;
}

img {
    border: 0;
    -ms-interpolation-mode: bicubic;
}

svg:not(:root) {
    overflow: hidden;
}

table {
    border-collapse: collapse;
    border-spacing: 0;
}

caption {
    padding: 0;
    text-align: left;
}

th, td {
    text-align: left;
    vertical-align: baseline;
    padding: 0;
}

form {
    margin: 0;
}

fieldset {
    border: 0;
    padding: 0;
    margin: 0;
}

legend {
    border: 0;
    *margin-left: -7px;
}

input, button, select, textarea {
    font-family: inherit;
    font-size: 1em;
    color: inherit;
    margin: 0;
}

input, button {
    line-height: normal;
    vertical-align: inherit;
    *vertical-align: middle;
}

input::-moz-focus-inner,
button::-moz-focus-inner {
    border: 0;
    padding: 0;
}

input[type="search"] {
    -webkit-appearance: textfield;
    -webkit-box-sizing: content-box;
       -moz-box-sizing: content-box;
            box-sizing: content-box;
}

input[type="search"]:focus {
    outline-offset: -2px;
}

input[type="search"]::-webkit-search-decoration {
    -webkit-appearance: none;
}

input[type="checkbox"],
input[type="radio"] {
    box-sizing: border-box;
    padding: 0;
}

input[type="submit"],
input[type="reset"],
input[type="button"],
button {
    cursor: pointer;
    -webkit-appearance: button;
    *overflow: visible;
}

select {
    background-color: inherit;
    line-height: normal;
}

textarea {
    vertical-align: top;
    overflow: auto;
    *font-family: sans-serif;
}

さて、まずは @extend の基本的な機能についてざっとおさらい。@extend される側として一連のスタイルを定義したセレクタがあり、そのセレクタを @extend で継承しつつプロパティを追加したりして、新しいセレクタを作ります:

// SCSS

// 継承元のセレクタ
.button {
    display: inline-block;
    border: 1px solid gray;
    background-color: silver;
    &:hover {
        border-color: black;
    }
}

// .button セレクタを継承・拡張
.button-download {
    @extend .button;         // .button を継承
    background-color: green; // プロパティを上書き
    border-radius: 4px;      // 新たなプロパティの追加
    .icon {                  // ネストしたセレクタの追加
        background: url(/img/download.png) no-repeat 0 50%;
    }
}

この SCSS をコンパイルすると、こういう CSS が生成されます:

/* CSS */

.button,
.button-download {
    display: inline-block;
    border: 1px solid gray;
    background-color: silver;
}

.button:hover,
.button-download:hover {
    border-color: black;
}

.button-download {
    background-color: green;
    border-radius: 4px;
}

.button-download .icon {
    background: url(/img/download.png) no-repeat 0 50%;
}

このように、共通するプロパティはひとつのルールセットに、そして差分だけが新たなルールセットにまとめられ、じつに合理的なコードが生成されます。ここでは 2 つのセレクタ間でしか @extend していませんが、これが増えてくるとさらにありがたみが増します。ボタンを例に出しましたが、たとえばリストやテーブルなど、基本的には似てるんだけど少しずつ違うスタイルのモジュールがいくつもある、みたいなときに威力を発揮します。

しかし、これだったら ミックスイン でもいいんじゃないの、という意見もあるかもしれません。この場合で言うと、.button のスタイルをミックスイン化して .button-download のルールセット内で @include すれば、結果として同じスタイルを実現することはできます。しかし、そこに至る考え方が @extend とミックスインではまるで違うのです。

ミックスインは、@include で挿入した箇所で展開されるコード片です。ミックスイン自体のコードは CSS としてコンパイルされず、@include されてはじめて実体を持ちます。そのため、使いそうなものをひととおりライブラリとして読み込んでおいて必要に応じて呼び出す、という使い方が可能です。

一方 @extend は、実際に存在している CSS のスタイルをもとにしたものです。一連のスタイル定義をいわば「スタイルオブジェクト」として捉え、@extend によってそれを継承・拡張して新たなオブジェクトを作るもの、と考えられます。

この「スタイルオブジェクト」というのは僕が勝手に呼んでいる名前で、なんとなくぼんやりとそう捉えている、というものです。僕はプログラマでもなければオブジェクト指向をきっちり勉強した経験もないので (こないだ友人の @marugoshi さんにちょっとだけご教授いただきましたが)、ここでぜひ皆さんのご意見をうかがいたいんですが、これってひょっとしてオブジェクト指向ですか?

上の SCSS のコードでやってることって、.button っていうひとつのオブジェクトがあって、それを継承しつつも一部のプロパティが違ったり新たなプロパティが追加された .button-download っていうもうひとつのオブジェクトが生成されてる、っていうふうに捉えてるんですが…

そして僕はこういうふうにスタイルを捉えるようになって、明らかにマークアップとスタイルの設計が変わったんですよ。それまで、CSS ってどう書いても最終的にはグチャグチャになる運命 (さだめ) なのでは… と思っていたんですが、はじめてスタイルというものが実体を持って見えるようになった、ような気がしたんです、Sass の @extend を使うようになって。

オブジェクト指向の CSS というと OOCSS というのが有名ですけど、あれってどうも曲解されているというか、ようするにスタイルをクラスに細切れにしてマークアップにぽんぽん放り込めばいいんでしょ、みたいな見方をされてる気がするんですよ。たとえばこんなの:

<a class="button button-download button-rounded button-green text-bold align-center valign-top font-15">ダウンロード</a>

これはさすがに極端ですが、でもいわゆる CSS フレームワーク的なアプローチを採ろうとすると多かれ少なかれこういったマークアップになりがちな気がします。

そうではなくて、マークアップをシンプルに保ち、かつスタイルを変更する際になるべく影響を受けないよいうに、あらかじめマークアップの各要素というかモジュールごとにスタイルとは切り離した適切な名前をつけておいて、スタイルはスタイルでオブジェクトとして体系化してマークアップから分離する、みたいな理想にオブジェクト指向な Sass で少し近づけるのかも… とか考えるんですが、どうでしょう。

最後に、Sass の @extend 関連で参考になった記事をいくつかリストアップしておきます:

• Selector Inheritance the Easy Way: Introducing @extend : Nex3:
  開発者のブログ
• Sassの@extendでCSSとHTMLをシンプルに – あと味:
  入門編として簡潔にまとまっていてわかりやすい
• Sass(Scss) Memo: @extend | Culture27:
  じつはややこしい @extend の仕様がかなり詳細に調べられていて素晴らしいです
• Extends and Control Directives: Two Crazy Things Sass Can Do That LESS Can’t | Design Shack:
  Sass は LESS と違って @extend とか使えてヤバい、という話
  (あわせて読みたい: LESSにextendを実装してみた – hokaccha.hamalog v2)
• The problem with CSS pre-processors | Blog | Miller Medeiros:
  Sass の問題点や要望など。@extend の継承元をコンパイルされないようにする機能とかたしかにあるといかも

えー、タイトルで「どこがすごいのか」と大見得を切っておきながらこれといった結論に至らずお恥ずかしい限りです。あと、アドベントカレンダーのスケジュールを乱してまことに申し訳ございませんでした!

比較的ニュートラルだけど、g や t やイタリックの f あたりのクセが好み。5 ウェイトでそれぞれにイタリックがあり、計 10 通りのバリエーションがあるのもいいです。とは言え実際にはそこまで必要ないので、このサイトでは 400、400 のイタリック、700、700 のイタリックという 4 種に絞って利用。

Google Web Fonts のフォントファイルを読み込むには CSS の @import ルールや JavaScript の API を使う方法もあるけど、おそらく link 要素でのインクルードがいちばん手軽で速いと思います。

<link rel="stylesheet"
href="http://fonts.googleapis.com/css?family=Open+Sans:400italic,700italic,400,700">

あとは CSS で font-family を指定するだけ。

body {
    font-family: "Open Sans", "Helvetica Neue", "Helvetica", "Arial", "Hiragino Kaku Gothic ProN", "ヒラギノ角ゴ ProN W3", "メイリオ", sans-serif;
}

ヒラギノやメイリオとの相性も悪くないと思うんですが、どうですかね。

ちなみに、このサイトでは長らく Helvetica Neue を使ってたけど、和文との相性が気になりだして Lucida Grande に鞍替え、でも Lucida Grande はイタリックがないしちょっとうるさい気がしてきたのでなんかいいのないかな、というのが今までの流れです。飽きたら Helvetica に戻します!

何を書こうか少し悩みましたが、とくにこれといったネタもないので、俺と WordCamp の関係や、俺が WordCamp について思うところなどをだらだらと書いてみます。ちなみにこのブログでは Web デザインについて淡々と書くことがほとんどなので、こういったスタイルの記事はめずらしいです、すごく。

さて、俺がはじめて WordCamp に参加したのは 2010 年春の WordCamp Yokohama 2010 でした。俺は基本的にこういったセミナー的なイベントにあまり積極的に参加しないし、それまで WordPress についてさほど勉強してたわけでもないのですが、当時仕事してなくて時間もあったし、タダだし、っていう軽い気持ちで参加したのでした。

会場でまず感じたのは、運営のある種の「ゆるさ」のようなものでした。かと言ってイベントはぐだぐだにはならず、なぜかそれなりに進行していく。少し大げさに言うと、イベントが運営スタッフによって動かされているのではなく、イベントが参加者もスピーカーもスポンサーも巻き込んでそれ自体の意思でずるずると動いているような、そんな感じ。そして俺にはその感じが面白かったし、けっこう心地良かったんです。

カンファレンスも、その筋の権威をお招きしてありがたいお話をうかがうみたいなノリがまるでなくて、現場で実際に WordPress に関わっている人たちがそれぞれの知見をシェアする場、という印象。スピーカーと参加者が明確に分かれてなくて、参加者のうち何人かがたまたま登壇してしゃべっている、そんな雰囲気でした。

カンファレンス後の懇親会も、ふだんならその手のはシカトしてとっとと帰るとこなんですが、勢いで参加してみたら思いのほか楽しかったです。あまり関係ないですが、そのとき こもりさん にはじめてお会いして、「いま無職なんですよ」みたいな話をしたら「僕も無職みたいなもんです」って返されたのが妙に印象に残ってますね。

というように WordCamp Yokohama 2010 がとても楽しかったので、もし自分にも貢献できることがあればやってみたいなーなどとぼんやり考えて、横浜で出会った運営スタッフの じゅんさん に、もし次に首都圏で何かやるときは呼んでねーみたいな話をしてたんです。そしたら今年の秋、こんど東京でやるのでデザイナーやりませんかと声をかけていただき、今に至るというわけです (ありがとう、じゅんさん!)。だから今回の WordCamp に参加して自分も何かやってみたいと思った方は、実行委員長の とおるさん あたりをつかまえて「何かやらせろ」って言ってみるといいです。なんなら次回の実行委員長とかやらせてもらえます。

以上、WordPress をマニアックに追っかけているわけでもない上、人見知りするし出不精だし友達も少ない、そんな俺でも WordCamp は楽しめるし、その気になれば運営スタッフとして関わることもできるよ、という話でした。参加登録 がまだの方はお早めにどうぞ!