terkel.jp

こんにちは、世界!

2008-02-29T00:00:00Z

もうずいぶん長いこと、このブログを手元でいじっている。あまりにたくさんの部分が未完成だけど、いいや。リリースしてしまう。話はそれからだ。

terkel.jp、公開。2008年2月29日、うるう年の余分に贈られた日に記す。

Mac 版 Firefox 3 はデフォルトのフォントサイズが 16px に

2008-04-21T00:00:00Z

4月16日に開催されたセミナー、CSS Nite in Ginza, Vol.24 に参加してきた。リリース間近の Firefox 3 の新機能について Mozilla Japan のスタッフが語る、というのがテーマ。僕はといえば、実はアンケート回答者に配られた Firefox ストラップが目当てだったりもしたわけだけど、ちょっとうれしい話も聞けた—Mac 版 Firefox のデフォルトのフォントサイズがついに 16px になるという!

これはおそらく日本語版のみの話だと思うけど、ほぼすべてのモダン・ブラウザがデフォルトのフォントサイズを 16px に標準化しているのに、Mac 版 Firefox だけが 14px だったのだ。ちなみになぜそうだったかとういと、旧 Mac OS において Osaka フォントの 16px が用意されていなかったからだとか。

今までは、CSS でフォントサイズをいわゆる「相対値」で指定し、かつ、Mac 版 Firefox でも同じサイズにしようとすると、IE 向けのハックが必要だった。たとえば、ベースとなる body 要素のフォントサイズを 10px 相当にするにはこんな感じ:

body {
  font-size: 10px; /* for Firefox, Safari, Opera */
}
* html body {
  font-size: 62.5%; /* for IE */
}

でも正味の話さあ、Mac 版 Firefox ってシェアなんぼよ? とか、こういう対応をしてるサイトとしてないサイトでフォントサイズばらばらじゃん! とか思ってしまうので、実際にはこんなふうに書いたことないけど。
今や僕もすっかり Mac の Firefox ユーザーですごめんなさい。

のっちメソッド: One pixel notched corners

2008-04-26T00:00:00Z

2009 年 6 月に改良版を書きました。

Ask the CSS Guy の記事 One pixel notched corners as used by Google Analytics を試してみた。Google Analytics で使われてるような、四隅が 1px 欠けているボックスの表現を画像を用いず CSS のみでやってみよう、という話。上記記事に対する Simon さんて方のコメントで「もっと簡単にできんじゃね?」という例があるけど、なんだか不思議なマークアップだったので、僕なりに整理してみる。

まず、例としてナビゲーションメニューのようなものを考えてみる。マークアップはこんな感じ:

<!-- HTML -->
<ul>
  <li><a href="#">One</a></li>
  <li><a href="#">Two</a></li>
  <li><a href="#">Three</a></li>
  <li><a href="#">Four</a></li>
</ul>

Google Analytics の場合、この a 要素の中身をなんと3重の b 要素でくるむという乱暴なマークアップらしいんだけど、ここでは上記ソースにはこれ以上手をいれない。

で、CSS。まず li 要素に 1px の上下ボーダーと 1px の左右マージンを持たせる:

/* CSS */
li {
  border-top: 1px solid #999999;
  border-bottom: 1px solid #999999;
  margin: 0.5em 1px;
}

次に、子要素である a 要素をブロック化し 1px の左右ボーダーを持たせ、かつ左右のマージンを -1px にし、li 要素からはみ出させる:

/* CSS */
li a {
  display: block;
  border-right: 1px solid #999999;
  border-left: 1px solid #999999;
  margin: 0 -1px;
}

以上。完成版デモをご参照されたし。色使いなんかを工夫すれば、かなり実用的なテクニックじゃないかと思う。命名、「のっちメソッド」。

「右クリック禁止」に戸惑う

2008-05-08T00:00:00Z

クライアントから、ある画像を「右クリック禁止」にしてほしい、との依頼があった。そのとき僕が感じた気持ちをひとことで言い表すのは難しい。それはいらだちでもあり、無力感でもある。

僕たち Web デザイナーは「右クリック禁止」がいかにバカげたギミックかを知っている。でも、クライアントが本当に心を痛めているとしたら? 「私の描いた絵が誰かのハードディスクに保存されてしまったら…」「見ず知らずのサイトからいつの間にかリンクされてしまったら…」そう考えると夜も眠れないんだとしたら? 彼らにその要望がいかに的外れなものであるかを説くことは、はたしてベストの選択だろうか?

(要素に) 名前をつけてやる

2008-05-10T00:00:00Z

いわゆるヘッダやフッタなど、ページを構成する主要なブロックをマークアップする際、div 要素に id 属性で名前をつけることが多い。<div id="header"> とか。なぜ class ではなく id なのか? その理由としておそらく最も多いのが、「ページ内で唯一のものだから」。HTML を解説した本やなんかを読むと、「複数出現する (またはその可能性のある) 要素は class で、唯一の要素は id で」なんて書いてあることがよくある。

僕も長いことそうしてたんだけど、どうも違うんじゃないか、と最近は考えてる。今しっくりくるのは、「id 属性は唯一の要素に名前をつけるためのものではなく、要素に一意の (unique) 名前をつけるためのもの」って考え方。つまり、その要素がドキュメントにいくつ出現するかってことじゃなくて、他の要素と識別されるべき要素かどうか。

実際のマークアップ手順としては、まず要素の「役割」や「種別」、「所属」のようなものをもとに class 属性を付与。で、もし「一意の名前」が必要であれば id 属性も付与、って感じ。

そのため、class 属性の値はいわゆる「文脈的」というか「構造的」というか、その要素の役割が理解されやすいキーワードであるべきなのに対し、id 属性の値はあくまで「識別子」なので、ほかとかぶりさえしなければどんな意味不明の文字列でも一向にかまわないはずだ。とはいえ、id 属性を持つ要素はすなわち URI を持つことになるわけで、そのへんは意識して名前を考えたほうがいいかなとも思う。

Google サイトマップを Movable Type で生成

2008-05-10T00:00:00Z

Google ウェブマスターツールを利用すると、Google にサイトマップを送信することができる。そうすることで、君のページを Google に見つけてもらいやすくなるわけだ。このサイトマップは Google の指定する XML 形式で記述する必要があるんだけど、ここでは、そのサイトマップを Movable Type のテンプレートを使って自動生成してみる。こんな感じ:

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.google.com/schemas/sitemap/0.84">
  <url>
    <loc><mt:BlogURL encode_xml="1" /></loc>
    <priority>1.0</priority>
  </url>
  <mt:Entries lastn="9999">
  <url>
    <loc><mt:EntryPermalink encode_xml="1" /></loc>
    <lastmod><mt:EntryModifiedDate format="%Y-%m-%d" /></lastmod>
  </url>
  </mt:Entries>
  <mt:Pages>
  <url>
    <loc><mt:PagePermalink encode_xml="1" /></loc>
    <lastmod><mt:PageModifiedDate format="%Y-%m-%d" /></lastmod>
  </url>
  </mt:Pages>
</urlset>

mt:Entries はブログ記事、mt:Pages は Web ページのデータをそれぞれ生成。このテンプレートを一度保存してしまえば、常に最新のサイトマップを Google に提供し続けることができる。

Movable Type 4.12 にアップグレード

2008-06-21T00:00:00Z

Movable Type 4 のセキュリティアップデートに伴うテスト。

再起動

2008-08-27T00:00:00Z

このサイトを 2008 年 2 月に公開してはや半年。なのに記事数はなんとたった 7!

再起動が必要、というわけでデザインを一新した。特に CSS でちょっとした発見もあったので、そこらへんは近日中に記事にする。ともあれ、terkel.jp、リニューアル。2008 年、夏。

戦争は終わった

2008-09-04T00:00:00Z

Google Chrome の出現によって、Web デザイナーはまたひとつ面倒な仕事を増やすことになったのか?

否。Google Chrome は Safari と同じレンダリングエンジン WebKit をベースにしている。Safari のテストを通過したサイトならほとんど問題なく表示されるだろう。もしあなたのサイトが Chrome で意図どおりに表示されないというのなら、そのバグは Safari でずいぶん長いこと放置されていたことになるかもしれない。

Google Chrome の出現によって、Mozilla Firefox は時代遅れの恐竜と成り果てるのか?

否。Mozilla Labs が発表した Ubiquity をチェックしてほしい。この始まったばかりの試みがどう発展していくのか、考えるだけでワクワクしてこないだろうか。Mozilla のアプローチはもちろん Google とは違う。そして幸運なことに、僕らはそのどちらも楽しむことができる。

では、Google Chrome の出現は新たなブラウザ戦争を引き起こすのか?

否! 少なくとも僕の眼には誰も戦争をしているようには見えない。Chrome の機能美や Ubiquity の可能性に刺激を受けたクリエイターが、また新たな何かを生み出す。それはフェアな競争だ。自らが生き残るために誰かを陥れる必要なんかない。ただ、楽しめばいい。

ときには真珠のように

2008-09-13T00:00:00Z

「Web デザイナーがあらゆる閲覧環境でのタイポグラフィをコントロールしようなんておこがましいとは思わんかね…」

CSS ハックをフォーマット

2008-09-26T00:00:00Z

いわゆる「スターハック」に代表されるセレクタレベルの CSS ハックについて、ソースコードの整形を工夫してみる。

body {
  font-size: 10px;
}
* html body {
  font-size: 62.5%;
}
*:first-child+html body {
  font-size: 62.5%;
}

この書き方、ハック部分が目立つのでメンテナンス性に優れてはいるものの、本来は必要ないはずの余分な記述が妙に偉そうにに居座ってる感じが、なんかイヤ。というわけで、こんなのはどうだろう:

body {
  font-size: 10px;
  } * html body {
  font-size: 62.5%;
  } *:first-child+html body {
  font-size: 62.5%;
}

改行とインデントをいじっただけなんだけど、視覚的にはひとつの規則集合のなかで宣言を追加してるようなイメージ。ハックのたたずまいがやや遠慮がちになるというか。微妙か?

さよなら

2008-10-01T00:00:00Z

この 9 月いっぱいをもって、2 年間勤めた会社を辞めました。次の仕事はまだ決まっておらず、これから求職活動が始まります。

今でこそいっぱしの Web ディヴェロッパーみたいな顔をしている私ですが、実は Web 業界での仕事はこの会社がはじめてでした。つまり実務経験ゼロの素人として拾ってもらったわけで、それだけでも御の字。おかげ様でこの業界でなんとかやっていけそうな自信も得られました。

なんだかんだと愚痴ってたくせに、いざ別れるとなるとみんながイイ奴に思えて困るよ、実際。ありがとう、さよなら!

mt:SetVars

2008-10-07T00:00:00Z

Movable Type 4.1 で追加されてたらしいけど、今日までその存在に気がつかなかったのがこの mt:SetVars タグ。これ、mt:SetVar や mt:SetVarBlock で個別に設定していた変数をいっぺんにまとめて書くことができるもの。例えば、

<mt:SetVarBlock name="title">
  <mt:BlogName encode_html="1" />
</mt:SetVarBlock>
<mt:SetVar name="main_index" value="1" />
<mt:SetVar name="index_template" value="1" />

…と書いていたところを、mt:SetVars を使えば以下のとおり代替できる:

<mt:SetVars>
  title=<mt:BlogName encode_html="1" />
  main_index=1
  index_template=1
</mt:SetVars>

これはわかりやすくて良い。

768 グリッド・システム

2008-11-30T00:00:00Z

Gridding the 960 ~ Authentic Boredom や 960 Grid System などに触発されて、幅 960 px のグリッド・システムについて考えてみた。

まず、なぜ 960 px なのか? この数字が導き出される大きな理由は 2 つ。まず前提として幅 1,024 px 以上のモニタを想定する。そこからスクロールバーやブラウザ自体のボーダーなどを差し引くと、考えられる「有効内寸」は幅 1,000 px 未満。ではなぜ 980 でも 950 でもなく 960 px なのかといえば、960 が「割り切りやすい」数字だからだ。

960 is divisible by 2, 3, 4, 5, 6, 8, 10, 12, 15, 16, 20, 24, 30, 32, 40, 48, 60, 64, 80, 96, 120, 160, 192, 240, 320 and 480. This makes it a highly flexible base number to work with.

— 960 Grid System

960 Grid System

…と前述の 960 Grid System にあるとおり、960 という数字は実に多くの整数で割ることができ、つまりはカラムのバリエーションが作りやすいのである。

でもちょっと待った。2008 年現在、デスクトップでもラップトップでも、幅 1,024 px をサポートしないモニタはごくごく少数だが、「新たな例外」というべきデバイスがいくつか存在している。例えば Wii のインターネットチャンネルや、Eee PC に代表される Netbook の多くは 800 px 幅だ。それにもし 1,024 px 幅でも、ブラウザのサイドバーを表示させていたり、そもそもウィンドウを縮小していたりすれば、やはり表示可能領域はせばまる。

というわけで、「幅 1,024 px を基準としつつ、サブカラムを除くメインカラムは 800 px に収める」てなアプローチが現実的になってくる。そこで「960 グリッド・システム」に加え、「768 グリッド・システム」を提案したい。800 px 幅のブラウザで縦スクロールバーがある場合を考慮にいれつつ、960 同様に割り切りやすい数字を求めるとこの 768 にいきつくのだ。

以下は、この 768 px をそれぞれ 12 と 16 のカラムに切ったグリッド図で、960 px 幅にも対応。

768 Grid System in 12 Columns

768 Grid System in 16 Columns

この数値文字参照がすごい! 2008 年版

2008-12-15T00:00:00Z

早いもので今年ももうこの季節である。文字実体参照に比べて覚えづらい数値文字参照、その中でも使用頻度の高いものにスポットを当てる「この数値文字参照がすごい!」の 2008 年版をお届けする。

第 1 位: 〜 (`〜`)

満場一致。文句なしでぶっちぎりの首位に立ったのはご存知「波ダッシュ」。そのややこしい背景を考えれば HTML での表記は可能な限り避けて他の表現で代替したいところ。たとえば英語圏では「いつからいつまで」「どこからどこまで」の「から」は en ダッシュ (–) を使うことが多いみたい (ソース: Dash - Wikipedia, the free encyclopedia) なのでそうしてみたり。

とはいえやむを得ずニョロニョロするしかない場合も多い。そんなときはあわてずこの数値文字参照を。その結果、まわりから「なんか汚くね?」と軽く却下されても、来年こそは負けずにきっちり話を通したい。そんな気持ちの読者も少なくないはずだ。

第 2 位: ※ (`※`)

まさにダークホース。並みいる猛者たちを抑え堂々の第 2 位に輝いたのは「米印」。知る人ぞ知る通好みな存在と思われがちながら、エディタによって化けることも多く、なかなかあなどれない実力の持ち主。* (アスタリスク) での代替を勧めたいところだが…

第 3 位: ' (`'`)

2 ケタとあなどることなかれ。「アポストロフィ」がヴェテランの意地を見せた。' が HTML では使用できないことは広く知られており、2009 年もまだまだ現役での活躍が期待できそうだ。

編集後記

さて「この数値文字参照がすごい!」、通称「この文字」の 2008 年版、いかがだっただろうか。賢明なる読者諸兄ならお気づきのとおり、いつまでたっても波ダッシュを覚えられない自分のための記事だったわけだが。第 2 位で早くも息切れするあたり… また来年お会いしましょう! 良いお年を!

WordPress 2.7 “Coltrane”

2008-12-15T00:00:00Z

WordPress の新しいヴァージョン、その名も「コルトレーン」がリリースされたそうな。この tarkel.jp は Movable Type で構築しているのだけれど、WP は以前から気になっていて、いよいよ乗り換えを検討しようかと考えている。今回のリリースで特に惹かれたのがここ:

最後になりますが、重要なことをお知らせします。このバージョンは手動で WordPress をアップグレードする最後のバージョンになるかもしれません (訳注: 日本語版を完全にアップグレードするには、現時点では自動アップグレードは使えません)。皆さんが自分や友達のブログをアップグレードするのにどれだけうんざりしているかを聞いて、最新版が公開されたら自動的に通知する機能とビルドインアップグレード機能を組み込みました。これで、準備ができたらクリック一つで自動的にファイルをダウンロードし、インストールし、アップグレードすることができるようになりました。

WordPress | 日本語 » WordPress 2.7 “コルトレーン”

そうなのよ! つい先日も MT のセキュリティアップデートを実施したばかりなんだけど、もうね、かったるくって。上記のフィーチャーが日本語版にもきっちり実装されれば、かなりグッド。

それにこの「コルトレーン」てネーミング。大きく出たな、というか、かなりの自信作なんでしょう、きっと。この年末にでもいじってみるかも。

jQuery のセレクタ機能を拡張する

2008-12-16T00:00:00Z

jQuery の魅力のひとつは豊富なセレクタ機能だけど、それをさらに拡張することもできる。その簡単な方法を紹介してくれている記事をみつけた。

Extending jQuery’s selector capabilities - James Padolsey

たとえばインライン要素を取得するセレクタ機能は以下のように書けば作れちゃう。

$.extend($.expr[':'],{
  inline: function(a) {
    return $(a).css('display') === 'inline';
  }
});

これで、以降は :inline でインライン要素を取得できる。じゃあついでにブロックレベル要素を取得する機能も追加。

$.extend($.expr[':'],{
  inline: function(a) {
    return $(a).css('display') === 'inline';
  },
  block: function(a) {
    return $(a).css('display') === 'block';
  }
});

素晴らしい!

jQuery で外部サイトへのリンクをコントロール

2008-12-20T00:00:00Z

外部のサイトへのリンクについて、例えばそのことを示すアイコンを付けたり、あるいは別ウィンドウで開いたり、といった扱いをすることはよくある。そんな場合、jQuery があれば以下のような JavaScript でそのコントロールが簡単に。

まず最初に jQuery のセレクタ機能を拡張しておく。ここでは要素が href 属性を持ち、かつその属性値 (リンク先) のホスト名 (ドメイン名) が今いるページのホスト名と異なる場合に :external セレクタで捕まえられるように拡張。

$.extend($.expr[':'],{
  external: function(a,i,m) {
    if(!a.href) {
      return false;
    }
    return a.hostname && a.hostname !== window.location.hostname;
  }
});

この拡張セレクタを利用して、該当する a 要素に class 属性を付与してみる。

$(function(){
  $('a:external').addClass('external');
});

つまりマークアップは一切いじる必要がないってとこがミソ。あとは CSS で背景画像を表示させるなりどうぞお好きに! ちなみに別ウィンドウで開く仕様にするならこう:

$(function(){
  $('a:external').addClass('external').click(function(){
    window.open(this.href);
    return false;
  });
});

No Line on the Horizon: U2

2008-12-20T00:00:00Z

No Line On The Horizon, the new studio album from U2, will be released on Monday 2nd March 2009.

U2.com | Official News

U2 の 12 作目のスタジオ・アルバム “No Line on the Horizon” が 2009 年 3 月にリリースされる。“All That You Can’t Leave Behid”、“How to Dismantle an Atomic Bomb” と近年の 2 作が充実していたこと、イーノ、ラノワ、そしてリリィホワイトという鉄板の製作陣であること、などを考えると不安要素があまりない。周囲からの評価やギグの動員なども落ち着いているというか安定期に入ったというか、なのでちょっとしたどんでん返しを期待する気持ちもあるというか。

Electric Arguments: The Fireman

2008-12-27T00:00:00Z

ザ・ファイアーマンのサード・アルバム、『エレクトリック・アーギュメンツ』がいい。かなりいい。

ザ・ファイアーマンといえば、ポール・マッカートニーがキリング・ジョークのユースとはじめたユニット。活動は不定期で、1993 年と 1998 年にアルバムを発表している。サウンドはアンビエントというかエクスペリメンタルというか、僕らが知るポールの音楽とは違う、実験的なものだった。まあ周囲の捉え方としては、ポールのソロ・キャリアの合間のちょっとした息抜きでしょ、みたいな感じで、実際、今までの 2 枚のアルバムはポールのファンでさえ扱いに困ってきまりの悪い愛想笑いを浮かべるしかないような微妙な作品で、ほぼ無かったことになってた。それが…

ごらんの有様だよ。早い話がこれ、ユースとの共同プロデュースによるポールの新作だよな。ポールお得意の一人多重録音が中心、しかも全編ヴォーカル入り。リラックスしつつも緊張感があって、ラフなようでいて繊細な音作り。楽曲の質も高い。それに今回はベースもいいね。ポールをシンガーやソングライターとしてよりもまずベース・プレイヤーとして認識している僕としては嬉しい。

それにしてもこの 66 歳、ここへきてのやりたい放題ぶりは目に余る。ナイジェル・ゴドリッチと組んでみたり、古巣を離れて新レーベルに移籍してみたり、余興と見せかけてガチ新譜を出してみたり…まだやるか、と。

Best of 2008: 映画

2008-12-30T00:00:00Z

そもそも観た本数が少なすぎのためショボいリストになっちゃったけど、2009 年はもっと観よう、という決意とともにざっくりと振り返ってみる。

さすがにベタすぎるだろう、このラインナップは。ていうかこれ、今年観た新作ほぼすべてか。

『ダークナイト』はまあ皆さん文句ないでしょう。劇場で観たときも良かったけど、DVD でディテイルをチェックするのも楽しい。もちろん最大の魅力はヒース・レジャーの「口元」!

『ポニョ』は子供に観せちゃいけない問題作だと思う。例えば『となりのトトロ』なんかでは、「こちら側とあちら側の境界線」のようなものが暗黙のうちにきっちりと描かれていた。本作ではそのあたりがじつにあいまいというか、そもそも境界線が溶けてなくなってしまっているというか、観ていると足元がぐらつくような不安をかき立てられるんだ。また観たいような、もう観たくないような。

『スピード・レーサー』は DVD で観ちゃったことが悔やまれる。これは劇場で観なきゃいけなかった! クリスティーナ・リッチ、かわいい。

『ゼア・ウィル・ビー・ブラッド』は主演のダニエル・デイ＝ルイスと音楽のジョニー・グリーンウッドの映画だよな。『マグノリア』で見せてくれたような、アクの強い俳優たちの鬼気迫る演技をそれ以上のテンションで強引にまとめ上げ、混沌としたストーリーの果てにわけのわからない救いのようなものまでぶち込む、みたいな PTA 節を期待するとハズす。デイ＝ルイスを中心とした人間ドラマを執拗かつ容赦なく追いかける、という作品。とはいえ力強く美しい作品であることは間違いない。

2009 年はできれば毎月 1 回は劇場に足を運びたいなー。DVD も迷ったらとりあえず買え、の姿勢で臨みたい。

Best of 2008: 音楽

2008-12-30T00:00:00Z

映画篇もそうだったけど、そもそも新作を聴いてない! みずからに猛省を促したい。

やはり今年はなんと言っても AC/DC。これが本当に素晴らしい作品で笑った。楽曲のクオリティ、ヴォーカルのパワー、ギターのキレが 80 年代に戻っちゃってるもん。AC/DC はどれから聴いたらいいんスか? というキッズはまず “Back in Black” と “The Razors Edge” とコレを押さえろ。まさに「最後の傑作」と呼ぶにふさわしい、見事なまでの集大成。あまりに美しい白鳥の歌。

ケイジャン・ダンス・パーティなんかも聴いてるよ、とか言ってリストに入れちゃうあたりのセンスがもうね、おっさんです。いやでもこのアルバムは良かったよ。巧みなソングライティングやヴォーカルのカリスマも魅力だけど、特にジョニー・マーやジョン・スクワイアらの系譜に連なるギターが素晴らしい。

ザ・ファイアーマンは別の記事で書いたとおり、予想外の当たり。ちなみに iTunes Store だとボーナス・トラック入りでしかも安いです。

スーパーグラスは世紀の大傑作 “Road to Rouen” に続く待望の新作! とおおいに盛り上がったわけだが、んー、なんか少し昔に戻っちゃった感じが残念かなー。前作のアコースティック路線をどう発展させてくれるかに期待してたんだけど。AC/DC じゃないんだから、まだまだ新しい音を聴かせてほしい、このバンドには。もちろん良い曲はあるけどね。

タミオは冒頭のギターの鳴りがやばい。この最初の瞬間を聴きたくて何度もリピートしたアルバム。

さよなら、2008 年!

2008-12-31T00:00:00Z

このブログを始めた。
タバコをやめた。
MacBook を買った。
転職した。

今年、俺はなにをしてきただろう。思いつくままにリストアップしてみて、それぞれが互いに繋がっていることに気づく。あるいは俺はひとつの小さな決心をしただけで、その結果、いくつかの出来事が起こったと言うべきか。俺はいつかこの年を、ひとつの決心といくつかの変化があった年として思い出すのかもしれない。

さよなら、2008 年!

Pop Life: Life Without Buildings

2009-01-11T00:00:00Z

ライフ・ウィズアウト・ビルディングスがプリンスの ‘Pop Life’ をカヴァーしてる音源を発見! モノはイタリーのレーベル Homesleep から 2001 年に出たコンピ盤 “HomesleepHome 2: Cover Songs” に収録されている。

内容はかなりストレートなカヴァーで、メロディから構成までほぼ原曲のまんま。これが意外なほどはまってて、まるで違和感がない。ほんとにこの曲が好きなんだろうなー、と好感の持てる仕上がり。ファンとしてはギターの空間系処理やバッキング・ヴォーカルの多重録音が新鮮で、なんだかうれしくなってしまった。

LWB というバンドについてはいずれ稿を改めてきっちり書きたいと思ってるんだけど、とりあえず情報共有まで。

JavaScript と CSS を使った「このページを印刷」リンク

2009-01-13T00:00:00Z

クリックするとブラウザの印刷ダイアログが立ち上がる、いわゆる「このページを印刷」リンク。マークアップはだいたいこんな感じになると思う:

<p class="print">
  <a href="#" onclick="window.print(); return false;">このページを印刷</a>
</p>

でもこれ、JavaScript が無効の場合はどうなるだろう? そう、何も起こらない無意味なリンクになっちゃうよね。そこで、JavaScript と CSS を使ってひと工夫してみよう。

まずは JavaScript。例によって jQuery を読み込んだ上で、こんな風なスクリプトを記述:

$(function(){
  $('body').addClass('js-enabled');
});

もちろんクラス名はなんでもよくて、body 要素になんらかの class 属性を付与できれば OK。つまり、JavaScript が有効であることの証しとして「しるし」をつけておくわけ。

そして最後に CSS:

p.print {
  display: none;
}
.js-enabled p.print {
  display: block;
}

すごく簡単なトリックなんだけど、要素をいったんまるごと消しといて、js-enabled クラスがある場合—つまり JavaScript が有効の場合のみ表示させるってわけ。この CSS を書き換えれば、たとえば今回のシチュエイションとは逆に、JavaScript が無効の場合にだけメッセージを見せる、なんてのも簡単。完成版デモを用意したのでチェックしてみて。

それに、このシンプルな JavaScript の有効判定はいろいろと応用ができそうだよね。だからもし「このページを印刷」リンクがなかったとしても、スクリプトを書くときはとりあえず body 要素に「しるし」をつけておく、ってのは悪いアイディアじゃないんじゃないかな。

スクロールで背景画像が変化する (ように見える) トリック

2009-01-14T00:00:00Z

CSS を使ったエフェクトで久々に楽しいのを発見! 説明するのが難しいので、下記ページのサンプルを (IE 6 以外のモダン・ブラウザで) チェックしてみてほしい。

Mike asks the CSS Guy about a scrolling trick with background images (Ask the CSS Guy)

これは思いつかなかったなー。垂直方向に並んだ要素にそれぞれ背景画像を用意して、background-attachment プロパティに fixed を指定、同じ位置に重ねるのがミソ。前述のとおり IE 6 には対応していないので、適宜ハックなどで対応を。

jQuery 1.3、リリース!

2009-01-15T00:00:00Z

jQuery の最新メイジャー・アップデイト、jQuery 1.3 がいよいよリリースされました! .live() とか .die() とか新しい要素もあるけど、全体的にかなり速くなったっぽいとこが売りっぽい。CSS セレクタ・エンジン Sizzle の搭載や各種リライトが奏功している模様。ベンチマークを見てみると、セレクタの書き方の最適化メソッドもやや変わってきそう。ともあれ、明日は仕事そっちのけでチェックする構えです。

そうだ、書き忘れてた。お誕生日おめでとう、jQuery!

スペースの幅

2009-02-09T00:00:00Z

いわゆる「半角スペース」の幅って font-size の値に対してだいたいどのくらいの割合なの? ってのを調べる必要があったので、よく使う代表的な欧文フォントについてまとめてみた。どうやって調べたかというと、

<p><span>&nbsp;</span></p>

こんな感じのマークアップに、

p {
  font-family: "Arial";
  font-size: 1000px;
}
p span {
  background-color: red;
}

というスタイルシートを当てる。ブラウザで表示させてみて、赤いスペースの幅を測って font-size の値で割れば、そのファミリーのスペース幅の相対値がおおよそ算出できるはず。

じゃあまずは Windows XP での結果から。

Font Family	Width of Space (em)
Arial	0.278
Verdana	0.352
Georgia	0.241
Courier New	0.6

表1：Windows XP + Firefox 3.0

なんとなく直感的に 0.5 em あたりじゃね? と思っていたので、こうしてきっちり数字を出してみると面白い。とくに Georgia の細さとか。

次、Mac。僕が CSS を書くときに上記 Windows フォントとよく一緒に組み合わせるフォントをチョイスしてみた。

Font Family	Width of Space (em)
Helvetica / Helvetica Neue	0.278
Lucida Grande	0.316
Hoefler Text	0.25
Monaco	0.6

表2：Mac OS X + Firefox 3.0

やっぱり似たフォントはスペースの幅も近い。なんか妙に安心した。

ひょっとすると同じ OS でもブラウザによってレンダリングが異なる可能性はあると思うけど、Windows XP の Firefox 3.0 と IE 7.0 でまったく同じ数値だったので、まあどのブラウザでもほぼ一緒だと思われる。

jQuery と CSS を使った Apple 風パンくず

2009-02-14T00:00:00Z

Fig 1: 「jQuery と CSS を使った Apple 風パンくず」完成図

パンくず (Breadcrumbs) ってその必要性に疑問を感じることの多い要素の筆頭だと思う。この案件で要るか、これ? みたいな。そんなわけだからあまり力を入れて作ったことがなかったんだけど、Veerle’s blog のパンくず作成チュートリアル Simple scalable CSS based breadcrumbs を読んで、必要かどうかはとりあえず置いといて、どうせ置くならお洒落な方がいい、っていうか俺もクールなパンくず作る! と盛り上がってしまい、作ってみた。

Fig 2: Apple のパンくず。影響力大

Fig 3: Delicious のタグのリスト。妙に好き

目論んだイメージとしては Apple 風のルックスに Delicious のチェーン状に繋がったタグのリスト的なロールオーバー効果をプラスした感じ。もちろん、カスタマイズの余地を十分に残しつつ、できる限りシンプルなコードを目指した。

1. マークアップ

パンくずをどうマークアップするか、というのはよく議論される話題。ちなみに前述の Veerle’s blog では ul、Apple は ol だ。でも俺に言わせりゃんなもん p に決まってんだろ、である。パンくずってのはあくまでも「迷子にならないための道しるべ」であるべきだと思うから、なんというかこう「1 本につながった感じ」が欲しいんだよね。リスト形式だと 1 つ 1 つのパンくずが独立しちゃってる気がして、どうにも違和感を感じるというか。そういった意味では ol ってのはまあアリかなと思うけど、でも実際のところ横一列に並べる以外の見せ方ってなかなか考えづらいわけで、そうするとやっぱ p じゃね、てのが僕の考え方だけどどうだろう。

まあとにかく、ここではパンくず全体を p 要素でマークアップする。各リンク間を「>」 (>) で区切って、「今ココ」は em で示す:

<p class="crumbs">
  <a href="#">Home</a><span> &gt;
  </span><a href="#">Archives</a><span> &gt;
  </span><a href="#">2009</a><span> &gt;
  </span><em>You Are Here!</em>
</p>

「>」はコントロールしやすくするため span で囲んでおく。このとき前後の要素との間にスペースを入れないように。マークアップは以上。次、スタイルシートいきます。

2. スタイルシート

p.crumbs {
  font-family: "Lucida Grande", "Verdana", sans-serif;
  font-size: 68.75%;
  line-height: 3.0;
  font-weight: bold;
  background-color: #e0e0e0;
  overflow: hidden;
}

まずは p を整形。line-height は Apple っぽくやや大きめに。だいたい 3 前後ぐらいがサマになると思う。overflow につては後述。次は a と em をまとめて指定:

p.crumbs a,
p.crumbs em {
  padding: 1.0em 2.0em 1.0em 1.0em;
  color: #404040;
  background-color: #e0e0e0;
  text-decoration: none;
  font-style: normal;
}
p.crumbs a:hover {
  color: #ffffff;
  background-color: #808080;
}

まず padding を設定して領域を広げる。もし p の line-height を 3 にしたなら、a の上下 padding はそれぞれだいたい 1em。もし上下に少しはみ出しても前述のとおり p の overflow を指定しとけば OK。また右だけ少し多めに取るのもポイント。

背景色は p と同じに。a:hover のデザインはここでは Delicious を意識しつつかなりざっくりとした反転パターンを採用したけど、実際はもう少し抑え気味のほうがおしゃれかな。

さて次はいよいよこのデザインのキモ、「>」部分にギミックを仕込む:

p.crumbs span {
  padding: 1.0em 0;
  margin-left: -1.5em;
  color: #e0e0e0;
  background: url(img/crumbs.png) no-repeat 100% 50%;
}

まず上下の padding に a と同じ値を指定。margin-left にマイナス値を指定し、直前の a 要素の上に重ねる。値の大きさはフォントによって調整が必要かも。また前景色を a の背景色と同じにして見えなくする。

Fig 4

Fig 5

背景画像は、Fig 4 のように右向きの三角部分を透過させ、かつその境い目の部分にラインを入れたものを用意。文字サイズに対応すべくやや大きめに。GIF でもいいんだけど、IE6 への対応は別途考えるとして、ここはぜひ半透明のアルファチャネル PNG でいってみよう。ついでに Fig 5 のようなロールオーバー用も作っておく。

さて、ここまでのソースをブラウザで見てみると、ぱっと見たところは出来上がったけども、リンクにマウスの乗せると Fig 6 のようにイマイチな結果になるはずだ。

Fig 6: もう一息

ここで要求される挙動はどんなものだろうか? a が :hover 状態になったときに「直前の span の背景画像」と「直後の span の前景色」が変更できればいいよね。はい、jQuery の出番です。

3. スクリプト

<script type="text/javascript" src="js/jquery.js"></script>

HTML/XHTML の head で jQuery を読み込み、さらに以下のような JavaScript を加える:

$(function() {
  $('p.crumbs a').hover(function() {
    $(this).prev('span').addClass('prev');
    $(this).next('span').addClass('next');
  }, function() {
    $('span.prev').removeClass('prev');
    $('span.next').removeClass('next');
  });
});

hover() イベントはその要素にマウスが乗ったときと外れたときに実行する関数を定義する。ここでは a にマウスが乗ったときに、prev() でその直前の、next() で直後の span を取得、それぞれに class を付与し、マウスが外れれば削除する、という関数。今回のマークアップ例でいうと、たとえば「2009」ってリンクにマウスが乗っている間、ソースは JavaScript エンジンによってこういうふうに生成されていることになる:

<p class="crumbs">
  <a href="#">Home</a><span> &gt;
  </span><a href="#">Archives</a><span class="prev"> &gt;
  </span><a href="#">2009</a><span class="next"> &gt;
  </span><em>You Are Here!</em>
</p>

あとはこの新たに生成された class のためのスタイルを書けばいい。

4. 再びスタイルシート

p.crumbs span.prev {
  background-image: url(img/crumbs-h.png);
}
p.crumbs span.next {
  color: #808080;
}

はい、出来上がり! 完成版のデモをどうぞ。

最後に背景画像について補足が 2 つ。まず、前もって読み込みを行っていないので最初にマウスを乗せたときに「ちらつき」が発生する。なんか対策したいところ。例えば p 要素あたりに持たせてしまっても良いかも:

p.crumbs {
  ...
  background: #e0e0e0 url(img/crumbs-h.png) no-repeat -9999px -9999px;
  ...
}

もうひとつ、IE6 がアルファチャネル PNG に対応していない件について。デモでは CSS のハックで IE6 のみに代替の透過 GIF をあてがってるけど、もちろん適当な JavaScript ライブラリかなんかを使っても良い。というかその方がキレイだし。ハッピィ・ヴァレンタイン!

お誕生日おめでとう、World Wide Web!

2009-03-13T00:00:00Z

20 年前の今日、世界を永遠に変える出来事が起こった—

1989 年 3 月、ティム・バーナーズ＝リーは Information Management: A Proposal と題するペーパーを CERN の関係者に配布した。ウェブの歴史の第一歩が、静かに踏み出されたのだ。この提案を目に見える形にするためのハイパーテキスト処理プログラム、すなわち最初のウェブ・ブラウザは、翌 1990 年のクリスマスまでには完成する。

（ウェブブラウザ小史 2001 - The Web KANZAKI）

20 年後の自分がこんなにも夢中になるものが生まれたというのに、当時まだ高校生だった僕はこの小さな大事件をまるで知らなかったよ。お誕生日おめでとう、World Wide Web!

チェック/ペケ

2009-03-28T00:00:00Z

HTML/XHTML でチェックマーク (Tick) やペケ (X mark) を表示させるには以下の文字参照が使える。

	数値文字参照	名称
✓	`✓`	CHECK MARK (tick)
✔	`✔`	HEAVY CHECK MARK (bold tick)
✗	`✗`	BALLOT X (cross)
✘	`✘`	HEAVY BALLOT X (bold cross)

しかし IE6 では文字化けすることが多いようなので、CSS で Unicode フォントを指定するといいみたい。

<!-- HTML/XHTML -->
... <span class="unicode">&#10004;</span> ...

/* CSS */
.unicode {
  font-family: "Arial Unicode MS", "Microsoft Sans Serif", sans-serif;
}

インライン要素に背景画像を指定する

2009-03-29T00:00:00Z

Fig 1: インライン要素に背景画像を指定

CSS でインライン要素に背景画像を指定する場合、IE6 と IE7 では致命的なバグがあるので注意。たとえば Fig 1 のように、パラグラフ中のハイパーリンクにアイコンを表示させたいとする。となると CSS はこんな感じになるだろう:

a.pdf {
  padding-left: 20px;
  background: url(/img/pdf.png) no-repeat 0 50%;
}
a.external {
  padding-right: 20px;
  background: url(/img/external.png) no-repeat 100% 50%;
}

すべてのモダン・ブラウザで Fig 1 のようなレンダリング結果が得られるが、背景画像を指定したインライン要素が改行して複数行にわたる場合、IE6/7 は Fig 2 のようにしくじる。

Fig 2: IE6/7 では改行を含むインライン要素で背景画像の表示位置がずれてしまう

この回避策が IE対策: 改行される可能性のあるインライン要素に背景画像を指定しない。- 我流天性 - がらくた屋で紹介されている。パディングと背景画像を該当のインライン要素には指定せず、かわりにその内側に仕込んだ空の span 要素に持たせるメソッドだ。

... <a href="..." class="pdf"><span>&nbsp;</span>テキスト</a> ...

a.pdf span {
  padding-left: 20px;
  margin-right: -0.3em;
  background: url(/img/pdf.png) no-repeat 0 50%;
}

空の span といっても、上記のように   を入れないとうまくいかない。ちなみに負のマージンはこの余分な   を相殺するためのもの。

これで IE6/7 でも Fig 1 のようにレンダリングされる。とはいえこんな無駄なマークアップをいちいち書くのはちょっとうんざりだし、そもそも IE6/7 以外のモダン・ブラウザには不要だし。というわけで、もう少し冴えたやり方を考えてみた。

まず、例によって jQuery の力を借りる:

<script type="text/javascript" src="/js/jquery.js"></script>

次に、JavaScript ファイルに以下のプラグインを用意:

$.fn.extend({
  inlineBgFix: function() {
    if ($.browser.msie && $.browser.version < 8.0) {
      $(this)
        .addClass('inline-bg-fix')
        .prepend('<span class="bg-l">&nbsp;</span>')
        .append('<span class="bg-r">&nbsp;</span>');
    }
  }
});

あとは必要に応じて上記の inlineBgFix() メソッドを呼び出す。例えば pdf という class を持つ a 要素に背景画像を適用するなら:

$(function() {
  $('a.pdf').inlineBgFix();
});

この結果、バージョン 8 未満の IE では以下のマークアップが生成される:

<a href="..." class="pdf inline-bg-fix">
  <span class="bg-l">テキスト<span class="bg-r">
</a>

そして CSS。まず IE6/7 用の記述から。「本来の」要素に指定されるパディングと背景画像を打ち消し、余分に挿入されたスペースを相殺しておく。なおスペースの幅はフォントによって異なるので調整のこと:

.inline-bg-fix {
  padding: 0 !important;
  background: none !important;
}
.inline-bg-fix .bg-l {
  margin-right: -0.3em;
}
.inline-bg-fix .bg-r {
  margin-left: -0.3em;
}

最後に、パディングと背景画像をまっとうなブラウザ用と IE6/7 用と一緒に指定。以下は要素の左側に配置する場合の例:

a.pdf,
a.pdf .bg-l {
  padding-left: 20px;
  background: url(/img/pdf.png) no-repeat 0 50%;
}

面倒だけど、とりあえずはこれでうまくいく。IE8 では修正されているのがせめてもの救い。

link か @import か

2009-04-10T00:00:00Z

In Chapter 5 of High Performance Web Sites, I briefly mention that @import has a negative impact on web page performance. I dug into this deeper for my talk at Web 2.0 Expo, creating several test pages and HTTP waterfall charts, all shown below. The bottomline is: use LINK instead of @import if you want stylesheets to download in parallel resulting in a faster page.

High Performance Web Sites :: don’t use @import

『ハイパフォーマンス Web サイト — 高速サイトを実現する 14 のルール』の著者、Steve Souders 氏のブログより。HTML ドキュメントに CSS ファイルをインクルードする際、link 要素と @import ルールをどう組み合わせるのが速いか、という話。上記の引用もとでは様々なパターンでのパフォーマンス実験の結果が紹介されている。ものすごくざっくりとまとめちゃうと、@import よか link のが速いよ、が結論。

CSS ファイルをどう分割するかってのはけっこう悩むもの。たとえば、この宣言は layout.css と modules.css のどちらに書くべきか、とか、そもそもどこまで細かく分割すべきか、とか。その結果、あの宣言ってどこに書いたっけ、とか。でもインクルードの方法でパフォーマンスに違いが出るってのは意識したことなかったなー、と反省。

ていうかパフォーマンスを考えるなら、link か @import かっていうより、まずは CSS ファイルの数を減らすことが先だよな。あとは保守性との兼ね合いで、どこまで分割するかを決めればいい。

つまり、CSS ファイルは可能な限り分割せず、かつ @import ではなく link でインクルードすべし、と。そうすれば分割についての悩みも減るうえ、サイトのパフォーマンスも向上する、はず。

小学校 8 年生

2009-04-11T00:00:00Z

僕たちは高校 3 年生と小学校 6 年生を同じ教室に集めて、同じ教科書を使って授業をしている。まずみんなに教科書どおりの説明をするけど、当然ながら小学生の子たちは正しく理解できない。僕たちは彼らの机まで行き、説明してやらなければならない。「あのね、ここはわかりやすく言うとね…」

body {
  font-size: 10px;
}
* html body {
  font-size: 62.5%;
}

この見慣れた光景に高校生たちは心底うんざりしている。彼らは早く次のページに進み、授業を終わらせたい。その気持ちはふたとおりの教え方をしなきゃいけない僕たちも同じ。でも机の半数以上を占領している小学生を無視するのはなかなか難しいんだ。

しかしついに、この小学生のうちの何人かが卒業することになった。これで少しはましな授業ができると思った。ところが。

body {
  font-size: 10px;
}
* html body {
  font-size: 62.5%;
}
*:first-child+html body {
  font-size: 62.5%;
}

小学校 6 年生のうち半数は留年。残り半数も卒業ではなく、なんと小学校 7 年生という新しい学年を作って進級してしまった。この新 7 年生は 6 年生に比べればまだ理解力はあるけど、でもやっぱり小学生だから、高校生と同じ授業を受けるのは難しかった。つまり僕たちは 7 年生のための新しい教え方を考案しなきゃならなかった。

この時点で、勘のいい教師はうすうす感づいていたのかもしれない。そしてあるいは新たな授業法を模索しはじめたのだろう。でも僕は楽天家だった。あの子たちもいずれは卒業していくから、それまでの辛抱。そう考えていた。

そして、春。別れの季節。小学校 6 年生と 7 年生の何人かは残念ながら留年が決まっていたけど、それは予想できたことだった。でも何人かは今度こそ卒業してくれるだろう。そう、僕は楽天家だった。

body {
  font-size: 10px;
}
* html body {
  font-size: 62.5%;
}
*:first-child+html body {
  font-size: 62.5%;
}
?!*@last-childくぁｗせｄｒｆｔｇｙふじこbody {
  font-size: 62.5%;
}

最後の教え方はでたらめなので、誰にも理解できません、念のため。でもでたらめを教えたくもなる。まさかの小学校 8 年生。悪夢以外のなにものでもない。にぶい僕でもついに気づく。彼らは卒業するつもりなどないのだ。おそらく彼らのうち何人かは何食わぬ顔で 9 年生に進級し、何人かは 6 年生のまま。いずれにせよ教室に居座り続けるだろう。

これでは永遠に授業が終わらない。こんな効率の悪いことを続けていては僕たちのからだが持たないし、授業をしっかり理解してくれている高校生の子たちにも申し訳ない。そう、ついに新しい段階に進むべきときが来たのだ。

<head>
...
<link rel="stylesheet" type="text/css" href="common.css" />
<!--[if IE]>
  <link rel="stylesheet" type="text/css" href="ie.css" />
<![endif]-->
...
</head>

/* common.css */
body {
  font-size: 10px;
}

/* ie.css */
body {
  font-size: 62.5%;
}

これが、現時点で僕がベストと考えるアプローチ。

小学生のために授業を中断するのはもうやめだ。彼らが理解できようとできなかろうと、まずはきっちりと教科書どおりに授業を終わらせる。高校生はここで帰ってよし。そして放課後、授業についてこられない小学生を集めて居残りの補習。ちなみにこの補習用の資料は学年別にそれぞれ用意することも可能だけど、きりがないのでほどほどにしておく。

時間と労力を割かなければいけないことに変わりはないけど、本来の授業と明確に分離することの意味は小さくない。とりあえず、高校生を無駄に拘束せずに済むだけでも大きな前進だ。

空がまた暗くなる

2009-05-03T00:00:00Z

RCサクセションの最後のアルバム『Baby a Go Go』がリリースされたのは1990年、僕が高校生のときだった。当時やっていたバンドのドラマーから借りて聴いたんだったと思う。そのときはかなり気に入ったんだけど、ここ十数年はまったく聴いていなかった。すっかり忘れていたというか。それが先日、友人と飲んでいてこのアルバムの話になり、懐かしさから久々に購入して聴いてみることにしたのだ。

そして僕はそこに収められた「空がまた暗くなる」に戦慄することになる。高校生のときはまるでわからなかった。こんなにも恐ろしい歌を、僕はほかに知らない。

おとなだろ　勇気をだせよ
おとなだろ　知ってるはずさ
悲しいときも　涙なんか
誰にも　見せられない

おとなだろ　勇気をだせよ
おとなだろ　笑っていても
暗く曇った　この空を
かくすことなどできない

ああ　子供の頃のように
さあ　勇気を出すのさ
きっと　道に迷わずに
君の家にたどりつけるさ

おとなだろ　勇気をだせよ
おとなだろ　知ってることが
誰にも言えないことばかりじゃ
空がまた　暗くなる

（RCサクセション「空がまた暗くなる」）

空は暗く曇っている。僕たちにはなすすべもない。ただただ泣きじゃくる者がいる。笑ってやり過ごそうとする者もいる。しかし空が明るさを取り戻すことはないし、もはやそのことを隠すこともできない。どこへも行こうとしない黒い雲はいよいよ厚くたれこめてゆく。

僕たちは道に迷っている。もうおとなになったはずなのに、家へ帰れなくなってしまっている。そして家にたどりつくために今、おとなである僕たちに子供のような勇気が求められている。そんな子供じみたものを手放すのと引き換えに、僕たちはおとなになったはずなのに。

彼は知っている。僕たちがこの暗い空におびえて泣いていること、すべてを笑ってごまかそうとしていること、勇気を失って道に迷っていること、そして、後ろめたい思いを胸に抱えたままでいること。

しかし彼は何も教えてくれない。彼は僕たちに泣くことも笑うことも禁じ、困難な矛盾を強い、誰にも知られていなかったはずの秘密を暴き、そして暗い空の下に僕たちを放り出したままどこかへ行ってしまう。どうすればこの空が再び明るくなるのか、その答えはついに示されない。ただ、このままではこの空がまた暗くなるばかりだと、彼はそう告げるのみだ。

僕たちはこんなにも恐ろしい歌を書く詩人を永遠に失ってしまったのだ。忌野清志郎の冥福を祈る。

僕が HTML 4.01 を選ぶ理由

2009-05-05T00:00:00Z

このサイトの文書型を XHTML 1.0 から HTML 4.01 に変更しました。

その理由を説明するために、まずはそもそも XHTML だった理由から振り返ってみます。結論から言ってしまえば、まあその、「とりあえず」、ですね。僕が Web デザインの勉強を始めたのが 2006 年初頭で、そのときに参考書として選んだのが 2005 年 7 月に初版が発行された『Web 標準の教科書 — XHTML と CSSでつくる “正しい” Web サイト』。なんとなく雰囲気が伝わるといいんですけど、いわゆる「Web 標準の時代」とでも言うべき時代に僕はこの世界に入ったわけです。当時の空気としては「これからは HTML よか XHTML ですよ」という流れがほとんど不可逆的なものとして捉えられていたと思います。以来 3 年間、僕は個人でも仕事でもいくつものドキュメントをマークアップしてきましたが、「これからは XHTML」っていう考えに大した疑問も抱かずに、「とりあえず XHTML」でやってきたわけです。

でもそろそろ時代が「これからは XHTML」ってのとはちょっと違うとこに来てるなー、とのん気な僕がようやく感じ始めたのがこの春。HTML 5 が盛り上がりを見せる反面、XHTML 2.0 はどうも「来ない」っぽいと。例えば An Event Apart や Safari 4 なんかのサイトが HTML 5 で書かれているの見て、「あ、もう始まってるんだ…」と思ったりとか。「くたばれ『Web標準』」って何よ？や Dave Shae が HTML にスイッチすることを表明した記事とかも刺激になりました。

だったら一気に HTML 5 で、というチョイスももちろんあったわけです。特にこのサイトのように Web のフロントエンド技術を話題にするようなサイトならその意義もおおいにあるでしょう。でもやっぱりまだそこまではちょっと、というのが本音です。独立したページでいろいろ実験するとかはやっていきたいですけど。

となると、すでに XHTML で構築しちゃったんだから、HTML 5 が固まるのを待ってリブートすれば? というのもまたひとつの選択肢でしょう。実際、僕も仕事で運用している XHTML サイトをいちいち HTML に書き換えるなんてことは提案しないでしょうし。僕がこのサイトを HTML 4.01 に書き換えたのは、もちろん HTML 5 に備えてではあるんですが、それよか大きいのが、今まで感じていたジレンマを解消できると思ったからです。

XHTML を書くことには常にジレンマがつきまといます。XML 宣言のジレンマ—ほんとは書くべきなんだろうけど、書くと IE で面倒なことになるからとりあえず省略—とか、メディアタイプのジレンマ—ほんとは application/xhtml+xml が推奨されてるらしいけど、やっぱり IE で上手くいかないのでとりあえず text/html—とか。もちろん、ここらへんのジレンマをちゃんと受け止めるというか、例えば IE の Quirks モードにきっちりつきあったり、コンテント･ネゴシエーションしたりってアプローチもあります。ありますが、じゃあそこまでして XHTML でありたいか、つまり XML でなければならいないかというと、少なくとも現時点でのこのサイトはその必要がまるでないわけです。僕が今まで仕事で書いてきた XHTML もそう。

もうひとつ、XHTML を選ぶ理由としてよく言われる、XHTML の「X」の部分、つまり拡張性について。これってけっこうクセモノというか、上手いとこ突くなあというか、ひっかかりやすい罠というか、なんかそんな風に感じてます。というのも、XHTML って HTML が書ければほとんど書けちゃう—つまり学習コストが低い。コストがほとんど変わらないの加えて「なんならオプションでいろいろと追加できますよ」とか言われれば、そりゃ「じゃあ、とりあえずこっちにしとこうか」とかなりません? なりますよね? だって、必要がなければ使わなくたっていいわけだから。でもさ、その拡張性があとから必要になったこと、ありますか? 少なくとも僕はこの 3 年間で一度もなかった。MathML? XSLT? んー、とりあえず、今はいいや。でしょ?

これってレンタルヴィデオ屋の会員証にクレジットカード機能がついてるみたいなもんでしょ、言ってみれば。会費は変わらず、今までどおりヴィデオは借りられて、しかもお買い物もできちゃう、みたいな。ただヴィデオを借りるばかりでクレジットカードを使わないでいると、この機能の存在自体を忘れがちだけど、でもこの余分のおかげでカード会社との契約書とかの煩雑な手続きが発生するし、ひょっとするとなんらかのトラブルが起こる可能性だってあるわけで。やっぱタダじゃ済まないというか。じゃあもう面倒だからこの際ハッキリさせようと。俺はただヴィデオが借りたいだけなんだと。もしクレジットカードが必要になったら、そんときは改めてお願いするわ、と。

まあだいたいこんなことを考えて、XHTML から HTML への切り替えに踏み切った次第です。やってみて、「マークアップはまず文書型の選択から」という当たり前すぎることを再認識できたのがすごく大きな収穫。いかに今までなにも考えずにマークアップしてきたか、ということです。だからこれから、やっぱ XHTML 1.1 で、とか、ためしに HTML 5 にしてみる、とかいう発想を持てるようになったと思う。まあ当面このサイトでは、HTML 5 に備えた HTML 4.01 の設計、みたいなのを模索してみたいと思います。

jQuery Counter Plugin

2009-06-08T00:00:00Z

CSS 2.1 の Counter 構文や CSS 3 の Lists モジュールのような、任意の要素に色んなタイプの連番を自動的にふる jQuery プラグイン、jQuery Counter Plugin を書いた。ol 要素ほか順列リストのマーカー部分を柔軟にコントロールしたい、というのが主な目的だけど、個人的な裏テーマは JavaScript の配列と正規表現の勉強。

Demo

Demo: jQuery Counter Plugin

Download

jQuery Counter Plugin

Usage

例えば以下のようなごく普通の ol 要素に適用する場合。

<ol>
  <li>List Item</li>
  <li>List Item</li>
  <li>List Item</li>
</ol>

プラグインを jQuery と一緒に読み込んで、setCounter() で呼び出す:

<script type="text/javascript" src="jquery.js"></script>
<script type="text/javascript" src="jquery.counter.js"></script>
<script type="text/javascript">
$(function() {
  $('ol').setCounter();
});
</script>

その結果、以下のように li 要素の子要素としてマーカーが生成される。同時に display プロパティの値が list-item である場合はデフォルトのマーカーが非表示に:

<ol style="list-style-type: none;">
  <li><span class="marker"><span class="marker-body">1</span>. </span>List Item</li>
  <li><span class="marker"><span class="marker-body">2</span>. </span>List Item</li>
  <li><span class="marker"><span class="marker-body">3</span>. </span>List Item</li>
</ol>

これだけだと普通の ol と変わらないようにも見えるけど、マーカー部分を装飾できたり、display プロパティでインライン化してもマーカーが消えなかったりとか、CSS で柔軟なコントロールが可能になるのは地味に便利、と自負。

そのほか、オプションを指定すれば list-style-type: cjk-heavenly-stem とか content: "[" counter(section, upper-roman) "] "; 的なことも可能。

Options

オプションはオブジェクトで指定。

$(function() {
  $('dl').setCounter({
    selector: 'dt',
    start: 8,
    markerType: 'あ',
    markerLeft: '(',
    markerRight: ') '
  });
});
</script>

selector

番号をふる子要素。この値を jQuery の children() に渡すので、指定できるのは直接の子要素のみ。デフォルトでは空白なので、ol なら li に番号がふられる。たとえば dl 要素のうち dt 要素にだけ番号を付与したい場合なら、$('dl').setCounter({ selector: 'dt' }); となる。

start

開始する番号。デフォルトは 1。

markerType

CSS の list-style-type にあたる部分で、デフォルトではアラビア数字 (1, 2, 3…)。以下のキーワードを指定できる。

値	出力例	説明
`01`	01, 02, 03 … 09, 10, 11 …	アラビア数字の 0 詰め (2 桁)。
`001`	001, 002, 003 … 099, 100, 101 …	アラビア数字の 0 詰め (3 桁)。
`0001`	0001, 0002, 0003 … 0999, 1000, 1001 …	アラビア数字の 0 詰め (4 桁)。
`a`	a, b, c … x, y, z	ラテン文字 (小文字)。
`A`	A, B, C … X, Y, Z	ラテン文字 (大文字)。
`i`	i, ii, iii … ix, x, xi …	ローマ数字 (小文字)。3999 まで。
`I`	I, II, III … IX, X, XI …	ローマ数字 (大文字)。3999 まで。
`A`	A, B, C … X, Y, Z	ラテン文字 (大文字)。
`あ`	あ、い、う … わ、を、ん	平仮名のあいうえお。
`ア`	ア、イ、ウ … ワ、ヲ、ン	片仮名のアイウエオ。
`い`	い、ろ、は … せ、す、ん	平仮名のいろは。
`イ`	イ、ロ、ハ … セ、ス、ン	片仮名のイロハ。
`子`	子、丑、寅 … 酉、戌、亥	十二支。全 12 文字。
`甲`	甲、乙、丙 … 辛、壬、癸	十干。全 10 文字。
`一`	一、二、三 … 九、十、十一 …	漢数字。9999 まで。
`壱`	壱、弐、参 … 玖、壱拾、壱拾壱 …	漢数字 (大字)。9999 まで。
`〇`	一、二、三 … 九、一〇、一一 …	漢数字 (位取り記数法)。9999 まで。

markerLeft

マーカーの左側に記号などを挿入できる。デフォルトではからっぽ。たとえば {markerType: '壱', markerLeft: '其の'} で「其の壱、其の弐、其の参 …」など。

markerRight

同じくマーカーの右側に挿入する記号。デフォルトは '. ' で、ol 要素のよくある感じになる。

ToDo

漢数字やローマ数字の位の計算で挫折しかけたけど、なんとか思っていたものができたのでとりあえずは満足。でもまだまだ改良の余地があるはずなので、課題をいくつかリストアップしておく。

switch 文と if 文の使い分け方がスマートじゃない気が。とくに 0 詰めのあたりとか、妙にうざい。
jQuery プラグインでありながらあまり jQuery っぽくない気が。なにかものすごく便利なメソッドを忘れてるような。
漢数字の 10000 以上に対応すべきか? 桁の計算式が面倒くさそうってのもあるけど、「那由他」とか「不可思議」とか中二っぽくてちょっと…
デモ作るのって難しいなー…

非置換要素の幅を明示せずにフロート

2009-06-28T00:00:00Z

CSS で非置換要素 (img とか objectとかフォームのコントロール系とか以外、ってことね) に float プロパティを指定する場合、同時に幅を具体的な数値で明示しなければならない、とよく言われる。さもなければ幅が 0 として扱われちゃうよと。

でもその仕様は CSS 2 での話で、CSS 2.1 にそのような記述はない。そのかわり、幅を明示せずに非置換要素をフロートした場合、その幅は内容に合わせて縮む (shrink-to-fit) とされている。

If ‘margin-left’, or ‘margin-right’ are computed as ‘auto’, their used value is ‘0’.

If ‘width’ is computed as ‘auto’, the used value is the “shrink-to-fit” width.

Calculation of the shrink-to-fit width is similar to calculating the width of a table cell using the automatic table layout algorithm. Roughly: calculate the preferred width by formatting the content without breaking lines other than where explicit line breaks occur, and also calculate the preferred minimum width, e.g., by trying all possible line breaks. CSS 2.1 does not define the exact algorithm. Thirdly, find the available width: in this case, this is the width of the containing block minus the used values of ‘margin-left’, ‘border-left-width’, ‘padding-left’, ‘padding-right’, ‘border-right-width’, ‘margin-right’, and the widths of any relevant scroll bars.

Then the shrink-to-fit width is: min(max(preferred minimum width, available width), preferred width).

(Visual formatting model details: 10.3.5 Floating, non-replaced elements)

幅を指定しないということはすなわち、width プロパティに初期値である auto が指定されていることになる。通常フローのブロックレベル要素で width が auto の場合、その幅は親要素内でいっぱいまで広がるけど、フロートした要素の場合は shrink-to-fit という方法で幅が算出されることになる、と。この shrink-to-fit というのはテーブルのセルと同じような挙動で、内容に応じて可能な限り小さく縮むというもの。

この柔軟なアルゴリズムはかなり使える。例えば横に並べたナビゲーション項目を画像ではなくテキストで作りたい場合とか。でもこの shrink-to-fit アルゴリズム、あまり多く紹介されていない気がする。僕もフロートするなら幅の指定も必須、とついこないだまで考えていたし。

やはり非置換要素のフロートというとマルチカラム・レイアウトに利用されることが多いから、自然と幅を明示することになるからかな。あと、どうも古いブラウザでバグがあるらしい。

スタイルシートをめぐる冒険: floatと一緒にwidthも指定しないと回り込まない

でも少なくとも IE 6 を含むモダン・ブラウザではサポートされていて、幅が 0 と解釈されることはない。

ちなみにこの shrink-to-fit って言い回し、Levi’s の 501 からきてるのだろうか?

のっちメソッド 2: なりゆき幅で横並び

2009-06-28T00:00:00Z

以前に書いたのっちメソッド: One pixel notched corners の改良版。まずはスクリーン・ショットを。

Gmail の「ラベル」なんかでも使われている、ボックスの四隅が 1 px 欠けた疑似角丸的な表現。これを CSS のみで実現するテクニックが「のっちメソッド」なわけだが、幅が固定のボックスにしか適用できなかった。そこで上図のように内容に応じて縮む「なりゆき幅」を実現するのが今日のお題。

まずはマークアップ。それぞれのボックスはブロックかインラインかを問わず二重の要素でラップされている必要がある。例えばこんな感じ:

<ul>
  <li><a href="#">HTML/XHTML</a></li>
  <li><a href="#">CSS</a></li>
  <li><a href="#">JavaScript</a></li>
<ul>

CSS では、まず float プロパティで親要素 (この例では li) を横並びにし、上下のボーダーと左右のマージンとを設定する:

li {
  float: left;
  boder: solid #008080;
  boder-width: 1px 0;
  margin: 0 2px;
}

次に内側の要素 (この場合は a) もフロートさせ、パディングと左右のボーダーを指定。そして四隅を欠けさせるためのキモ、左右に -1px のマージンを指定して親要素からはみ出させる。なおここで position: relative も指定しないと IE 6 で意図どおりにはみ出してくれないので注意。

li a {
  float: left;
  padding: 0 0.5em;
  boder: solid #008080;
  boder-width: 0 1px;
  margin: 0 -1px;
  position: relative; /* for IE 6 */
}

以上。完成版のデモをどうぞ。タブやページ送りなどのナビゲーションなんかに使えるんじゃないだろうか。

幅を明示せずにフロートさせることで、幅がなりゆきで算出される shrink-to-fit アルゴリズムが適用されるわけだけど、今回の例ではフロートのもうひとつの特性も利用している。それは「フロートした要素はその要素タイプにかかわらずブロック・ボックスを生成する」という挙動。これ、あまり知られていないというか、そう言われてみればそうか、という挙動じゃないかな。以下は Eric Meyer の “CSS: Pocket Reference” からの引用:

A floated element will generate a block-level box no matter what kind of element it may be. Floated nonreplaced elements should be given an explicit width, as they otherwise tend to become as narrow as possible.

(Eric A. Meyer, CSS: Pocket Reference)

フロートってテクニックは CSS を習得する過程で最初につまづくとこだと思うんだけど、実は習得したのちにちゃんと振り返る機会があまりないものなのかもしれない。なにしろ習得過程で思いどおりにいかない場面にいやってほど直面してさんざん試行錯誤しているので、いったん習得した (と思えた) らもう考えたくない、ってのはありそうな話。でも以外と挙動を理解してないんだなー、と最近は感じる。まだまだ応用の余地がありそうな気がするんだよね、フロートって。

青いスウェードの靴

2009-07-07T00:00:00Z

俺の家に火をつけてもいい
俺の車を盗んでもいい
俺の酒を残らず飲んでしまってもいい

お前が何をしようと勝手だが
俺の青いスウェードの靴だけは踏むな

(カール・パーキンス「ブルー・スエード・シューズ」)

この星に生まれて良かったよ。こんなに大切なことをたったの 2 分間で教えてもらえる。

YouTube が IE6 にサヨナラ

2009-07-16T00:00:00Z

良いニュース! YouTube が IE6 のサポートをまもなく打ち切るという。現在 IE6 で同サイトを訪れると、インターネットをより楽しんでいただくためには、最新のブラウザにアップグレードしてください。 YouTube での Internet Explorer 6 のサポートはまもなく終了します。今すぐアップグレードしてください。というメッセージとともに Firefox 3.5、Google Chrome、そして IE8 のダウンロードを促すリンクが表示される。

YouTube という人気サイトがこのような決断をし、かつそのことを大きくアピールしてくれたことの意義はとても大きい。なぜならこのアピールは「ブラウザってなに?」という人たちにも有効なのだから。彼らにとって Web ブラウザは PC にあらかじめ備わるひとつの「機能」にすぎず、乗り換えるもなにも今のところインターネットが使えていれば問題はないのである (ソースはうちの妻)。だから Firefox や Chrome がいかに安全で快適なブラウザであるかを 100 万回アピールしても、「YouTube が観られなくなるよ」のひと言には勝てない。これは IE6 の死をかなり後押ししてくれるはずだ。ここでほかの人気サイトが便乗してくれることを期待してやまない。

それにしても、「IE6 のシェアが下落」とか「IE6 をサポートしない宣言」とかいう話題が出たときに必ず聞こえてくる、「でも日本ではまだダメだよね」とかいう声っていったいなんなんだろう? そんな根拠のないあきらめをどこかの誰かが語るのを聞くうちはまだいい。最悪なのはその声が自分の頭の中で聞こえたときだ。

しかし時代は変わる。今回の YouTube のメッセージは IE6 ユーザにブラウザのアップデイトを促すだけじゃない。僕たちのような Web のフロントエンドで日々もがいているディヴェロッパを勇気づけてもくれる。YouTube に (つまりは Google に) 拍手。

横並びにしたリスト項目の区切り

2009-07-20T00:00:00Z

こんなふうに、横並びにしたリスト項目の間に区切りを表示させたいときにどうするか? すべての項目に区切りを表示させてしまうと区切りがひとつ多くなってしまうので、なんらかの工夫が必要になってくるわけです。

<ul>
  <li><a href="/">Home</a></li>
  <li><a href="/archives/">Archives</a></li>
  <li><a href="/portfolio/">Portfolio</a></li>
  <li><a href="/about/">About</a></li>
</ul>

上記のようなマークアップを例に、CSS でリスト項目を float: left; または display: inline; で横に並べ、各項目の左側にボーダーまたは背景画像で区切りを配置する場合を考えてみます。

おそらくもっともスマートなのは、いったんすべての項目に区切りを指定し、:first-child 疑似クラスを使って先頭の項目だけ指定を上書き、というやり方。しかし :first-child 疑似クラスは IE6 で使えないので、:first-child に相当するクラスを手動で、または jQuery などを利用して自動で付与する、というのがありそうなアプローチです。

それでももちろんいいんですが、各項目の左マージンに区切りの幅と同じ大きさのマイナス値を指定し、親要素の overflow プロパティに hidden を指定することでも実現できます。

ul {
  position: relative;
  overflow: hidden;
  padding: 0;
  margin: 0;
  list-style: none;
}
ul li {
  float: left;
  padding: 0 0 0 4px;
  margin: 0 5px 0 -1px;
  border-left: 1px solid #808080;
}

もしリスト全体を右揃えにするなら、ul に幅を指定せず float: right; でいけます。

難点は中央揃えが難しいこと。ul を二重の div でくるんだりすればおそらくなんとかなると思いますが、そこまでいくとちょっとね。

自由

2009-08-15T00:00:00Z

自由には香りがある
生まれたての赤ん坊の頭のてっぺんのような

（ボノ「ミラクル・ドラッグ」）

要素を非表示化するスタイル

2009-08-16T00:00:00Z

HTML にはスクリプトが有効である場合は表示されない noscript 要素というのがあるけど、同様に「スタイルシートが有効の場合」や「印刷した場合」など、状況に応じて要素を非表示化するスタイルを書いてモジュール化しておくと便利。

/* スタイルシートが有効の場合は非表示 */
.nostyle { display: none; }

/* スクリーンメディアでは非表示 */
@media screen {
.noscreen { diaply: none; }
}

/* 印刷では非表示 */
@media print {
.noprint { diaply: none; }
}

<p class="nostyle">このパラグラフはスタイルシートが有効である場合には表示されません。</p>
<p class="noscreen">このパラグラフはスクリーンメディアでは表示されません。</p>
<p class="noprint">このパラグラフは印刷時には表示されません。</p>

09-09-09

2009-09-09T00:00:00Z

ついにこの日がやって来た。2009 年 9 月 9 日、水曜日。ザ・ビートルズのオリジナル・カタログが、80 年代の CD 化以来はじめてのデジタル・リマスタリングを施されて、新たに生まれ変わる。

この祝いの日に、どのアルバムが良いとか悪いとか、このバンドがいかに偉大だったかとか、そんな話はしたくない。こうして自分のブログにアートワークを並べられる、そのことだけで幸せ。

みんなで IA: CSS Nite LP, Disk 7

2009-09-15T00:00:00Z

「情報アーキテクチャ (Information Architecture)」をテーマにしたセミナー、CSS Nite LP, Disk 7: IA スペシャルに参加してきました。6 時間にも及ぶ長丁場でしたが、どのセッションもかなり濃い内容で、有意義なイヴェントだったと思います。

情報アーキテクチャとは何かを僕なりにごく乱暴に要約すると、「情報をわかりやすく伝えるための設計」といったところでしょうか。ユーザが何を求めているかを分析すること、コンテンツを把握し適切に分類すること、ナビゲーションを構造化すること…。そう、つまり、Web サイトを作る人ならだれもが考えていることだし、また考えるべきことだと言えます。

情報アーキテクチャは、扱っているものが「情報」という、ともすればどこまでも抽象的になってしまうようなものなので、とっつきにくいというか、とっかかりがつかみにくいものに感じがちです。しかし、みんながそれぞれの立場から「どうすればより伝わるのか」ということを考え、そしてそのアイディアを共有する、そういったごくシンプルなことが情報アーキテクチャの基本なのだと思います。グラフィック・デザイナーならレイアウトや色彩設計から、フロントエンド技術者ならコードから発想するでしょう。それが情報アーキテクチャの出発点です。

そして情報アーキテクチャのとくに重要にして難しい点が、「いかにして共有するか」という点だと思います。せっかくの設計もメンバー間できちんと共有されなければ意味がありません。そのためのドキュメント形式の選択も悩むところです。しかしそもそもがはっきとしたカタチのないものですから、情報アーキテクチャ作業の成果物としてのドキュメントはプロジェクトによってその姿を変えるはずです。同様に、だれがどれだけ情報アーキテクチャに携わるのかもプロジェクトごとに違ってきます。プロジェクト・マネージャーが中心になってドキュメントに落とし込むのが適切な場合もあれば、メンバー全員で議論した結果をイメージで描き起こすのが早い、という場合もあるでしょう。そうしてベストな方法を探りながら進めるしかないのではないでしょうか。

Web サイト作りに携わるすべてのひとが、それぞれのアプローチで「わかりやすさ」を考え、共有し、そしてゴールを目指す。そんな本来当たり前であるはずの仕事のあり方を本当に実現するために、情報アーキテクチャという古くて新しい手法についてしっかり考えていきたい、そう感じさせるセミナーでした。

Rubbergard Record

2009-10-04T00:00:00Z

製作のお手伝いをしていた、神田神保町のレコード・ショップ Rubbergard Record (ラバーガード・レコード) のサイトが、本日めでたく公開されました。

Rubbergard はソウル、ジャズ、ブラジル音楽、ロックなどの廃盤ヴァイナルと CD を中心に扱う、いわゆる「中古レコード屋」で、昨年の夏から営業しています。ほとんどひとりでやってる小さな店なんですが、店長みずから買い付けるアイテムのクオリティがとにかくハンパないです。いつ行っても聴いたことのないようなブツが出てくるような、音楽好きなら行って損はないと断言できる、充実の品揃えを誇ります。

ここの店長とは 15 年来の付き合いなのですが、彼ほどの音楽バカにはお目にかかったことがないです。彼の最大の強みは、お客さんの話をちょっと聞けば、今までどういう聴き方をしてきたかとか、今はどんなものを聴きたいのか、といったことを敏感に察知する能力。で、「こんなのあるけど、どう?」とさりげなくサジェスト。とはいっても「一見さんお断り」な雰囲気はまるでないので、気軽に立ち寄って音楽の話をするだけでも楽しめると思うし、ついつい長居してしまうこと請け合いの、居心地のいい店なんです。

サイトとしては、当初の予定では EC サイトとしてオープンする予定だったのですが、諸般の事情からとりあえずブログとして公開。studio-fun.net の kan さんに WordPress での構築をお願いしました。僕はいつものフロントエンド開発のみならず、久々にヴィジュアル・デザインまで担当しています。A List Apart をかなりパクってしまいましたが。ていうか縦長のロゴを配置する方法をほかに思いつかなかった。

あまつさえプロジェクト・マネージメントなんていう慣れない仕事も受け持ってしまったせいで、スケジュールがかなりグダグダになってしまいました。古くからの友人だってことで店長からはかなり大目にみてもらってますが、申し訳ない思いでいっぱいです。やっぱ餅は餅屋というか。

とにかく Rubbergard Record、良いお店なので、よろしくお願いします!

HootSuite で鉄道の運行状況を知る

2009-10-08T00:00:00Z

悪天候でダイヤが乱れた場合など、鉄道の運行状況をリアルタイムで知りたいときには、Web ベースの Twitter クライアント HootSuite が便利だ。

適当な名前で新しいタブを作る。
検索ボックスから利用する路線名で検索。
検索結果を Save as Column ボタンで保存。
利用する路線のぶんだけ 2 と 3 を繰り返す。

こうしてよく使う路線を登録しておけば、あと必要なときにそのタブを開くだけ。iPhone やモバイル版クライアントを使っている皆さんのつぶやきから、リアルタイムな運行状況を知ることができる。「山手線、運転再開の車内アナウンスなう」とか。

フロントエンド Web 開発のためのローカル・ブックマーク

2009-10-23T00:00:00Z

最近はブックマークといえばページ単位で Delicious に登録する場合がほとんどだけど、リファレンス系のサイトやオンライン・ツールなど、仕事中にちょくちょく使うものはやはりブラウザにブックマークしておくのが便利。というわけで、「フロントエンド Web 開発」とか言うとなんか大げさだけど、とにかく僕が仕事場の Firefox に保存している「そっち方面」のブックマークを、整理しつつさらしてみる。

W3C
- HTML
- CSS
  - CSS: Current Work
  - CSS 2.1
  - CSS 2
  - CSS 1
HTML
- ごく簡単な HTML の説明 (The Web KANZAKI)
- ばけらの HTML リファレンス (未完成) (bakera.jp)
- Microformats
CSS
- CSS - Contents and compatibility (QuirksMode)
JavaScript
- jQuery
  - jQuery 日本語リファレンス
タイポグラフィ
- Typetester
- Hints of fonts on the web (Academic HTML)
画像
- punypng
ブログ
- WordPress Codex 日本語版
- MovableType.jp
Web マスター
Firefox
- Add-ons for Firefox
- resource://gre/res/html.css
- resource://gre/res/forms.css
- resource://gre/res/quirk.css
- resource://gre/res/viewsource.css

ひとつだけ補足。Firefox の項の resource:// ではじまるパスを Firefox のロケーションバーに入力すると、ブラウザのデフォルト CSS を確認できる。ちょくちょく見るようなものではないけど、いわゆるリセット CSS 的なものを書くときなんかには参考になるので、ブックマークしておくと便利。

The Stone Roses: 20th Anniversary

2009-10-28T00:00:00Z

ザ・ストーン・ローゼズのファースト・アルバム“The Stone Roses”が発表されて今年で20年が経つ。これを記念して、同アルバムの新装盤がリリースされた。このアルバムはこれまでも何度かリイシューされてきたが、今回はイアン・ブラウンとプロデューサーのジョン・レッキーが直々にリマスタリング作業にあたっており、20周年の名にふさわしい決定版と言えるだろう。

新しいサウンドは全体的にボトムが強化された印象。レニとマニという強力なリズム隊を擁するバンドだっただけに、この方向性は正しい。音像をクリアにしすぎず、あくまで本来の雰囲気を損なわないよう配慮している点も評価したい。

またアルバム本編がリマスタリングされるとともに、アルバム未収録のシングル曲や初出のデモ音源などもあわせてリリースされる。しかしながら商品のエディションが複数あり、どのエディションにどのマテリアルが収録されているのかなどが少々わかりづらい。そこで本稿ではこれらのエディション、およびそこに収められたマテリアルについて検証してみたい。

エディションの比較

まず8月にリリースされた輸入盤が3エディション。さらに日本ではそれらのどれとも違う独自編集の2エディションがリリースされており、以下の計5つのエディションが存在する。

Collector’s Edition

いわゆる全部入りエディション。LPサイズの大型ボックスは90年代初頭のボックスセット・ブームを思い起こさせる。5,000セットのみの限定品。今回リリースされるすべての音源のみならず、タイトルどおりまさにコレクター向けの「おまけ」をふんだんに盛り込んでる。後述する音源や映像以外の主なコンテンツは以下のとおり。

金箔・エンボス加工、シリアル・ナンバー入りのボックス
180グラムの重量盤ヴァイナル3枚（音源としてはすべてほかのエディションでも聴けるものだが、“The Extras”のヴァイナルはこれでしか手に入らない）
48ページのブックレット
6枚のシングルのアートワーク

Legacy Edition

2 CD + DVDの計3枚組。スリップケース入りのブック型パッケージ。日本盤も『レガシー・エディション』のタイトルだが収録内容は異なるので注意。

Special Edition

オリジナル・アルバムのみの、いわゆる通常盤。ただ、ほかのエディションのアルバム本編とは違い、このエディションのみボーナス・トラック‘Fools Gold [Full Length]’を追加収録した全12曲構成。

レガシー・エディション〈リミテッド〉

日本盤の2エディションはともに『レガシー・エディション』のタイトルだが、こちらは〈リミテッド〉と銘打たれた限定盤で、CD 3枚組。「三方背スリーブケース仕様」「オリジナル・アルバム紙ジャケット復刻」などの惹句があるが、はっきり言って出来はかなりしょぼく、ただの紙製パッケージの域を出るものではない。しかしそこはどうでもよくて、重要なのは内容が上記の輸入盤3エディションのどれとも違う日本独自編集である点。今回リリースされる音源のほぼすべてを網羅している。

レガシー・エディション

日本における通常仕様盤で、CD 2枚組。〈リミテッド〉同様に日本独自編集で、同エディションから“The Lost Demos”をオミットした構成。

各エディションに収められたマテリアルをまとめると以下のとおり。

	Collector’s Edition	Legacy Edition	Special Edition	レガシー・エディション〈リミテッド〉	レガシー・エディション
The Stone Roses	✔	✔	✔	✔	✔
The Extras	✔			✔	✔
The Lost Demos	✔	✔		✔
DVD	✔	✔
Lemon USB	✔

マテリアルの詳細

ではディスクごとに各マテリアルを検証していこう。なお、筆者は『レガシー・エディション〈リミテッド〉』しか入手していないため、そこに含まれないDVDやUSBについての情報はウェブで収集したものであることをお断りしておく。

The Stone Roses

デジタル・リマスターされたアルバムの本編。今までこのアルバムには収録曲の違ういくつかのヴァージョンが存在するが、ここではUKオリジナル・リリースに準じている（“Special Edition”のみボーナス・トラックとして‘Fools Gold’を収録）。

I Wanna Be Adored
She Bangs the Drums
Waterfall
Don’t Stop
Bye Bye Badman
Elizabeth My Dear
(Song for My) Sugar Spun Sister
Made of Stone
Shoot You Down
This Is the One
I Am the Resurrection

The Extras

シングルのみに収録された曲をデジタル・リマスターを施して収めたディスク。彼らの場合、‘Fools Gold’、‘What the World Is Waiting For’、そして‘One Love’などの重要な曲がアルバム未収録であることや、シングルB面にも聴き逃せない佳曲が多いことから、これらをコンパイルするのみならず、きっちりリマスターしたことの意義は大きい。

Elephant Stone [12″ Version]
Full Fathom Five
The Hardest Thing
Going Down
Guernica
Mersey Paradise
Standing Here
Simone
Fools Gold [Full Length]
What the World Is Waiting For
One Love [Full Length]
Something’s Burning [Full Length]
Where Angels Play

7″と12″など複数のヴァージョンが存在する曲の場合、すべてフル・レングスの12″ヴァージョンを採用（ヴァージョン違いについての詳細は後述）。‘Full Fathom Five’は“Elephnt Stone”の12″ヴァイナルに収録されていたヴァージョンで、今回が初めてのCD化。なお以下の楽曲は今回のリマスターにあたってわずかに手が加えられている。

Standing Here
: イントロのギターの最初の部分がほんの一瞬だけ拡張された。
Where Angels Play: イントロにハイハットのカウントが追加された。蛇足としか思えない、意図不明の改変。

The Lost Demos

デモ音源集。売りである未発表曲‘Pearl Bastard’は、悪い曲ではないが、かなり地味。‘Going Down’路線というか、ゆったりしたテンポでいかにもシングルB面的な雰囲気。ほかの曲も、完成版とアレンジが大幅に異なるなどといったことはなく、いまいち聴きどころにとぼしい。つまりアルバムのレコーディングに入る時点で楽曲やアレンジがかなり練られていたということになるわけだが。

I Wanna Be Adored
She Bangs the Drums
Waterfall
Bye Bye Badman
(Song for My) Sugar Spun Sister
Shoot You Down
This Is the One
I Am the Resurrection
Elephant Stone
Going Down
Mersey Paradise
Where Angels Play
Something’s Burning
One Love
Pearl Bastard

DVD

1989年のBlackpoolにおけるギグと、6本のプロモ・ヴィデオを収録。内容は『ザ・ストーン・ローゼズDVD』のディスク1と同様と思われる。

Lemon USB

“Collecor’s Edition”にのみ付属の、レモン型USBメモリ。今回リリースされた全音源とプロモ・ヴィデオ6本に加え、ここでしか手に入らない以下のマテリアルを収録。

未発表の「逆回転」トラック5曲
‘Fools Gold’レコーディング時に撮影されたホーム・ヴィデオ映像
ケータイ着信音
デスクトップ壁紙
48ページのデジタル・ブックレット

上記のうち、「逆回転」は英国のiTunes Storeで販売されているシングル5種に分散されて収録のものと同一と思われる。

また「ホーム・ヴィデオ」は以下で観られるものと同一とのこと。

The Stone Roses during the recording of Fools Gold | Music | guardian.co.uk

どのエディションを買うべきか？

結論から言うと、日本盤『レガシー・エディション』の通常盤（CD 2枚組）をすすめる。

『レガシー・エディション〈リミテッド〉』は、“The Lost Demos”を含む点と紙ジャケである点がアドヴァンテージだが、デモ音源は地味、紙ジャケは出来がしょぼいことから、あまりおすすめはできない。最大のポイントは未発表曲の‘Pearl Bastard’を含む点なので、この曲が欲しいかどうかが決め手になるだろう。

今回リリースされるすべてのマテリアルを手に入れようとするなら“Collecor’s Edition”一択になってしまうが、同エディションでしか聴けない音源は、「楽曲」とは呼び難い5曲の「逆回転」トラックのみ。あとは「モノ」としての価値に重きを置くかどうかだろう。

アルバム本編にデモ音源とDVDを加えた輸入盤の“Legcy Edition”はもっとも中途半端な内容と言わざるを得ない。デモ音源の出来は前述のとおり、映像もほかのソースから入手可能であることから却下。

シンプルにアルバムのみの“Special Edition”という手もあるが、‘Elephant Stone’、‘What the World Is Waiting For’、‘One Love’などの代表曲が聴けないのはありえないのでやはり却下。

というわけで、日本盤『レガシー・エディション』の通常盤こそもっとも賢い選択と断言する。この日本独自仕様を採用したSony Music Japanの英断はおおいに評価されていい。また、もし「音源」をひととおり揃えたいなら『レガシー・エディション〈リミテッド〉』、余程の思い入れと予算と収納スペースがあるならば記念品として“Collecor’s Edition”、といったところだろう。

オルタネイト・ヴァージョン

このほか、今回リリースされたどのエディションにも収録されていないヴァージョンもいくつかあるので整理してみる。以下に挙げたほかにもリミクスなど別ヴァージョンが数多く存在するが、バンドがSilvertone Recordsを離れた1991年春以降にリリースされたもののほとんどは、メンバーが関与していないものと見なし、一部の例外を除いてここでは取り上げない。

Elephant Stone [7″ Version]: 今回“The Extra”に収録されている同曲は12″ヴァージョン。この7″ヴァージョンはイントロがドラム・ソロではなく歪んだギターのフレーズから始まるなど、全体的にリズム・トラックより上モノを前面にフィーチャーしたギター・バンドっぽい出来。“The Complete Stone Roses”のほか、かつてアルバムの米国盤や再発盤にも収録されていたので入手は容易。
Full Fathom Five: 前述のとおり、この曲はCDと12″ヴァイナルでヴァージョンが異なる。CDヴァージョンは現在“The Complete Stone Roses”に収録。
She Bangs the Drums [Single Version]: アルバムからのシングル・カット。イントロのハイハットがカットされているほか、とくにコーラスでのバッキング・ヴォーカルやギターのミックスがアルバム・ヴァージョンと異なる。かつては日本独自企画盤『ホワット・ザ・ワールド・イズ・ウェイティング・フォー』にも収録されていたが、現在は“The Complete Stone Roses”で入手可能。
Fools Gold [7″ Version]: シングル“Fools Gold/What the Worid Is Waiting For”に収録の、イントロとアウトロをエディットした短縮版。“The Complete Stone Roses”と、今回の20th Anniversaryに合わせてリリースされたシングルCD“Fools Gold”で聴くことができる。
One Love [7″ Version]: 同曲の英国盤7″ヴァイナルと、日本および米国盤シングルCDに収録された短縮版。現在は“The Complete Stone Roses”と“The Very Best of The Stone Roses”で入手可能。
Something’s Burning [7″ Version]: “One Love”の7″ヴァイナルに収録の短縮版。CDでは“The Complete Stone Roses”にのみ収録。
Sally Cinnamon [Live at the Hacienda]: シングル“I Wanna Be Adored”に収録のライヴ・ヴァージョン。バンドがすでにレーベルを移籍している1991年9月のリリースであるため、おそらく本作を世に出すことについてメンバーは関与していなかったと思われる。今回の20周年盤をはじめどのコンピレーションにも収録されておらず、シングルCDか12″ヴァイナルでしか聴くことができない。

このとおり、今回の 20 周年リリースで手に入らない音源のほとんどは“The Complete Stone Roses”で聴くことができるが、唯一の例外が‘Sally Cinnamon’のライヴ・ヴァージョン。しかし困ったことに、このヴァージョンの内容がじつに素晴らしいのだ。

最初のヴァースはジョン・スクワイアのギターとマニのベースを中心に王道ギター・バンド然とした展開を見せるものの、イアン・ブラウンの神懸かり的にド下手なヴォーカルによってすべてがバラバラと崩れ落ちそうになる。しかしなんとか最初のコーラスにたどり着いたあと、怒濤の如くセカンド・ヴァースに突入してからは、レニのカミナリのようなドラムがすべてを支配するバンドの必勝パターン。ヴォーカルは曲が進むにつれ調子を取り戻すどころかもはや修復不可能な域に達するが、しかし音程がはずれればはずれるほど歓喜の涙があふれそうになるというこのマジック！

……という、「これを聴いて何も感じない人とは友達になれません」クラスのものなので、なんとか探して聴いてみてください。

Movable Type から WordPress へ

2009-11-15T00:00:00Z

このサイトのパブリッシング・プラットフォームを Movable Type から WordPress へ変更した。以下、いくつか覚え書きを。

パーマリンクの移行

すでにある記事のパーマリンクをそのまま持ってくる方法はいくつかあるようだけど、以下で紹介されている「MT で WP 形式のデータを書き出す」という方法を採用。下書きの記事は消えちゃうけど、パーマリンクのほかコメントとタグはすべてそのままスムーズにいけた。

Movable Type から WordPress に固定リンク込みで完璧に移行する方法 - ネットスクランダー

プラグイン

プラグインは、デフォルトで入ってたものやよく紹介されてる定番らしきもののほか、いくつか探してインストールした。

Disable WPAUTOP: 編集画面で改行時に p 要素のタグが自動的に挿入される機能を無効化。旧サイトから持ってきたデータがおかしなマークアップに修正されていたので。
EnglishDate: 投稿日時を英語表記にするプラグイン。はじめは、/wp-content/languages にある ja.po ファイルを Poedit で編集して、生成される ja.mo をサーバにアップロード、ってことをやってたんだけど、このやり方だとアップデートのときにもとに戻ってしまうので、プラグインで対応することに。
XTH: デフォルトでは XHTML 1.0 で出力されるコードを、妥当な HTML 4.01 に変換してくれるプラグイン。

リデザイン

ついでと言ってはなんだけど、一部をリデザインしてみた。まずコメント投稿フォーム。

フォームのコントロール類は、デフォルトのスタイルからあまりにかけ離れるとフォームとして認識してもらえない可能性があるので、どこまでいじるべきか難しいところ。そこをあえて大胆な見せ方をしてみようかと思い、いろいろデザイン案を作ってたんだけど、結局は思い直してかなり無難にまとめた。「フォームらしさ」の演出になればいいなという期待を込めて、入力フィールドとボタンに border-radius を軽く適用。Firefox と Safari と Chrome ではうっすらと角丸になっているはず。ちなみに以下のように属性セレクタや疑似クラスなどを遠慮なく使っているため、IE6 ではプレーンなスタイルのまま。

input[type="text"],
textarea {
  border: 2px solid silver;
  border-radius: 2px;
  -moz-border-radius: 2px;
  -webkit-border-radius: 2px;
}
input[type="text"]:hover,
textarea:hover {
  border-color: gray;
}
input[type="text"]:focus,
textarea:focus {
  border-color: #0080ff;
}

input[type="submit"] {
  border: 0;
  border-radius: 2px;
  -moz-border-radius: 2px;
  -webkit-border-radius: 2px;
  background: gray;
  color: white;
}
input[type="submit"]:hover {
  background: black;
}
input[type="submit"]:active {
  background: #0080ff;
}

もうひとつはページ下部に並べた、フィードとソーシャル系 Web サービスへのリンク。

はじめはプレーンなリストに Favicon を表示するようなのを考えてたんだけど、ちょっとひねってこんな感じにしてみた。各サイトのロゴやなんかから拾ったキー・カラーを背景色に指定してるわけだけど、これだけでそれぞれのサイトの雰囲気が感じられるのが面白くて、けっこう気に入ってる。CSS では属性セレクタを使って、リンク先のドメインを前方一致で指定。とは言え自分のサイトなので、アカウント ID まで含む完全な URI を書いちゃってもいいんだけど。例によって IE6 では無効なので、デフォルトの背景色も忘れずに。

#elsewhere a {
  background: #0080ff;
  color: white;
}
#elsewhere a[href^="http://twitter.com/"] {
  background: #33ccff;
}
#elsewhere a[href^="http://delicious.com/"] {
  background: #3274d0;
}
#elsewhere a[href^="http://www.last.fm/"] {
  background: #d51007;
}
#elsewhere a[href^="http://mixi.jp/"] {
  background: #ff9900;
}
#elsewhere a:hover {
  background: black;
}

ちょっと前だと、こういった属性セレクタを利用したスタイルを IE6 でも実現すべく jQuery のプラグインを書いたりしてたけど、もうぼちぼちその手のアプローチは必要ないかなと感じるようになってきた。

Menlo と Mac の等幅フォント

2009-11-23T00:00:00Z

2010-05-17 更新: Opera 10.5 ではイタリックとボールドともに有効ですが、ボールドの太り方がやや弱いようです。
2009-12-21 更新: Firefox でイタリックまたはボールドを指定すると Menlo でレンダリングされない問題は修正されています。Opera ではイタリックとボールドは無効ですが、Menlo のレギュラーでレンダリングされるようになっています。

Mac の Snow Leopard には新しい等幅 (固定幅) フォント Menlo がインストールされている。なかなか美しいのでさっそく CSS で使ってみようと思ったんだけど、どうも挙動がおかしいので検証してみた。

まずはじめに以下の CSS を試してみる:

code {
  font-family: "Menlo", "Courier", monospace;
}

そのレンダリング結果はこのとおり:

Safari 4.0

Firefox 3.5

Opera 10

意図どおりレンダリングされたのは Safari だけだった。Firefox ではレギュラーのみ Menlo で、イタリックまたはボールドでは第 2 候補の Courier が適用されている。Opera では第 2 候補どころかブラウザのデフォルトになってしまう (この場合はヒラギノ。イタリックになっていないのはヒラギノがイタリックを持っていないためと思われる) 。

そこで以下のように @font-face ルールをからめると、Firefox でもボールドとイタリックで表示させることができる:

@font-face {
  font-family: "Menlo";
  src: local("Menlo Regular");
}
code {
  font-family: "Menlo", "Courier", monospace;
}

Firefox 3.5

しかしこの場合、Safri と比べると微妙に字形が異なる。これはおそらく、用意されている「本当の」イタリックやボールドではなく、@font-face で指定している Menlo Regular をブラウザのレンダリングで擬似的にボールドやイタリックに見せているのだと思われる。そのためレギュラーとボールドで字幅が異なり、「等幅」とは呼び難いものになってしまう。

しかも Opera ではやはり無効。@font-face の記述をいろいろと試してみたけど、どうやら Menlo というキーワードが出たとたんに挙動がおかしくなるらしい、ってとこまでしかわからなかった。ていうか @font-face ってほとんど初めて書いたので自信なし。

というわけで、そもそも等幅でレンダリングされないというのは無視できないので、少なくとも今のところ CSS で Menlo を指定するのは危険だ。Photoshop で使うとエラーが発生したり、Keynote でおかしな表示になったりと、まだ未完成な製品ということなのだろうか。なかなかかっこいいフォントだと思うのでぜひ使いたいのだけど。

ちなみに、同じく Mac OS X の等幅フォントである Monaco でも「ボールドとイタリックが用意されていない問題」が発生する。Safari と Firefox ではブラウザが擬似的にレンダリングするため字幅がおかしくなり、Opera ではすべてレギュラーにしかならない:

Safari 4.0

Firefox 3.5

Opera 10

結論: Mac OS X 向けの等幅フォントを CSS で指定するなら ~~Courier~~ Courier New が無難。

Courier、Courier New、Consolas

2009-11-30T00:00:00Z

前回の記事では CSS で Mac 向けに等幅フォントを指定する際の注意点を取り上げ、Menlo と Monaco はあまりおすすめできない、Courier が無難、と結論づけた。しかしそこでは Courier とその改訂版である Courier New について検証していなかったし、それに Windows 環境をまるで考慮していなかった。そこで今回は前回の補足として、CSS で等幅フォントを指定するベターな方法をさらにしつこく探ってみたい。

ではまず Courier と Courier New の Mac でのレンダリングを確認してみる。少なくとも v10.3 (Panther) 以降の Mac OS X にはどちらのフォントもあらかじめインストールされている。以下は Mac OS X v10.6 (Snow Leopard) + Safri 4.0 でのスクリーンショット:

Courier (Mac)

Courier New (Mac)

ともにレギュラー、イタリック、ボールド、ボールド・イタリックの 4 書体が用意されており、レンダリングに問題は見受けられない。では Windows ではどうだろうか。以下は Windows XP SP3 + IE8 でのスクリーンショット:

Courier (Windows)

Courier New (Windows)

Courier のレンダリングが Mac と大きく異なる。イタリックは極端に傾きすぎで判読しづらいうえ、とくに IE8 では一部の文字が完全につぶれてしまうし、ボールドはレギュラーと字幅が異なる (「等幅」ではなくなってしまう)。レギュラーのみを使うのでなければ、実用に堪えるものではないと思う。

というわけで、前回の検証結果「Menlo は Firefox と Opera で正しく認識されない」と「Monaco はイタリックとボールドが用意されていない」、そして今回の「Courier のイタリックとボールドは Windows で使えない」をあわせて考えると、CSS で等幅フォントを指定する際にもっとも「安全」なのは Courier New、ということになる。なんか面白味のない結論で申し訳ないけど。

code {
  font-family: "Courier New", monospace;
}

なお、もし Mac と Windows での見栄えの違いにさほどこだわらないのであれば、Windows 向けに Consolas を指定するのもおすすめ。

Consolas

Consolas は Windows Vista や Office 2007 などに同梱されるフォントだが、無償の PowerPoint Viewer 2007 をインストールすることでも入手できる。イタリックの特徴的な字形 (i、j、k、l など) は好みの分かれるところかもしれないが、個人的にはかなり美しいと思う。とくに Courier 系に比べて横幅がスリムである点に注目してほしい。ソースコードなど、なるべく折り返さず 1 行に収めたい場合にうれしい。とはいえ Vista 以前の Windows の多くにはインストールされていないので、第 1 候補が Conslas、なければ Courier New、という指定が望ましい:

code {
  font-family: "Consolas", "Courier New", monospace;
}

このほかに Windows でインストール率の高い等幅フォントとして Lucida Console があるが、Monaco などと同様にイタリックとボールドを持たないため、あまりおすすめしない。

Luciad Console

CSS のみで吹き出し

2009-12-06T00:00:00Z

hail2u.net - Weblog - Pure CSS な吹き出しに触発されて、画像や JavaScript を使わずに CSS だけを使って「吹き出し」を作る方法を僕も考えてみた。

Demo: CSS のみで吹き出し

マークアップは 2 重の要素があれば OK。ここではそれぞれ bubble と body というクラスを付与した div と p を例に説明する:

<div class="bubble">
  <p class="body">Speech!</p>
</div>

CSS の最低限必要な部分のみを抜き出すと以下のとおり。これは背景が黒いボックスの下に左向きのしっぽを出す場合の例:

.bubble {
  float: left; /* または position: absolute; */
  border-left: 10px solid black;
  border-bottom: 10px solid transparent;
  -border-bottom-color: white; /* for IE6 */
}
.bubble .body {
  float: left; /* または width を明示 */
  margin-left: -20px;
  background: black;
  color: white;
  -position: relative; /* for IE6 */
}

外側の .bubble は吹き出しの「しっぽ」部分を担当する。「ボディ」の幅は内側の要素によって決定するので、ここでは width を指定せず、position: absolute; を指定するか、左右どちらかにフロートさせる。しっぽ部分は隣接する 2 辺のボーダーの組み合わせによって作られる。このテクニックはいろんなサイトで紹介されているので詳細は省略。ただ、IE6 は border-color プロパティの値として transparent が無効なので、吹き出しがテキストや画像に重なる可能性がある場合は難しい。背景が単色なら上記のように背景色を明示してしまえばいける。

内側の .body は吹き出しのボディ部分。幅を固定する場合は width プロパティに値を明示し、またもしこの要素がインライン要素なら display: block; でブロック要素化する。テキストの量による可変幅にするなら左右どちらかにフロート。ここまでだとしっぽがボディの外側にある状態なので、マージンにマイナス値を指定して外側の要素の外側にはみ出させることにより、しっぽをボディの内側まで移動させる。

あとは、.bubble のボーダーの太さでしっぽの大きさを調整したり、.body に border-radius を指定したりして装飾する。ちなみに IE ではしっぽの角度を 45° に (つまり .bubble の 2 辺のボーダーの太さを同じに) しないと斜めのラインが汚くなるようなので注意。デモにはいくつかのパターンを用意したのでご参考にされたし。

さっそくこのサイトでもブログ記事のコメント数を表示するのに採用してみたけど、「0」ばかりで軽く落ち込んだ。

Yet Another Related Posts Plugin

2009-12-15T00:00:00Z

WordPress で関連記事をリストアップするプラグイン、Yet Another Related Posts Plugin (YARPP) を導入してみた。同様のプラグインは多数あるけど、出力結果をテンプレートで柔軟にコントロールできるところが気に入って選んだ。Google のエンジニアのお墨付きってのも魅力。

出力結果をカスタマイズするには、まずテンプレートを用意する必要がある。プラグインの yarpp-templates フォルダの中に yarpp-template-example.php というファイルがあるので、これを使用中のテーマのディレクトリにコピーし、適当な名前に変更した上で編集する。テンプレートの中身は yarpp-template-example.php を参考にすればごく簡単。ちなみにファイル名は yarpp-template- ではじまっていないと YARPP のテンプレートと認識されないので注意。

こうして用意したテンプレートをテーマのディレクトリにアップロードしたら YARPP 管理画面へ。「表示設定 (ウェブサイト用)」セクションにある「テンプレートを使って表示」にチェックを入れ、自作のテンプレートを選択する。ちなみにリストの挿入箇所をカスタマイズするには、管理画面で「自動的に関連記事を表示する」のチェックをはずし、テンプレートの任意の箇所に <?php related_posts() ?> を記述すればいい。

あとはフィルターや関連スコアの設定をいじって出力結果を調整。この部分はしばらく運用してみないと勘がつかめないな。

Lamy safari

2009-12-20T00:00:00Z

はじめて万年筆を買った。Lamy safari のイエロー、ニブは EF。カートリッジではなくコンバータを使うことにして、インクはブルーブラックを選んだ。お店は高田馬場の竹宝商会。

コンバータにインクを吸い上げるとき、インク壺にペンをどこまで突っ込んでよいのかわからず何度か空振りしてしまった。どうもペン軸までどっぷりつけるものらしい。

書き味やなんかについては、なにせはじめての万年筆なのでほかと比べてどうこうとは言えないのだけど、とりあえず今まで使ってきた 3 色ボールペンとは当然のことながらまるで違い、「ペンの先から紙にインクを流し込んでいる」ような感覚がとても新鮮。力の入れ具合で微妙な色ムラができるところや、乾くと色合いが落ち着いて「インクが紙に定着した」感じになるところも楽しい。

俺の CSS リセット: 2009 冬

2009-12-26T00:00:00Z

各ブラウザが持つデフォルトのスタイルをいったんリセットし、のちのスタイル指定を容易にするための「CSS リセット」。どこまでリセットするかは難しいところで、俺も常に試行錯誤を続けていますが、この頃はだいたいこんなふうにしてます:

html, body, div, h1, h2, h3, h4, h5, h6,
p, ul, ol, li, dl, dt, dd, address, hr,
pre, blockquote, ins, del, form, fieldset, legend,
table, caption, thead, tfoot, tbody, tr, th, td {
  padding: 0;
  margin: 0;
}
h1, h2, h3, h4, h5, h6 {
  font-size: 1em;
}
ul p, ol p, dl p, table p,
ul ul, ol ul, dl ul, table ul,
ul ol, ol ol, dl ol, table ol,
ul dl, ol dl, dl dl, table dl,
ul pre, ol pre, dl pre, table pre,
ul table, ol table, dl table, table table {
  font-size: 1em;
  margin: 0;
}
pre {
  white-space: pre-wrap;
  word-wrap: break-word;
}
img, object {
  border: 0;
  vertical-align: bottom;
}
sub {
  line-height: 1;
  vertical-align: text-bottom;
}
sup {
  line-height: 1;
  vertical-align: text-top;
}
q:before, q:after {
  content: "";
}
fieldset {
  border: 0;
}
input, button, select, optgroup, option, textarea {
  background: inherit;
  color: inherit;
  font-family: inherit;
  font-style: inherit;
  font-variant: normal;
  font-weight: inherit;
  font-size: 1em;
  letter-spacing: normal;
  word-spacing: normal;
  text-transform: none;
}

簡単に説明すると、主に以下のようなことをやっています:

ブロックレベル要素の padding と margin をリセット
見出しの font-size をリセット
テキスト系の要素が入れ子になった場合の font-size と margin をリセット
pre 要素の長いテキストを折り返す指定
sub 要素と sup 要素の水平位置はブラウザ間の差異が大きいので調整
フォームのコントロールにおけるタイポグラフィの継承を調整

とくにフォーム関連はどこまでいじるか悩むところですが、コントロールにおけるタイポグラフィの継承に重点を置いています。background プロパティを指定しているのは、これがないと Safari と Chrome で input 要素の submit/reset/button タイプや select 要素のタイポグラフィが継承されないため。ちょっと記述がウザいかなとは思うんですが、個人的にいつもつまずくとこなのであえてこうしてます。

br 要素の letter-spacing プロパティとか legend 要素の color プロパティといった、かつてはよく加えていた IE6 向けの指定をなるべくけずるようにしているので、以前に比べてだいぶすっきりしてきました。

Best of 2009: 音楽

2009-12-31T00:00:00Z

我ながらびっくりするほど新譜を聴かない 1 年だった。その隠居っぷりは昨年の比ではない。そこで仕方なく、Best of というよりも、新旧問わず「今年よく聴いたものチャート」を作ってみた。そしてこのチャートがまたびっくりするほどつまらないものになってしまった。ソースは Last.fm で、過去 12 か月の再生回数を元にしている。

アーティスト

時系列でいうと、U2 → 清志郎 → マイケル → ビートルズ。時の流れに身をまかせ。レディオヘッドやストーン・ローゼズはリイシューが出たため。ブルハとピーズは、まあそういう気分だったってことでしょう。再生回数でいうと、ビートルズが 3,000 回以上でダントツ、U2 が 800 回、以下 400 から 200 回、みたいな感じ。とにかく 9 月以降はビートルズしか聴いてない。

アルバム

The Beatles - Mono Masters (The Beatles in Mono)
The Beatles - The Beatles
U2 - No Line on the Horizon
The Beatles - Revolver
The Beatles - Please Please Me
RC Succession - Baby a Go Go
The Beatles - A Hard Day’s Night
The Beatles - With the Beatles
The Beatles - Sgt. Pepper’s Lonely Hearts Club Band
The Beatles - Magical Mystery Tour

トラックの再生回数で集計しているため、単純にトラック数の多いビートルズの 2 枚組が上位に。1 位の『モノ・マスターズ』は『パスト・マスターズ』のモノラル版で、バラ売りはされておらずボックス・セットにのみ収録。とにかくこのボックスをひたすら聴いてた。とくに好きなのは『ホワイト・アルバム』のディスク 1。3 位の U2 は実はあんまり好きじゃない。『ポップ』以来の失敗作、は言い過ぎだけど、ここ 2 作の充実度がハンパなかっただけに、まあディスコグラフィ的にここらでこういうのがあってもいいか、というのが僕の評価です。それよか YouTube でやったギグの生中継のが印象に残る。ちなみに Baby a Go Go は RC の最高傑作ですので。念のため。リンク先は Amazon。

トラック

U2 - I’ll Go Crazy If I Don’t Go Crazy Tonight
U2 - Get on Your Boots
U2 - Magnificent
The Beatles - I Saw Her Standing There
The Beatles - Love Me Do
The Beatles - Please Please Me
The Beatles - Twist and Shout
The Beatles - We Can’t Work It Out
The Beatles - All I’ve Got to Do
The Beatles - It Won’t Be Long

U2 の I’ll Go Crazy はアルバム中もっとも U2 らしい、いわば保守的な曲。ビートルズに初期の曲が多いのは、いきなり全作品を聴かず、リリース順に自分をじらしつつ 1 枚ずつ聴くという縛りプレイをしていたため。でも『サージェント・ペパー』あたりでどうでもよくなり、結局はぐちゃっと一気に聴いた。

来年の抱負

年明け早々に、LCD Soundsystem とか Spoon とか Vampire Weekend とか、気になる新譜が出るのでちゃんと追いかけたいです。ていうかちゃんと働きます。

Font Squirrel で始める @font-face

2009-12-31T00:00:00Z

書式が複雑、IE 向けの EOF ファイルを用意するのが面倒、ライセンスが英語でわからん、などの理由から CSS の @font-face にとっつきにくさを感じている人は少なくないと思います。そのあたりのハードルをかなり下げてくれそうなサイトが、Font Squirrel です。

「商用利用可能で高品位なフォントが無料で!」というようなよくあるサイトのように見えますが、違います。このサイトの最大の特長は @font-face を強力にサポート してくれるところにあります。

このサイトを利用して @font-face を導入するには、ファイル一式がすでに用意されている @font-face Kits をダウンロードする方法と、@font-face Generator でファイルを生成する方法があります。前者のほうがより簡単ですが、どちらの方法でも @font-face のわずらわしさをかなり軽減してくれることは間違いありません。それぞれの利用方法について説明していきます。

@font-face Kits

まず最初に、サイトの@font-face Kits ページへ移動します。かなりの数のフォントが並んでいますが、この中から利用したいフォントを選びます。

お目当てのフォントが見つかったら、サムネイルをクリックして、フォントの詳細ページへ移動します。ここでは The League of Movable Type の League Gothic を例に話を進めます。

データをダウンロードするには、右上に見えている Download OTF というボタンはではなく、その下の @font-face Kit というリンクをクリックします。すると Download @font-face Kit というボタンが出現するので、ZIP 形式の「キット」をダウンロードします。またこのページでは、実際にタイプしたテキストでテストしたり、ライセンスを確認したりもできます。

ダウンロードした ZIP を解凍すると、以下のファイルが含まれています (League Gothic の場合):

League_Gothic.eot
League_Gothic.otf
League_Gothic.svg
League_Gothic.woff
demo.html
stylesheet.css
SIL Open Font License 1.1.txt

このうち、まずは 4 つのフォントファイルをサイトのしかるべきディレクトリに置きます。

最後に CSS の編集です。stylesheet.css には以下のように @font-face があらかじめ記述されています (読みやすいよう改行しています):

@font-face {
  font-family:
    'LeagueGothicRegular';
  src:
    url('League_Gothic.eot');
  src:
    local('League Gothic Regular'),
    local('LeagueGothic'),
    url('League_Gothic.woff') format('woff'),
    url('League_Gothic.otf') format('opentype'),
    url('League_Gothic.svg#LeagueGothic') format('svg');
}

この部分をまるごと任意の CSS ファイルにコピーし、src プロパティの url 値をフォントファイルまでのパスに書き換えます。また、フォントによっては CSS や HTML ファイルにクレジットの記載が必要な場合があるので注意してください。

ちなみにこの @font-face の書式は Paul Irish 氏のBulletproof @font-face syntax に基づいており、CSS ファイルにもその旨がクレジットされています。書式についての詳細はリンク先を参照してください。

以上で準備は完了です。これで @font-face で定義したフォントをいつでも指定できます。実際に動作しているデモを用意したので試してみてください:

Demo #1: League Gothic

なお、この @font-face Kit パッケージで配布されているフォントはすべて @font-face での利用が可能であるはずですが、ライセンスにはひととおり目を通しましょう。ライセンスは各フォントのページから参照できます。

@font-face Generator

このサイトのもうひとつの売りは @font-face Generator です。上記 @font-face Kit パッケージが用意されていないフォントでも、この機能を使えば簡単に「キット」を作成することができます。

まずはフォントを選びましょう。ここでは exljbris Font Foundry の Museo Sans を例に解説します。

このフォントは @font-face Kit が用意されておらず、ダウンロードできるのは OTF フォーマットのみです。では @font-face での利用はできないのかというとそうではなく、ライセンスを読むとこのように記載されています:

You may use this font for Font-Face embedding, but only if you put a link to http://www.exljbris.nl on your page and/or put this notice /* A font by Jos Buivenga (exljbris) -> http://www.exljbris.nl */ in your CSS file as near as possible to the piece of code that declares the Font-Face embedding of this font.

つまり、ページまたは CSS ファイルにクレジットを記載すれば @font-face で利用して構いませんよ、ということです。しかし IE での表示に必要な EOF フォーマットは用意されていないので、この @font-face Generator で生成する必要があります。@fonta-face Kit を利用するのに比べて手間はかかりますが、それでもとても簡単です。

まずは OTF フォントをダウンロードします。ページ右上の Download OTF ボタンをクリックすると、外部サイトである MyFonts に移動します。

この Museo Sans ファミリーのうち、価格が $0 の Museo Sans 500 と Museo Sans 500 Italic をカートに入れ、$0 で購入します。なおこの際ユーザ登録が必要です。お会計が終わったら ZIP 形式でデータをダウンロードします。

ダウンロードが完了したら再び Font Squirrel に戻り、@font-face Generator ページへ。

Add Fonts ボタンをクリックし、さきほどダウンロードした OTF ファイルをアップロードします。Museo Sans はレギュラーとイタリックの 2 書体ですが、同時に処理することが可能です。

次にフォームの Agreement 欄、Yes, the fonts I'm uploading are legally eligible for web embedding. にチェックを入れます。これはつまり、「私がアップロードしているフォントは @font-face での利用が許されています」という宣言です。しつこいようですがライセンスを必ず確認しましょう。ここにチェックを入れない限りデータはダウンロードできません。

そのほかいくつかオプションのチェック項目がありますが、正直に言ってよくわからない項目が多いです。とりあえずデフォルトのままダウンロードしてみて、テストの結果が思ったとおりにならなかった場合にやり直す、というのでもいいのではないでしょうか (いい加減で申し訳ないです…)。

最後に「キット」をダウンロードします。あとは @font-face Kit の場合と同様ですが、CSS ファイルにクレジットを入れるのを忘れないように。

Demo #2: Museo Sans

いまのところ和文での利用は難しいですが、欧文のみに限られる部分、たとえばナビゲーションとか見出しとか日付とかにはビシビシ使ってみてよいのではないでしょうか。とくにブログのテーマなんかを作る場合、テーマのディレクトリ内にフォントも同梱しておけば、かなりデザインの幅が広がります。

とは言え実際に @font-face を使ってみて思ったのは、選択肢が一気に増えすぎるせいで、いともたやすくまとまりのないデザインになってしまうんですね。今までの「Arial か Verdana か Georgia ぐらいしか使えねー」っていう束縛が、逆に統一感を約束してくれてもいたのかなー、と思った次第です。

Happy New Year 2010

2010-01-01T00:00:00Z

Happy New Year 2010

リデザイン!

2010-02-02T00:00:00Z

約 1 年半ぶりにサイトをリデザインした。細かいところはまだいろいろといじると思うけど、とりあえずおもな変更点をまとめておきたい。

Before: Vesion 2.1

After: Version 3.0

レイアウト

ページ全体は 768px の固定幅、左寄せ。本文部分の左側 4 分の 1 を余白にして、画像やソースコードなどをはみ出させるレイアウトを試しに採用。Jason Santa Maria や maratz.com あたりをパクってる。

タイポグラフィ

リデザインしたかった最大の理由が、ヘッダ。以前は Helvetica/Arial をかなり大きめに配置してたけど、さすがに邪魔に感じてきて、スッキリさせたかった。そこで、ロゴとグローバル・ナビゲーション、および見出しの一部に @font-face で The League of Movable Type の League Gothic を採用。フォントファイル一式は、以前このブログでも紹介した Font Squirrel から入手した。ちなみに CSS はこんな感じ:

@font-face {
  font-family:
    "League Gothic";
  src:
    url("/fonts/League_Gothic.eot");
  src:
    local("League Gothic Regular"),
    local("LeagueGothic"),
    url("/fonts/League_Gothic.woff") format("woff"),
    url("/fonts/League_Gothic.otf") format("opentype"),
    url("/fonts/League_Gothic.svg#LeagueGothic") format("svg");
}

.page-header .logo,
.page-header .nav.global {
  font-family: "League Gothic", "Arial Narrow", sans-serif;
}

なお、@font-face は読み込まれる際にスタイルの適用されていない状態が一瞬見えてしまう場合がある。この現象を FOUT (Flash of Unstyled Text) と呼ぶらしい。

対策のひとつとして、@font-face で指定したフォントに似ていて、かつインストール率の高いフォントをフォールバックとして指定するという手がある。そうすれば、@font-face フォントに切り替わったときに違和感が少ない、という考え。というわけでとりあえずここでは Arial Narrow を指定してみたけど、League Gothic と似ているとは言いがたいので、FOUT 対策としてはかなり微妙。

そのほかの部分は今までと変わらず Helvetica/Arial、等幅は Menlo/Consolas。和文フォントは指定せず、ブラウザの設定に依存。基本の CSS は以下の通り:

body {
  font: 15px/1.67 "Helvetica Neue", "Helvetica", "Arial", sans-serif;
}
code, kbd, samp {
  font-family: "Menlo", "Consolas", "Courier New", monospace;
}

カラー

今までは背景色 white (#ffffff) に前景色 black (#000000)、そしてリンクは #0080ff という、かなりざっくりした配色だったんだけど、このサイトは横幅がせまくて画像やボーダーなどが少ないこともあり、かなりまぶしく感じることがあった。そこで今回は、背景をごく薄いオフホワイトの #fcfcf8、前景はブラックに近いブルーの #002040 にしてみた。イメージとしては、最近愛用のツバメノートにブルーブラックのインクで書いた感じを狙っている。

そのほか、今までざっくりしていた反動で、#f0f0e0 や #e0e0c0 などのベージュ系、#8090a0 のブルーグレイなど、僕にしては微妙な色も使ってるけど、微調整がめんどうなのでざっくりに戻すかも。

コメントフォームを廃止して、かわりに Twitter とはてなブックマークでの言及を収集して表示させることにした。はじめての試みなので、上手くいくかどうかやや不安。JavaScript から各種 API を利用してるんだけど、長くなるので詳しくは稿を改めて書きたい。

Last.Fm Records

2010-02-04T00:00:00Z

Last.fm から、最近聴いてるアルバムや “Love” 登録した曲などのデータを取得して自分のサイトに表示する WordPress プラグイン、Last.Fm Records を導入してみました。

プラグインをダウンロードして有効化すると、管理パネルの「設定」からオプションをいじれます。おもな項目は以下のとおり:

Last.fm username: Last.fm でのユーザー名。ちなみに、自分のデータのみならず「気になるあの人のお気に入りリスト」なんてのも可能。
Period: “Recent Tracks” や “Last 7 days” など、取得するデータの種類を選択。
Count: アイテムの件数。
Refresh time: Period が “Recent Tracks” の場合の更新頻度。
Off-set (from GMT +0): 用途不明。とりあえず日本なので +9。
Default thumb: ジャケ写がない場合のデフォルト画像。
Add stylesheet: あらかじめ用意されたスタイルを選べますが、あんまりクールじゃないので自分で書くのがおすすめ。

実際にページに表示するには、WordPress の「ウィジェット」機能を利用する手もありますが、テンプレートの中で表示させたい箇所に以下のコードを挿入しても OK です:

<div id="lastfmrecords"></div>

結果、以下のようなマークアップが生成されます:

<div id="lastfmrecords">
  <ol>
    <li style="display: inline;">
      <a href="http://www.last.fm/music/Perfume/Perfume%3A+Complete+Best">
        <img src="http://userserve-ak.last.fm/serve/126/41074031.jpg" id="lastfmcover0" title="Perfume: Complete Best by Perfume">
      </a>
    </li>
    <li style="display: inline;">
      <a href="http://www.last.fm/music/Perfume/GAME">
        <img src="http://userserve-ak.last.fm/serve/126/29327629.png" id="lastfmcover1" title="GAME by Perfume">
      </a>
    </li>
    <li style="display: inline;">
      <a href="http://www.last.fm/music/Perfume/%E2%8A%BF">
        <img src="http://userserve-ak.last.fm/serve/126/29542861.png" id="lastfmcover2" title="⊿ by Perfume">
      </a>
    </li>
    . . .
  </ol>
</div>

あとは CSS で整形すれば完成。ol で出力されるものの li にインラインで display: inline; が指定されている点に注意。例としてこのサイトでのスタイルを載せておきます:

#lastfmrecords ol {
  overflow: hidden;
  width: 100%;
  padding: 5px 0 0;
  margin: 0;
}
#lastfmrecords ol li {
  display: block !important;
  float: left;
  margin: 0 2px 5px 0;
}
#lastfmrecords ol li a img {
  max-width: 48px;
  max-height: 48px;
  padding: 1px;
  border: 1px solid silver;
}
#lastfmrecords ol li a:hover img {
  border-color: #002040;
}

ちなみに、プラグインの ZIP の中の last.fm.records.js は、WordPress でなくても jQuery プラグインとして使うことが可能。オプションの指定方法など、詳しくは作者のサイトで解説されています。

画像のマークアップを通じて Progressive Enhancement を理解する試み

2010-02-09T00:00:00Z

Progressive Enhancement と Graceful Degradation って、ひょっとしてこういうことかな? という思いつき。

<img src="logo.png" alt="Google">

このマークアップを、「もし画像が利用できない場合はテキストで代替する」と読むのが Graceful Degradation。

「もし画像が利用できる場合は画像を表示する」と読むのが Progressive Enhancement。

わりと気に入ってるアイディアなんですが、どうでしょうか。Progressive Enhancement と Graceful Degradation について、詳しくは以下のリソースをどうぞ。

XAMPP と MAMP のバーチャルホスト設定

2010-02-24T00:00:00Z

XAMPP と MAMP のバーチャルホスト設定について、職場が変わったりマシンを入れ替えたりするたびにいちいちググるのが面倒になったので、「とりあえずこれで動く!」という自分なりの設定を書いておく。各設定についての詳細は Apache のドキュメンテーションなどを参照のこと。

XAMPP + Windows

XAMPP for Windows を C:\xampp にインストールしていて、E:\My Documents\Projects に複数のサイトのデータを格納している場合を想定する。各種設定は C:\xampp\apache\conf にある httpd.conf を編集することで行なう。このファイルは管理するサイトが増えるたびに開くことになるので、どこかにショートカットを作っておくとあとで楽。

まず、プロジェクト管理ディレクトリについて、SSI ほかオプションの使用を可能にし、またローカルからのみアクセスを許可する設定をカマす。httpd.conf の末尾に以下を記述。

<Directory "E:/My Documents/Projects">
    Options All
    Order Deny,Allow
    Deny from all
    Allow from localhost
</Directory>

次に、バーチャルホストを利用できるようにするため NameVirtualHost を記述。そしてサイトごとに <VirtualHost> ブロックを作成し、DocumentRoot でサイトのルートディレクトリを、ServerName で適当なホスト名を指定する。先ほどの <Directory> の記述に続けて、httpd.conf の末尾に以下のように追記していく。

NameVirtualHost *:80

<VirtualHost *:80>
    DocumentRoot "E:/My Documents/Projects/example"
    ServerName example.localhost
</VirtualHost>

<VirtualHost *:80>
    DocumentRoot "E:/My Documents/Projects/example2"
    ServerName example2.localhost
</VirtualHost>

...

ここではホスト名に .localhost という TLD を使ってるけど、ユニークなものであればどんな名前でも OK。

最後に、C:\WINDOWS\system32\drivers\etc にある hosts というファイルをテキストエディタなどで開く。httpd.conf で設定した ServerName の値ににしたがって、管理するサイトの分だけ以下のように追加していく。ちなみにこの hosts も httpd.conf と同様にショートカットを作成しておくと便利。

127.0.0.1       localhost
127.0.0.1       example.localhost
127.0.0.1       example2.localhost
...

以上! XAMPP Control Panel から Apache を再起動 (いったん Stop して再度 Start) し、Web ブラウザで http://example.localhost/ を見ればサイトを確認することができるはず。

ついでに、拡張子が .html または .htm のファイルも SSI で利用できるようにしておくと便利。httpd.conf のどこかに AddOutputFilter INCLUDES .shtml という記述があるので、その行末に以下のように追記する。

AddOutputFilter INCLUDES .shtml .html .htm

MAMP + Mac OS X

MAMP を /Applications/MAMP にインストールしてあり、/Users/<usdername>/Projects に複数のサイトのデータを格納している場合を想定する。

バーチャルホストの設定の前に、MAMP はポート番号が 8888 に設定されているので、これを HTTP のデフォルトである 80 に変更しておく。それには MAMP のコントロールパネルから「環境設定」を開き、「ポート」タブで「Apache と MySQL の標準ポートに設定」をクリックすればよい。このあたりは MAMP のインストール for Mac - 独学! 未経験から Web デザイナーになる!! でていねいに解説されているのでご参照されたし。

さて、XAMPP と同様、/Application/MAMP/conf/apache にある httpd.conf を開き編集する。どこかにエイリアスを作っておくのが吉。記述方法は XAMPP と同様で、以下のような感じで末尾に記述していく。

<Directory "/Users/<usdername>/Projects">
    Options All
    Order Deny,Allow
    Deny from all
    Allow from localhost
</Directory>

NameVirtualHost *:80

<VirtualHost *:80>
    DocumentRoot "/Users/<usdername>/Projects/example"
    ServerName example.localhost
</VirtualHost>

<VirtualHost *:80>
    DocumentRoot "/Users/<usdername>/Projects/example2"
    ServerName example2.localhost
</VirtualHost>

...

そして Windows と同様に hosts ファイルを編集。Mac の場合は /private/etc ディレクトリにあるので、なんらかのエディタで開いて以下のようにホストを追加する。

127.0.0.1 localhost
...
127.0.0.1 example.localhost
127.0.0.1 example2.localhost
...

MAMP のコントロールパネルから Apache を再起動すれば完了!

なお MAMP で SSI を利用する場合、httpd.conf 内の関連記述が以下のようにコメントアウトされているので、

#AddType text/html .shtml
#AddOutputFilter INCLUDES .shtml

まず上記 2 行の行頭にある # を消去し、必要に応じて AddOutputFilter 行の末尾に拡張子を追加する。

AddType text/html .shtml
AddOutputFilter INCLUDES .shtml .html .htm

参考

Apache HTTP サーババージョン 2.2 ドキュメントの簡易リンク集:

13 か 15

2010-03-06T00:00:00Z

先日、Twitter で @smashongmag (Smashing Magazine のアカウント) からこんな問いかけがありました:

What font-size do you usually use for your body copy? (If em, convert to px): 11px, 12px, 13px? Let us know! #smfont

「(Web ページの) 本文のフォントサイズっていつも何ピクセルにしてる?」というわけですね。この問いに対するぼくの答えは決まっていて、それは「13px か 15px」です。なぜ 12px でも 14px でもなく、13px と 15px なのか。その理由は、Windows 日本語環境の「事実上の標準」と言えるフォント、ＭＳＰゴシック (MS PGothic) にあります。

Fig 2: ＭＳＰゴシック 12px

Fig 3: ＭＳＰゴシック 13px

ＭＳＰゴシックの 12px と 13px のスクリーンショットを並べてみました (Fig 2 と 3)。一見したところほとんど同じに思えるかもしれませんが、よく見比べるとかなり印象が違うはずです。12px だと文字と文字の間隔がかなりきっちり詰められているのに対し、13 px はやや余裕があって読みやすいと感じませんか?

さらによく見ると、文字ひとつひとつの大きさは同じですが、微妙に文字間隔が異なるのがわかります。つまり、ＭＳＰゴシックは 13px の字形を持っておらず、12px の字形に文字間隔を加えることで 13px を表現しているのです。しかし結果として、その文字間隔が可読性に貢献しているわけです。

Fig 4: ＭＳＰゴシック 12px 拡大図

Fig 5: ＭＳＰゴシック 13px 拡大図

もちろん、文字間隔と言っても均等に 1px ずつあけるのではなく、プロポーショナル・フォントとしてバランスが考えられています (Fig 4 と 5)。つまり、CSS で font-size: 12px; letter-spacing: 1px; と指定するのとはまったく違うわけです。

そしてこの 12px と 13px の関係と同じことが、14px と 15px の間でも起こります (Fig 6 と 7)。

Fig 6: ＭＳＰゴシック 14px

Fig 7: ＭＳＰゴシック 15px

とは言え、「なんか間が抜けてるように見えてヤだ」って意見もあると思いますし、少しでもスペースを節約しなければならない場合もあると思います。しかし、いわゆる「本文」としてある程度まとまった分量のテキストの場合、このくらいの余裕がほしいと感じる人は少なくないはずです。

そんなわけで、日本語を中心としたコンテンツで、ある程度の割合のユーザーがＭＳＰゴシックで閲覧していると想定される場合、Web ページの本文のフォントサイズは 13px か 15px がベスト、というのが僕の意見です。

Opera 10.50 の CSS バグ: input 要素に border-radius

2010-04-19T00:00:00Z

Opera 10.50 では border-radius プロパティがサポートされましたが、input 要素に対して指定する場合、ちょっとしたバグがあるので注意が必要です。そのバグとは、ボーダーを消した (border-width: 0; または border-style: none; を指定した) input 要素に border-radius を指定すると、background-color の指定が無効になる、というものです。10.51 でも修正されませんでした。

たとえば以下の場合、背景色の指定は反映されません。

input[type="submit"] {
  border: 0;
  border-radius: 4px;
  background: #0060c0;
}

このバグを回避するには、background-color と同時に、background-image に透過画像を指定します。

input[type="submit"] {
  border: 0;
  border-radius: 4px;
  background: #0060c0 url(transparent.png);
}

これで背景色の指定が有効になります。この回避策は以下のサイトで紹介されていました:

Attrakt.se Blog: Annoying Opera CSS3 bug - INPUT border-radius

ちなみに、input 要素のボーダーのどれか 1 辺以上を表示させることでも回避できます。しかしこの方法には副作用があり、submit タイプの場合、同じフォーム内にある text タイプの input 要素にフォーカスした際、アウトラインのようなものが表示されてしまいます (下図参照)。

WordPress で HTML5 を書くための準備

2010-04-21T00:00:00Z

現在、このサイトを HTML5 で再構築しようと画策しています。今日はその「準備編」ということで、WordPress で HTML5 をパブリッシュするために、どのようにテンプレートをいじればよいかを考えてみました。ここでは WordPress 2.9 のデフォルトのテーマ、WordPress Default 1.6 に手を加えていきます。

文書型宣言

header.php の 7 行目 (実際に出力されるのは 1 行目) あたりで以下のように文書型が宣言されています:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

これを以下のように修正します:

<!DOCTYPE html>

HTML5 の文書型宣言では大文字か小文字かは問われませんので、<!DOCTYPE HTML> でも <!doctype html> でもでもかまいません。

文字コード宣言

header.php の 11 行目あたりに以下の記述があります:

<meta http-equiv="Content-Type" content="<?php bloginfo('html_type'); ?>; charset=<?php bloginfo('charset'); ?>" />

これをこのように書き替えます:

<meta charset="<?php bloginfo('charset'); ?>" />

<?php bloginfo('charset'); ?> の部分は WordPress の設定画面で指定した文字コードが出力されます。たとえば <meta charset="UTF-8" /> など。

JavaScript

IE が HTML5 の新しい要素タイプを認識でないという問題を解決するため、header.php の head 要素内で、CSS より先に html5shiv スクリプトを以下のようにインクルードします。

<!--[if lt IE 9]>
<script src="http://html5shiv.googlecode.com/svn/trunk/html5.js"></script>
<![endif]-->

CSS

section や nav といった HTML5 の新しい要素タイプのうち、ブロックボックスとしてレンダリングしたいものについて CSS で明示します。これは header.php の head 要素内に style 要素として書いてもいいし、style.css などの CSS ファイルに書いてもいいです。

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

まとめ

header.php のおもな変更点をまとめるとこんな感じです:

<!DOCTYPE html>
<html lang="ja">
<head>
<meta charset="<?php bloginfo('charset'); ?>" />
<title> . . . <title>
<!--[if lt IE 9]>
<script src="http://html5shiv.googlecode.com/svn/trunk/html5.js"></script>
<![endif]-->
<style>
section, nav, article, aside, hgroup, header, footer, figure, figcaption {
  display: block;
}
</style>
. . .
</head>
. . .

これで、WordPress で HTML5 を書くための最低限の準備は整いました。あとは肝心の body 要素内のコンテンツのマークアップですが、それはまた次回。

HTML5 へ移行

2010-04-26T00:00:00Z

というわけで、このサイトを HTML5 でマークアップしてみました。個別記事内のフレージング系の見直しはまだ手つかずで、まずはセクショニングまわりから固めています。納得のいかない部分もありますが、まずは公開して、これからさらに手を加えていこうと思います。

さて、個別記事ページの構成はこんな感じになってます:

div.page#page
- header.page-header
  - h1.logo
  - nav.global
- article.content
  - header.content-header
    - nav.paging
    - p.date
    - h1.title
  - div.content-body
    - (Content goes here)
  - footer.content-footer
    - nav.paging
    - section#tags
    - section#related-posts
  - aside.content-aside
    - section.comments
      - article.comment
- aside.sidebar
  - section#search
  - section#archives-by-tag
  - section#about
  - section#elsewhere
  - section#subscribe
  - section#lastfm
- footer.page-footer
  - p.credits

ページ全体のヘッダとフッタとして header/footer を配置し、記事部分は article で、そして検索やタグクラウドなど、記事よりもサイト全体に関わる部分は aside でマークアップしています。

マークアップでとくに悩んでいるのは、「タグ」「関連記事」「コメント」といった記事の終わりに並ぶ要素群です。今のところ、「タグ」と「関連記事」は footer、「コメント」は aside とし、どちらも記事本体の article 内に置きました。しかしどうも拡大解釈気味というか、いまいちしっくりこない気もしています。

あと、どこまで nav 要素とすべきかも難しいです。とりあえず、ページのヘッダのいわゆるグローバルナビゲーションと、記事のヘッダとフッタに配置している前後の記事へのリンクを nav でマークアップしていますが、記事の「タグ」や「関連記事」、それにサイト内検索もナビゲーションっちゃナビゲーションだよな… という悩み方をしています。

そのほか、role 属性も入れようと思ったのですが、仕様がよくわかかっていない—というかどの仕様を読めばいいのかよくわかっていない—ので保留。Microformats ももう少しきっちりやりたいところです。

マークアップにあたって、仕様書のほか、実際に HTML5 で書かれたサイトなどをいろいろと参照しましたが、とくに HTML5 Doctor の記事と、ドクターたちの個人サイトのソースコードは参考になりました:

やっぱり HTML5 はまだまだ導入事例が少なく、暗中模索している人も多いのではないでしょうか。とくに個人のサイトをお持ちの皆さんはどんどんトライしてみて、意見交換が活発になるといいなと思います。

ツッコミ歓迎!

HTML5 の dl 要素

2010-04-27T00:00:00Z

HTML5 の 2010 年 3 月 4 日付 W3C 草案で、dl 要素は以下のように定義されています:

The dl element represents an association list consisting of zero or more name-value groups (a description list). Each group must consist of one or more names (dt elements) followed by one or more values (dd elements). Within a single dl element, there should not be more than one dt element for each name.

HTML4 では、dl 要素は definition list (定義リスト) であり、term (dt) と description (dd) から構成されるとされていました (Lists in HTML documents)。それが HTML5 では「名前と値のグループからなるリスト」となっており、その例として、「定義語とその定義」や「メタデータの題目と値」などが挙げられています。

ちょっときびしいなと思うのが、“Within a single dl element, there should not be more than one dt element for each name.” という部分。1 つの dl 要素の中で、同じ内容を持つ dt 要素が複数存在すべきではない、とのこと。より「連想配列」的な性格を強めたということでしょうか。

しかしそうなってくると、以下のような dl の使い方は推奨されないということになりますよね…

<dl class="news">
  <dt>2010-04-27</dt>
  <dd>ブログを更新しました</dd>
  <dt>2010-04-27</dt>
  <dd>プレスリリースを発表しました</dd>
  <dt>2010-04-01</dt>
  <dd>サイトをリニューアルしました</dd>
</dl>

<dl class="dialog">
  <dt>Costello</dt>
  <dd>Look, you gotta first baseman?</dd>
  <dt>Abbott</dt>
  <dd>Certainly.</dd>
  <dt>Costello</dt>
  <dd>Who's playing first?</dd>
  <dt>Abbott</dt>
  . . .
</dl>

ひとつめの例はサイトの更新履歴、ふたつめは会話文のマークアップ例ですが、どちらも同じ内容を持つ dt 要素が 2 回以上出現しているので、あまりよろしくないということになります。あくまで “should not” ですが。

Delicious Feeds API に URL をそのまま渡す

2010-04-30T00:00:00Z

Delicious の Feeds API を利用するとページの被ブックマーク関連情報を取得できるが、対象ページの URL を MD5 ハッシュ値で渡さなければならないという謎の掟がある。しかしデータを JSON 形式で取得する場合は、以下の方法で URL をそのまま渡すことも可能。

まず、そのページのブックマーク件数や使われているタグなどを取得する場合:

http://feeds.delicious.com/v2/json/urlinfo/blogbadge?url={url}

個々のブックマークのユーザー名、日付、タグなどのデータは:

http://feeds.delicious.com/v2/json/url/blogbadge?url={url}

公式ドキュメントには載ってないっぽいけど、どちらも {url} にページの URL をそのまま入れれば JSON 形式でデータが取得できる。そのほかのパラメータはドキュメントを参照のこと。以下はうちのサイトの例:

この記事を書くにあたって以下の記事を参考にしました (ありがとうございます) が、一部情報が古くなっているようなので注意:

deliciousの本家Helpに書かれていないAPIの使いかた : tech.kayac.com - KAYAC engineers' blog

aside 要素とプル・クオート

2010-04-30T00:00:00Z

HTML5 の 2010 年 3 月 4 日付 W3C 草案では、aside 要素は以下のように定義されています:

The aside element represents a section of a page that consists of content that is tangentially related to the content around the aside element, and which could be considered separate from that content. Such sections are often represented as sidebars in printed typography.

The element can be used for typographical effects like pull quotes or sidebars, for advertising, for groups of nav elements, and for other content that is considered separate from the main content of the page.

なにが難しいってこの tangentially related って部分をどう解釈するかが難しいんですが、そこは置いときます。今回ここで取り上げたいのは、上記草案のうちふたつめの段落、要素の具体的な使用例の部分。そこには、aside 要素は「プル・クオートや囲み記事のようなタイポグラフィ上の効果や、広告、nav 要素のグループ、またそのほかページの中心となる内容から切り離されていると見なせるコンテンツのために使われる」とあります。ここで気になったのが「プル・クオート」という聞き慣れない単語です。調べてみると英語版 Wikipedia に記事がありました:

A pull quote (also known as a lift-out quote or a call-out) is a quotation or edited excerpt from an article that is typically placed in a larger typeface on the same page, serving to lead readers into an article and to highlight a key topic. The term is principally used in journalism and publishing.

プル・クオートとは「記事からの引用または手を入れた抜粋で、一般的には同一ページ内に大きめの書体で配置され、リード文の役割を果たし、主要な話題を目立たせるもの」であり、「おもに新聞・雑誌や出版で使われる用語」である、と。「クオート」というとほかのリソースからの引用を思い浮かべがちですがそうではなく、みずからの要約やハイライトのための抜粋ということのようです。

そう言われて僕がすぐに思いついたのは、雑誌のインタヴュー記事で主要な発言を抜き出して見出しのように見せるやつです。とくに数ページにわたる長い記事で、キャッチーかつ全体を要約するようなセンテンスをページの上部や段落の間などに挿入するあれ、あれをどうやらプル・クオートと呼ぶらしい。たしかに、あの部分は記事の内容を把握する助けになりますが、もしページ上に存在しなかったとしても記事そのものには影響がないので、aside 要素の定義にマッチしているように思いますね。

というわけで、aside 要素をどのように使うか迷ったときは、プル・クオートのような「その前後の内容に関係する (かもしれない) けれども、なくてもその前後には影響のない要素」というようなものを思い浮かべるといいかもしれません。

blockquote + footer

2010-05-02T00:00:00Z

コメントでの指摘を受け、新しく記事を起こしました: HTML5 での引用と引用元のマークアップ

HTML5 の 2010 年 3 月 4 日付 W3C 草案で、footer 要素は以下のように定義されています:

The footer element represents a footer for its nearest ancestor sectioning content or sectioning root element. A footer typically contains information about its section such as who wrote it, links to related documents, copyright data, and the like.

（4.4.9 The footer element — HTML 5）

「footer 要素は、直近の祖先にあたるセクショニング・コンテントまたはセクショニング・ルート要素に対するフッターを示します。フッターは一般的に、執筆者、関連文書へのリンク、著作権などといった、そのセクションについての情報を含みます」、といったところですね。たとえばおもにページの下部に入るサイトの著作権などのクレジットや、ブログ記事の執筆者や日付などをマークアップするのに使うことになると思います。

さて「セクショニング・コンテントまたはセクショニング・ルート要素に対するフッター」とのことですが、この「セクショニング・ルート」となる要素のひとつに blockquote 要素があります。blockquote のフッターとなれば、引用元の情報を記述するのにうってつけではないでしょうか。というわけで、HTML5 における blockquote のマークアップを考えてみました:

<blockquote cite="http://ja.wikipedia.org/wiki/1Q84">
  <p>『1Q84』（いちきゅうはちよん）は、村上春樹の長編小説。</p>
  <p>2009年5月、書き下ろしとして新潮社から刊行された。2009年11月に第63回「毎日出版文化賞　文学・芸術部門」を受賞した。</p>
  <footer>
    出典: <cite>1Q84 - Wikipedia</cite>,
    <time datetime="2010-05-02">2010 年 5 月 2 日</time>
  </footer>
</blockquote>

blockquote 要素内の footer 要素に、引用元を示す cite 要素と情報の取得日時を示す time 要素を含めています。引用元の URI は blockquote 要素の cite 属性で示していますが、たとえば以下のように jQuery を使って、cite 属性値の URI を抽出して cite 要素にリンクを設定することもできます:

$(function () {
  $('blockquote[cite]').each(function () {
    var pattern = /^https?\:/i;
    var citeUrl = $(this).attr('cite');
    var citeElm = $(this).children('footer').children('cite');
    if (pattern.test(citeUrl) && citeElm) {
      citeElm.wrap('<a href="' + citeUrl + '"/>');
    };
  });
});

なお、HTML5 では cite 要素の定義がかなりきっちりしていて、人名をマークアップをするために使われるべきではないとされています:

The cite element represents the title of a work (e.g. a book, a paper, an essay, a poem, a score, a song, a script, a film, a TV show, a game, a sculpture, a painting, a theatre production, a play, an opera, a musical, an exhibition, a legal case report, etc). This can be a work that is being quoted or referenced in detail (i.e. a citation), or it can just be a work that is mentioned in passing.

A person’s name is not the title of a work — even if people call that person a piece of work — and the element must therefore not be used to mark up people’s names. (In some cases, the b element might be appropriate for names; e.g. in a gossip article where the names of famous people are keywords rendered with a different style to draw attention to them. In other cases, if an element is really needed, the span element can be used.)

（4.6.5 The cite element — HTML 5）

よって、フッターの引用元の文言に人名などが含まれる場合、以下のようにマークアップするのが適切と思われます:

<blockquote>
  <p>エレベーターはきわめて緩慢な速度で上昇をつづけていた。おそらくエレベーターは上昇していたのだろうと私は思う。</p>
  <footer>
    村上春樹『<cite>世界の終りとハードボイルド・ワンダーランド</cite>』より
  </footer>
</blockquote>

マークアップする上で blockquote 要素と cite 要素というのはなかなか扱いの難いものだったと思います。たとえば blockquote 要素の中に cite 要素を含めるのは是か非かとか、blockquote 要素の外に cite 要素を置いた場合にどうやって両者を紐付けるかとか。

このあたり、footer 要素を使うことでかなりすっきりするのではないかと思うのですが、どうでしょうか。

HTML5 での引用と引用元のマークアップ

2010-05-07T00:00:00Z

前回の記事で、HTML5 における引用と引用元のマークアップについて以下のような提案をしました:

<blockquote>
  <p>エレベーターはきわめて緩慢な速度で上昇をつづけていた。おそらくエレベーターは上昇していたのだろうと私は思う。</p>
  <footer>
    村上春樹『<cite>世界の終りとハードボイルド・ワンダーランド</cite>』より
  </footer>
</blockquote>

引用元についての情報を footer 要素でマークアップし、かつ blockquote 要素の中に置くというアプローチです。かなり気に入っていたのですが、はてなブックマークでこんなコメントをいただきました (ありがとうございます):

“Content inside a blockquote must be quoted from another source” なので引用文以外の情報を含めるのはアウト。（そういう場合は<figure>を使うってのがどこかで言われてたけど、どこだったっけ…）

（はてなブックマーク - vantguarde - 2010年5月6日）

HTML5 仕様書の blockquote の項にあたってみると、たしかにこうあります:

The blockquote element represents a section that is quoted from another source.

Content inside a blockquote must be quoted from another source, whose address, if it has one, should be cited in the cite attribute.

（4.5.5 The blockquote element — HTML5 [W3C Working Draft 4 March 2010）

見落としておりました。「blockquote の内容はほかのリソースからの引用でなければならず、引用元は cite 属性で言及されるべき」といったところでしょうか。HTML 4.01 ではゆるかったのが HTML5 ではきっちりしているようです。失礼いたしました…

というわけで、HTML5 において引用と引用元をマークアップするにはどうするのがよいか、再び考えてみました。以下、いくつかの案を挙げてみます。

1. div + p

<div class="quote">
  <blockquote>
    <p>エレベーターはきわめて緩慢な速度で上昇をつづけていた。おそらくエレベーターは上昇していたのだろうと私は思う。</p>
  </blockquote>
  <p class="cite">
    村上春樹『<cite>世界の終りとハードボイルド・ワンダーランド</cite>』より
  </p>
</div>

まず最初の案は、HTML5 の新しい要素タイプを使わないマークアップ。まあ、間違いではないですよね、少なくとも。でも引用と引用元の結びつきが弱いというか、セマンティックでないというか。やはりここはもう少し積極的に HTML5 の新要素を活かしたマークアップを模索したいところです。

2. article + footer

<article>
  <blockquote>
    <p>エレベーターはきわめて緩慢な速度で上昇をつづけていた。おそらくエレベーターは上昇していたのだろうと私は思う。</p>
  </blockquote>
  <footer>
    村上春樹『<cite>世界の終りとハードボイルド・ワンダーランド</cite>』より
  </footer>
</article>

ふたつめ、引用元を footer 要素で、blockquote 要素を含む全体を article 要素でマークアップ。前回の記事で見たように、引用元を footer でマークアップするのは悪くないと思うんですが、引用を article と見なすのはやや無理がありそうな気がしますね。というわけで、次。

3. figure + figcaption

<figure>
  <blockquote>
    <p>エレベーターはきわめて緩慢な速度で上昇をつづけていた。おそらくエレベーターは上昇していたのだろうと私は思う。</p>
  </blockquote>
  <figcaption>
    村上春樹『<cite>世界の終りとハードボイルド・ワンダーランド</cite>』より
  </figcaption>
</figure>

今のところいちばん良さそうかなと思っているのがこれです。引用元を figcaption 要素で、bloclquote 要素を含む全体を figure 要素でマークアップします。HTML5 の 2010 年 3 月 4 日付 W3C 草案での figure と figcaption の定義は以下のとおりです:

The figure element represents some flow content, optionally with a caption, that is self-contained and is typically referenced as a single unit from the main flow of the document.

The element can thus be used to annotate illustrations, diagrams, photos, code listings, etc, that are referred to from the main content of the document, but that could, without affecting the flow of the document, be moved away from that primary content, e.g. to the side of the page, to dedicated pages, or to an appendix.

（4.5.12 The figure element — HTML5 [W3C Working Draft 4 March 2010]）

The figcaption element represents a caption or legend for the rest of the contents of the figcaption element’s parent figure element, if any.

（4.5.13 The figcaption element — HTML5 [W3C Working Draft 4 March 2010]）

引用元の情報はまさに引用のキャプションと見なすことができるので、かなりしっくりくる気がします。ただ、figure 要素は「主たるコンテントから切り離せる」ものとされているのに対し、引用は前後の文脈と密接に関連する場合が多いので、そのあたりがやや微妙かもしれません。

また上記草案では、figure と figcaption の用例として詩の一節を引用する場合を挙げています。blockquote 要素を用いていないのが気になりますが:

<figure>
  <p>'Twas brillig, and the slithy toves<br>
    Did gyre and gimble in the wabe;<br>
    All mimsy were the borogoves,<br>
    And the mome raths outgrabe.</p>
  <figcaption>
    <cite>Jabberwocky</cite> (first verse). Lewis Carroll, 1832-98
  </figcaption>
</figure>

figure と figcaption の例をもうひとつ、HTML5 Doctor の記事より。引用というよりソースコードとその注釈をマークアップするケースですが:

<figure>
  <blockquote>
    <p><code>&lt;small&gt;&lt;a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/"&gt;Creative Commons Attribution Share-alike license&lt;/a&gt;&lt;/small&gt;</code></p>
  </blockquote>
  <figcaption>
    Using <code>&lt;small&gt;</code> around a <a href="http://creativecommons.org/choose/" title="Choose a License">Creative Commons license</a> link with <code>rel="license"</code>
  </figcaption>
</figure>

どうでしょうか。figure と figcaption でいけそうかなと思うんですが… いやー、難しい!

google-code-prettify を導入

2010-05-14T00:00:00Z

ソースコードを強調表示するシンタックス・ハイライトをブログに導入したくていくつか調べてみたんだけど、結局 google-code-prettify にした。行番号を入れたりのリッチな機能は必要なくて、シンプルにシンタックスの抽出をやってくれるものを探していたので。

導入にあたっては、hail2u.net の記事を参考に Google の Closure Compiler を利用した。このブログで扱うソースコードというと HTML か CSS か JavaScript、まれに PHP といったところなので、コアである prettify.js のほかに lang-css.js を加えてコンパイルした。

カラーリングは頑張って微妙な色合いも試してみたけど、ことごとく挫折。最終的には CSS の color キーワードでざっくり指定するのがしっくりきた。

.prettyprint .kwd,
.prettyprint .tag { color: purple; }
.prettyprint .typ,
.prettyprint .atn { color: maroon; }
.prettyprint .str,
.prettyprint .atv { color: navy; }
.prettyprint .lit { color: blue; }
.prettyprint .pun { color: teal; }
.prettyprint .pln { color: black; }
.prettyprint .dec,
.prettyprint .com { color: green; }

なお、バージョン 8 未満の IE では改行が除去されてしまうというバグが発生する。

シカトしようかとも思ったけど、さすがにこれじゃ読んでいられないので、コンディショナル・コメントで対応した。「バージョン 8 以上の IE とそのほかのブラウザ」という条件なので、記述がちょっとややこしい。

<!--[if gt IE 7]><!-->
  <script type="text/javascript" src="/js/google-code-prettify.js"></script>
<!--<![endif]-->

印刷用の CSS と jQuery プラグイン

2010-05-14T00:00:00Z

URL のリストを出力するスクリプトを一部修正して Gist に置きました。

このサイトの印刷時のスタイルというものをまったく考えていなかったことに気づいたので、あわてて CSS と jQuery プラグインを書いて対応した。テストするのに結構な量の紙を消費したけど、サイトを見てる人には印刷してもらわない限り工夫が伝わんないってのがなんかもったいないとか思ったので、やったことをまとめて記事にしてみる。

Fig 1: スクリーンショット

Fig 2: 印刷プレヴュー

CSS ファイル

印刷専用の CSS ファイルは用意せず、汎用 CSS ファイルの末尾に @media ルールで記述している。サイトの規模や運用方法なんかにもよるだろうけど、ファイル数はなるべく減らしたいので。

不要な要素を削除

CSS ではまずは印刷物として必要のない要素を display: none; で削除。各種ナビゲーション、ボタン、関連記事のリスト、サイドバー (検索、タグ・クラウドなど) あたりをばっさり消した。

表示エリアの幅

スクリーンでのレイアウトは左側に大きくパディングをとってるけど、印刷時は本文部分を中心に width を auto、左右の padding と margin を 0 にして、表示領域をなるべく広く確保。

タイポグラフィ

ロゴや見出しに Web フォントを使ってるけど、同じフォントがローカルにも入ってないと印刷には反映されない、というのは盲点だった。そのためロゴは Helvetica/Arial を使った印刷専用のスタイルに大幅修正。邪魔にならないサイズに抑えつつ、それだけだとちょっとさみしいので Favicon 画像を content プロパティで挿入してみた。

.logo {
  font: 16px/1 "Helvetica Neue", "Helvetica", "Arial", sans-serif;
}
.logo:before {
  content: url(/img/favicon.png);
  margin: 0 8px 0 0;
  float: left;
}

本文部分のフォントフェイスはメイリオで、サイズは 10px、行間はスクリーンよりやや大きく。メイリオはスクリーンで ClearType が無効の場合にかなり汚いので使うのがためらわれるけど、印刷だと小さいサイズでも読みやすいしボールドがしっかりボールドになるしでけっこうおすすめ。背景色と前景色はモノクロ、でもリンクやコードなどの配色はスクリーンのまま。

body {
  font: 10px/1.8 "Meiryo", "Lucida Grande", "Verdana", sans-serif;
  background: white;
  color: black;
}

リンクの URL をリストアップ

言うまでもなく、印刷されたドキュメントはハイパーリンクの機能を持たないので、なんらかの手段でリンク先の URL を表現したいところ。よく用いられるのは、CSS の content プロパティで href 属性の値を出力する方法:

.content-body a:after {
  content: " (" attr(href) ")";
}

詳しくは A List Apart: Articles: CSS Design: Going to Print などを参照のこと。スマートだけど、とくに長い URL の場合に文章のリズムがくずれて読みにくくなってしまうのが難点。そこで今回は、リンクの URL を抽出して記事のおわりにリストアップする jQuery プラグインを書いてみた:

(function ($) {
  $.fn.printHrefList = function () {
    return this.each(function () {
      if (!$(this).is(':has(a[href])')) {
        return;
      }
      var $this = $(this),
        $hrefList = $('<dl class="href-list" />').appendTo(this).hide(),
        urlArr = [];
      $this.find('a[href]').each(function () {
        var $this = $(this),
          url = this.href,
          index;
        if ($.inArray(url, urlArr) < 0) {
          urlArr.push(url);
          index = urlArr.length;
          $hrefList.append('<dt>' + index + '</dt><dd>' + url + '</dd>');
        } else {
          index = $.inArray(url, urlArr) + 1;
        }
        $this.after(
          $('<sub class="href-index">[' + index + ']</sub>').hide()
        );
      });
    });
  };
})(jQuery);

なにをやってるかというと、

対象要素の末尾に dl 要素を生成し、いったん非表示に
対象要素内の a 要素を見つけて、それぞれのうしろに sub 要素を生成して連番をふり、やはりいったん非表示
a 要素の番号を dt に入れて dl に追加
同じく a 要素の href 属性値を dd に入れて dl に追加

という流れ。たとえば .content-body 内のリンクを抽出したいなら、まずこうしてメソッドを呼び出す:

$(function () {
  $('.content-body').printHrefList();
});

そして、リスト (dl) とリンクの番号 (sub) が .hide() で非表示になっているので、印刷時のみ表示されるようにスタイルを指定する:

@media print {
  sub.href-index {
    display: inline !important;
  }
  dl.href-list {
    display: block !important;
  }
}

Fig 3: スクリプトと CSS 適用後の印刷プレヴュー

~~同じ URL が複数出現した場合にちょっとうざいかなと思ったけど、対応するとややこしくなりそうなので保留。~~同じ URL が複数出現した場合に繰り返し出力しないよう修正した。

Bulletproof @font-face: Smiley variation

2010-05-16T00:00:00Z

CSS の @font-face ルールの「安全な」書式として Paul Irish 氏の提唱する Bulletproof @font-face syntax (邦訳: hail2u.net - Weblog - 安全な@font-faceの書き方(抄訳)) がいつの間にかアップデートされていました。“Smiley variation” と名付けられたその最新版はこうなってます:

@font-face {
  font-family:
    'Graublau Web';
  src:
    url('GraublauWeb.eot');
  src:
    local('☺'),
    url('GraublauWeb.otf') format('opentype');
}

“☺”。そう、「スマイリー・フェイス」です。はじめはなにかのジョークかと思いましたがそんなことはなく、マジでした。これを src プロパティのローカル参照部分に指定すると「より安全」というわけです。なぜか?

まず、この「スマイリー版」に至る前、「オリジナル版」の Bulletproof @font-face はこうでした:

@font-face {
  font-family:
    'Graublau Web';
  src:
    url('GraublauWeb.eot');
  src:
    local('Graublau Web Regular'),
    local('Graublau Web'),
    url('GraublauWeb.otf') format('opentype');
}

ポイントはふたつの src プロパティです。IE は Web フォントとして EOT 形式しかサポートしていませんが、そのほかのどのブラウザも EOT 形式をサポートしていません。そこで、ローカルのフォント名を参照する local() 書式を解釈できない IE の実装を利用して、ふたつの指定を分岐させているのです。つまりこの例は、「IE はサーバ上の GraublauWeb.eot を参照。それ以外のブラウザは、もしローカルに Graublau Web Regular または Graublau Web という名前のフォントがあればそれを、なければサーバの GraublauWeb.otf を参照せよ」と言っていることになります。

さて、「オリジナル版」から「スマイリー版」への修正点は、このふたつめの src プロパティのうちローカルのフォント名を参照する部分です。この書き方のどこに問題があるのかというと、ローカルのフォント名はユーザの環境に依存するので、サイト制作者の意図とは異なるフォントが読み込まれる可能性がある、という点らしいです (参考: Different Fonts Named The Same: Does This Happen Frequently? | Typophile)。つまり、サイト制作者がローカルのフォント名として Graublau Web を指定しても、もし Helvetica を Graublau Web という名前で使用している人がいれば、その環境では Helvetica で表示されてしまう、ということになります。まれなケースではありますが、その可能性は否定できないわけです。

じゃあローカル参照を省略しちゃえばよくね? となるんですが、前述のとおりそもそもこの記述は IE とそのほかのブラウザで指定を振り分けるためのものなので、local() の部分を削除すると IE 向けの指定が上書きされてしまう—つまり IE で Web フォントが無効になってしまいます。

そこで Irish 氏が提案しているのが、ローカル参照としてあえて「ありえないフォント名」を指定するという方法です。Mac では Unicode の 2 バイト文字がフォント名として無効なこともあり、“☺” という名前のフォントがローカルにインストールされている、または今後リリースされる可能性はまずないであろう、と。

この結果、IE は変わらず local() が指定された src プロパティを無視するのでサーバの EOT フォントを読み込み、そのほかのブラウザは “☺” フォントをローカルで探すものの見あたらないのでやはりサーバのフォントを読み込む、ということになります。めでたしめでたし。

なお、以前このブログでも紹介した Font Squirrel でダウンロードできる CSS ファイルはこの「スマイリー版」で記述されており、Irish 氏もその利用をすすめています。

未来

2010-06-07T00:00:00Z

「信じたい」と思えない未来なんて、「未来」に価しない。

（橋本治『ぼくらの未来計画――貧乏は正しい！』）

「暗示の外に出ろ。俺たちには未来がある」

（いとうせいこう『解体屋外伝』）

未来は僕等の手の中‼

（真島昌利「未来は僕等の手の中」）

HTML5 の autofocus 属性を jQuery でクロスブラウザに

2010-07-18T00:00:00Z

一部を修正して Gist に置きました。IE6 と 7 で autofocus 属性値を省略すると動作しない件にも対応しています。

HTML5 ではフォームのコントロールに autofocus 属性が定義されています。その名のとおり、ページが読み込まれたときにコントロールに自動でフォーカスするためのものです。

<input type="search" name="s" autofocus>
<input type="submit" value="Search">

現時点では Safari 5.0、Chrome 5.0、Opera 10.60 がサポートしています。そこで、前回の placeholder の記事と同様に、IE6–8 や Firefox でも HTML5 で autofocus を扱えるように jQuery スクリプトを書いてみました。

$(function () {
  var supportsInputAttribute = function (attr) {
    var input = document.createElement('input');
    return attr in input;
  };
  if (!supportsInputAttribute('autofocus')) {
    $('[autofocus]').focus();
  }
});

とても簡単です。まず autofocus 属性がサポートされているか調べ、もしサポートされていなければ focus() メソッドで autofocus 属性を持つ要素にフォーカスします。デモを用意したので確認してみてください。

なお、autofocus は boolean attribute なので、前述のマークアップ例のように属性の省略記法が使えるのですが、そうすると IE6 と 7 ではこのスクリプトが動作しません。そのため以下のように属性名と値を省略せずに書く必要があります。

<input type="search" name="s" autofocus="autofocus">

HTML5 の placeholder 属性を jQuery でクロスブラウザに

2010-07-18T00:00:00Z

2011-09-23更新: 一部を修正して Gist に置きました。

フォームの入力フィールドにあらかじめテキストを表示させておく「プレースホルダ」。ブラウザの検索バーなんかに見られるような、フィールドが空のときは薄く文字が表示されていて、フォーカスすると消えるあれです。このプレースホルダの機能、HTML5 では input 要素や textarea 要素の placeholder 属性で簡単に実現できます。

<label>お名前 <input type="text" name="fn" placeholder="山田 太郎"></label>

しかしながら、この placeholder 属性をサポートしているのは今のところ Safari と Chrome のみ。そのほかのブラウザでは無視されてしまいます。そこで、この placeholder 属性をクロスブラウザで扱えるようにする jQuery スクリプトを書いてみました。実際に動作しているデモも用意したのでどうぞ。

$(function () {
  var supportsInputAttribute = function (attr) {
    var input = document.createElement('input');
    return attr in input;
  };
  if (!supportsInputAttribute('placeholder')) {
    $('[placeholder]').each(function () {
      var
        input = $(this),
        placeholderText = input.attr('placeholder'),
        placeholderColor = 'GrayText',
        defaultColor = input.css('color');
      input.
        focus(function () {
          if (input.val() === placeholderText) {
            input.val('').css('color', defaultColor);
          }
        }).
        blur(function () {
          if (input.val() === '') {
            input.val(placeholderText).css('color', placeholderColor);
          } else if (input.val() === placeholderText) {
            input.css('color', placeholderColor);
          }
        }).
        blur().
        parents('form').
          submit(function () {
            if (input.val() === placeholderText) {
              input.val('');
            }
          });
    });
  }
});

解説してみます。まずはじめのポイントは、ブラウザが placeholder 属性をサポートしているかどうかを判定している点です。判定には実際にはドキュメントに現れないダミーの input 要素を作り、placeholder プロパティの有無を調べます。その結果、もしブラウザが placeholder をサポートしていればスクリプトは何もしません。以降のスクリプトはサポートしていないブラウザでのみ実行されます。

var supportsInputAttribute = function (attr) {
  var input = document.createElement('input');
  return attr in input; // 引数で指定された属性がサポートされていれば true を返す
};
if (!supportsInputAttribute('placeholder')) {
  // placeholder 属性をサポートしないブラウザでのみ実行
}

placeholder 属性は input 要素だけではなく textarea 要素でも使われるので、セレクタは以下のように placeholder 属性を持つすべての要素を対象とします。

$('[placeholder]').each(function () {
  // placeholder 属性を持つすべての要素で実行
});

次に、対象の各要素の placeholder 属性の値と、プレースホルダの前景色をそれぞれ変数に格納します。ここではプレースホルダの前景色に具体的な色ではなくシステムカラーの GrayText を指定。OS やブラウザの GUI で選択できないテキストやなんかに使われる色ですね。実際の色は環境に依存するわけですが、だいたい #999 とか #aaa あたりになるようです。また読み込み時のフィールドの前景色も保持しておきます。

var
  input = $(this),
  placeholderText = input.attr('placeholder'), // placeholder 属性の値
  placeholderColor = 'GrayText', // プレースホルダの前景色
  defaultColor = input.css('color'); // フィールドの本来の前景色

そして、フィールドがフォーカスを得たときと失ったときにその value を調べ、プレースホルダの表示と非表示を実行します。ページの読み込み時にはフィールドがブラー状態になるようにし、その時点でフィールドが空なら placeholder 属性の値をフィールドにセット、そしてフォーカス時にプレースホルダが表示されていればそれを消去。同時に前景色も切り替えています。最後に、フィールドの value にプレースホルダが入った状態でそのまま送信されないように、フォームのサブミット時にも値をチェックしています。

input.
  focus(function () { // フォーカス時
    if (input.val() === placeholderText) {
      input.val('').css('color', defaultColor);
    }
  }).
  blur(function () { // ブラー時 (フォーカスが外れたとき)
    if (input.val() === '') {
      input.val(placeholderText).css('color', placeholderColor);
    } else if (input.val() === placeholderText) {
      input.css('color', placeholderColor);
    }
  }).
  blur(). // ページ読み込み時にいったんブラー
  parents('form').
    submit(function () { // サブミット時
      if (input.val() === placeholderText) {
        input.val('');
      }
    });

プレースホルダをどのように表現するかについては、新たに span などの要素を生成して CSS でフィールドに重ねるという手法もありますが、ここではフィールドの value にプレースホルダのテキストを突っ込むというアプローチを採りました。そのため、クライアントサイドでフォームをバリデートするようなスクリプトとの共存は難しいかもしれません。

またこのスクリプトの弱点として「placeholder 属性の値と同じ文字列をサブミットできない」という点があります。つまり、たとえば “Lorem ipsum” というプレースホルダが設定されたフィールドに “Lorem ipsum” という文字列を入力しても、それはプレースホルダと見なされてしまい送信できないわけです。これはうまく解決する方法が思いつかなかったので、とりあえずプレースホルダの文言を工夫するしかないです…

ところで、プレースホルダにはどのようなテキストがふさわしいのでしょうか。W3C の仕様では以下のように書かれています:

The placeholder attribute represents a short hint (a word or short phrase) intended to aid the user with data entry. A hint could be a sample value or a brief description of the expected format. The attribute, if specified, must have a value that contains no U+000A LINE FEED (LF) or U+000D CARRIAGE RETURN (CR) characters.

Note: For a longer hint or other advisory text, the title attribute is more appropriate.

The placeholder attribute should not be used as an alternative to a label.

（4.10.7.2.11 The placeholder attribute — HTML 5 [W3C Working Draft 4 March 2010]）

というわけで、placeholder が示すのは「ユーザのデータ入力を補助するためのちょっとしたヒント」といったところですね。具体的には「こんな感じで入力してくださいね」という記入例のようなものなどでしょうか。また長いヒントや注意書きなどは title 属性のほうがよいでしょう、とされています。ちなみに今回のスクリプトのデモは上記仕様にあったマークアップ例を使わせてもらってます。

とくに注意したいのが「label 要素の代替として用いられるべきではない」という部分です。たとえば以下のようなマークアップはけっこうやってしまいそうですが、あまりよろしくないですね:

<input type="text" placeholder="お名前">
<input type="email" placeholder="メールアドレス">

シングルライン CSS

2010-08-07T00:00:00Z

最近、CSS を書くときにコードのフォーマットを今までと少し変えてみてます。宣言 (プロパティと値のセット) ごとに改行するのではなく、セレクタごとに改行する、いわゆる シングルライン CSS です。つまり、

table {
  border-collapse: collapse;
  margin: 2em 0;
}
table th, table td {
  pading: 0.5em 1em;
  border: 1px solid silver;
}

↑ こうじゃなくて、

table { border-collapse: collapse; margin: 2em 0; }
table th,
table td { pading: 0.5em 1em; border: 1px solid silver; }

↑ こう。パッと見は読みづらく感じるかもしれませんが、実際に自分のコードを管理してみると意外にそんなことはなくて、すぐに慣れます。

このフォーマットにして良かったのは、まず探している箇所が見つけやすくなりました。CSS コードを読む場合、まず見るのは宣言ではなくセレクタであるはずで、その点でこのフォーマットは 1 行に 1 セレクタなので目で追うのがすごく楽です。

もうひとつは CSS モジュールの設計に良い影響が期待できること。ある程度の大きさのモジュールの場合、宣言ごとの改行だとコード上で見えているのは常にモジュールの一部でしかないのに対し、セレクタごとに改行するとモジュール全体を見通すことが容易で、しかもそれぞれのモジュールが「かたまり」として浮かび上がって見えてきます。その結果、より可搬性や独立性の高いモジュールの設計を意識しやすくなりました。

そもそもこのフォーマットを試したのは、CSS のコードがひたすら縦方向に長くなっていくところがイヤで、そこをなんとか圧縮したかったからなんですが、結果的にそれだけではなく、CSS の設計面を今までとは違った角度から見られるようになったことは大きな収穫でした。

HTML5 + WAI-ARIA: 入門篇

2010-08-10T00:00:00Z

このサイトを HTML5 でリニューアルした際に保留としたまますっかり忘れかけていましたが、ようやく WAI-ARIA を導入してみました。

WAI-ARIA は W3C の Web Accessibility Initiative (WAI) が公開している技術仕様で、Web コンテントや Web アプリケーションのアクセシビリティを強化することを目的としています。具体的には、Web ブラウザや支援技術 (AT) がコンテントのセマンティクスをより適切に認識できるよう、HTML ドキュメントに要素の「役割」や「状態」といった詳細な情報を付与するものです。名称に RIA とあるように、Ajax などによるリッチ・インターネット・アプリケーションをおもな対象とした仕様ですが、HTML5 によるシンプルな Web ページに取り入れることもできます。ここでは WAI-ARIA の HTML5 への導入について「入門篇」としてまとめてみました。

WAI-ARIA ではドキュメントの要素が「どのような役割を持っているか」を「ロール (role)」と呼び、HTML 要素の role 属性 として表現します。仕様には多くのロールが定義されていますが、そのうち Web ページの文書構造を定義したものが Landmark Roles という一連のロールです。Landmark という名前のとおり、ドキュメントの特定の領域に対して「目印」をつけるイメージでしょうか。たとえば、サイト内検索フォームを含む nav 要素に対して、以下のようにロールを示すことができます:

<nav role="search">
  <h2>Search this site</h2>
  <form ...>
    <p><input type="search" ...>...</p>
  </form>
</nav>

では、以下のような「ページヘッダ」「コンテント」「サイドバー」「ページフッタ」からなる典型的な Web ページを想定し、いくつかのロールについてどのようにマークアップに組み込むかを考えてみます:

<body>
  <header class="pageHeader">
    <h1 class="logo">...</h1>
    <nav class="globalNav">
      <ul>...</ul>
    </nav>
  </header>
  <article class="content">
    <header class="contentHeader">
      <h1>...</h1>
      <time pubdate datetime="...">...</time>
    </header>
    <div class="contentBody">
      ...
    </div>
  </article>
  <aside class="sidebar">
    ...
  </aside>
  <footer class="pageFooter">
    <nav class="legal">
      <ul>...</ul>
    </nav>
    <p class="copyrighgt"><small>&#169;...</small></p>
  </footer>
</body>

まず、ロゴやサイト内検索などを含むサイト全体に向けたコンテンツ領域のためのロール、banner を「ページヘッダ」に組み込むことができます:

<header role="banner" class="pageHeader">
  <h1 class="logo">...</h1>
  <nav class="globalNav">
    <ul>...</ul>
  </nav>
</header>

contentinfo は「親となるドキュメントについての情報を含む領域」とされており、そこに含まれる情報の例として「著作権や個人情報についての考え方」が挙げられています。「ページフッタ」が該当しますね:

<footer role="contentinfo" class="pageFooter">
  <nav class="legal">
    <ul>...</ul>
  </nav>
  <p class="copyright"><small>&#169;...</small></p>
</footer>

main はその名のとおり「ドキュメントの主たるコンテント」です。ブログの個別記事ページなら記事本体の artcile 要素がふさわしいでしょう:

<article role="main" class="content">
  <header class="articleHeader">
    <h1>...</h1>
    <time pubdate datetime="...">...</time>
  </header>
  <div class="articleContent">
    ...
  </div>
</article>

以上、主要な Landmark ロールについて簡単な例を挙げてみました。このように HTML のソースコードにちょっと手を加えるだけで、アクセシビリティの強化が図れるだけでなく、たとえばサイトのヘッダには記事のヘッダにはない特別なセマンティクスを与えたように、マークアップをより明確にすることができるのです。

というわけで、HTML5 でのマークアップには WAI-ARIA をぜひおすすめしたいのですが、情報がまだ少ないために導入がためらわれる場合もあると思います。また WAI-ARIA の仕様は小さいものではないので、すべてを把握しようとすると大変です。しかし、今回の例のようにページの基本的な構造に組み込むのは難しいことではないので、フロントエンドに携わる皆さんにはぜひ取り組んでみてもらいたいと思います。そしてより良い使い方についての議論などが活発になって、情報が増えるといいですよね。実際、僕もまだ理解していない部分ばかりですし。たとえば、HTML5 の nav 要素と WAI-ARIA の navigation ロールなど、意味のかぶるものをどう捉えるべきかとか。

最後に今回参考にしたリソースをまとめておきます。まず W3C の文書ですが、技術仕様 WAI-ARIA 1.0 のほか、いくつかの関連文書が公開されています:

加えて上記仕様の邦訳とそのほかにいくつか。とくに Opera の Gez Lemon 氏の記事は WAI-ARIA を今すぐ使い始めるべきとを強くアピールしてくれていて好きです。「Aria のロールやプロパティを追加すると、HTML 4.01 や XHTML 1.0 でバリデートしない。しかしそれでもよいのだ」とか「ARIA を使うことにデメリットは何もない」とか:

Web サイトのスマートフォン最適化: UA 判別篇

2010-08-11T00:00:00Z

iPhone 買いました。iPhone 4。はじめてのスマートフォンですよ。

で、この機会にこのサイトのスマートフォン最適化を図ろうと考えたわけです。今までなにもしてなかったので。しかし恥ずかしながらスマートフォン向けのサイトを作った経験がなかったので、どこから手をつけたものかわからない。そこで、とりあえず参考になりそうなネタを探そうと「wordpress iphone 最適化」あたりでググってみたところ (このサイトは WordPress で作ってます)、どうも WPtouch iPhone Theme というプラグインが人気らしい。このプラグインは有効にするだけで WordPress サイトをスマートフォン向けに最適化してくれる便利なもので、採用してるサイトもよく見かけます。

でもプラグインをそのまま導入したんじゃ面白くない。やっぱテーマは自分でいじりたいし。となると、とりあえず知りたいのは「スマートフォンからのアクセスをどのように判別しているのか」または「スマートフォン向けのコンテントやスタイルをどのように振り分けているのか」といったところで、そこらへんがわかればあとはいつものテーマ作りの手法でどうにかなるだろうと考えまして、とりあえずダウンロードしてソースコードを覗いてみたんです。あわよくば自前のテーマの参考にしようと。すると wptouch.php というファイルに以下のような箇所を見つけました:

<?php
  $useragents = array(
    'iPhone',         // Apple iPhone
    'iPod',           // Apple iPod touch
    'Android',        // 1.5+ Android
    'dream',          // Pre 1.5 Android
    'CUPCAKE',        // 1.5+ Android
    'blackberry9500', // Storm
    'blackberry9530', // Storm
    'blackberry9520', // Storm v2
    'blackberry9550', // Storm v2
    'blackberry9800', // Torch
    'webOS',          // Palm Pre Experimental
    'incognito',      // Other iPhone browser
    'webmate'         // Other iPhone browser
  );
?>

これはどこからどう見てもスマートフォン判別用の文字列 (の配列)。どうやらこれを HTTP ヘッダの User-Agent と突き合わせて、スマートフォンからのアクセスを判別しているらしい。そうとわかればあとは簡単で、自作テーマの functions.php にこんな関数を書いてみました:

<?php
  // Thanks to BraveNewCode's WPtouch iPhone Theme for the UA list.
  // (http://wordpress.org/extend/plugins/wptouch/)
  function is_mobile () {
    $useragents = array(
      'iPhone',         // Apple iPhone
      'iPod',           // Apple iPod touch
      'Android',        // 1.5+ Android
      'dream',          // Pre 1.5 Android
      'CUPCAKE',        // 1.5+ Android
      'blackberry9500', // Storm
      'blackberry9530', // Storm
      'blackberry9520', // Storm v2
      'blackberry9550', // Storm v2
      'blackberry9800', // Torch
      'webOS',          // Palm Pre Experimental
      'incognito',      // Other iPhone browser
      'webmate'         // Other iPhone browser
    );
    $pattern = '/'.implode('|', $useragents).'/i';
    return preg_match($pattern, $_SERVER['HTTP_USER_AGENT']);
  }
?>

この is_mobile() 関数でやっているのは、

まず想定されるスマートフォンを判別するための文字列の配列を作り、
それを正規表現パターンに変換して、
HTTP ヘッダの User-Agent にマッチすれば true を返す、

といったところです。これで、is_mobile() を条件分岐タグとしてテンプレートで使うことができます。たとえばスマートフォン専用の CSS を読み込ませる場合はこうです:

<?php if (is_mobile()) { ?>
<link rel="stylesheet" type="text/css" href="/css/mobile.css" />
<?php } ?>

「スマートフォン以外の場合にサイドバーを読み込む」ならこう:

<?php
  if (!is_mobile()) {
    get_sidebar();
  }
?>

なお同様の判別は JavaScript でも可能です。スマートフォン用 CSS の適用はこんな感じでできます:

// Thanks to BraveNewCode's WPtouch iPhone Theme for the UA list.
// (http://wordpress.org/extend/plugins/wptouch/)
function is_mobile () {
  var useragents = [
    'iPhone',         // Apple iPhone
    'iPod',           // Apple iPod touch
    'Android',        // 1.5+ Android
    'dream',          // Pre 1.5 Android
    'CUPCAKE',        // 1.5+ Android
    'blackberry9500', // Storm
    'blackberry9530', // Storm
    'blackberry9520', // Storm v2
    'blackberry9550', // Storm v2
    'blackberry9800', // Torch
    'webOS',          // Palm Pre Experimental
    'incognito',      // Other iPhone browser
    'webmate'         // Other iPhone browser
  ];
  var pattern = new RegExp(useragents.join('|'), 'i');
  return pattern.test(navigator.userAgent);
}
if (is_mobile()) {
  var link = document.createElement('link');
  link.rel = 'stylesheet';
  link.type = 'text/css';
  link.href = '/css/mobile.css';
  document.getElementsByTagName('head')[0].appendChild(link);
}

蛇足ながら、上記 if 文の link 要素を生成する部分は、jQuery なら以下のように書けますね:

$(function () {
  if (is_mobile()) {
    $('<link/>').attr({
      rel: 'stylesheet',
      type: 'text/css',
      href: '/css/mobile.css'
    }).appendTo('head');
  }
});

しかし、ここまで長々と書いといてなんですが、こういった UA 判別のアプローチって、実際のところどうなんでしょうね? 判別のために文字列のリストを用意するっていう部分が、どうもいまいちなんじゃないかって気がするんですよね。たとえば、今後出てくるであろう新しいスマートフォンに対応しようとすると、このリストを永遠にメンテナンスし続けなきゃなんないじゃないですか。実際、つい先日も WPtouch iPhone Theme のアップデートで新しい BlackBerry が 3 つも追加されてたし。

コンテントを出し分けたり別の URL へリダイレクトしたりしようとすると、やはり今回のような UA 検出が必要かもしれませんが、もしスマートフォンを判別する目的がスタイルの振り分けなら、やっぱメディアクエリーを使うのが王道なのかなと思い始めてます。というわけで、この続きは「メディアクエリー篇」で…

search 型 input 要素のスタイルをリセット

2010-08-13T00:00:00Z

HTML5 では、input 要素の type 属性に search という検索フィールドのための値が使えます。現時点ではこの search タイプをサポートしているのは Safari と Chrome のみなのですが、これらの対応ブラウザでは、入力したテキストをキャンセルするボタンが表示され、Mac ではフィールドが角丸になります。

しかし、Safari と Chrome でこの search タイプの input を CSS でスタイリングしようとしてもほとんどコントロールできず、ブラウザのデフォルトでレンダリングされてしまいます。font、padding、border、background といったごく基本的なプロパティがことごとく無効。これをなんとかリセットし、text タイプと同様にスタイリングできるようにもっていくのはけっこう面倒で、以下のようなコードが必要です:

/* Reset input[type="search"] */
input[type="search"] {
  -webkit-appearance: textfield;
  -webkit-box-sizing: content-box;
}
input[type="search"]:focus {
  outline-offset: -2px;
}
input[type="search"]::-webkit-search-decoration {
  display: none;
}

順に説明すると、まず -webkit-appearance という、コントロールの外観を決めるプロパティで searchfield というデフォルト値が設定されているので、textfield 値で上書き。これで基本的なプロパティは制御が可能になります。また、-webkit-box-sizing プロパティが border-box になっているので、text タイプと同じ content-box にしておきます。

この段階でほとんど text タイプと同じスタイルになるのですが、よく見るとまだ細かな違いがあります。

まず、フォーカス時に表示されるアウトラインと要素の間に微妙な隙間があります。これは outline-offset で制御が可能で、-2px にすると text タイプと同じになるようです。

もうひとつ、入力領域の左側に padding プロパティではコントロールできない余白が発生します。これはどうやら ::-webkit-search-decoration という擬似要素のようで、デフォルトでは以下のような指定になっています:

input[type="search"]::-webkit-search-decoration {
  -webkit-appearance: searchfield-decoration;
  display: inline-block;
}

正直、どういう意味を持つ要素なのかいまいちよくわからないのですが、ともあれこれを display: none; で非表示にすれば余白はなくなります。

::-webkit-search-decoration 擬似要素は results 属性という Apple 独自の拡張が関係しています。results 属性は search 型 input 要素の検索履歴を保存し入力候補としてリストアップするためのもので、値として履歴の表示件数を数値で指定します (<input type="search" results="10">)。Safari でしか利用できませんが、指定すると虫眼鏡と下向き三角形のアイコンが表示され、履歴を参照できるようになります。

::-webkit-search-decoration 擬似要素はこのアイコンまわりのスタイルを指定するものらしく、そのため results 属性を指定している場合は非表示にできません。

なお、この ::-webkit-search-decoration 擬似要素については forestk さんのご指摘をもとに追記しました。ありがとうございます。

以上でようやく search タイプのスタイルがリセットできます。あとは text タイプと同様のスタイリングが可能なはずです。デモを用意したので、Mac の Safari か Chrome で確認してみてください。

HTML5 のテーブル関連要素

2010-11-02T00:00:00Z

HTML5 のテーブル関連要素の仕様は HTML 4.01 から変更されている部分がけっこうあるようなので、変更点を簡単にまとめてみました。なお本稿での HTML5 の仕様は 2010 年 10 月 19 日付 W3C 草案を参照しています。

table 要素はテーブルの内容を説明するための summary 属性を持てるが、代替手段を用いることが推奨される。たとえば表の前にテキストを配置したり、caption 要素や figcaption 要素を用いたりなど。
caption 要素の内容モデルは Flow content なので、ほとんどの要素を含むことができる。たとえば p とか ul とか。ただし table 要素を子孫に含んではダメ。
col 要素は span 属性を持たない colgroup 要素の子要素でなければならない。つまり table の直下に置いてはダメで、必ず colgroup の中に置く必要がある。
tbody 要素は省略できる。XHTML 1.0 といっしょ。
tfoot 要素は tbody 要素または tr 要素のうしろに出現してもよい。つまり、HTML 4.01 では thead → tfoot → tbody の順でなければいけなかったのが、thead → tbody → tfoot もアリ。ただし、同じ table 要素内に複数あってはダメ。
td 要素は scope 属性を持てない。同属性を持てるのは th 要素だけ。
td 要素と th 要素の abbr 属性と axis 属性は廃止。仕様では代替手段が提案されており、abbr 属性は「セルの内容を明白かつ簡潔にすべし、より詳細なテキストを含めるには title 属性を使え」、axis 属性は「対応する th 要素の scope 属性を使え」としている。

以前に書いた dl 要素もそうですが、今までおなじみの要素でも HTML5 で仕様が再定義されていることがあります。新しい要素とか廃止されたフィーチャーとかの大きな変更は HTML5 differences from HTML4 (邦訳: HTML5 における HTML4 からの変更点) などにまとめられているのでわかりやすいですが、たとえば本稿で取り上げた col/colgroup 要素みたいに地味な変更は仕様書を読んでいても気づきにくいので注意が必要ですね。

PHP で著作権表示の年を自動更新

2010-12-30T00:00:00Z

PHP を使ってサイトの著作権表示 (コピーライト) の年を自動で更新したいとき、よく用いられるのが以下のようなコードです:

&#169; 2001–<?php echo date('Y'); ?> Example.com

&#169; <?php
  $then = 2010; // サイトの公開年
  $now = date('Y');
  if ($then < $now) {
    echo $then.'–'.$now;
  } else {
    echo $then;
  }
?> Example.com

サイトの公開年 ($then) と現在の年 ($now) を比較して出力を分岐させるわけです。もし WordPress なら、以下のように関数を functions.php に書いておいてもいいかもしれません:

function get_copyright_date ($then) {
  $now = date('Y');
  if ($then < $now) {
    return $then.'–'.$now;
  } else {
    return $then;
  }
}

WordPress テンプレート内で公開年を引数にして使います:

&#169; <?php echo get_copyright_date(2010); ?> Example.com

著作権表示自体の是非はさておき。

百景

2011-01-02T00:00:00Z

百景という、テレビ・舞台の美術やマンションギャラリーなどの企画・設計・制作を手がけるデザイン会社の Web サイト作りをお手伝いしました。私がひとりでデザインから実装まですべて手がけたのは、自分の個人サイト以外でははじめてです。

クライアントは設立して 1 年、従業員 5 名の会社で、今まで Web サイトを持っていませんでした。そのため、私が今までの仕事でおもに担当してきたフロントエンド部分だけでなく、クライアントとの打ち合わせをはじめ、ドメインやサーバの手配、情報設計、ライティングなど、Web サイト作りの過程をひととおり経験することができました。

Web デザインの現場では、まずヴィジュアル・デザインのモックアップ (カンプ) を Photoshop や Fireworks で作り、それをクライアントに見せてゴーサインをもらい、そしてフロントエンドの実装に入る、という流れが一般的です。ですが今回のプロジェクトでは、カンプを作ってクライアントに見せることはせず、実際に HTML と CSS と JavaScript で Web ページを作るところからはじめる、というアプローチを採りました。クライアントにはすべてをブラウザで確認してもらうわけです。そもそもデザインがシンプルだったからというのもあるかもしれませんが、ワークフローとしてうまくいったと思います。

デザイン面では、ロゴがすでにあったので、そのイメージを活かすよう、タイポグラフィを中心に据えてシンプルにまとめることを心がけました。一部には Google Fonts API を利用して Web フォントを埋め込んでいます。グローバルナビゲーションに Reenie Beanie、見出しに Josefin Sans という、いずれも Google Fonts で提供されているフォントです。

マークアップは HTML5 です。canvas や video などの派手なフィーチャーはありませんが、HTML5 ならではの要素として、コンタクト情報に Microdata を組み込んでいます。

border-radius など CSS3 のフィーチャーもいくつか採用しています。クライアントに対しては、たとえば「IE だとここのボタンの角が丸くなりません」などいくつか具体例を挙げて説明し、環境によって見え方が異なるという点を理解していただきました。

というわけで、かなり好きなようにやらせていただいたサイトです。百景のみなさん、どうもありがとうございました。

HTML5 のカスタムデータ属性を jQuery プラグインのオプションとして使う

2011-01-10T00:00:00Z

HTML5 ではマークアップにカスタムデータ属性を埋め込むことができますが、これを jQuery プラグインのオプションとして利用する方法について考えてみました。なお、ここでやっていることと同様のことが『jQuery クックブック』の「レシピ 12.7」に書かれていたので参考にしています。

まず、従来の典型的な jQuery プラグインでのオプションの扱い方は、オプションをオブジェクトとして定義し、そこに適切な適当なデフォルト値を与え、メソッド呼び出しの際に必要に応じて上書きする、というものです:

(function ($) {

  $.fn.myPlugin = function (options) {

    // デフォルトのオプションをメソッド呼び出し時の指定で上書き
    var opts = $.extend({}, $.fn.myPlugin.defaults, options);

    return this.each(function () {
      // 関数の本体
    });

  };

  // デフォルトのオプションを設定
  $.fn.myPlugin.defaults = {
    width:  160,
    speed:  'fast',
    repeat: true
  };

  $(function () {

    // メソッドの呼び出し時にオプションのうち 1 つを上書き
    $('.myClass').myPlugin({
      width: 320
    });

  });

})(jQuery);

$.extend() を使って空のオブジェクト ({}) をデフォルトオプションのオブジェクト ($.fn.myPlugin.defaults) で上書き (拡張) し、さらにメソッドを呼び出す際に引数 (options) で上書きできるようにしています。こうすることで、メソッド呼び出し時に必要なオプションだけを指定してあとはデフォルトのまま、といったことが可能です。上記の例ではメソッド呼び出し時にオプション width を上書きしているので、関数の中で opts.width は 320 という値に書き替えられています。

こういったプラグインに HTML5 のカスタムデータ属性を絡めるにはどうするか。具体的には、メソッドに渡すオプションとして、デフォルトを継承しつつ、メソッド呼び出し時に指定でき、さらにマークアップのカスタムデータ属性で上書きできるようにするにはどうすればいいか。

例として、Twitter の API を使って複数のアカウントそれぞれの Tweet を数件ずつを出力するようなプラグインを考えてみます。それにはオプションとして Twitter のアカウント名や表示件数を指定できることが必要になりますが、アカウント名はマークアップにカスタムデータ属性として埋め込み、表示件数はメソッド呼び出し時に指定できるようにしてみます:

(function ($) {

  $.fn.loadTweets = function (options) {

    // デフォルトのオプションをメソッド呼び出し時のオプションで上書き *1
    options = $.extend({}, $.fn.loadTweets.defaults, options);

    return this.each(function () {
      var $this = $(this);

      // メソッドを呼び出す要素ごとにカスタムデータ属性の値を取得 *2
      var customData = {
        screen_name: $this.data('twitter-screen-name'),
        count:       $this.data('twitter-count'),
        include_rts: $this.data('twitter-include-rts')
      };

      // *1 を *2 で上書き
      var opts = $.extend({}, options, customData);

    });

  };

  // デフォルトのオプションを設定
  $.fn.loadTweets.defaults = {
    count:       10,
    include_rts: true
  };

  $(function () {

    // クラス .tweets を持つ要素ごとに loadTweets() メソッドを呼び出し
    $('.tweets').loadTweets({
      count: 4
    });

  });

})(jQuery);

<!-- 各要素のカスタムデータ属性にオプションを指定 -->
<div class="tweets" data-twitter-screen-name="BarackObama"></div>
<div class="tweets" data-twitter-screen-name="DalaiLama"></div>

まずデフォルトのオプションをメソッド呼び出し時の引数に上書きし、さらに要素ごとにカスタムデータ属性の値で上書きしています。つまり同じオプション項目について、マークアップのカスタムデータ属性 → メソッド呼び出し時の引数 → デフォルト、という優先順位になるわけです。またメソッド呼び出し時の引数同様、カスタムデータ属性は必要な項目のみ指定することができます。

なお、上記のようにカスタムデータ属性の値を data() メソッドで取得できるのは jQuery 1.4.3 以降です。それ以前のバージョンの場合は $this.attr('data-twitter-screen-name') などとする必要があります。

Sass でもう一度 CSS を楽しく!

2011-03-07T00:00:00Z

僕もようやく Sass をはじめました。評判どおり、ヤバいです。CSS を書くすべての人に習得してほしいとすら思います。とくに、最近 CSS を書いていてもつまらなかったり、設計に行き詰まりを感じたりしている人は、迷わず Sass を試してみるべきです。Sass のサイトには “Sass makes CSS fun again”—「Sass でもう一度 CSS を楽しく」というフレーズが掲げられていますが、ハッタリではありません。

しかし、実際に Sass を導入するのは敷居が高いと感じる人も多いのではないかと思います。コマンドラインとかよくわからん、独自構文の学習コストが気になる、実際に仕事で使えるのか疑問…など。

そこでこの記事では、僕が Sass をはじめるにあたって感じていた不安などをもとに、「Sass は難しくないよ!」というアピールを試みます。少しでも Sass 導入の障壁を取り除く助けになればうれしいです。

はじめに

そもそも Sass とはなにか、Sass のどこがすごいのか、といったことを知るには以下のリソースが最適です。まずチェックしてみてください。必見・必読です:

インストール

さて、いざ Sass を試してみようと思ってググってみたものの、多くの記事は「コマンドプロンプトを起動して…」とか「ターミナルに以下のコマンドを…」みたいなところからはじまっていて戸惑った人も多いのではないでしょうか。しかも「まず Ruby をインストールし…」とまるで馴染みのないプログラミング言語まで出てくる始末。多くの非プログラマにとって、コマンドラインを操作するあの「黒い画面」は馴染みがなく、とっつきにくいものだと思います。

しかし、「黒い画面」は Sass をインストールするときと作業に入るときにほんの少しのコマンドを打ち込むだけで、Sass のコード自体はいつもの使い慣れたエディタで編集できます。また Ruby はインストール時にちょっとだけ意識しなければいけませんが、以降はまったく気にする必要がないので、知識がなくても問題ありません。

まず、「黒い画面」がはじめてで怖いという人は是非この記事を読んでみてください。僕はこれで克服しました:

Webデザイナーの為の「本当は怖くない」”黒い画面”入門 Part.01 | FJORD, LLC（合同会社フィヨルド）

そして Windows/Mac へのインストールや編集の準備はすごく簡単です。手順は以下の記事がわかりやすいと思います:

構文

「Sass は CSS を拡張するメタ言語」などと言われるとややこしそうな印象を受けますがそんなことはありません。Sass の記法である SCSS (Sassy CSS) 構文は CSS と互換性があります。そのため、たとえばすでに書いた style.css という CSS ファイルを style.**scss** と拡張子を変えるだけで Sass として機能します。つまり Sass の構文を覚えないと何もできないということはなく、書き慣れた CSS はそのままに、少しずつ「Sass 化」していくことができるのです。

それに、入れ子、変数、ミックスインといった Sass 構文のフィーチャーは、どれも CSS をひととおり習得しているなら直感的に理解できるもので、触っているうちにすぐに書けるようになると思います。

以下のリソースは公式のリファレンスです。いきなりすべてを使いこなすことは難しいしその必要もないですが、ざっと見渡しただけでも Sass がいかにパワフルか伝わると思います:

チームでの導入

そして、Sass 導入における最大の難関は、チームで CSS を編集するプロジェクトに導入すること—つまり「会社で使えるかどうか」ではないでしょうか。

これはたしかに簡単ではないと思います。複数のメンバーが CSS を編集する可能性がある場合、その全員が Sass を学ぶ必要がありますが、メンバーのスキルやモチベーションには差があるでしょうし、導入や習得のための時間を割けないこともあるでしょう。

それでも導入を検討する価値は充分にあるし、そこにトライできる環境にいる人は是非ともそうしてみてほしいです。もちろんすべてのメンバーが同等の習熟度にある必要はありません。たとえばリーダーが基本のフレームワークを作り、ほかのメンバーが必要に応じてモジュールを追加する、というような運用も通常の CSS に比べてやりやすいです。

そして、もしチームに Sass を導入することができないとしても、ひとりひとりが Sass を習得することをあきらめてほしくない、と強く願います。なぜなら、Sass のもっとも素晴らしい点は、効率化や保守性の向上より、それを学ぶことによって CSS をより構造的に捉えられるようになることだと思うからです。Sass を習得すれば、「素」の CSS を書いたりマークアップしたりするときにも必ずプラスの影響があります。

おわりに

Web のフロントエンド技術を習得する最良の方法のひとつは、優れたサイトの「ソースを見る」ことです。しかし Sass は製作者のローカルで CSS を生成するものなので、ブラウザから Sass のソースを読むことができません。そこで Sass のテクニックを学ぶために製作者どうしで情報を共有したいところなのですが、Sass についての情報はまだまだ少なく、それはなかなか容易ではないというのが現状です。

ですから皆さん、是非、Sass を使ってみてください。そしてシブいミックスインを書いて公開してください!

OOCSS の Spacing クラスのようなものを Sass で

2011-03-18T00:00:00Z

「OOCSS (Object Oriented CSS) の Spacing クラスのようなもの」というのは、よくあるこういったやつです:

/*
p,m = padding,margin
a,t,r,b,l,h,v = all,top,right,bottom,left,horizontal,vertical
*/

.pt0,  .pv0,  .pa0  { padding-top:     0px !important; }
.pr0,  .ph0,  .pa0  { padding-right:   0px !important; }
.pb0,  .pv0,  .pa0  { padding-bottom:  0px !important; }
.pl0,  .ph0,  .pa0  { padding-left:    0px !important; }

.pt10, .pv10, .pa10 { padding-top:    10px !important; }
.pr10, .ph10, .pa10 { padding-right:  10px !important; }
.pb10, .pv10, .pa10 { padding-bottom: 10px !important; }
.pl10, .ph10, .pa10 { padding-left:   10px !important; }

.pt20, .pv20, .pa20 { padding-top:    20px !important; }
...

.mt0,  .mv0,  .ma0  { margin-top:      0px !important; }
.mr0,  .mh0,  .ma0  { margin-right:    0px !important; }
.mb0,  .mv0,  .ma0  { margin-bottom:   0px !important; }
.ml0,  .mh0,  .ma0  { margin-left:     0px !important; }

.mt10, .mv10, .ma10 { margin-top:     10px !important; }
.mr10, .mh10, .ma10 { margin-right:   10px !important; }
.mb10, .mv10, .ma10 { margin-bottom:  10px !important; }
.ml10, .mh10, .ma10 { margin-left:    10px !important; }

.mt20, .mv20, .ma20 { margin-top:     20px !important; }
...

こんなふうに上下左右の padding と margin を定義したクラスをあらかじめ用意しておき、必要に応じて HTML にクラスを付与して余白をコントロールしようというわけです。

これの扱いにくい点としては、用意したけど実際には使わない無駄なクラスが発生してしまうことや、新たなクラスを追加する際の編集が面倒なことなどが挙げられます。

で、この手法そのものの是非とかはとりあえず置いといて、Sass を使うとこういったコードを効率的に生成できますよ、という話。

/* SCSS */

@mixin spacing($size) {
  $type: 'p';
  $prop: 'padding';
  @for $i from 1 through 2 {
    @if $i > 1 {
      $type: 'm';
      $prop: 'margin';
    }
    .#{$type}t#{$size} { #{$prop}-top:    #{$size}px !important; }
    .#{$type}r#{$size} { #{$prop}-right:  #{$size}px !important; }
    .#{$type}b#{$size} { #{$prop}-bottom: #{$size}px !important; }
    .#{$type}l#{$size} { #{$prop}-left:   #{$size}px !important; }
    .#{$type}v#{$size},
    .#{$type}a#{$size} {
      @extend .#{$type}t#{$size};
      @extend .#{$type}b#{$size};
    }
    .#{$type}h#{$size},
    .#{$type}a#{$size} {
      @extend .#{$type}r#{$size};
      @extend .#{$type}l#{$size};
    }
  }
}

なんか無駄に仰々しい気もしますが、こんな感じのミックスインを定義しておいて、あとは必要な余白のサイズを引数にして @include します:

/* SCSS */

@include spacing(0);
@include spacing(10);
@include spacing(20);

これをコンパイルすると以下の CSS が生成されます (改行やスペースは読みやすいようにいじってます):

/* CSS */

.pt0,  .pv0,  .pa0  { padding-top:     0px !important; }
.pr0,  .ph0,  .pa0  { padding-right:   0px !important; }
.pb0,  .pv0,  .pa0  { padding-bottom:  0px !important; }
.pl0,  .ph0,  .pa0  { padding-left:    0px !important; }

.mt0,  .mv0,  .ma0  { margin-top:      0px !important; }
.mr0,  .mh0,  .ma0  { margin-right:    0px !important; }
.mb0,  .mv0,  .ma0  { margin-bottom:   0px !important; }
.ml0,  .mh0,  .ma0  { margin-left:     0px !important; }

.pt10, .pv10, .pa10 { padding-top:    10px !important; }
.pr10, .ph10, .pa10 { padding-right:  10px !important; }
.pb10, .pv10, .pa10 { padding-bottom: 10px !important; }
.pl10, .ph10, .pa10 { padding-left:   10px !important; }

.mt10, .mv10, .ma10 { margin-top:     10px !important; }
.mr10, .mh10, .ma10 { margin-right:   10px !important; }
.mb10, .mv10, .ma10 { margin-bottom:  10px !important; }
.ml10, .mh10, .ma10 { margin-left:    10px !important; }

.pt20, .pv20, .pa20 { padding-top:    20px !important; }
.pr20, .ph20, .pa20 { padding-right:  20px !important; }
.pb20, .pv20, .pa20 { padding-bottom: 20px !important; }
.pl20, .ph20, .pa20 { padding-left:   20px !important; }

.mt20, .mv20, .ma20 { margin-top:     20px !important; }
.mr20, .mh20, .ma20 { margin-right:   20px !important; }
.mb20, .mv20, .ma20 { margin-bottom:  20px !important; }
.ml20, .mh20, .ma20 { margin-left:    20px !important; }

たとえばもし 25px のがあとから必要になったら、@include spacing(25); と 1 行加えるだけ。これならあらかじめ大量のクラスを用意せずに必要なクラスだけを作るのが容易だし、無駄を少なく抑えられます。プロジェクト間で使い回すにもミックスインだけを持っていけばいいので楽。

あと、この手の CSS にはある種の後ろめたさのようなものがつきまとうものですが、それが Sass によって少しは軽減されるというか…

Sass の @import ルール

2011-03-28T00:00:00Z

Sass の @import ルールは CSS ファイルだけではなく Sass ファイルもインポートできる。この機能は地味に見えるが、実際に使ってみるとものすごく便利。とくに、ミックスインをモジュールとしてファイルに分割しておき、必要に応じて呼び出すような場面でその便利さを痛感する。

例として、opacity プロパティのクロスブラウザ対応コードのミックスインを考えてみる。まず以下のようなコード片を _opacity.scss というファイル名で用意しておく:

// _opacity.scss

@mixin opacity($alphavalue) {
    opacity: $alphavalue;
    -ms-filter: "progid:DXImageTransform.Microsoft.Alpha(Opacity=#{ $alphavalue * 100 })"; // for IE 8
    filter: alpha(opacity=#{ $alphavalue * 100 }); // for IE 5-7
}

こういったモジュールとしてインポートして使う Sass ファイルは、それ単独で CSS にコンパイルする必要がない。そんなときはファイル名の先頭に _ (アンダースコア) をつけておく。そうすると、ディレクトリごと --watch していてもそのファイルは単独ではコンパイルされない。

で、このファイルをメインの Sass ファイルからインポートすれば、opacity ミックスインを利用できる。なおその際、ファイルの拡張子と先頭のアンダースコアは省略可能:

// style.scss

@import "opacity"; // _opacity.scss をインポート

.opaque {
    @include opacity(0.8); // opacity ミックスインを参照
}

最後にこのメインの Sass ファイルをコンパイルすれば以下のような CSS が出来上がる:

/* style.css */

.opaque {
    opacity: 0.8;
    -ms-filter: "progid:DXImageTransform.Microsoft.Alpha(Opacity=80)";
    filter: alpha(opacity=80);
}

ちなみに、ひとつの @import ルールで複数の Sass ファイルをいっぺんにインポートすることもできる:

@import "reset", "fonts", "css3/border-radius";

どれだけ細かくファイルを分割しても最終的に 1 枚の CSS ファイルにコンパイルできるので、CSS の @import ルールとは違って HTTP リクエストの増大を気にする必要はない。

また、CSS の @import ルールは @charset ルールをのぞくすべてのルールに先行していなければならないが、Sass の @import は場所を選ばない。たとえば、CSS の末尾に記述されることの多い印刷用スタイルやモバイル用スタイルなどを別ファイルとして用意して Sass の最後にインポートする、といったことも容易だ。

このように、Sass は CSS の @import ルールが抱える問題の多くを解決し、スタイルシートのより柔軟な設計・開発・管理をサポートしてくれる。

Firefox 4 のデフォルト CSS

2011-04-12T00:00:00Z

Firefox 4 のデフォルト CSS は、以下のような URL をロケーションバーに入力すればブラウザから確認できる (ちなみに 3.6 とはパスが異なる):

resource://gre-resources/html.css
resource://gre-resources/forms.css
resource://gre-resources/quirk.css

resource://gre-resources/ を見るとほかにもいろいろある。内容は全部は見てないけど、HTML5 の新要素に対する指定や :-moz-any() セレクタやなんかが追加されてて、3.6 からけっこう変わってた。

要素をスクロールに追従させる jQuery プラグイン

2011-05-22T00:00:00Z

Apple Store のサイドバーのように、要素をウィンドウのスクロールに追従させる jQuery プラグイン、jQuery Floating Widget を作りました。説明が難しいので、まずはデモをご覧ください!

jQuery Floating Widget plugin demo

このアイデア自体は新しいものではなくて、たとえば以下の記事で詳しく紹介されています:

Fixed Floating Elements | jQuery for Designers - Tutorials and screencasts

この方法で基本的にうまくいくんですが、フッターの高さがある程度あると、下までスクロールしたときに該当要素がフッター領域に食い込んでしまう場合があります。そこで、上記記事での実装を参考に、要素の「動ける範囲」を制限するための処理などを加えたものを考えてみました。

例として、フロートによる 2 カラムのレイアウトで、サイドバーをスクロールに追従させる場合をもとに解説します。マークアップと基本的なスタイルは以下のとおりです:

<div class="header"> . . . </div>

<div class="content-wrapper">

    <div class="content"> . . . </div>

    <div class="sidebar">
        <div class="floating-widget">
            <!-- この要素がスクロールについてきます -->
        </div>
    </div>

</div>

<div class="footer"> . . . </div>

.content-wrapper {
    position: relative;
    *zoom: 1;
}
.content-wrapper:after {
    display: block;
    clear: both;
    height: 0.01px;
    content: "";
}
.content {
    float: left;
    width: 512px;
}
.sidebar {
    float: right;
    width: 256px;
}
.floating-widget {
    margin: 50px 0;
}

該当要素の動ける範囲を制限する祖先要素 (div.content-wrapper) には、スクロールが下まで来たときに該当要素を絶対配置するための position: relative; と、高さを取得するための clearfix が必要です。

プラグイン本体とその呼び出し方は以下のとおりです:

// プラグイン
(function ($) {
    $.fn.floatingWidget = function () {
        return this.each(function () {
            var $this = $(this),
                $parent = $this.offsetParent(),
                $window = $(window),
                top = $this.offset().top - parseFloat($this.css('marginTop').replace(/auto/, 0)),
                bottom = $parent.offset().top + $parent.height() - $this.outerHeight(true),
                floatingClass = 'floating',
                pinnedBottomClass = 'pinned-bottom';
            if ($parent.height() > $this.outerHeight(true)) {
                $window.scroll(function () {
                    var y = $window.scrollTop();
                    if (y > top) {
                        $this.addClass(floatingClass);
                        if (y > bottom) {
                            $this.removeClass(floatingClass).addClass(pinnedBottomClass);
                        } else {
                            $this.removeClass(pinnedBottomClass);
                        }
                    } else {
                        $this.removeClass(floatingClass);
                    }
                });
            }
        });
    };
})(jQuery);

// 呼び出し
$(function () {
    $('.floating-widget').floatingWidget();
});

ウィンドウのスクロール位置を見て、要素がスクロールに追従している状態 (.floating) と祖先要素の下端にとどまっている状態 (.pinned-bottom) というそれぞれの状態に応じてマークアップのクラスを書き換えています。また最初に該当要素と祖先要素の高さを比較し、サイドバーの高さがコンテンツを超えるような場合はなにも起こりません。

ちなみに jQuery の offsetParent() は position プロパティが static 以外である直近の祖先要素を返すメソッドです。また outerHeight() メソッドはパディングとボーダーを含む要素の高さを返しますが、引数に true を渡すとさらにマージンも含めた高さを返します。

最後に、.floating と .pinned-bottom というクラスに対してスタイルを追加します:

.floating-widget.floating {
    position: fixed;
    top: 0;
}
.floating-widget.pinned-bottom {
    position: absolute;
    bottom: 0;
    _position: static;
}

スクロールのたびにスクリプトでスタイルを書き換える方法もありますが、それだと動きがカクカクしがちなので、JavaScript の仕事は位置によってマークアップのクラスを変更するだけにして、配置は CSS にまかせるというアプローチを採りました。

position: fixed; を解釈しない IE6 ではスクロールに追従しませんが、下まで来ると position: absolute; が適用されて要素が突然移動してしまうので、ハックで static を上書きしています。

ソースコードは以下からどうぞ。恥ずかしながら GitHub デビューしました!

terkel/jquery-floating-widget - GitHub

jQuery Last.fm Profile Plugin

2011-07-10T00:00:00Z

Last.fm の API を利用して、ユーザのプロファイルから最近聴いた曲やもっとも再生回数の多いアルバムやなんかを取得して表示する jQuery プラグイン。自分のサイト用に書いて使ってたんだけど、一部を書き直したり機能を追加したりして GitHub に公開してみました。まずはデモをどうぞ:

Demo: jQuery Last.fm Profile Plugin

使い方。まず jQuery と一緒にプラグインをインクルードしてください。jQuery のバージョンは 1.4.3 以降である必要があります:

<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.6.2/jquery.min.js"></script>
<script src="/path/to/jquery.lastfm-profile.js"></script>

データを表示させたい箇所には以下のように適当な要素を置いてください:

<div id="my-favourite-artists"></div>

そして loadLastfmProfile() メソッドを呼び出します:

$(function () {
    $('#my-favourite-artists').loadLastfmProfile({
        user:   'terkeljp',
        method: 'TopArtists',
        period: 'overall'
    });
});

オプションはスクリプト呼び出し時に指定するだけではなく、HTML5 のカスタムデータ属性としてマークアップに仕込むこともできます:

<div id="my-favourite-artists"
    data-lastfm-user="terkeljp"
    data-lastfm-method="TopArtists"
    data-lastfm-period="overall"></div>

指定できるオプションは以下のとおりです:

user (data-lastfm-user): データを取得する Last.fm ユーザ名。初期値は 'LAST.HQ'
method (data-lastfm-method): 取得するデータの種類。'TopArtists' (再生回数の多いアーティスト)、'TopAlbums' (再生回数の多いアルバム)、'TopTracks' (再生回数の多い楽曲)、'RecentTracks' (最近再生した楽曲)、'NowPlaying' (現在再生中の楽曲) のうちいずれかを指定。初期値は 'TopAlbums'
period (data-lastfm-period): 取得するデータの集計期間。'7day'、'3month'、'6month'、'12month'、'overall' のうちいずれかを指定。初期値は '7day'
limit (data-lastfm-limit): 取得するデータの件数。初期値は 10
image (data-lastfm-image): 各アイテムの画像を表示するかどうか。初期値は true
imageSize (data-lastfm-image-size): 各アイテムの取得する画像のサイズ。'small' (幅 34px)、'medium' (幅 64px)、'large' (幅 126px) のうちいずれかを指定。初期値は 'medium'
imageSquare (data-lastfm-image-square): 各アイテムの画像を正方形で取得したい場合は true を指定。初期値は true
text (data-lastfm-text): 各アイテムのタイトルやアーティスト名をテキストで表示するかどうか。false を指定すると画像の alt 属性とリンクの title 属性に同内容の値が入る。初期値は true
playcount (data-lastfm-playcount): 再生回数を表示するかどうか。初期値は true
loadingMessage (data-lastfm-loading-message): データの取得が完了するまでの間に表示される内容を指定。初期値は 'Loading…'
errorMessage (data-lastfm-error-message): データの取得に失敗した場合に表示される内容を指定。初期値は 'Failed to load data.'
contentBefore (data-lastfm-content-before): アイテムのリストの前に挿入する内容。初期値は '' (何も挿入されない)
contentAfter (data-lastfm-content-after): アイテムのリストの後ろに挿入する内容。初期値は '' (何も挿入されない)

プラグインのデータは以下でダウンロードできます:

terkel/jquery-lastfm-profile - GitHub

Last.fm というと最近はあまり話題にのぼることが少ない気がしますが、サイトを利用してる人は淡々とログを蓄積し続けている、みたいな印象ですかね。API はいろんなデータがいじれてけっこう楽しいですよ。

フォント変えた

2011-08-08T00:00:00Z

このサイトの基本のフォントファミリーを変えてみた。

/* 変更前 */
body {
    font-family: "Helvetica Neue",
                 "Helvetica",
                 "Arial",
                 "Hiragino Kaku Gothic Pro",
                 "ヒラギノ角ゴ Pro W3",
                 "メイリオ",
                 sans-serif;
}

/* 変更後 */
body {
    font-family: "Lucida Grande",
                 "Hiragino Kaku Gothic Pro",
                 "ヒラギノ角ゴ Pro W3",
                 "メイリオ",
                 "Helvetica",
                 "Verdana",
                 sans-serif;
}

ざっくり言うと、Helvetica から Lucida Grande へ、Arial からメイリオ/Verdana への変更。本文で和文と欧文が混ざってるときに、欧文部分が Helvetica/Arial だとやや詰まり気味に感じられるのが気になりだし、だったらいっそ OS のシステムフォントに合わせるような方向で、と考えてこうなった。

このへんは千差万別のフォント環境を考えはじめるとキリがないので、「Windows XP でヒラギノがインストールされてる場合」よりも「Mac でメイリオがインストールされてる場合」を重視、ぐらいのゆるいアプローチです。

Microdata + schema.org を実際に使ってみる

2011-08-30T00:00:00Z

schema.org は Google、Microsoft (Bing)、Yahoo! という Web 検索の大手 3 社が共同で取り組んでいる試みで、より構造化されたマークアップのための共有の語彙集 (vocabulary) を提供しようというものです。この schema.org の語彙を利用して、実際のマークアップに Microdata を追加する具体例をいくつか考えてみました。

schema.org の アイテム型 (item type) は階層 (hierarchy) のかたちで定義されています。型ごとに独自の プロパティ が定義され、上位の型のプロパティは下位の型に引き継がれます。最上位は Thing という汎用の型で、name、url、image、description というもっとも基本的なプロパティが定義されています。そしてその下に CreativeWork、Event、Intangible、Organization、Person、Place、Product、といった型があり、そこからそれぞれさらに詳細な型に分岐しています。schema.org を利用するには、まずこの型階層のツリー図からアイテムにふさわしい型を見つけます。

例 #1: 企業情報

最初に、いわゆる企業サイトであればほぼ必ず用意される、社名、住所、電話番号などを記した「企業情報」のコンテンツを考えてみます。サンプルとして Google の会社情報のマークアップを使わせてもらいました (一部記述を省略しています):

<div>
    <b>グーグル株式会社</b><br>
    〒106-6126<br>
    東京都港区六本木 6 丁目 10 番 1 号<br>
    六本木ヒルズ森タワー 私書箱 22 号<br>
    TEL: 03-6384-9000<br>
    FAX: 03-6384-9001
</div>

企業情報で使えそうな型を schema.org で探すと、Organization 型の派生である Corporation 型がよさそうです。これをマークアップに組み込んでみます:

<div itemscope itemtype="http://schema.org/Corporation">
    <b itemprop="name">グーグル株式会社</b><br>
    <span itemprop="address" itemscope itemtype="http://schema.org/PostalAddress">
        〒<span itemprop="postalCode">106-6126</span><br>
        <span itemprop="addressRegion">東京都</span>
        <span itemprop="addressLocality">港区</span>
        <span itemprop="streetAddress">六本木 6 丁目 10 番 1 号<br>
            六本木ヒルズ森タワー</span>
        私書箱 <span itemprop="postOfficeBoxNumber">22</span> 号
    </span><br>
    TEL: <span itemprop="telephone">03-6384-9000</span><br>
    FAX: <span itemprop="faxNumber">03-6384-9001</span>
</div>

まず itemscope 属性でアイテムを定義し、同要素の itemtype 属性で schema.org の URL を指定してアイテムの型とします。そしてデータとして表現したい項目ごとに itemprop 属性を持つ要素でマークアップしてプロパティとします。

name、telephone、faxNumber の各プロパティはそれぞれ要素の内容がそのまま値になっており、とくに難しいことはないと思います。少しややこしいのが address プロパティで、itemprop 属性を持った要素が同時に itemscope 属性を持っており、アイテムが入れ子になっています。

住所を表現する PostalAddress 型の各プロパティを日本の住所表記に当てはめるのにやや迷うところですが、だいたいこんな感じになると思います:

addressCountry: 国
postalCode: 郵便番号
addressRegion: 都道府県
addressLocality: 市区町村
streetAddress: 市区町村以降 (町・字・地番・住居表示・方書)
postOfficeBoxNumber: 私書箱番号

そのほか、企業情報で使う機会の多そうなプロパティとしては、description、url、email、foundingDate といったところでしょうか。

例 #2: ブログ記事

ブログの個別記事のための型として BlogPosting 型が用意されています:

<article itemscope itemtype="http://schema.org/BlogPosting" itemref="copyright">
    <header>
        <time pubdate datetime="2011-08-30" itemprop="datePublished">
            August 30, 2011
        </time>
        <h1 itemprop="name">
            <a href="/blog/microdata-schema-org.html" itemprop="url">
                Microdata + schema.org
            </a>
        </h1>
        <p>
            Tag(s):
            <span itemprop="keywords">
                <a href="/tag/markup">markup</a>,
                <a href="/tag/semanticweb">semanticweb</a>
            </span>
        </p>
    </header>
    <div itemprop="articleBody">
        <!-- content goes here -->
    </div>
</article>

...

<footer>
    <p id="copyright">
        &#169; 2008–2011
        <span itemprop="author" itemscope itemtype="http://schema.org/Person">
            <a href="/about/" rel="author" itemprop="url">
                <b itemprop="name">Takeru Suzuki</b>
            </a>
        </span>,
        licensed under a <a href="http://creativecommons.org/licenses/by/2.1/jp/" rel="license">Creative Commons Attribution 2.1 Japan</a>.
    </p>
</footer>

アイテム (article 要素) の itemref 属性に注目してください。itemref 属性でドキュメント内の ID を指定した場合、その要素をアイテムのデータとして追加することができます。この場合、アイテム内にはない著者情報 (itemprop="author") をスコープ外の要素 (#copyright) から取得しています。このように itemref 属性によってマークアップ構造に縛られない柔軟なデータ表現が可能で、たとえば複数のアイテムから同一のプロパティを参照するような場合などに便利です。

また、itemprop が指定された要素のほとんどはその内容 (textContent) がプロパティの値になりますが、一部の要素は異なる点にも注意が必要です (HTML Microdata - 2.4 Values)。この例では、a 要素は href 属性、time 要素は datetime がそれぞれのプロパティの値となります。

参考

最後に、Microdata と schema.org を知る上で参考になるリソースをいくつか挙げておきます:

HTML Microdata (W3C Working Draft)
Microdata: A Primer: 日本語のスライド。Microdata の基本がわかりやすく解説されています
Microdata - Dive Into HTML5: 『入門 HTML5』のオリジナルテキスト。マークアップの具体例がわかりやすいです
Extending HTML5 — Microdata | HTML5 Doctor: マークアップ例、schema.org も含む様々な語彙集やツールの紹介、関連リソースのリンク集、とたいへん充実した記事
microdata について - ウェブマスターツールヘルプ
Webmaster Tools - Rich Snippets Testing Tool: Google のテストツール
Live Microdata: テストツール。JSON 形式でデータが見られます

Google Chrome Frame: サイト管理者向けガイド

2011-08-31T00:00:00Z

2013-06-30更新: 2013 年 6 月、Googe Chrome Frame の開発終了が発表されたのを受け、新しい記事を書きました。

IE で Google Chrome と同等のレンダリングを実現するプラグイン、Google Chrome Frame が正式版になりました。ユーザはよりリッチで快適な Web 体験ができるし、サイト管理者としても事実上古い IE のシェアが減ることになって嬉しい、しかもインストールに管理者権限が不要という、ちょっといいプラグインなんですよね Chrome Frame。

とは言えユーザがインストールして使ってくれないことにははじまらないので、この Chrome Frame の利用を促進するためにサイト管理者にできることを紹介します。

ページを Chrome Frame でレンダリングさせる

まず、すでに Chrome Frame がインストールされている場合にページを Chrome Frame でレンダリングさせる方法です。HTML の head 要素内に以下の記述を加えます:

<meta http-equiv="X-UA-Compatible" content="chrome=1">

もし IE の meta スイッチを指定している場合、まとめて以下のように書きます:

<meta http-equiv="X-UA-Compatible" content="IE=Edge,chrome=1">

これで、もし Chrome Frame がインストールされていれば、そのページは Chrome Frame でレンダリングされます。

Chrome Frame のインストールを促す

次に、まだ Chrome Frame をインストールしていないユーザにインストールを促す方法です。それには Google から提供されている CFInstall.js というスクリプトを利用します:

<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/chrome-frame/1/CFInstall.min.js"></script>
<script type="text/javascript">
window.attachEvent('onload', function () {
    CFInstall.check({
        mode: 'overlay'
    });
});
</script>

このコードをページの body 要素内に記述します。その際 IE の条件コメントを利用して、IE 以外のブラウザでロードされないようにしましょう。この例では IE8 未満を対象にしていますが、プロジェクトの要件によって検討してください。ついでにホワイトスペースや改行も削除してみます:

<body>
...

<!--[if lt IE 8 ]>
<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/chrome-frame/1/CFInstall.min.js"></script>
<script type="text/javascript">window.attachEvent('onload',function(){CFInstall.check({mode:'overlay'});});</script>
<![endif]-->
</body>

スクリプトはロードされると Chrome Frame がインストールされているかどうかを判別し、もしされていなければインストールを促すダイアログを表示します。ユーザがインストールせずにダイアログを閉じた場合、以降は cookie によって同一ドメインでは表示されません (cookie の有効期限は 1 年間に設定されているようです)。

表示方法は mode オプションで指定できるようですが、この 'overlay' という値が推奨されています。ここでは最低限のオプションしか指定していませんが、そのほかの仕様についてはドキュメンテーションを参照してください。

ちなみに HTML5 Boilerplate もバージョン 2.0 でこのスクリプトを採用していますね。

以上、IE に呪いの言葉を浴びせるのもいいけどそれ以外にもできることがあるかもよ、という話でした。

CSS ルールセット構造図

2011-09-24T00:00:00Z

ごく基本的なことなんだけど、すぐに忘れてごっちゃになるので図を描いた。せっかくなので上げとく。詳しくは CSS3 module: Syntax や CSS の名前の整理 - IT戦記などを参照のこと。

WordCamp Tokyo 2011 をデザイン

2011-11-08T00:00:00Z

今年 11 月 27 日に開催される WordPress のイベント、WordCamp Tokyo 2011 にデザイナーとして参加し、ロゴやサイト、バナーなどをデザインしました。

僕はふだんの仕事ではフロントエンドエンジニアとして HTML、CSS、JavaScript を書いていることがほとんどで、ロゴなどのグラフィックデザインまで手がけることはめずらしいです。勢いで T シャツやステッカーまで作ってしまいました。

デザインのコンセプトなどについては同サイトに記事を書きました。おそらく WordCamp 史上もっとも地味なデザインではないかと思うんですが、僕の考える WordPress らしさを表現したつもりです。

もちろんイベント当日は僕も会場にいます。みなさんぜひ遊びに来てください!

WordCamp と俺

2011-11-22T00:00:00Z

いよいよこんどの日曜日に開催がせまった WordCamp Tokyo 2011。俺もデザイナーとして運営に参加しているわけですが、その運営スタッフがおのおののブログに日替わりで WordCamp についての記事を書くリレーブログなる企画があり、このたび真木さんからのバトンを受けて、いよいよ俺に順番がまわってきました。

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

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

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

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

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

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

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

Open Sans

2011-12-09T00:00:00Z

このサイトのボディの欧文フォントとして Google Web Fonts で提供されている Open Sans を使ってみることにした。Chrome ウェブストアとかで採用されてるので見たことある人も多いんじゃないでしょうか。

比較的ニュートラルだけど、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", "Hiragino Kaku Gothic ProN", "Meiryo", sans-serif;
}

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

Open Sans + ヒラギノ角ゴ ProN (Mac)

Open Sans + メイリオ (Windows)

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

Sass の @extend はどこがすごいのか

2011-12-16T00:00:00Z

この記事では Less & Sass Advent calendar 2011 の 16 日目として、Sass の @extend 機能について書いてみます。が、諸事情により締め切りを過ぎてからあわてて書いており、かなりとっ散らかったものになるであろうことをあらかじめお断りしておきます。

さて、まずは @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 の継承元をコンパイルされないようにする機能とかたしかにあるといかも

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

俺の CSS リセット: 2011 冬

2011-12-25T00:00:00Z

年末だからというわけでもないのですが、いつものサイト作りに使う CSS リセットについて見直してみました。今までもちょっとずつ手を入れてはいたのですが、今回はかなり大きく修正しています。というのも、Nicolas Gallagher と Jonathan Neal の両氏による normalize.css を知り、大きく影響を受けたからです。

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, https://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;
}

長い… 要素の分類と記述順は HTML5 の仕様書を参考にしました。以下、それぞれのパートごとにできる限り解説してみます。

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;
}

まずは HTML5 の新仕様関連で、normalize.css 丸写しです。HTML5 以前の古いブラウザ向けですね。video や audio などマルチメディア系の要素は個人的に扱った経験がないため詳しくはわからないんですが、とりあえずは display まわりを揃える程度なので、このままいってよさそうです。将来的に実装が進んだときはもうちょっと複雑な記述が必要になるのかもしれません。hidden 属性は HTML5 で新しく定義されたグローバル属性です。属性セレクタによる指定のため IE6 では非表示になりませんが。

The root element

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

次はドキュメントのルートであるところの html への指定で、ここも normalize.css まんまです。

font-size: 100% は、フォントサイズを em 単位で指定した場合に「文字サイズの変更」をおこなうとサイズが極端に変動するという IE6/7 のバグへの対応です。これはいずれかの祖先要素のフォントサイズを % 単位で指定しておくと回避できるので、こうしておけば body 以下で自由に em が使えます。

overflow-y: scroll は IE6/7 以外のブラウザ向けで、ドキュメントの高さがウィンドウより小さくても縦のスクロールバー領域を確保するというものです。

次の -webkit-text-size-adjust: 100% と -ms-text-size-adjust: 100% は iOS の文字サイズ自動アジャスト機能に対するもののようです。が、手元の iPhone で軽く検証したりググってみたりしたものの、正直よくわかっていません… とりあえず、この値を none にしてしまうのはどうもよくないらしいとか、IE Mobile がなぜか -webkit-text-size-adjust をサポートしてた (けど直った?) とか、iOS だけじゃなくてデスクトップ版 Safari にも影響があったとか、なんかややこしいらしいってことだけはわかりました。どなたかご教授いただけると嬉しいです! ここでは参考になりそうなリンクだけ並べてお茶を濁します:

Sections

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

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

body の font-family はとりあえずざっくりと指定しておいて、あとはプロジェクトごとに細かくやる (あるいはやらない) という感じ。margin はリセット。ちなみに body のマージンはデフォルトだと IE6/7 でやや大きいです。

hn は normalize.css だと HTML5 のセクショニング要素の対応として h1 { font-size: 2em; } しか指定してない (#41: Normalize headings - Issues - necolas/normalize.css - GitHub) ですが、ここでは h1 から h6 まで font-size と margin をリセットしてます。

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;
}

段落やリストなど、実際にサイトでよく使うとこですね。このへん、normalize.css ではあまりいじってないんですが、ここではけっこうリセットしてます。

まず p などブロックレベル要素の margin はリセット。ul と ol は padding も 0 に、li のマーカーもなし。normalize.css では nav 要素の子孫である場合にだけマーカーなしですが、実際問題としていわゆる普通のサイトではマーカーとして独自の画像を用意することが多いと思うので。

hr は Firefox のスタイルがちょっと例外的なので他のブラウザに合わせる方向。IE6/7 以外は上下に 0.5em の margin を持っていますが、IE6/7 では上下の余白がコントロールできないため、きっちり見た目を揃えるのが難しいです。なのであえてリセットせずそのまま残してます。

pre はまず Safari と Chrome でフォントサイズが揃わない問題への対応として font-family: monospace, sans-serif を指定。あと行が長くなったときに折り返すようにしています。

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;
}

いわゆるインライン要素。このあたりは基本的にデフォルトの font-weight や font-style をそのまま活かします。

a の outline プロパティは、Eric Meyer 氏のリセットの古い版で「ちゃんとあとから自分で定義し直してね!」っていう注釈つきで :focus { outline: 0; } となってた (のちに修正された) のがそのまま広まってしまった感があります。が、それではアクセシビリティ上の問題があるので、そのあたりを考慮したものになってます。以下、参考資料:

strong と b は Firefox や WebKit のデフォルトでは bold ではなく bolder という相対値です。つまり、<h1><b>Steve Jobs</b>: 1955–2011</h1> というマークアップで h1 の font-weight が bold (700) の場合、その中の b は 900 となるわけです (CSS Fonts Module Level 3 - 3.2 Font weight: the font-weight property)。このままでもいいんですが、予期したウェイトよりも太くなってしまうってことがけっこうありそうなので bold に揃えよう、ってことだと思いますたぶん。ウェイトがノーマルかボールドしか使えない場合がほとんどの和文フォントではあまり気にする機会がありませんが。

sub と sup は行の高さと縦位置の調整です (CSS for _{and ^{— Gist}})。

br は親要素に letter-spacing が指定されているときに連続して改行しても認識されないという IE6/7 のバグへの対応。

Embedded content

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

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

img はリンク時のボーダーを消して、IE7 で拡大縮小したときに綺麗にする、っていういつものやつです。svg は IE9 向けの指定みたいです。

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;
}

そして最後はフォーム関連。やはりここがもっともややこしいですね。基本的に normalize.css まんまなので詳しくはそちらを参照していただきたいんですが、おもに以下のような指定を追加してます:

fieldset の余白とボーダーはリセット。
Chrome は select に background-color を指定しないとフォント系プロパティを継承しないので指定。

HTML5 の新しいコントロール型として search 型にけっこうな手間をかけてますが、これからほかの新しい型の実装も進んだとき、今までのようにすべてリセットしてクロスブラウザでピクセルパーフェクトなルックを目指すというのはいよいよ現実的ではないと思います。そういった意味で、フォームこそ CSS ノーマライズという考え方の真価が発揮されるところかもしれません。

メンテナンス

さて、この手のコードは、チームや個人で一度これと決めてしまうとあまり中身を見直されることなくそのまま使い回されるということになりがちです。その結果として、すでに不要になった古い (バッド) ノウハウが残り続け、よくわからないまま「おまじない」として次世代に受け継がれていく… という、あまり好ましくない事態が想定されます。とくに今後、要らないベンダー接頭辞が残り続けているという事態はちょくちょく目にすることになりそうです。ですから、ブラウザの実装の進歩やシェアの変動を踏まえつつ、折を見て内容を吟味して、更新し続けることが重要だと考えます。

というわけで、上記 CSS のソースコードは Gist に置いてます。気がついたときにちょくちょく手を入れると思うので、本稿での記述とは違っていることがあるかもしれません。あと現時点でのデモページも用意しました。HTML の中身は normalize.css のをそのまま拝借しています:

参考

最後に参考にしたリソースのリストを。まずはブラウザのデフォルトのスタイルシートを確認できるサイトです。IE のは公式じゃないし、Opera のは見つけられませんでした:

あと、メジャーな CSS リセットをいくつか:

CSS Tools: Reset CSS: Eric Meyer’s CSS Reset
HTML5 Reset Stylesheet | HTML5 Doctor
CSS Reset - YUI Library

メリー・クリスマス!

キャプションの幅を画像の幅に合わせる

2012-01-08T00:00:00Z

Fig 1: Wikipedia のキャプションつき画像の例

ちょっとわかりにくいタイトルになってしまいましたが、つまり 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 を用いたり幅を固定したりといった手法が必要でしょう。

Fig 3: IE7 で `figure` 要素と `img` 要素に `max-width` プロパティを指定した場合の表示例

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

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

for 属性に対する属性セレクタの IE7 での挙動

2012-02-22T00:00:00Z

IE7 には、label 要素の for 属性に対する CSS の属性セレクタが無効になるバグがあります。

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

Re-Make/Re-Model

2012-04-08T00:00:00Z

およそ 2 年ぶりにこのサイトを全面的にリデザインしました。印象としてはさほど大きく変化していないと思うんですが、内部的にはけっこういじってます。細かい部分は追って別の記事にするとして、とりあえずおもな変更点などをざっとまとめてみました。

レスポンシヴ!

…ってほどではないのですが、レイアウトを表示域に応じたものにしています (Fig 1)。

Fig 1: 表示域の幅 320px、768px、1024px (左から) でのスクリーンショット

body {
    font-size: 1em;
}

@media screen and (max-width: 32em) {
    body {
        font-size: 0.875em;
    }
}

[role="banner"],
[role="main"],
[role="contentinfo"] {
    margin-left: auto;
    margin-right: auto;
    max-width: 46em;
    padding-left: 1em;
    padding-right: 1em;
}

@media screen and (min-width: 64em) {
    [role="banner"],
    [role="main"],
    [role="contentinfo"] {
        padding-left: 17em;
    }
    .logo {
        left: 2em;
        position: absolute;
    }
}

CSS でレイアウトに関するおもな記述を抜き出すとこんな感じです。各コンテナの幅は指定せず最大幅のみ指定しています。

スマートフォンなど表示域の幅が狭い場合、フォントサイズがデフォルトのままだとやや大きく感じられたので、ベースをやや小さくしています (デフォルトが 16px なら 14px 相当)。この指定だと iPhone の縦で全角文字が 1 行あたりだいたい 20 文字入ります。

表示域の幅が十分に広い場合は左側に余白を作ってロゴをそちらに配置し、画面あたりの縦の情報量を増やしています。この左側の余白に記事の日付を置いたり画像をはみ出させたりとかも試してみましたが、あまり上手くいかなかったのでやめました。

なおメディアクエリをサポートしていない環境のために Respond.js を使っています。

ロゴとナビゲーション

ヘッダのロゴとナビゲーションには League Gothic を使っていましたが (Fig 2)、わりとよく見るようになったし、本来は大文字で使ったほうが活きる書体という気もするので変えることにしました。ロゴは Open Sans Condensed の Book 700、ナビゲーションは本文と同じ Open Sans の Bold 700 に (Fig 3)。Open Sans がとても気に入っているということです!

Fig 2: 旧ヘッダ

Fig 3: 新ヘッダ

ロゴ部分にはこのブログについての簡単な説明のようなものを入れてみました。マークアップとしては h1 と h2 で、それらを hgroup でまとめて、さらに a でまるごとリンクにしています。

<a href="/">
    <hgroup class="logo">
        <h1>terkel.jp</h1>
        <h2>A blog by…</h2>
    </hgroup>
</a>

ナビゲーションのラベルはすべて大文字で、そうすると単語ごとの「かたまり感」のようなものが出せる反面、パッと見でテキストとしてやや認識しづらくなるので、文字間と単語間に余裕を持たせています。

.primaryNav {
    font-weight: bold;
    letter-spacing: 0.125em;
    text-transform: uppercase;
    word-spacing: 0.25em;
}

ロゴの装飾とナビゲーションのインジケーターに使っている「円」のイメージにはあまり意味はないのですが、全体的に堅いイメージになりがちなのが若干柔らぐのでいいかなと思ってます。

タグ、関連記事、ツイート

各記事のタグとタグクラウド、Yet Another Related Posts Plugin による「関連記事」、あと僕の Twitter から最新ツイートを表示するウィジェットをなくしました。

タグは記事を探す手がかりとして使えるだけではなく、その記事の言及している内容を端的に示すことができるということもあり採用していましたが、そういった部分はタイトルや概要をわかりやすくすることで解決したいなと考えてます。そのかわり今後は検索機能をもっと使いやすくしたいですね。

関連記事は必要に応じて記事内で言及したほうがいいという判断ですね。プラグインの精度はけっこう高くて良かったですが。

ツイートは自作 jQuery プラグインで読み込んでいたんですが、やはり前後の文脈をすっ飛ばしてそれだけ載っけてもよくわからんというか、場合によっては良くない印象を与えることもあると思ったので。ちなみに Last.fm のウィジェットは誰も必要としていないですが自分が好きなので残します。

カラー

背景色のオフホワイト #f8f8f0、前景色のブルーブラック #002040、リンク色のブルー #0080ff の 3 色を基本にして、これらを Sass の mix 関数で混ぜて色を作っています。

$white:     #f8f8f0;
$black:     #002040;
$blue:      #0080ff;

$darkgray:  mix($white, $black, 25%);
$gray:      mix($white, $black, 50%);
$lightgray: mix($white, $black, 75%);
$palegray:  mix($white, $black, 87.5%);

$darkblue:  mix($black, $blue, 50%);
$lightblue: mix($white, $blue, 75%);
$paleblue:  mix($white, $blue, 87.5%);

というわけでもちろん CSS は Sass を使って書いているわけですが、来るべき Sass 3.2 も視野に入れつつ書き方を試行錯誤しているので、現時点ではかなりぐちゃぐちゃ (「ソース見んな」って意味です)。近々プレリリース版を入れて整理して、まとまったら一式を GitHub に公開したいですね。

Re-Make/Re-Model

いままでホームページには最新の記事 1 本をまるまる載せてたんですが、直近の 8 本の抜粋を並べることにしました。でもそれだけだとちょっとさびしいのでスローガンというかキャッチコピーのようなものを置きたい、ということでロクシー・ミュージックの曲から Re-Make/Re-Model というフレーズを拝借。フォントはロゴと同じ Open Sans Condensed の Book 300 で、FixText で幅に応じてフォントサイズが変化するようになってます。

このフレーズを選んだのはもちろんそれなりに思うところがあってのことなのですが、そのあたりはこれからこのブログや仕事などで見せていければと思っております!

ブログ記事リストのマークアップ

2012-04-10T00:00:00Z

サイトをリデザインしたのにともない、全体的にマークアップについても見直しているのですが、ちょっと悩んだのがホームやアーカイヴ・ページなどにある「ブログ記事の概要や抜粋のリスト」です。

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

<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、みたいな感じに考えるといいかなと思ってます最近は。

テーブルセルの vertical-align: baseline

2012-04-12T00:00:00Z

CSS でテーブルセルに対して vertical-align: baseline を指定したときの挙動はちょっと面白いです。そのセルが属するテーブル行で vertical-align: baseline が指定されたセルのうち、テキストの最初の行のベースラインの位置がもっとも低いセルによってそのテーブル行のベースラインが決まり、セルのテキストの最初の行のベースラインがそこに合わせられます (17.5.3 Table height algorithms [CSS 2.1])。たとえば同一行の見出しセルとデータセルでフォントサイズが異なる場合でも、このアルゴリズムによってバランス良く配置することが可能です。

Fig 1: フォントサイズの異なるセルに `vertical-align: baseline` を指定した結果

これを応用して、テーブル以外の要素でも 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 なので、多くの場合はわざわざ指定する必要がないはずです。もしどちらか一方のテキストが複数行にわたっても、ベースラインは最初の行をもとに決定されます。

Fig 2: フォントサイズの異なる要素に `display: table-cell` を指定した結果

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

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

画像置換のあれへの補足

2012-04-17T00:00:00Z

先月あたり、CSS による画像置換テクニックの話題がにわかに盛り上がりを見せていました。その経緯についてまとりさんの記事で紹介されていますが、僕からも簡単に補足してみます。

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

/* 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 の記事に詳しいです。

Browse Happy!

2012-05-19T00:00:00Z

古いブラウザを使っているユーザに最新版へのアップグレードを呼びかけるプロジェクト、Browse Happy が日本語に翻訳されました。このプロジェクトは 2004 年に The Web Standards Project (WaSP) が発足させ、2005 年に WordPress.org が引き継いだという経緯のようですが、はっきり言ってここ数年はその存在がほとんど忘れられていたと思います。それが最近になって WordPress.org の翻訳チームによって各国語への翻訳がはじめられ、ちょっとだけ再注目されつつあります。現時点では約 20 の言語への翻訳が完了しているようです。

サイトを見るとわかるとおり、WordPress.org が管理しているとは言えその内容は WordPress とは直接の関係がなく、広くウェブのユーザ全般にアピールするものです。そもそもブラウザにはいろいろあってユーザが自由に選べるということや、古いブラウザのセキュリティ上の問題などを周知し、さらに各ブラウザの最新版のダウンロードを促す、というコンテンツがひとつのページにまとまっていて、「とりあえずここ見て!」って言えて便利だし、じつに有意義なプロジェクトだと思います。

で、このサイトをユーザに対して周知したいわけですが、実際のところ周知したいのは古い IE のユーザということになると思うので、条件コメントを使ってあるバージョン以下の IE の場合にメッセージを表示する、という方法が考えられます。たとえば HTML5 Boilerplate のテンプレートでは、以下のように IE7 未満のユーザ向けに Google Chrome Frame へのリンクとあわせて表示されるようになっています:

<!--[if lt IE 7]>
    <p class=chromeframe>Your browser is <em>ancient!</em> <a href="http://browsehappy.com/">Upgrade to a different browser</a> or <a href="http://www.google.com/chromeframe/?redirect=true">install Google Chrome Frame</a> to experience this site.</p>
<![endif]-->

アップグレードを促す前にまず「あなたの使っているブラウザは古いですよ」ということを伝えなければいけないわけですが、この Your browser is ancient! をそのまま日本語にしてしまうとややきついので、もう少しやんわりと、かつ明確に伝わるものにしたいところです。また想定されるユーザ層などによってセキュリティやパフォーマンスなど訴求したいポイントも異なると思うので、やはりプロジェクトごとに文言は検討すべきでしょう。ちなみにこのサイトでは IE8 未満を対象にメッセージを表示するようにしています:

<!--[if lt IE 8]>
    <p class="ie-prompt" style="background-color:#FBFB78;font-size:87.5%;margin:0;padding:1em;">お使いのブラウザはバージョンが古いため、サイトを快適にご利用いただけないかもしれません。<a href="http://browsehappy.com/">最新のブラウザにアップグレード</a> するか、<a href="http://www.google.com/chromeframe/?redirect=true">Google Chrome Frame をインストール</a> してください。</p>
<![endif]-->

さて、こういった施策はやはりそれなりの規模のクライアント・ワークで実施してこそ効果が期待できるものです。とは言えコンテンツとは直接関係のないものを加えることを製作者側から提案するのは気が引ける、ということもあると思います。しかしながら、古いブラウザのシェアを下げたいというのは製作者側の都合だけではなく、クライアントにとっても自社のサイトをよりリッチに快適に利用してもらえる機会が増えるということにつながり、たしかなアドヴァンテージになるはずです。サポートするブラウザを検討すると同時に、こういった施策の導入も積極的に検討していきたいところです。

CSS ショートハンド・プロパティの問題点

2012-06-14T00:00:00Z

CSS のショートハンド・プロパティは複数のプロパティを一括して宣言できますが、メンテナンスしづらくなったり、思わぬバグの原因になったりすることがあります。そしてその問題が見えにくいことがさらに面倒です。font プロパティを例に、実際にどのような弊害があるのか検討してみます。

html {
    font: 87.5%/1.5 "Georgia", serif;
}

このショートハンドは一見すると次の 3 つのプロパティをひとまとめにしたものに見えます。

html {
    font-size: 87.5%;
    line-height: 1.5;
    font-family: "Georgia", serif;
}

しかし、font プロパティは上記のほか font-style、font-variant、font-weight プロパティも指定でき、そして省略されたプロパティには初期値が割り当てられます。つまり、実際には以下のように宣言されていることになります。

html {
    font-style: normal;
    font-variant: normal;
    font-weight: normal;
    font-size: 87.5%;
    line-height: 1.5;
    font-family: "Georgia", serif;
}

さて、このショートハンドで書かれたコードをチームで共有する場合を考えてみます。ひょっとするとこのコードを書いた人は、明示されているプロパティのみを宣言したかったのであり、プロパティの省略とそれに伴う暗黙の初期化については意図していなかったのかもしれません。しかしコードを読む人にとってはそこに記述されているコードがすべてなので、それはすべて意図的なものと捉えるしかありません。つまり、ここでは font-style、font-variant、font-weight の値として normal を指定する必要がある、と読むことになるわけです。こうしてコードに対する認識の食い違いが生まれ、本来は必要のないスタイルが定義され、そして最悪の場合にはバグを生むことになります。

ただ実際のところ、html や body 要素に対して font プロパティを宣言するのはいわゆるリセットやノーマライズ的な意味での場合が多いので、上記の例が問題になることはあまりないかもしれません。しかしそれはレンダリング結果にたまたま影響がないだけで、やはり表面化していない問題が潜んでいるのだと思います。

もうひとつの例として、HTML5 Boilerplate の画像置換テクニックのコードを見てみます。

.ir {
    font: 0/0 a;
    text-shadow: none;
    color: transparent;
}

この font プロパティのうち、ここでのスタイルの要件を満たすために必要なのは font-size と line-height のみです。font-family は必要ないのですが、構文上省略できないため、せめてコードを短くしたいという理由で書体名ではなく a という文字列が宣言されています。また省略された 3 つのプロパティに初期値を指定する必要もありません。しかしこのようにトリッキーな記述をされると、あとから編集する人が手を入れることが難しく、内容が検討されないまま「おまじない」としてコピペされ続けてどこかで思わぬ弊害を生んだり、逆に検討しようとすると無駄な時間がかかったりする可能性があります。こういったハック寄りのテクニックではとくに、必要最低限の記述にとどめるべきでしょう。

font プロパティのほかにも、たとえばブロックボックスを親要素の左右中央に配置するスニペット margin: 0 auto; は上下まで指定する必要があるか検討すべきだし、background プロパティなんかはいい加減に書いてると思わぬ結果を招くことがよくあるので、やはりショートハンド全般に注意が必要です。

というわけで、ショートハンド・プロパティはコードが短くすっきりする反面、余分なプロパティを宣言してしまうことがあり、かつそれが意図されたものかどうかわかりづらくなってしまう、という問題があります。やはりその都度必要なプロパティだけを宣言するよう心掛けるのが良いのではないでしょうか。CSS の場合、そういった余分な宣言があっても結果的に問題が表面化しないということも多いので、なかなか意識するのが難しいところではありますが、このあたりを考慮できると、将来にわたって安全で運用しやすい CSS に一歩近づけるように思います。

スクリプトが無効の場合のスタイル

2012-07-01T00:00:00Z

たとえばホームページのビジュアル要素など、いったん非表示にしておいてスクリプトでふわっとフェードインさせたい、みたいなことはよくある。そのとき非表示にする操作も JavaScript にやらせると一瞬見えてしまうことがあるので CSS で非表示化したいが、それだとスクリプトが無効の場合に何も表示されなくなってしまう… というような、スクリプトによる操作を前提にしたスタイルのフォールバックをどうするかという問題。

ここのところよく使っていたのは、JavaScript で html 要素の class 属性を操作し、それをもとに CSS を書くという手。Modernizr でも使われてるあれ。

(function () {
    var root = document.documentElement;
    root.className = root.className.replace(/\bno[-_]?js\b/ig, '') + ' js';
})();

こんなようなコードを head 内で読み込んでおけば、スクリプトが有効の場合には html 要素の no-js (または no_js や noJS) クラスが削除されて js クラスが付与されるので、これをもとに CSS のルールセットを分岐させればいい。

.foo { ... }
.js .foo { display: none; }

またはこう:

.foo { display: none; ... }
.no-js .foo { display: block; }

ちなみに Sass 3.2 の placeholder (%) セレクタを使うとこう書けて便利:

.js %js-hidden { display: none; }
.foo { @extend %js-hidden; ... }

このスクリプトは body の最後に置いたのでは遅いので、head に置くほうがいい。なお HTML 4.01 や XHTML 1.0 では html 要素は class 属性を持てない (動くけど)。

そしてもうひとつの手として最近思いついたのが、head 内で noscript 要素を使って別のスタイルシートを読み込む方法。

<head>
    ...
    <link rel="stylesheet" href="/css/style.css">
    <noscript>
        <link rel="stylesheet" href="/css/noscript.css">
    </noscript>
    ...
</head>

デフォルトのスタイルシートではスクリプト有効の前提で書いて、無効の場合のスタイルを別ファイルに書けばいい。ひとつの要素に対して複数のファイルを編集しなきゃいけないけど、スニペットに依存しない点は良いと思う。

なお HTML 4.01 や XHTML 1.0 では head 内に noscript を置けないし、noscript 内に link を置けない。HTML5 Rocks!

最近試している Sass の書き方

2012-07-12T00:00:00Z

最近、Sass 3.2 (プレリリース版) を使って新しい書き方を模索しているんですが、その方向性に自信が持てないので、ちょっとさらしてみて反応を見ようという試みです。

まず基本的な方向として、以下のような考え方を参考にしています:

マークアップに合わせてスタイルを書くのでもなく、スタイルに合わせてマークアップするのでもない、それぞれを適切に書いた上で結びつける、というようなことを僕なりにやろうとしています。スタイルの実装と、それらを利用するためのインターフェイスを分離する、みたいなイメージで、具体的には Placeholder (%) セレクタと @extend を中心にしたものです。

// _breadcrumbs.scss

%breadcrumbs {
    backgrund-color: $palegray;
}

%breadcrumbs-link {
    text-decoration: none;
    &:hover {
        text-decoration: underline;
    }
}

%breadcrumbs-separator {
    color: $gray;
}

%breadcrumbs-current {
    font-weight: bold;
}

例としてパンくずナビゲーションのスタイルを考えてみます。まずこのように % セレクタを使ってスタイルをパーツに分解して書き下ろします。このとき、マークアップの要素タイプやクラス名や入れ子構造などは考えず、ただ必要なスタイルに名前をつけていく感じです。これをたとえば _breadcrumbs.scss というファイルにしておきます。

_breadcrumbs.scss はスタイルを定義しているだけで、それだけでは CSS を生成しません。CSS を生成する Sass ファイルとして style.scss を用意し、_breadcrumbs.scss を @import し、そしてマークアップとスタイルを @extend を使ってつなぎ合わせます。

<div class="crumbs-nav">
    <a href="/">Home</a> <span class="separator">›</span>
    <a href="/artist">Artist</a> <span class="separator">›</span>
    <em>Bobby Womack</em>
</div>

マークアップがこのようなものだったとします。このとき、マークアップは _breadcrumbs.scss のスタイル定義を気にする必要はなく、(ひとまず) 妥当なマークアップであれば良いです。そして style.scss では以下のように書きます。

// style.scss

@import "breadcrumbs";

.crumbs-nav {
    @extend %breadcrumbs;
    a {
        @extend %breadcrumbs-link;
    }
    .separator {
        @extend %breadcrumbs-separator;
    }
    em {
        @extend %breadcrumbs-current;
    }
}

スタイル定義はマークアップに依存しないので、たとえばパンくずが div.crumbs-nav ではなく ol だったり #pankuzu だったりしても、手を入れるのは style.scss の一部だけです (とは言え、スタイルを適用するのに要素が足りなかったり、スタイルの調整が必要な場合もあります)。この調子であらゆるスタイルをそれぞれモジュールとして定義し、style.scss 上でそれらをインクルードし、マークアップと結びつけていきます。その結果、CSS が 1 行も書かれていない style.scss と多数の Sass モジュールが出来上がります。

こうするとまずスタイルを定義する人とマークアップする人の分業がやりやすくなるはずというのがありますが、なによりマークアップとスタイルがそれぞれを束縛し合ったまま足踏みしているような状況から抜け出すきっかけになるのでは、というのが大きいです。

加えて、「このスタイルは汎用的なものか」「どこかで使い回す可能性があるか」みたいなことをいちいち考えず、すべてのスタイルをフラットなモジュールとして捉えられるというのも特徴です。これは良いことなのかちょっと微妙とも思いますが。

これでマークアップ、スタイル、そして両者を結びつける役割が分離できてめでたしめでたし、と言いたいところですが、スタイル定義を一切含まず、ひたすら @import と @extend を繰り返すだけのファイルを見ていると、なんだか遠いところに来てしまったような気がして言い知れぬ不安を覚えます。とくにひとりでフロントエンドすべてを面倒見るような規模の場合、このやり方だとメリットが見えにくいというか、実際に僕が今ひとりでこうやっていて、いったいどこに向かってるんだろうかという気持ちになったのでこの記事を書いています。

あとファイルをどんな感じで分割するか、@import はどうやるのが良いか (ファイルの先頭にまとめてかそのつどか) といったあたりも悩むところです。どこに何を書いたかすぐに分からなくなるし。

ちなみに、実際にこのやり方で書いてみるとふつうの CSS の 3 倍手間がかかるし、3 倍頭を使いますが、それはむしろ良いことだと考えているというか、そういうものだという理解です。「ウェブ標準」が流行ったときに structure と presentation の分離ということが盛んに言われましたが、結局のところただ HTML と CSS のファイルが分離できただけでは、という気がしていた者としては、ある種の手応えはあるし、そのうち何かが見えてくるはず、とは思います。

皆さん、どんなふうに書いてますか?

@media と @extend

2012-07-13T00:00:00Z

Sass で @extend を CSS の @media と絡めて使おうとすると、組み合わせによってはエラーや警告が出てしまうので注意が必要。

%foo {
    color: red;
}

.bar {
    @media screen and (min-width: 768px) {
        @extend %foo; // ERROR!
        margin: auto;
    }
}

スクリーンの幅が 768px 以上のときは .bar に %foo を継承させる、という意図だけど、これは “Extend directives may only be used within rules.” というエラーが出て通らず、ファイルのコンパイルが丸ごと失敗してしまう。

%foo {
    color: red;
}

@media screen and (min-width: 768px) {
    .bar {
        @extend %foo; // WARNING
        margin: auto;
    }
}

こうやって @media を外側に持ってくるとエラーにはならないけど、警告が出て @extend が評価されない (そのほかの宣言は大丈夫)。メッセージは “@extending an outer selector from within @media is deprecated. You may only @extend selectors within the same directive. This will be an error in Sass 3.3. It can only work once @extend is supported natively in the browser.” と言っていて、いまは警告で済むけど次はない、ってことらしい。

@media の内側から外のセレクタを @extend することはできないようなので、必要であれば @extend される側のセレクタの中に @media を宣言することになる。

%foo {
    @media screen and (min-width: 768px) {
        color: red;
    }
}

.bar {
    @extend %foo; // Works!
}

ただ、このやり方だとスタイルを細切れにして @extend しまくる設計の場合に継承元セレクタごとにいちいちクエリを書く必要があり、出力結果も @media まみれのちょっと悲惨なものになる。@media と絡むところでは無理に @extend しようとせず、素の CSS に近い感じで書くのがいいのかもしれない。とくに最近はメデイアクエリでスタイルを細かく分岐させることも多いと思うので気をつけたい。ていうか気をつけます。

NIR ミックスイン

2012-07-20T00:00:00Z

NIR (Nash Image Replacement) をわりとよく使うようになったので、最近は Sass のミックスインにしています:

@mixin nir ($src, $w: auto, $h: auto, $x: 0, $y: 0) {
    overflow: hidden;
    @if ($w != auto) {
        width: $w;
        height: $h;
    }
    *text-indent: -9999px;
    *background-image: url($src);
    *background-repeat: no-repeat;
    @if ($x != 0) {
        *background-position: $x $y;
    }
    &:before {
        content: url($src);
        display: inline-block;
        font-size: 0;
        line-height: 0;
        @if ($x != 0) {
            margin-left: $x;
            margin-top: $y;
        }
    }
}

@mixin nir-position ($x, $y) {
    &:before {
        margin-left: $x;
        margin-top: $y;
    }
    *background-position: $x $y;
}

もっともシンプルな使い方はスプライトではなく単独の画像を使う場合で、画像のパスと幅と高さを nir() に渡すだけ。

.logo {
    @include nir("/img/logo.png", 128px, 36px);
}

結果こうなります:

.logo {
     overflow: hidden;
     width: 128px;
     height: 36px;
     *text-indent: -9999px;
     *background-image: url("/img/logo.png");
     *background-repeat: no-repeat;
}

.logo:before {
    content: url("/img/sprite.png");
    display: inline-block;
    font-size: 0;
    line-height: 0;
}

スプライト画像の場合は座標の指定も必要です。たとえばソーシャル系のリンクをロールオーバーつきのアイコンで表現するにはこんな感じ:

.social-links {
    a {
        display: inline-block;
        @include nir("/img/sprite.png", 32px, 32px);
        &[href^="https://twitter.com/"] {
            @include nir-position(-180px, -190px);
            &:hover {
                @include nir-position(-180px, -230px);
            }
        }
        &[href^="http://www.facebook.com/"] {
            @include nir-position(-220px, -190px);
            &:hover {
                @include nir-position(-220px, -230px);
            }
        }
    }
}

まず a 要素に対して nir() でスプライト画像のパスとアイコンのサイズを指定して、次いでリンク先や状態ごとに各アイコンの座標を nir-position() で個別に指定しています。

.social-links a {
    display: inline-block;
    overflow: hidden;
    width: 32px;
    height: 32px;
    *text-indent: -9999px;
    *background-image: url("/img/sprite.png");
    *background-repeat: no-repeat;
}

.social-links a[href^="https://twitter.com/"] {
    *background-position: -180px -190px;
}
.social-links a[href^="https://twitter.com/"]:before {
    margin-left: -180px; margin-top: -190px;
}
.social-links a[href^="https://twitter.com/"]:hover {
    *background-position: -180px -230px;
}
.social-links a[href^="https://twitter.com/"]:hover:before {
    margin-left: -180px; margin-top: -230px;
}

.social-links a[href^="http://www.facebook.com/"] {
    *background-position: -220px -190px;
}
.social-links a[href^="http://www.facebook.com/"]:before {
    margin-left: -220px; margin-top: -190px;
}
.social-links a[href^="http://www.facebook.com/"]:hover {
    *background-position: -220px -230px;
}
.social-links a[href^="http://www.facebook.com/"]:hover:before {
    margin-left: -220px; margin-top: -230px;
}

擬似要素なので Firefox 以外でアニメーションできないとかそもそもコンパイル結果のコードがうざいとかいろいろありますが、ちょっとしたアイコンやなんかにはやっぱり便利なのでけっこう重宝します。

jQuery Image Rollover

2012-08-04T00:00:00Z

jQuery Conference で発表されたらしい、Douglas Neiner さんの Contextual jQuery 3 というスライドが興味深かったので、参考にしながらためしに画像ロールオーバー (マウスが乗っかると画像が差し替わるあれ) の jQuery プラグインを書いてみました。ワーク・イン・プログレス。

terkel/jquery-imagerollover · GitHub

この手のスクリプトでよくあるのが、$(document).ready() のタイミングで各画像に .each() で処理をバインドするというやり方で、僕もその方法で書いたプラグインを使っていました。たとえば .rollover というクラスを持った画像を対象にする場合、だいたいこんな感じです:

$(document).ready(function () {
    $('.rollover').each(function () {
        ...
        $(this).bind({
            mouseenter: function () {
                // ロールオーバー処理
            },
            mouseleave: function () {
                // デフォルトに戻す処理
            }
        });
    });
});

しかし、このやり方だと .rollover が 100 個あれば 100 個の要素を検索して 100 回の初期化がおこなわれることになります。これを .on() を使って以下のように書き換え、1 回の初期化で済ますようにしました:

$(document).on('mouseenter mouseleave', '.rollover', function (event) {
    ...
    if (event.type === 'mouseenter') {
        // ロールオーバー処理
    } else {
        // デフォルトに戻す処理
    }
});

ここでは説明のためかなり大雑把に書いていますが、基本的にこんな感じです。加えて、クラス名ではなく画像ファイル名の接尾辞によって要素を選択するようにしたり、mouseenter/mouseleave と同時に focusin/focusout も対象にしたり、ロールオーバー時の画像をプリロードして各画像に .data() で持たせたり、イベントを重複して登録しないようにチェックを入れたりとかしています。

jQuery のプラグインというといつも決まった書式でばかり書いていたので、なれない書き方でかなり苦労している上、いまいち内容に自信が持てませんが、個人的に苦手なイベント系の理解が少しだけ深まったような気がします。

リンクのスタイルを変えた

2012-08-05T00:00:00Z

このサイトの本文などのリンクのスタイルを少し変えました。

いままではボールドで前景色は明るいブルー (#0080ff)、:hover で text-decoration: underline というスタイルだったのを、ウェイトはノーマル、前景色を暗く (#00509f) し、border-bottom で薄いグレーの下線、そして :hover 時に前景とボーダーを明るいブルーに、というスタイルにしました。

[role="complementary"] a,
.credits a,
.mainContentBody a {
    border-bottom: 1px solid #d9ddda;
    color: #00509f;
    text-decoration: none;
}

[role="complementary"] a:hover,
.credits a:hover,
.mainContentBody a:hover {
    border-bottom-color: #0080ff;
    color: #0080ff;
}

CSS としては上記のような感じですが、これだと記事中の画像にリンクがある場合に不要なボーダーができてしまうので、figure > a { border-bottom-width: 0; } みたいに上書きしてます。このへんもっと上手く書きたいんですが地味に難しいですね。

変えたのは前景色の明るさがうるさく感じるようになったのがきっかけですが、たとえば Android の和文フォントがボールドにならないなど、環境によって異なるフォントのスタイルになるべく依存しないほうがいいな、というのもあります。

mustache と lscache

2012-08-07T00:00:00Z

このサイトでは Last.fm API からデータを取ってきて僕が最近よく聴いてるアルバムを表示する、っていうのをやってるんですが、このスクリプトを mustache と lscache というライブラリを組み合わせて書き直してみたところけっこういい感じになったので、簡単に紹介してみます。

mustache は様々な言語で利用できるテンプレート・エンジンで、ここで使っているのはその JavaScript 実装である mustache.js です。導入や使い方についてはまっはさんの記事がわかりやすくて参考になりました。

まず API から JSON データを取得し、これを整形して mustache 用のオブジェクトにします:

var data = {
        heading: 'This Week’s Top 10',
        albums: [
            {
                name:  'Solaris – Cliff Martinez',
                url:   'http://www.last.fm/music/Cliff+Martinez/Solaris',
                image: 'http://userserve-ak.last.fm/serve/64s/43127407.png'
            },
            {
                name:  'Marquee Moon – Television',
                url:   'http://www.last.fm/music/Television/Marquee+Moon',
                image: 'http://userserve-ak.last.fm/serve/64s/76164550.png'
            },
            ...
        ]
    };

そして mustache テンプレートを準備:

var template =
        '<h2>{{heading}}</h2>' +
        '<ol>' +
            '{{#albums}}<li>' +
                '<a href="{{url}}">' +
                    '<img src="{{image}}" alt="{{name}}">' +
                '</a>' +
            '</li>{{/albums}}' +
        '</ol>';

テンプレートはこのように文字列で定義します。{{key}} っていうのが mustache タグで、データの入る部分です。{{#albums}} から {{/albums}} まではループですね。このテンプレートとデータを Mustache.render() に渡せば HTML を生成してくれるので、これを DOM に挿入すれば完成です:

var html = Mustache.render(template, data);
$('#container').html(html);

で、このもとになる JSON データを毎回 API から取得するのは無駄なので、一度 HTML を作成したらそれをローカルにキャッシュして再利用しよう、というのが次のステップです。そこで lscache を使います。lscache は localStorage によるデータの取り扱いを簡単にしてくれるライブラリです。

lscache.set('lastfmHTML', html, 60 * 24);

このように lscache.set() メソッドでデータをローカルに保存します。データとして渡せるのは文字列またはオブジェクトです。ここでは 'lastfmHTML' というキーに先ほど生成した HTML 文字列を保存しています。データの保持期間が分単位の数値で指定でき、この例では 24 時間を指定しています。

このキャッシュされたデータを API 呼び出しの前にチェックして、データがあればそのまま使い、なければ API からデータを取得して HTML を生成してキャッシュ、というかたちにします。キャッシュされたデータを取得するには lscache.get(key) です:

var cache = lscache.get('lastfmHTML');

if (cache) {
    $('#container').html(cache);
} else {
    // データ取得、HTML 生成、キャッシュ
    ...
    $('#container').html(html);
    lscache.set('lastfmHTML', html, 60 * 24);
}

コード例がかなり雑ですが、だいたいこんな流れです。どちらのライブラリもシンプルで直感的に扱えます。

localStorage については、はじめて触ったけど簡単だしすげーいいじゃんっていうのと同時に、いままで考えたことのない領域なのでどう使っていけばいいのかいまいちわからんというか、問題提起されたりもしてるみたいだし慎重になっちゃいますねー、という感じですね (歯切れ悪い…)。

Google Web Fonts が IE で適切に読み込まれない

2012-09-03T00:00:00Z

Google Web Fonts のウェブフォントには IE 8 以下でちょっとしたバグがある。このサイトでもずっと放置してたのをようやく直しました…

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

たとえば上記のように書けば、Open Sans のウェイト 400 (ノーマル) と 700 (ボールド)、そしてそれぞれのイタリックの計 4 書体が読み込まれる。あとは CSS でふつうに h1 { font-family: "Open Sans", sans-serif; font-weight: bold; } みたいな感じで指定が可能。

Fig 1: Open Sans on IE 9

これは IE9 でのレンダリング例。小文字の a や e あたりを見るとわかるとおり、ボールドやイタリックは機械的に太らせたり傾けたりしたものではなく、それぞれデザインされた字形を持っている。

Fig 2: Open Sans on IE 8

しかし同じ CSS でも IE 8 で見ると、イタリックはノーマルをそのまま傾けただけ、ボールドも二重にしたノーマルをずらして重ねたような、いわゆるにせのボールドとイタリックになってしまう。利用できるはずの「本物」のイタリックやボールドが呼び出されず、ノーマルしか使えないという状態。IE 7 と 6 も同様。

この問題はけっこう前から話題になっていたらしくて、解決策もある。

複数のウェイトやスタイルをひとつの link 要素で指定するのではなく、以下のように個別の link に分割してリクエストすると、IE 8 以下でもそれぞれちゃんと使える。

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

ただリクエストが増えてしまうのは嬉しくないので、いったん一括で指定したあと、問題のある IE 8 以下を対象に条件コメントで分岐させる、という回避策がとりあえずは有効。

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

<!--[if lt IE 9]>
    <link href="http://fonts.googleapis.com/css?family=Open+Sans:400italic" rel="stylesheet">
    <link href="http://fonts.googleapis.com/css?family=Open+Sans:700" rel="stylesheet">
    <link href="http://fonts.googleapis.com/css?family=Open+Sans:700italic" rel="stylesheet">
<![endif]-->
...
</head>

上記の例では、IE 8 以下でも最初の link で 400 は有効になっているので、残りの 3 書体を改めて個別に指定している。同じファミリーの複数のウェイトとスタイルを一度にリクエストした場合に起きる問題なので、複数のファミリーを指定する場合や、ノーマルを使用せずボールドやイタリックのみの場合など、組み合わせによって必要な記述が変わってくる。検証しましょう。

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

<!--[if lt IE 9]>
    <link href="http://fonts.googleapis.com/css?family=Open+Sans:700" rel="stylesheet">
<![endif]-->
...
</head>

link じゃなく @import を使った場合も同じバグがあり、やはりリクエストを分割することで回避できる。このサイトでは管理のしやすさから @import を使ってたんだけど、これを機に link に変更した。

text-rendering: optimizeLegibility

2012-09-04T00:00:00Z

WordPress の次期デフォルト・テーマ、Twenty Twelve の CSS を見ていたら、body 要素に text-rendering: optimizeLegibility という見慣れないプロパティが指定されていたのでちょっと調べてみました。

text-rendering プロパティは CSS ではなく SVG の仕様に定義されています。現在のところ利用できるブラウザは Firefox、Chrome、Safari。指定できる値は

auto (初期値)
optimizeSpeed
optimizeLegibility
geometricPrecision
inherit

ですが、現状では auto や geometricPrecision の挙動がブラウザによって異なるようです。

このうち optimizeSpeed と geometricPrecision は違いがよくわからなかったのですが、optimizeLegibility はカーニングと合字 (リガチャ) をうまい具合に調整してくれるもので、現実世界でもけっこう使えそうです。ただフォントがカーニングや合字のデータを持っていなければ指定しても何も起こりません。和文フォントでは、メイリオと MS 系ゴシック・明朝は効果がないですが、ヒラギノ角ゴ・明朝は軽くカーニングが調整されます。

ヒラギノ角ゴ ProN における `text-rendering: optimizeLegibility` の効果の比較。上から無効時、有効時、およびそれらを重ねたもの (赤が有効時)。検証環境は Mac OS X 10.6 + Chrome 21

上記の記事によると、Firefox では font-size が 20px 以上 (一般的な見出しを想定していると思われる) の場合はデフォルトで optimizeLegibility が適用されるとのことですが、Firefox 15 で見る限りどうもサイズに関係なくそうなってるみたいです。また環境やほかのプロパティとの食い合わせによっては不具合があるとの報告もありますが、ざっと確認したところこれといった問題はなさそうだったので、このサイトでも採用してみることにしました。

html {
    font-family: "Open Sans", "Hiragino Kaku Gothic ProN", "Meiryo", sans-serif;
    text-rendering: optimizeLegibility;
    ...
}

Normalize.css をそのまま使うことにした

2012-09-06T00:00:00Z

Normalize.css は僕もプロジェクトによって部分的に取り入れてたんだけど、v2.0 になったのをきっかけに今後はどのプロジェクトでもまるごと採用していこうかと考えてる。たとえばこのサイトでは今までどうやっていたかというと、

@mixin normalize-html {
    font-family: sans-serif;
    -webkit-text-size-adjust: 100%;
    -ms-text-size-adjust: 100%;
}

@mixin normalize-body {
    margin: 0;
}

html {
    @include normalize-html;
    font-family: $sans-serif;
    overflow-y: scroll;
    ...
}

body {
    @include normalize-body;
    background-color: $white;
    color: $black;
    ...
}

こんな風に Normalize.css をセレクタごとに Sass ミックスインに分解して、プロジェクトの SCSS の各セレクタに @include する、という面倒なことをしてた。v2.0 以前はとくに見出しやリストやフォームあたりでプロパティの上書きという無駄が発生しがちだったのでこういうアプローチを採ってたんだけど、どのスタイルを取り込んでるか把握するのがたいへんだし、どうしても二度手間感が拭えない。あとチームでメンテナンスする場合に「Normalize.css 使ってるよ」って一言で言えずコードを追ってもらう必要があるのも面倒。

その点、v2.0 は古いブラウザ用のコードがかなり削られたので内容がシンプルになり、無駄が発生しづらくなった。というわけで、最近のプロジェクトではまるごと使うことにした。具体的には、Normalize.css をリネームしてコメントを削除しただけの _normalize.scss という SCSS ファイルを用意してそのまま @import する。

いわゆる CSS リセットをかましたいようなプロジェクトでも、reset.css みたいなのを使うんじゃなくて、_normalize.scss を @import した上で、プロパティごとにリセットする % セレクタを用意して、これを必要に応じて @extend するという手を使ってみてる。

@import "normalize" // import _normalize.scss

%reset-margin {
    margin: 0;
}

%reset-padding {
    padding: 0;
}

%reset-list-style {
    list-style: none;
}

.site-logo {
    @extend %reset-margin;
}

.primary-nav {
    ul {
        @extend %reset-margin;
        @extend %reset-padding;
    }
    li {
        @extend %reset-list-style;
    }
}

ちなみに、Normalize.css が古いブラウザ (とくに IE 7 と 6) のサポートをやめたと言っても、内容に根本的な変更があったわけではなく、いくつかのスタイルを整理したのがアップデートの中心なので、古いブラウザをサポートするプロジェクトに使えないということはまったくない。今までどおり古いブラウザをサポートした v1.0.1 も提供されてるけど、無駄が発生しやすいので今となってはちょっと微妙。v2.0 をインクルードした上でプロジェクトごとに必要なスタイルを追加する方がいいと思う。古いブラウザのサポートをやめたというより、外に追い出して製作者に委ねた、と捉えるとよさそう。

幅の狭い画面向けの等幅フォントに M+ 1m を採用

2012-09-10T00:00:00Z

このサイトでは記事にソースコードを掲載することが多いけど、スマートフォンなど幅の狭い画面では折り返しが増えて読みづらくなってしまう。そこで幅の狭い等幅フォントに変えれば多少は読みやすくなるかと考え、M+ Fonts の M+ 1m をウェブフォントとして利用させていただくことにした。

M+ 1m (約 12px) を幅 320px のスマートフォンで表示したところ

残念ながら今のところ Google Web Fonts にはないので、Font Squirrel からダウンロードしたフォントをサーバに上げて @font-face で参照。5 つのウェイトが用意されてるけど、ここで使うのは Regular と Bold のみ。表示域の幅がある程度狭い場合にのみ適用されるよう、メディアクエリで切り替えてる。

code,
samp,
kbd {
    font-family: "Menlo", "Consolas", monospace;
}

@media screen and (max-width: 32em) {
    code,
    samp,
    kbd {
        font-family: "M+ 1m", monospace;
    }
}

結果にはかなり満足してるけど、読み込むウェブフォントが増えてきちゃったのでなんか最適化を検討します…

CSS ボタンのグラデーションとボーダーをグレースケールの RGBA で

2012-11-14T00:00:00Z

CSS でボタンを作るとき、背景のグラデーションとボーダーをグレースケールの RGBA にしたものをもとにすると、背景色やフォントを変えるだけでバリエーションが作れるので便利です。

button {
    background-image: linear-gradient(rgba(255, 255, 255, 0.1), rgba(0, 0, 0, 0.1));
    background-origin: border-box;
    border: 1px solid rgba(0, 0, 0, 0.1);
    border-radius: 0.25em;
    box-shadow: 0 1px 2px rgba(0, 0, 0, 0.1), inset 0 1px rgba(255, 255, 255, 0.1);
    cursor: pointer;
    display: inline-block;
    line-height: 1.5;
    padding: 0.25em 1em;
    text-align: center;
    white-space: nowrap;
}

基本になるボタンはだいたいこんな感じです。背景は半透明の白から黒へのグラデーションにし、ボーダーも半透明の黒にします。この基本ボタンをもとに、背景色や前景色などを書き加えるだけで色のバリエーションが作れます。

button.default {
    background-color: white;
    color: black;
}

button.submit {
    background-color: #00c000;
    color: white;
}

button.delete {
    background-color: #c00000;
    color: white;
}

見落としがちなのが background-origin プロパティです。この初期値は padding-box で、そのままだとグラデーションの開始と終了の位置がボーダーの内辺になります。ボーダーを単色で塗りつぶすならそれでもいいんですが、このコード例のようにボーダーの不透明度を下げてグラデーションを透過させるとちょっと不自然です (Fig 2)。

Fig 2: background-origin: padding-box; (初期値)

そこでこれに border-box を指定すると、背景配置範囲をボーダーの外辺にすることができます。ボーダーが RGBA なら背景に沿ってグラデーションするので、より自然な感じになると思います (Fig 3)。このあたりの背景関連プロパティについては CSS3 での背景指定方法のまとめ | Unformed Building が詳しくまとまっていてわかりやすいです。

Fig 3: background-origin: border-box;

コード例はかなりはしょった CSS で書きましたが、実際には Sass のプレースホルダー・セレクターを使うとより便利です。ご参考までに jsFiddle で簡単な拡張例もあわせてデモを作ってみました。GitHub や Twitter Bootstrap あたりに見られるような、最近よくある感じを取り入れたつもり。

Demo: CSS Buttons - jsFiddle

ボタンを例に書きましたが、それだけに限らずグラデーションを使う場面で広く利用できるテクニックです。これを僕は hail2u.net の記事などで知ったんですが、あまり浸透していない気がするので、ズルいデザインに触発されたのもあり、書いてみた次第です。

Sass のミックスインをローカルな名前で呼ぶ

2012-11-19T00:00:00Z

Sass でライブラリをプロジェクトに組み込む場合など、ミックスインを「ローカル」な名前で呼ぶようにしておくと便利なことがある。

// ミックスインの実装
@mixin awesome_gradient ($angle, $color-stops...) {
    $prefixes: webkit, moz, o;
    // ...
}

// ローカルなミックスインの定義
@mixin linear-gradient ($args...) {
    @include awesome_gradient($args);
}

// ローカルなミックスインをインクルード
.foo {
    @include linear-gradient(180deg, rgba(255, 255, 255, 0.5), rgba(0, 0, 0, 0.5));
}

ここで .foo は linear-gradient というミックスインをインクルードしているけど、そのミックスインはローカルな名前を提供しているだけで、実際には awesome_gradient を呼んでいる。一見すると無駄だけど、これがどんな場合に便利かというと、たとえばライブラリのミックスインを利用してるけどやっぱ別のに差し替えたい、みたいなときにラク。

// 別のミックスインの実装
@mixin yetAnotherLinearGradient ($first, $rest...) {
    // ...
}

// ローカルな名前はそのまま
@mixin linear-gradient ($args...) {
    @include yetAnotherLinearGradient($args);
    // @include awesome_gradient($args);
}

このように、ミックスインの実装は awesome_gradient から yetAnotherLinearGradient に差し替えたけど、ローカルな名前は linear-gradient のままなので、ミックスインをインクルードしている箇所では修正の必要がない。

重要なのはローカルのミックスインを定義するときに $args... という可変長引数 (Variable arguments) を使うことで、これによってミックスイン間で引数の形式が異なってもある程度は吸収できる。もっともミックスインの設計がまったく異なるような場合にはインクルードしてる箇所も修正しないといけないけど。

またこの記事のもうひとつのメッセージとして、linear-gradient の混沌から僕を救ってくれるクールなミックスインないですか、というのもあります。

Hybridity

2012-12-03T00:00:00Z

今週の土曜日、友人のレコード店 Rubbergard Record がオーガナイズする Hybridity というパーティがあるんですが、その告知ページを作るという仕事をしました。イヴェントの内容は、僕はこっち方面のシーンには明るくないのであれなんですが、その筋では知る人ぞ知る方々が出演するらしく、とくにブラジル音楽が好きなら楽しめると思います。お暇ならぜひ!

デザインはウェブフォントを使ってポスター風の表現を試してみました。このサイトでも全面で採用している Open Sans と Open Sans Condensed のウェイトとサイズの組み合わせでなんとかそれっぽく。文字サイズをコンテンツ幅に合わせるためには FitText、タイトルのカーニングの調整用には Lettering.js という jQuery プラグインを使っています。たいした文字量ではないので Lettering.js は必ずしも必要じゃないんですが、使ってみたかったので。

背景画像を全画面で表示するのは body 要素に background-attachment: fixed と backgournd-size: cover でいけるかと思ったんですが、iOS で background-attachment が思った挙動にならず、空の div を position: fixed で配置するという方法を採りました。

時間もなかったので、緻密な計算より勢い重視でぶっ込むという方向で攻めました。久々に好き勝手やらせてもらえていい気分転換にもなったし、わりかし満足してます。

こういった「仕事しました!」っていう記事を書くのすごく久しぶりな気がする…

画像の最大幅を calc() で制御する

2012-12-16T00:00:00Z

画像の幅をコンテンツに合わせてフレキシブルにしたい場合、親要素の幅を超えないようにするには CSS の max-width プロパティに 100% を指定する。

img {
    max-width: 100%;
    border: 1px solid silver;
    padding: 0.25em;
}

ただ、画像にパディングやボーダーを持たせた場合、その分が親要素の幅より大きくなってしまうことがある (Fig 1)。

Fig 1: パディングとボーダーを持つ画像に `max-width: 100%;` を指定すると、親要素の幅を越えてしまうことがある

これをつねに親要素に収めるようにするには、box-sizing プロパティを利用して画像の幅がパディングとボーダー込みで算出されるようにする、という手がある。

img {
    max-width: 100%;
    border: 1px solid silver;
    padding: 0.25em;
    box-sizing: border-box;
}

これでも上手くいんくんだけど、img 要素の width と height 属性もこの box-sizing の影響を受けるため、マークアップで指定した値と実際に表示される大きさが違ってしまってちょっと面倒。たとえば、いわゆる Retina ディスプレイを考慮して縦横が 2 倍の画像を width/height で半分の大きさに縮小する、みたいな場面で計算が狂ってくる。

そこで、画像の max-width の値として calc() を利用してみる。

img {
    max-width: calc(100% - 1px * 2 - 0.25em * 2);
    border: 1px solid silver;
    padding: 0.25em;
}

親要素の幅から画像の左右のパディングとボーダーの大きさを引き算したものが画像の最大幅になる。このように % と em と px という異なる単位を一緒にしてもちゃんと計算してくれる。これならマークアップで width と height を指定しても、親要素の幅が充分にあればそのとおりの大きさで表示され、足りなければパディングとボーダーの分も含めて親要素の幅を超えることはない。

calc() は IE9 を含めすでにけっこうサポートされてるけど、フォールバックとしてはレイアウトが破綻しない程度にざっくり計算した値も入れておく。ベンダー接頭辞として -moz- はたぶんもう要らないけど -webkit- はまだ要る。あと Android と Opera、よろしくお願いします。

img {
    max-width: 96%;
    max-width: -webkit-calc(100% - 1px * 2 - 0.25em * 2);
    max-width: -moz-calc(100% - 1px * 2 - 0.25em * 2);
    max-width: calc(100% - 1px * 2 - 0.25em * 2);
    border: 1px solid silver;
    padding: 0.25em;
}

こういうのは Sass でなんとかなりそうな気がちらっとするけど、Sass はあくまで静的な CSS を書き出すものなので、calc() のようにクライアント側で動的に演算するようなものはそもそも無理。ミックスインを作るとしてもせいぜいベンダー接頭辞を付与するタイプのものしかできないはず。その場合も、単位が混ざってる時点でエラーになってしまうため、式を文字列として渡す必要がある。

@mixin calc ($prop, $expr) {
    $prefixes: webkit, moz;
    @each $prefix in $prefixes {
        #{ $prop }: -#{ $prefix }-calc(#{ $expr });
    }
    #{ $prop }: calc(#{ $expr });
}

img {
    @include calc(max-width, "100% - 1px * 2 - 0.25em * 2");
}

calc() をちゃんと使ったのはじつは今回がはじめてだったんだけど、いままであきらめてたのがあっさり実現できてちょっと感動した。

ハヤカワ・ポケット・ミステリのデザイン

2012-12-17T00:00:00Z

ハヤカワ・ポケット・ミステリ、通称「ポケミス」は 1953 年から現在まで刊行が続いている翻訳ミステリのシリーズ。黄色い小口と抽象画の装画による特徴ある装幀を目にしたことのある人は多いと思う。その装幀を手がけていた勝呂忠氏が 2010 年に亡くなり、『虐殺器官』や『これからの「正義」の話をしよう』などの仕事で知られる装幀家の 水戸部功 氏がその跡を継ぎ、デザインも一新された。

ここに並べたのはそのリニューアル後の作品。タイポグラフィを中心に据えたデザインは書店で大いに目を引く。おそらくペンギン・ブックスの Great Ideas シリーズなどを意識されてるのかなとか思うけど、ここでそのデザイン手法などについてどうこう言うつもりはないしそれができるとも思ってなくて、ただ好きなので並べてみたかっただけ。もし僕がいつかまかり間違って本を書くようなことがあればこの方に装幀をお願いしたいなー (妄言)。

JavaScript のビットマスクによるフラグの管理

2012-12-23T00:00:00Z

JavaScript のビットマスクをはじめて使った。というかビット演算子というものに触れるのがそもそもはじめて。最初は何が何やらわからなかったけど、以下のページなどを参考にしつつなんとかやってみた。

状況としては、ユーザー設定のフラグをビットマスクで管理していて、それを API を通じて GET/POST する、という感じ。ここでは例として、アプリケーションのユーザー設定で、各種ソーシャル系サービスと連携するかどうかみたいなデータを管理する場合を想定する。

まず、各フラグのデータを 1、2、4、8… という整数値で定義しておく。こういったデータは定数として扱うのでキーを大文字にすることが多い、らしい。

var social = {
        TWITTER:     1,
        FACEBOOK:    2,
        GOOGLE_PLUS: 4,
        TUMBLR:      8
    };

HTML ではこれらのフラグに対応したチェックボックスを用意し、カスタムデータ属性でフラグの値を埋め込む。これは Underscore.js のテンプレートを使った例で、<%= ... %> の部分が数値に置き換わって出力される。

<label>
    <input type="checkbox" data-flag="<%= social.TWITTER %>">
    Twitter
</label>
<label>
    <input type="checkbox" data-flag="<%= social.FACEBOOK %>">
    Facebook
</label>
<label>
    <input type="checkbox" data-flag="<%= social.GOOGLE_PLUS %>">
    Google+
</label>
<label>
    <input type="checkbox" data-flag="<%= social.TUMBLR %>">
    Tumblr
</label>

テンプレートがロードされたら、API から取得したフラグと各チェックボックスのカスタムデータ属性の値を & 演算子で判定し、アリなら checked にする。この例では 1 つ目と 4 つ目がオンになる。

var flags = 9; // API から取得したフラグ
$('input[type="checkbox"]').each(function () {
    $(this).attr('checked', !!(flags & $(this).data('flag')));
});

データを POST するときは、オンになってるチェックボックスを抜き出して、| 演算子でフラグを立てる (という言い方でいいんだろうか?)。なんかループしなくてもできるやり方がありそうな予感がするけど思いつかない。

var flags = 0;
$('input[type="checkbox"]:checked').each(function () {
    flags |= $(this).data('flag');
});

ビット演算子、『サイ本』では 1 ページ半ほどの扱いで「読み飛ばしても問題ありません」って言ってるし、『The Good Parts』だと「悪いパーツ」に入ってるし、まったく意識したこともなかったけど、やっぱ使うときは使いますね。たしかに一見して何をやってるかわかんなくて、どうやら動いてるもののいまいち不安。結果、「考えた人頭いいなー」といういつもの馬鹿みたいな感想が浮かびました。

小数の桁数と丸め方を制御する Sass 関数

2012-12-25T00:00:00Z

Sass の数値で出力されるのは小数点以下 5 桁までで、6 桁めが四捨五入される (Sass 3.2 のデフォルト設定の場合)。つまり、0.333333... は 0.33333 に、0.666666... は 0.66667 に丸められる。でもたとえば 16px/12px の結果として 1.33333 ではなく 1.34 がほしい、というような場面もある。数値を丸める関数として round()、ceil()、floor() が用意されてるけど、いずれも小数部分を丸めて整数を返すもので、任意の桁を操作するということはできない。というわけで、小数点以下の桁数と丸めを制御する round-decimal()、ceil-decimal()、floor-decimal() という関数を作ってみた。

// Round (四捨五入)
@function round-decimal ($number, $digits: 0) {
    @return to-fixed($number, $digits, 'round');
}

// Ceil (切り上げ)
@function ceil-decimal ($number, $digits: 0) {
    @return to-fixed($number, $digits, 'ceil');
}

// Floor (切り捨て)
@function floor-decimal ($number, $digits: 0) {
    @return to-fixed($number, $digits, 'floor');
}

@function to-fixed ($number, $digits: 0, $round: 'round') {
    $n: 1;
    // $number must be a number
    @if type-of($number) != number {
        @warn '#{ $number } is not a number.';
        @return $number;
    }
    // $digits must be a unitless number
    @if type-of($digits) != number {
        @warn '#{ $digits } is not a number.';
        @return $number;
    } @else if not unitless($digits) {
        @warn '#{ $digits } has a unit.';
        @return $number;
    }
    @for $i from 1 through $digits {
        $n: $n * 10;
    }
    @if $round == 'round' {
        @return round($number * $n) / $n;
    } @else if $round == 'ceil' {
        @return ceil($number * $n) / $n;
    } @else if $round == 'floor' {
        @return floor($number * $n) / $n;
    } @else {
        @warn '#{ $round } is undefined keyword.';
        @return $number;
    }
}

// round-decimal(0.333)    => 0
// round-decimal(0.333, 1) => 0.3
// round-decimal(0.333, 2) => 0.33
// round-decimal(0.666)    => 1
// round-decimal(0.666, 1) => 0.7
// round-decimal(0.666, 2) => 0.67

// ceil-decimal(0.333)     => 1
// ceil-decimal(0.333, 1)  => 0.4
// ceil-decimal(0.333, 2)  => 0.34
// ceil-decimal(0.666)     => 1
// ceil-decimal(0.666, 1)  => 0.7
// ceil-decimal(0.666, 2)  => 0.67

// floor-decimal(0.333)    => 0
// floor-decimal(0.333, 1) => 0.3
// floor-decimal(0.333, 2) => 0.33
// floor-decimal(0.666)    => 0
// floor-decimal(0.666, 1) => 0.6
// floor-decimal(0.666, 2) => 0.66

いずれも引数は丸めたい数値と小数点以下の桁数 (デフォルトは 0)で、関数の実体は to-fixed() という、JavaScript の toFixed() をイメージした関数 (ちょっと違うけど)。たとえば ceil-decimal(0.3333, 2) なら、

@return ceil(0.3333 * 100) / 100

ということになるので、33.33 を切り上げた整数 34 の 1/100、つまり 0.34 が返る。

Gist にも上げときました。関数名が適切かどうかの添削を誰か。

Changes

January 12, 2013 – ソースコード中、to-fixed() 関数のエラー処理と条件分岐を修正

Sass のカスタム関数の書き方

2013-01-06T00:00:00Z

Sass はネイティブ関数のほかに、@function ディレクティブを使ってカスタム関数を自由に定義することができます。僕もより共有や再利用のしやすいものを作るべく試行錯誤していますが、ここではそのうち最近試しているいくつかのパターンについて書いてみました。ご意見求む。

接頭辞

attr() や calc() など CSS のネイティブ関数や percentage() や type-of() といった Sass のネイティブ関数と名前が衝突するのを防ぐため、カスタム関数の関数名に接頭辞をつけることを検討しています。現行の CSS/Sass だけではなく将来追加される新しいネイティブ関数も考慮するとやはり何らかの対策をしておきたいところで、接頭辞は現実的な解であるように思います。Sass リファレンスの関数ディレクティブの項でも以下のように接頭辞の採用を勧めています:

It is recommended that you prefix your functions to avoid naming conflicts and so that readers of your stylesheets know they are not part of Sass or CSS. For example, if you work for ACME Corp, you might have named the function above -acme-grid-width.

もしライブラリのようなかたちで公開するものなら、例に挙げられているようにプロジェクト名を接頭辞にするとよさそうです。たとえば compass-grid-width() とか bourbon-grid-width() とか。もしくは Principles of writing consistent, idiomatic CSS で提案されているように x- が汎用的でいいかなと思うんですが、どうでしょう?

@function x-sprit-unit ($number) {
    // ...
}

@function x-convert-to-rem ($number) {
    // ...
}

エラー処理

渡された引数の型や単位などをチェックし、もし想定したものでない場合は戻り値を変更したり警告のメッセージを出力したりしています。例として数値から単位を取り除く関数を考えてみましょう (なおこの関数は Stack Overflow や jsdo.it などを参考にしました)。

@function x-strip-unit ($number) {
    @return $number / ($number * 0 + 1);
}

この関数は引数として数値が渡されることを想定しているので、もし文字列が渡されるとエラーとなり、コンパイルに失敗します。そこで引数の型が数値かどうかチェックし、もし真なら本来の処理、偽なら @warn ディレクティブで警告し、引数を処理せずそのまま返すようにしてみます:

@function x-strip-unit ($number) {
    @if type-of($number) == number {
        // 通常の処理
        @return $number / ($number * 0 + 1);
    } @else {
        // エラー処理
        @warn '#{ $number } is not a number.';
        @return $number;
    }
}

これでもいいんですが、@return ディレクティブは実行されると処理が関数の呼び出し元に戻る (つまり関数の残りは実行されない) ので、以下のように書くこともできます:

@function x-strip-unit ($number) {
    @if type-of($number) != number {
        // エラー処理
        @warn '#{ $number } is not a number.';
        @return $number;
    }
    // 通常の処理
    @return $number / ($number * 0 + 1);
}

複数の引数を多重にチェックする必要がある場合などはとくに、このようにエラー処理を前半にまとめるとコードの見通しが良くなります。

エラーの場合にどういった値を返すべきかは関数によって違ってくるでしょう。任意の引数をそのまま返すか、null を返すか、あるいは想定される値と見なして通常の処理をするか (たとえば単位の省略を許容するなど)、といったパターンが考えられます。

その関数がいったい何なのかについてコメントを残しておくと、チームのメンバーや未来の自分に感謝してもらえるのでおすすめです。書式はなんでもいいのですが、ほかのプロジェクトで使いまわすことなどを考えると、ある程度スタンダードに添っているといいかなと思い、JavaScript でわりと使われているらしい YUIDoc や JsDoc Toolkit あたりを真似たものを試してみてます。

// Strip unit from number
// @function x-strip-unit
// @param    {Number} $number number to strip unit
// @return   {Number} unitless number
// @example
//     x-strip-unit(-16px)        => -16
//     x-strip-unit(0.5em)        => 0.5
//     x-strip-unit(0.5cm + 10mm) => 1.5
@function x-strip-unit ($number) {
    // ...
}

機能についての簡単な説明に続けて関数名を示し、引数の型と識別子、戻り値の型、あと記述例などが書いてあるといいと思います。なおこれらのコメントは開発のためのものでコンパイル後には必要ないというか残ってるとおかしいので、/* */ 形式ではなく // 形式で。

もちろんこのコメントからドキュメンテーションが自動生成できると面白いんですが、そこまではできてないです。Ruby とか Node とかよくわかんないので… sassdoc ってプロジェクトもあるみたいですがどうなんでしょうね。でもコメントを残すだけでも充分有意義なはずです。

また Sass のドキュメンテーションとともに、CSS のスタイルガイドというものもちゃんとやんなきゃとずっと思いつつやれていないので、合わせて考えたいところですね (新年の抱負)。

NIR for Retina Images

2013-02-18T00:00:00Z

擬似要素と content プロパティを利用した画像置換テクニックの NIR (Nash Image replacement) と、いわゆる Retina ディスプレイ向けの高解像度画像 ([email protected] みたいなやつ) を組み合わせる方法について。まずは NIR についておさらい:

.nir {
    overflow: hidden;
    width: 160px;
    height: 50px;
    *background: url(sprites.png) no-repeat 0 -25px;
    *text-indent: -9999px;
}

.nir:before {
    content: url(sprites.png);
    display: inline-block;
    font-size: 0;
    line-height: 0;
    margin-left: 0;
    margin-top: -25px;
}

要素の幅と高さと overflow: hidden を指定した上で、:before 擬似要素の content プロパティで画像を生成し、テキストをボックスのそとに追い出して見えなくする、というテクニック。スプライト画像の場合は左上からの座標を margin-left と margin-top で指定すれば対応できる。擬似要素をサポートしない IE7 以下では背景画像と text-indent による昔ながらの画像置換でフォールバック。

これを 2 倍のサイズで書き出した高解像度の画像でやるにはちょっと工夫が必要になる。というのも、画像をブラウザで半分に縮小して表示する必要があるわけだけど、content プロパティで生成した画像のサイズは width/height プロパティなどではコントロールできないからだ。背景画像なら background-size が使えるけどもちろんそれも無理。そこで CSS Transforms の scale() 関数を使う:

.nir {
    overflow: hidden;
    width: 160px;
    height: 50px;
}

.nir:before {
    content: url([email protected]);
    display: inline-block;
    font-size: 0;
    line-height: 0;
    margin-left: 0;
    margin-top: -25px;
    -webkit-transform: scale(0.5);
    -ms-transform: scale(0.5);
    transform: scale(0.5);
    -webkit-transform-origin: 0 0;
    -ms-transform-origin: 0 0;
    transform-origin: 0 0;
}

.no-csstransforms .retina-nir {
    background: url(sprites.png) no-repeat 0 -25px;
    text-indent: -9999px;
}

.no-csstransforms .retina-nir:before {
    display: none;
}

このように transform プロパティに scale(0.5) を指定することで画像が半分のサイズで表示される。ちなみに background-size プロパティではこのように画像のサイズを基準にした相対的な指定はできず、画像の実際のサイズを元にした数値を CSS に反映させる必要があるけど、これはシンプルに比率を渡せるのでその点でも便利。

見落としがちなのが transform-origin プロパティで、この初期値が 50% 50% であるため、画像の左上を基点に座標を指定するためには 0 0 を指定する必要がある。

フォールバックとしては transform が使えるかどうかを基準にする必要があるので、Modernizr を利用して、もしサポートしていなければ擬似要素は利用せず「等倍」の画像を背景として表示している。具体的には IE8 以下がその対象。もちろんできれば CSS だけで判別したいけどちょっと思いつかなかった。

これを Sass のミックスインにするとこんな感じ:

// NIR for Retina image
@mixin retina-nir (
    $x:      0,
    $y:      0,
    $width:  null,
    $height: null,
    $path:   "/img/sprites",
    $mod:    "@2x",
    $ext:    ".png",
    $ratio:  2
) {
    @if $x > 0 { $x: -$x; }
    @if $y > 0 { $y: -$y; }
    overflow: hidden;
    @if $width {
        width: if(type-of($width) == number and unit($width) != '%', $width/$ratio, $width);
    }
    @if $height {
        height: if(type-of($height) == number and unit($height) != '%', $height/$ratio, $height);
    }
    &:before {
        content: url($path + $mod + $ext);
        display: inline-block;
        font-size: 0;
        line-height: 0;
        margin-left: $x/$ratio;
        margin-top: $y/$ratio;
        @include transform(scale(1/$ratio));
        @include transform-origin(0 0);
    }
    .no-csstransforms & {
        background: url($path + $ext) no-repeat $x/$ratio $y/$ratio;
        text-indent: -9999px;
        &:before {
            display: none;
        }
    }
}

// transform
@mixin transform ($transform-function) {
    $prefixes: webkit, ms;
    @each $prefix in $prefixes {
        -#{ $prefix }-transform: $transform-function;
    }
    transform: $transform-function;
}

 // transform-origin
@mixin transform-origin ($origin) {
    $prefixes: webkit, ms;
    @each $prefix in $prefixes {
        -#{ $prefix }-transform-origin: $origin;
    }
    transform-origin: $origin;
}

// usage
.nir {
    @include retina-nir($y: -50px, $width: 320px, $height: 100px);
}

実際の作業では Retina サイズの画像をもとに CSS を書くことになると思うので、サイズや位置の引数は縮小した結果ではなく高解像度画像の実際のサイズを基準にした数値を渡し、それぞれ 2 で割るようにしてある (パーセント値の場合を除く)。座標に正の数値を渡した場合に負に変換するのはおせっかいな気もするけど、個人的によく間違うので入れた。transform 関係はほかでも使うので別ミックスインに分けてある。

もちろん、画像置換に限らず CSS generated content には同じ手が使える。

接頭辞つきのクラス名にマッチする CSS セレクター

2013-03-05T00:00:00Z

Kraken というフロントエンドのフレームワークのコードを見ていたら、なるほどと感心する CSS セレクターの書き方を見つけた。grid-one、grid-two みたいな接頭辞つきのクラス名にマッチするセレクターで、こんな感じ:

[class^="grid-"],
[class*=" grid-"] {
    /* ... */
}

単純に考えると [class*="grid-"] でいけそうな気がするけど、それだと foo-grid- みたいに頭に余計なものがついていてもマッチしてしまう。そこでホワイトスペースを接頭辞の前に置いて [class*=" grid-"] とすることでそれを避けている。すると今度は class="grid-one" みたいに class 属性の先頭で頭にホワイトスペースがない場合にマッチしないので、[class^="grid-"] という前方一致のルールを追加。

ひょっとすると [class|="grid"] でスマートに解決できそう、とか思うけど、それだと接頭辞ではない grid クラスもマッチしてしまうし、複数のクラスがあった場合に先頭のものしかマッチしない。| は基本的に言語コード用と考えたほうが良さそう。

この接頭辞パターンの ^ を $ にしてホワイトスペースとハイフンの位置を入れ替えれば接尾辞にマッチするパターンも作れる。

[class$="-item"],
[class*="-item "] {
    /* ... */
}

簡単なデモも書いてみた。

CSS selector matches class prefix/suffix - CodePen

こういう正規表現みたいなの日本語で説明するのすごく面倒…

MathSass

2013-04-14T00:00:00Z

CSS で角度を扱う機会が増えてきたので、三角関数を中心にいくつかの数学関数を Sass 関数として実装してみてる。「三角関数を中心に」とかさらっと書いてるけど、書いてる本人はタンジェントとか高校で習ってないと言い張る程度の理解なので注意。書いてるうちに芋づる式に増えて手に負えなくなってきたところで GitHub に公開することにした。

terkel/mathsass · GitHub

ほんとは Ruby のモジュールで書けば簡単かつ精度も高いだろうし、将来 Sass のネイティブに実装されれば用なしになるわけだけど、勉強になるのでやってて満足度は高い。

これ系の Sass 実装でまとまったものは adambom/Sass-Math と Team-Sass/Sassy-math ぐらいしか見つけられなかったし、これらの中でもものによってバグってるっぽいのもあったので、ほかに 404 Blog Not Found:javascript - Mathを再発明してみたや『C言語による最新アルゴリズム事典』などを参考にした。

今のところの具体的な利用シーンとしては「幅と高さから角度を求める」とか「幅と角度から高さを求める」といったところなので、とりあえずこれで足りてるものの、せっかくなので log() とかもあると格好がつくのかなというのはある。いつ使うのかはさっぱりわからないけど。

あとはテストをちゃんと書きたいんだけど、それぞれの関数で典型的な数値というか、この場合にこの値が得られれば実装として合格、みたいなのがわからないので書けずにいる。答え合わせはブラウザーの JavaScript コンソールで Math.sqrt(2) とかやっておー合ってる合ってるみたいな進め方なのでかなり不安。

そんなわけで math 好きな皆さんのご参加をお待ちしております。

次は行列に挑戦だ!

Ruby で Sass のカスタム関数を書く

2013-05-25T00:00:00Z

Sass で関数を書く方法は 2 つあります。ひとつは Sass の @function ディレクティブを使って Sass ファイル内に定義する方法。

$grid-width: 40px;
$gutter-width: 10px;

@function grid-width ($n) {
    @return $n * $grid-width + ($n - 1) * $gutter-width;
}

簡単かつカジュアルに書ける反面、当然ながら Sass のネイティブ関数やディレクティブの制限を受けるので、できないことも多いです。とくに Sass は文字列系の関数があまり用意されておらず、不満を感じることも少なくありません。

もうひとつの方法は、Ruby でカスタム関数を書いて Sass を拡張する という方法です。Ruby の知識が必要で、かつ Sass ファイルに直接定義するのとは違って別ファイルから読み込む必要があったり、少しハードルが高いのも確かですが、Sass だけでは難しい複雑な処理を書けます。

(ちなみに、以前このブログの記事で @function による関数を「カスタム関数」と書いたことがありましたが、おそらくそっちはただの関数で、Ruby の方をカスタム関数と呼んだ方が良さそうです)

というわけで、Ruby は『初めての Ruby』(おすすめ!) をざっと眺めた程度の理解しかありませんが、カスタム関数を書いてみました。

今回書いたのは escape() という関数です。おもに content プロパティで使うことを想定していて、文字列を渡すと \ と Unicode のコードポイントでエスケープしてくれる、というものです (ちなみに CSS における文字のエスケープについては CSS character escape sequences · Mathias Bynens が良くまとまってます)。たとえば、

.hello {
    &:before {
        content: escape("ヾ(๑╹◡╹)ﾉ");
    }
}

これが、

.hello:before {
    content: "\30FE\28\E51\2579\25E1\2579\29\FF89";
}

こうなります。

これを Sass の @function でやろうとすると、現状ではおそらく巨大な Unicode のテーブルを擬似連想配列っぽいリストに入れて回す、みたいなことになって、あまり実用的じゃありません。やはりここは Ruby でいきたい。そこで、P4D という、プログラマーとデザイナーが集まって何か作ったり相談したりする会があるんですが、そこにお邪魔してルビィストの @satococoa にこういうの作りたいんですけど… とぶつけ、マンツーマンで教えていただきつつ出来上がった (というかほぼ @satococoa が書いた) のがこれです:

module Sass::Script::Functions

    def escape(string)
        assert_type string, :String
        Sass::Script::String.new(string.value.codepoints.map{ |i|
            '\\' + i.to_s(16).upcase
        }.join(''), :string)
    end
    declare :escape, :args => [:string]

end

コードは Sass のドキュメンテーションにある例をもとにしました。

はまったのが string.value の部分で、この .value を抜かして string.codepoints としても動きません。Sass のドキュメンテーションにあるように、String#value メソッドによって文字列が Ruby でいじれるかたちになるらしいです。

あと Ruby の String#codepoints を使っているため、Ruby 1.8 系統では動きません。Mac の Ruby はいまも 1.8 がデフォルトらしいので注意。僕も Qiita の記事を見ながら 1.9.3 にしました。

Sass::Script::String.new() に渡してる 2 つめの引数 :string は quote() 関数のソースにあったのをそのまま持ってきたもので、文字列が " で囲まれて返ってくるみたいです。

で、使い方。まず上記 Ruby コードを functions.rb などとして、プロジェクトの適当なディレクトリに置きます。そして watch するときに、

$ cd /Users/me/Projects/my-project
$ sass --watch ./sass:./css -t compact -r ./sass/functions.rb

というように、-r オプション (--require のショートカット) でファイルへのパスを渡します。こうするとそのファイルを読み込んでくれて、あとは Sass ファイルのどこでも escape() 関数が使えるようになります。ちなみに、パスの先頭の ./ を抜いてディレクトリ名から指定するとなぜかだめっぽいです。

さらに別のカスタム関数があれば、この module Sass::Script::Functions と end の間に突っ込んでいけばそれぞれ動くみたいです (「みたいです」とか「らしいです」とか「っぽいです」とかばっかりで申し訳ないですが…)。

module Sass::Script::Functions

    def escape(string)
    # ...

    def yet_another_awesome_function(number)
    # ...

end

こんな感じで便利関数をまとめておけばプロジェクト間で使いまわすことも簡単です。この functions.rb を、もし中身が空っぽでもプロジェクトごとの Sass ディレクトリに必ず置き、watch 時には require するようにする、という運用にしてもいいかなと思ってます。扱いとしては WordPress の functions.php みたいな感じ。

Ruby のパワーを借りればほんとに色んなことができそうなので、夢が広がる一方、どこまでやっていいんだろうとか、運用がちょっと面倒くさそうとか、バグっても直せなくて泣いちゃうかもとか、素直に Compass 使えやとか、色々と懸念もありますが。

あと、じつは escape() 関数は似たようなプラグインがすでにあったんだけど、そちらは引数の 1 文字目しか見てないのでちょっと違う。やっぱこの手のはマルチバイト圏に暮らす僕たちがこそ頑張りたいですねー。

ヾ(๑╹◡╹)ﾉ Happy styling!

Google Chrome Frame の開発が終了

2013-06-30T00:00:00Z

Googe Chrome Frame の開発終了が発表されました。2014 年 1 月以降はアップデートとサポートもおこなわれないそうです。

HTML に Chrome Frame 用のコードが残っていても、ただちに問題になるということはないと思いますが、これから新たに作るサイトに埋め込む理由はあまりないですし、公開しているサイトで手を入れることが可能なら修正しておくと良いと思います。

<!--[if lt IE 9]>
<p class="ie-prompt">お使いのブラウザはバージョンが古いため、サイトを快適にご利用いただけないかもしれません。<a href="http://browsehappy.com/">最新のブラウザにアップグレード</a> するか、<a href="http://www.google.com/chromeframe/?redirect=true">Google Chrome Frame をインストール</a> してください。<</p>
<![endif]-->

たとえばこのサイトではこのように、古い IE 向けに Chrome Frame のインストールを促すプロンプトを出していました。こういった場合、Chrome Frame へのリンクを消し、代わりに Browse Happy や What Browsers? などに誘導すると良いでしょう。

<meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1">

また、このように X-UA-Compatible に Chrome Frame を有効にする指定がある場合は、chrome=1 パラメーターを削除します。

<meta http-equiv="X-UA-Compatible" content="IE=edge">

静的な Google マップを JavaScript API で差し替える

2013-07-06T00:00:00Z

Google Maps JavaScript API で Google マップを埋め込む場合、当然のことながら JavaScript が有効でない環境では何も起こらず真っ白になってしまう。これを回避するため、まず Google Static Maps API を利用して HTML に静的な画像のマップを埋め込み、そのパラメーターを読み出して JavaScript API に渡して、動的マップで静的マップを差し替える、とやるとうまい具合に解決できそうと思ってやってみた。

<div id="map-container">
    <img src="http://maps.googleapis.com/maps/api/staticmap?markers=35.6604005,139.7290428&zoom=14&size=480x320&sensor=false" alt="...">
</div>

まず HTML には img 要素でマップを画像として配置する。静的マップには JavaScript は不要で、このように src 属性でパラメーターを渡すだけで利用できる。位置は座標の代わりに住所でも指定できるし、マーカーやパスなどけっこうカスタマイズもできる。alt には地図の用途に応じて、たとえば駅からの道順などを入れましょう。

で、この src のパラメーターをパースして JavaScript API に渡す。まずは API の読み込み。

<script src="http://maps.google.com/maps/api/js?language=ja&sensor=false"></script>

そして静的マップからのパラメーターの読み出しとマップの生成。

function initGoogeMap () {
    var mapContainer = document.getElementById('map-container'),
        mapImageSrc = mapContainer.getElementsByTagName('img')[0].getAttribute('src'),
        mapParams = decodeURIComponent(mapImageSrc.split('?')[1]).split('&'),
        mapData = {},
        latLng,
        mapOptions,
        map,
        marker,
        markerLatLng,
        i,
        len,
        pair;
    for (i = 0, len = mapParams.length; i < len; i++) {
        pair = mapParams[i].split('=');
        mapData[pair[0]] = pair[1];
    }
    markerLatLng = mapData.markers? mapData.markers.split(','): null;
    latLng = mapData.center? mapData.center.split(','): markerLatLng;
    mapOptions = {
        center: new google.maps.LatLng(latLng[0], latLng[1]),
        zoom: +mapData.zoom || 16
    };
    map = new google.maps.Map(mapContainer, mapOptions);
    if (mapData.markers) {
        marker = new google.maps.Marker({
            position: new google.maps.LatLng(markerLatLng[0], markerLatLng[1]),
            map: map
        });
    }
}

window.onload = initGoogeMap;

ちょっと雑な気もするけど、center または markers の座標と zoom だけを想定した例だとだいたいこんな感じだと思う。これで <div id="map-container"> の中身が JavaScript API で書き換えられるので、静的マップは削除される。パラメーターの内容によってはもうちょっと複雑になると思うけど、やることは同じで、静的マップの src 属性をパースして JavaScript API に渡すだけ。

これで、JavaScrpt 無効時には静的な画像のマップ、有効時にはインタラクティブなやつ、という出し分けができる。

IE8 で擬似要素のスタイルの動的な更新ができない

2013-07-27T00:00:00Z

JavaScript で要素のクラス属性を操作してスタイルを変更するような場合、IE8 には :before/:after 擬似要素のスタイルが再描画されないというバグがある。

<p>
    <a href="#" class="selected">One</a>
    <a href="#">Two</a>
    <a href="#">Three</a>
    <a href="#">Four</a>
</p>

<script src="//ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js"></script>
<script>
$('p').each(function () {
    var $links = $(this).find('a'),
        i = $links.filter('.selected').eq(0).index(),
        len = $links.length;
    function selectItem () {
        i = (len - i > 1)? i + 1: 0;
        $links.removeClass('selected');
        $links.eq(i).addClass('selected');
    }
    setInterval(selectItem, 3000);
});
</script>

たとえばこんなふうに、一定時間ごとに selected というクラスを持つ要素が切り替わるようなスクリプトがあって、その要素の :before 擬似要素にスタイルを書く、という場合。

a:before {
    background-color: silver;
    content: "";
    display: inline-block;
    height: 1em;
    width: 1em;
}

a.selected {
    background-color: yellow;
}

a.selected:before {
    background-color: green; /* not working in IE8 */
}

グリーンのボックスを持ったリンクが 3 秒ごとに切り替わっていくはずだけど、IE8 では :before で生成したボックスのスタイルが更新されず、初期状態のグレーのまま変化しない。

これを更新させるには、content プロパティの値になんらかの変更を加える必要がある。

a:before {
    background-color: silver;
    content: "";
}

a.selected:before {
    background-color: green;
    content: " ";
}

このように空文字列から空白文字に変更するか、

a:before {
    background-color: silver;
    content: "";
}

a.selected:before {
    background-color: green;
    content: "" "";
}

あるいは空文字列を追加するのでもいい。

Demo: IE8 で擬似要素のスタイルの動的な更新ができない

Stack Overflow の回答が参考になったけど、サンプルがちょっとわかりづらかった。

IE8 には :hover:before (または :hover:after) のスタイルが適用されないというバグがあって、:hover になんらかのスタイルを指定することで回避できるけど、この content 上書きパターンでもいける。スクリプトによる属性の更新とホバーやフォーカスなどが重なると挙動があやしくなることもあるけど、おおむね機能してるっぽいし、正直これ以上あまり深追いしたくない…

MathSass v0.9.1

2013-09-16T00:00:00Z

Sass の数学関数ライブラリ、MathSass を少しアップデートした。

terkel/mathsass · GitHub

おもな変更は log() の実装で、これにより pow() の指数に小数が使えるようになった。また log() に必要な frexp() と ldexp()、定数 $LN2 と $SQRT2 も追加。

今回も 404 Blog Not Found:javascript - Mathを再発明してみたの JavaScript 実装を参考にした、というよりほぼ JS を Sass に翻訳しただけです。dankogai さんありがとうございます。

あと小さなアップデートとして atan2($y, $x) の $x が負のゼロ (-0) の場合の結果を修正した。Sass でゼロが正か負かを判別するには 1/-0.0 == 1/0 という式が必要みたいで、引数に渡すときは -0 ではなく -0.0 とする必要がある。

  -0   == 0   // true
  -0.0 == 0   // true
1/-0   == 1/0 // true
1/-0.0 == 1/0 // false

Compass を使えば pow() の指数に小数使うとかふつうにできるんだけど、なるべくあれを使いたくないという人は僕だけではないだろうし、頭の体操にもなるし、というふうに自分を納得させつつ作業した。

そして今回もちゃんとした数学の知識がないまま突き進んでるので、どうやら期待した値が得られているようだけど自分が何をやっているのかはよくわかっていないという状態で、まじで誰かに添削してほしいです…

v5

2014-01-01T00:00:00Z

久々にこのサイトをリデザインしました。5 代目のテーマです。

もっとも変えたかったところはページのヘッダー部分で、ここをすっきりさせて、記事タイトルが前面に出るようにしたかった。結果、ロゴは Open Sans のイタリックにし、ナビゲーションはフッターに移動しました。ただ about ページへのリンクはページ前半にあった方がいいような気もするので、そのへんはもう少し変えるかも。

いままであった検索フォーム、広告、ソーシャル系などは改めて再検討する予定で、いったん削除しました。そのほかマークアップ、とくに Microdata ももうちょっと見直します。

タイポグラフィ的には、Open Sans とヒラギノ角ゴ、メイリオの組み合わせというベースは従来どおり。ソースコードは Ubuntu Mono、引用はヒラギノ明朝と游明朝にしてみました。スペーシングなどはあまり変えてないです。

あと気づかれなさそうな変更点として、title 要素の記事タイトルとブログ名の区切りを en dash から middle dot (·) に変えました。最近の好み。

Sass のソースコードは GitHub のリポジトリで引き続き公開しています。このリポジトリ、いままでは最初に公開したっきりあまり更新してこなかったんですが、最近はかなり日常的に Git を使うようにもなってきたので、もう少し頑張ります。

ここ数か月わずらっていた「デザインのダサさが気になってブログを更新したくない」という症状が少し落ち着いたので、今年は書くよ!

横に水平線のあるテキスト

2014-01-09T00:00:00Z

[email protected]" width="640" height="240" />

図1：横に水平線のあるテキストの例

おもに見出しなどで見かける、テキストの左右 (またはそのどちらか) に水平線を配置したスタイル。これを CSS で実現する方法について考えてみました。

Demo: 横に水平線のあるテキスト

重ねて隠すパターン

まず最初は、1 本の水平線を幅いっぱいに配置した上で、テキストに重なる部分を隠す、という方法です。

<h2><span>Hello</span></h2>

マークアップはこのように二重の要素が必要です。外側の h2 要素の擬似要素で水平線を作り、内側の span 要素に背景色を指定してテキスト部分を隠します。

h2 {
    position: relative;
    text-align: center;
}

h2:before {
    border-top: 1px solid;
    content: "";
    position: absolute;
    top: 50%;
    left: 0;
    width: 100%;
}

h2 span {
    background-color: white;
    display: inline-block;
    padding: 0 0.5em;
}

コードもさほど複雑ではなく、悪くないように思えます。しかし背景が単色である必要があり、画像の場合には使えません。また単色の場合でも、祖先要素と同じ色をその都度指定する必要があり、使いまわす上でやや難があります。もちろんマークアップを二重にしなければいけない点もマイナスです。

はみ出させて隠すパターン

次は、内側の要素の擬似要素で大きなサイズの水平線を作り、外側の要素ではみ出した部分を隠す方法。マークアップは重ねて隠すパターンと同じく二重になっている必要があります。

h2 {
    overflow: hidden;
    text-align: center;
}

h2 span {
    display: inline-block;
    padding: 0 0.5em;
    position: relative;
}

h2 span:before,
h2 span:after {
    border-top: 1px solid;
    content: "";
    position: absolute;
    top: 50%;
    width: 99em;
}

h2 span:before {
    right: 100%;
}

h2 span:after {
    left: 100%;
}

水平線は内側の span 要素の :before と :after 擬似要素を左右に配置して表現します。これらに 99em など充分な幅を持たせ、はみ出した分は外側の h2 要素に指定した overflow: hidden により切り取ります。もちろん擬似要素の幅は 999% とか 9999px とかでもいいです。

重ねて隠すパターンと比べると、コードはやや複雑なものの、背景のスタイルを問わないという利点があります。しかし外側の要素に指定する overflow プロパティにはマージンの相殺やドロップシャドウの描画などで子要素への副作用があり、できれば利用を避けたいところです。また擬似要素の幅にいわゆるマジック・ナンバーというか、論理的ではない値を指定しなければいけない点に気持ち悪さもあります。二重のマークアップがいまいちなのは重ねて隠すパターンと同じ。

Flexbox パターン

最後は flexbox (flexible box) を利用したパターンです。

<h2>Hello</h2>

マークアップはこのとおり 1 つの要素でいいです。

h2 {
    display: flex;
    align-items: center;
    text-align: center; /* for no-flexbox browsers */
}

h2:before,
h2:after {
    border-top: 1px solid;
    content: "";
    display: inline; /* for IE */
    flex-grow: 1;
}

h2:before {
    margin-right: 0.5em;
}

h2:after {
    margin-left: 0.5em;
}

(CSS の flexbox 関連プロパティは、現時点では多くの環境でベンダー接頭辞が必要ですが、このコード例では記述を省略しています。ベンダー接頭辞を含むコードはデモで確認してみてください)

まず display: flex によって h2 要素が「flex コンテナー」になり、その子要素が「flex アイテム」になります。水平線を表現するのは h2 要素の :before と :after 擬似要素です。「flex コンテナーの直接の子要素であるテキストは匿名の flex アイテムに包まれる」という仕様なので、「左の水平線」「テキスト」「右の水平線」という 3 つの flex アイテムが並ぶことになります。

align-items は flex アイテムの並ぶ方向に対して垂直方向のアラインメントを指定するプロパティです。この値を center とすることでテキストと水平線が上下中央に配置されます。また flex-grow: 1 によって、左右の余ったスペースを埋めるかたちで水平線が広がります。なお、IE10 と 11 では擬似要素の display プロパティに inline block inline-block のいずれかを指定しないと表示されないという現象があり、あわせて指定しています。

この flexbox パターンは多くの点で前の 2 パターンより優れています。まず、祖先要素と同じスタイルを繰り返す必要もなく、子要素のスタイルに影響を与えることもない、ほかの要素から独立した可搬性の高いスタイルである点。そして、本来は必要のない部分を描画をした上で隠すといった遠回りなアプローチではなく、「テキストの左右にコンテンツ幅いっぱいの水平線がある」という本来のデザイン意図をそのまま論理的にコードで表現できている点。

余分なマークアップを必要としないところも大きな利点ですが、それはセマンティクス上の理由もさることながら、こういったスタイルの可搬性や論理的な表現のためにも重要だと思います。

flexbox の仕様は二転三転している上、ブラウザーの実装状況も複雑ですが、こういったほかへの影響の少ないちょっとした装飾から少しずつ採用を進めてみるのもいいんじゃないかと思います。

Bed: Expanded Edition

2014-01-26T00:00:00Z

ファイヴ・サーティ（Five Thirty）が1991年にリリースした唯一のアルバム、“Bed”のエクスパンデッド・エディションが出た。リマスターされたアルバムとシングル収録曲、BBCでのライヴ音源4曲、そして未発表のデモ音源6曲を収録したCD 2枚組。

で、このリマスター音源の出来がとにかくひどい。リンク張っといてなんだけど、はっきり言って買っちゃいけないレベル。まずとにかく曲間のつなぎがめちゃくちゃで、イントロの数秒が削除されちゃってたり、本来はクロスフェードの曲がなぜかいったんフェードアウトしてたり。盤起こしと思われるひどい音質の曲もある。これ担当者は絶対に完成品をプレイバックしてないと思う。なんかのソフトにぶっ込んでプリセットのエフェクトかけたのをそのまま出したみたいな感じ。

そういうわけで買う理由があるとするならライヴ音源とデモ音源なんだけど、こっちも正直あまりぱっとしない。BBCの音源はとくにライヴならではのスリリングな演奏とかスタ録と大きく異なるアレンジが聴けるとかでもなく、あまり面白みが感じられなかった。未発表曲のデモには悪くないのもあるけど、あまり練られていないジャムっぽい曲も多い。ラスト・シングル“You”に収録された‘Cuddly Drug’や‘Slow Train into the Ocean’みたいなクオリティを期待してただけに、ちょっと残念。

また、公式にリリースされた音源のうち本作に収録されていないものもいくつかある。

まず、East/Westからデビューする以前、1985年にOther Recordsから出したEP “Catcher in the Rye”の4曲。内容はかなりヘボいんだけど微笑ましいというか。このEPの曲はすべてコンピ盤The Cutting Edgeに収録されている。

それから1990年にMidnight Musicから出た“Alvin Lives (in Leeds)”というコンピ盤に、ジョージ・ハリソンの‘My Sweet Lord’のカヴァーが収録されているけど、これも未収録。ヴォーカルはポールで、原曲に近いアコースティックな感じではじまって後半はギターがワウワウ言うという、まあ彼ららしい出来。これはCDも出てるんだけどAmazonのカタログには載ってないっぽい。

同じく1990年の“Happy Daze Volume Two”というコンピには‘Something’s Got to Give’の別ヴァージョンが収録されてるんだけど、どうやらこのCDはどれも不良盤らしく、全編にノイズが入っててまともに聴けない。

“Bed”のCDは当時から音がショボい印象があったけど、今回のひどいリイシューを経験して改めて聴いてみると、音圧が低いだけで必ずしも音が悪いわけではないと感じた。1990年頃のCDはどれも音が悪い、リマスター万歳！　という思い込みは捨てることにしました。

Cargo Cult CSS の日本語訳

2014-02-14T00:00:00Z

昨年の 11 月に書かれた Cargo Cult CSS という記事を日本語に翻訳して公開しました。本当は昨年中に公開するつもりが、行き詰まったり放置期間を挟んだりしてるうちにずいぶん時間が経ってしまった。

内容は読んでいただくとわかるとおり、昨今の CSS フレームワークのあり方をかなり厳しく批判するもの。記事中では「カーゴ・カルト」というキーワード自体については説明していないけど、Wikipedia などを読めばつかめると思う。また記事からリンクしている “Cargo Cult Science” - by Richard Feynman というドキュメントは、『ご冗談でしょう、ファインマンさん』で有名な物理学者リチャード・フィリップス・ファインマンがカリフォルニア工科大学の卒業式で述べた式辞で、同書の下巻で日本語訳が読めます。

英語のドキュメントの日本語訳の公開はずっとやりたいと思っていたものの今回がはじめてでした。簡単ではないし時間がかかるけど、じっくり推敲すればちょっとずつ良くなっていくのが感じられてけっこう楽しいです。今後も機会があればやっていきたいと思ってます。

ちなみに翻訳については『英文翻訳術』の多大な影響を受けています。個人的に本当に目から鱗の内容で、自分も翻訳をやってみようと考えるきっかけになった本です。

文書の先頭へのリンク

2014-03-02T00:00:00Z

文書の特定箇所をターゲットとするハイパーリンク、いわゆる「ページ内リンク」で、<a href="#top">Top of the Page</a> のように top というフラグメント識別子を指定すると、それは文書の先頭へのリンクになります。このとき top という名前を持った要素がページの先頭に存在する必要はありません (もし存在すればその要素へのリンクになる)。

…という仕様があることを、つい最近 MDN 経由ではじめて知りました。どうやらもともと一部のブラウザーの独自仕様だったものが HTML5 において仕様に定められた、という経緯のようです。

文書の先頭へのリンクの実装方法としては、コンテンツ全体をラップする #wrapper や #container、あるいは文書の最上部に位置する #header といったフラグメントへのリンクというかたちで実現する例がよく見られます。しかしこれらの手法は、結果的には目的を果たせているように見えるものの、マークアップとしてはあくまで「コンテンツ全体」や「ヘッダー」へのリンクであり、「文書の先頭」へのリンクという本来の意図とは異なるものです。その点、top フラグメント識別子を使うと、そのリンクが文書の先頭へナビゲートすることを目的としたものである、ということを明示できます。

一方で、フラグメント識別子として top というキーワードが予約語のような扱いになってしまう (もし文書中に名前として使えば先頭に戻るリンクが機能しなくなる) のはいまいちです。そう考えると、<a href="#">Top of the Page</a> という空のフラグメント識別子へのリンク (これも top と同様の動作をすると仕様に記されている) を使うか、あるいは button 要素に JavaScript でスクロール処理を持たせる、という方法がいいかなあという気がします。

グラデーションとテキスト・シャドウによるリンクの下線

2014-04-06T00:00:00Z

Crafting link underlines on Medium などで紹介されている、リンクの下線をグラデーションの背景とテキスト・シャドウで表現する手法をこのサイトでも試してみました。やろうとしているのは、下線の色、位置、サイズのコントロールと、ディセンダーと直接まじわらずグリフをまたぎ越すような表現。

a {
    background: linear-gradient(#e00000 50%, transparent 50%) 0 1.25em repeat-x;
    background-size: 1px 2px;
    text-shadow:
        0 1px white,
        0 -1px white,
        1px 0 white,
        1px 1px white,
        1px -1px white,
        -1px 0 white,
        -1px 1px white,
        -1px -1px white;
}

@media print, (-webkit-min-device-pixel-ratio: 1.25), (min-resolution: 1.25dppx) {
    a {
        background-size: 1px 1px;
    }
}

.backgroundsize.cssgradients a {
    text-decoration: none;
}

まず、下線の色と transparent で塗り分けた垂直方向のグラデーションを用意し、水平方向に繰り返します。垂直方向の位置は background-position で指定するわけですが、その基準はフォントやブラウザーによって異なり、かなり微妙な調整が必要。太さは background-size でコントロールでき、画像なので高 DPI の環境では 1px より細くすることも可能です。

ディセンダーと重なる部分は、ボディの背景と同じ色の text-shadow を 8 方向に配置して表現します。そのため背景が写真などの場合は使えません。

なお、このスタイルは CSS グラデーションと background-size がともにサポートされている必要があるので、Modernizr で機能判定をした上でデフォルトの下線を消すようにしています。

Demo: グラデーションとテキスト・シャドウによるリンクの下線

和文まじりの場合はとくに位置の調整が面倒なので、どんな場面にも気軽に使えるというものではないですが、テキスト主体のサイトの本文などでは検討してもいいかなと思いました。

アイコンの実装方法

2014-06-24T00:00:00Z

ウェブページにおけるアイコンの実装方法はさまざまです。マークアップに img 要素を配置する方法もあるし、CSS から背景画像やアイコン・フォントを使う方法もあります。そういった中からどの方法を採用すべきかを判断するには、HTML Standard の Requirements for providing text to act as an alternative for images にあるとおり、「そのアイコンの意味を伝えるテキストが付随するかどうか」を考える必要があります。

テキストが付随しないアイコン

家のアイコンだけでホームページへのリンクを表す場合など、ラベルとしてのテキストが存在しないアイコンは、自分自身でその意味を伝える必要があります。こういったアイコンの実装方法は限られていて、ほぼ 1 つしかありません。alt 属性に代替テキストとしてラベルを指定した img 要素をマークアップに配置する方法です。

<a href="/">
    <img alt="Home" src="icon-home.png">
</a>

CSS による背景画像やアイコン・フォントで表現する方法もありますが、その画像やフォントが意図どおりに読み込まれなかった場合に意味がまったく伝わらなくなってしまいます。必ず、適切な alt 属性をともなった img 要素をマークアップに配置すべきです。

なお、HTML 文書にアイコン画像を埋め込む方法としては、img 要素のほかにインラインの svg 要素も考えられます。ここでは詳しく触れませんが、その場合、title や desc といった要素による代替テキストのほか、foreignObject 要素などによるフォールバックも考慮する必要があるでしょう。

テキストが付随するアイコン

家のアイコンのすぐ下に Home という文字列があるような、その周囲にラベルとしてのテキストがあるアイコンはどうでしょうか。この場合、ユーザーに意味を伝える目的はテキストが果たしており、アイコンの役割はテキストを補助することであると言えます。そのため、アイコンの実装方法の自由度は高いです。

まず、マークアップに画像を埋め込む方法。この場合、代替テキストは空文字列である必要があります。

<a href="/">
    <img alt="" src="icon-home.png">
    Home
</a>

CSS を利用するなら、擬似要素とスプライト画像による方法が手軽です。マークアップにはテキスト以外に追加の要素や属性は必要ありません。

<style>
a[href="/"]:before {
    background: url(sprites.png) no-repeat 0 -160px;
    content: "";
    display: inline-block;
    height: 32px;
    width: 32px;
}
</style>

<a href="/">
    Home
</a>

アイコン・フォントも利用できますが、スクリーン・リーダーを考慮した追加のマークアップなど、安全でアクセシブルな実装を実現するにはそれなりの手間がかかります。

<style>
.icon-home:before {
    font-family: "icomoon";
    content: "\e608";
}
</style>

<a href="/">
    <span class="icon-home" aria-hidden="true"></span>
    Home
</a>

これら CSS を利用した実装は、マークアップに画像を埋め込む手法に比べ、パフォーマンスやメンテナビリティに優れています。しかし、画像やアイコン・フォントが利用できない環境ではアイコンは表示されないため、あくまでラベルとしてのテキストが付随する場合にのみ採用すべき方法です。

レスポンシブなラベル

いわゆるレスポンシブ・デザインでは、こういったアイコンに付随するテキストの有無を、画面のサイズなどによって切り替えたい場合があります。画面が狭いときはアイコンのみで、十分に広ければテキストも表示、というように。

結論から言うと、これを HTML と CSS だけで実装するとどうしても問題の生じる可能性があるため、JavaScript によって DOM を操作するのがより良い実装と考えます。以下、それぞれについて検証してみます。

CSS でテキストの表示を切り替える

テキストが表示されていない状態を考慮し、マークアップには alt 属性にラベルを指定した img 要素を配置します。ラベルとなるテキストは data-* 属性などに保存しておき、メディア・クエリに応じて擬似要素と content プロパティで表示を切り替える、というのが CSS による実装パターンです。

<style>
@media (min-width: 481px) {
    [data-label-text]:after {
        content: attr(data-label-text);
    }
}
</style>

<a href="/">
    <img alt="Home" src="icon-home.png">
    <span aria-hidden="true" data-label-text="Home"></span>
</a>

マークアップの alt 属性と CSS の生成内容で同じテキストが重複することになり、スクリーン・リーダーのユーザーを混乱させる可能性がありますが、この問題は aria-hidden 属性を持った要素を利用することで回避できます。

しかし、視覚系ブラウザーで画像が読み込まれなかった場合、同じテキストが繰り返し表示されてしまいます (この例では Home Home という表示になる)。

逆に、img 要素の alt 属性を空文字列とし、マークアップにあらかじめ含めたテキストの表示を CSS で切り替えるという実装でも、視覚系ブラウザーで画像が読み込まれなかった場合になにも表示されなくなってしまい、やはり問題があります。

このように、HTML と CSS だけによるアプローチでは、画像が利用できない環境に対応しきれません。

JavaScript で DOM を書き換える

理想的な実装は、画面が狭いときは alt 属性の指定された img 要素のみ、広いときは alt が空文字列の img とテキスト、というふうにマークアップを切り替える、ということになります。

<!-- 画面が狭いときは alt ありの img のみ -->
<a href="/">
    <img alt="Home" src="icon-home.png">
    <span class="text"></span>
</a>

<!-- 画面が広いときは alt が空の img とテキスト -->
<a href="/">
    <img alt="" src="icon-home.png">
    <span class="text">Home</span>
</a>

そこで以下のような JavaScript を考えてみました。

<!-- matchMedia() polyfill - https://github.com/paulirish/matchMedia.js -->
<script src="matchMedia.js"></script>
<script src="matchMedia.addListener.js"></script>

<script>
/**
 * Show/hide icon labels using media queries.
 *
 * @param {Object}  images     NodeList of icon images
 * @param {String}  mqString   Media query string
 * @param {Boolean} [fallback] Show label text for no-media-queries browsers
 * @example
 *     var navIcons = document.querySelectorAll('nav img');
 *     responsiveIconLabel(navIcons, '(min-width: 801px)', true);
 */
function responsiveIconLabel (images, mqString, fallback) {

    var mqSupported = window.matchMedia && window.matchMedia('only all').matches,
        textTemplate = document.createElement('span'),
        mql,
        mqListeners = [],
        i,
        len;

    textTemplate.className = 'text';

    for (i = 0, len = images.length; i < len; i++) {
        (function (img) {
            var alt = img.alt,
                txt = textTemplate.cloneNode(false);
            img.parentNode.insertBefore(txt, img.nextSibling);
            if (mqSupported) {
                mqListeners.push(swapAltText);
            } else if (fallback) {
                swapAltText(true);
            }
            function swapAltText (match) {
                if (match) {
                    img.alt = '';
                    txt.innerHTML = alt;
                } else {
                    img.alt = alt;
                    txt.innerHTML = '';
                }
            }
        })(images[i]);
    }

    if (mqSupported) {
        mql = window.matchMedia(mqString);
        mql.addListener(updateIconLabel);
        updateIconLabel(mql);
    }

    function updateIconLabel (mql) {
        var i,
            len,
            match = mql.matches;
        for (i = 0, len = images.length; i < len; i++) {
            mqListeners[i](match);
        }
    }
}
</script>

使い方は、まずマークアップとして alt 属性にラベルのテキストを指定した img 要素を用意します。

<a href="/">
    <img alt="Home" src="icon-home.png" class="icon-home">
</a>

アイコンの画像と、テキストを表示するメディア・クエリ文字列を引数にして、responsiveIconLabel 関数を呼び出します。3 つめの引数ではメディア・クエリをサポートしない環境でテキストを表示するかどうかを指定しています。

var homeIcon = document.querySelectorAll('.icon-home');
responsiveIconLabel(homeIcon, '(min-width: 801px)', true);

MediaQueryList オブジェクトの matches プロパティにより、指定したメディア・クエリにマッチしていれば img の alt を空にして、代わりにテキストを表示します。これは addListener メソッドにより、メディア・クエリの結果が変更されるたびに更新されます。

<a href="/">
    <img alt="" src="icon-home.png" class="icon-home">
    <span class="text">Home</span>
</a>

なお window.matchMedia をサポートしない環境のために matchMedia() polyfill を読み込んでいます。

Demo
Source

MathSass v0.9.3

2014-07-05T00:00:00Z

しばらく放置してた MathSass プロジェクトに、Ruby gem 化するプルリクエストをもらったのでマージした。Ruby gem よくわからないので言われるがままにパブリッシュしたところ、gem の名前が大文字まじりになっており、ちょっと失敗したと思っている。

同時に SassMeister でサポートしてもらえるようにイシューを立てたらその日のうちに採用してもらえた。

その前には npm、Bower、Travis、Grunt、Bootcamp をサポートするプルリクエストというのももらっていて、意外と気に入ってくれる人がいるようでうれしい。

selector-replace() の利用

2014-07-16T00:00:00Z

近々リリース予定の Sass 3.4.0 では、& が SassScript で使えるようになるほか、セレクター関連の関数が大きく充実する。SassMeister ではすでに使えるのでいくつか試してみたけど、セレクターを置換するselector-replace() 関数がかなり便利そう。

使用例としてはまず、ネストしたセレクターで、ルートと直近のセレクターの間に別のセレクターを挿入する、というのが考えられる。

.outer {
    color: red;

    .inner {
        color: green;

        @at-root {
            #{ selector-replace(&, '.outer', '.outer .foo') } {
                color: blue;
            }
        }
    }
}

& で親セレクター .outer .inner を参照し、そのうち .outer を .outer .foo に置換することで、親セレクターの「間」に新たなセレクターを割り込ませるようなかたちになる。

.outer {
    color: red;
}
.outer .inner {
    color: green;
}
.outer .foo .inner {
    color: blue;
}

もうひとつ、汎用的なクラス・セレクターを定義したブロックの中で、要素タイプによる絞り込みができる。

.bar {
    .button {
        border: 1px solid;

        @at-root {
            #{ selector-replace(&, ".button", "a.button") } {
                text-decoration: none;
            }
        }
    }
}

.button という要素を問わないセレクターを定義し、その中で要素タイプが a だった場合に絞り込んだスタイルを書ける。

.bar .button {
    border: 1px solid;
}
.bar a.button {
    text-decoration: none;
}

ぱっと思いついたのはこんなところ。どちらの例も、今までだとルートから書き直す必要があったので、けっこう便利になる気がする。

ただ、まだ検証しきれてないけど、単純な置換ではなく @extend と同様のロジックらしく、直感に反する結果になることもある。最初の例で言うと、selector-replace(&, '.outer', '.outer .foo') ではなく selector-replace(&, '.inner', '.foo .inner') とすると、以下の出力になる。

.outer .foo .inner,
.foo .outer .inner {
    color: blue;
}

@extend 同様、ちょっと理解しづらいので、気をつけないとすぐ複雑になると思う。

@at-root はどうやって使えばいいのかいまいちわからなかったけど、これでようやく活用できそう。

Srcset and sizes の日本語訳

2014-09-09T00:00:00Z

レスポンシブ画像の新しいアプローチである srcset と sizes 属性の入門記事 Srcset and sizes を日本語に翻訳し、srcset と sizes として公開しました。

絵本風のイラストレーションと平易な文章のためとっつきやすそうに見えるものの、内容はかなりややこしいです。というか「レスポンシブ画像がいかにややこしいか」がテーマのようなもので、僕も最初に読んだときはすんなり理解できませんでした。またレスポンシブ・レイアウトをある程度理解していることを前提としているし、ビューポートや画面密度といったキーワード、vw 単位といったものはとくに説明されずに話が進むので、わりかしハードルは低くないです。しかし、いま HTML を書いているひとの多くが直面しているであろうレスポンシブ画像の問題について、入門記事としてうってつけなのは間違いないと思います。とくに、製作者とブラウザーで画像の描画について知っていることが食い違っているというあたりはわかりやすくていいです。

記事中の画像は、Picturefill ライブラリのちからを借りて、実際に srcset と sizes を使っています。Picturefill はいくつかのプロジェクトで使ってみましたが、じゅうぶん実用に耐えるという感触です。

イラストレーションの言葉も日本語に訳されていますが、これは著者のエリックさんがみずから描いてくれたものです。翻訳の許諾を求めるために連絡したところ、快諾してくれたうえ、「おれ、ハイスクール時代に日本語ちょっとやってたし、絵も描き直すよ!」と申し出てくれました。サンキュー、エリック!

和欧混植の条件分岐

2014-09-26T00:00:00Z

CSS によるフォントの和欧混植は、たいがいの場合、font-family プロパティを使ったシンプルな実装で間に合う。ファミリ名をカンマ区切りのリストとして指定すれば、ユーザーのローカル環境に応じて利用可能なフォントが適切に選択される。

html {
    font-family:
        "Helvetica Neue", "Arial",
        "Hiragino Kaku Gothic ProN", "Meiryo",
        sans-serif;
}

しかし、こういったシンプルなアプローチでは実現できないケースもある。「特定の和文フォントが利用可能な場合に、特定の欧文フォントと組み合わせて利用したい」というのがそれ。たとえば、「ヒラギノ明朝か游明朝のいずれかが利用できるなら Times と組み合わせて使いたいが、どちらの明朝体も利用できないなら Helvetica とゴシック体の組み合わせを使いたい」とか。これを実現するには、なんらかの方法でユーザーのローカル環境で利用できる和文フォントを検出し、その結果に応じて欧文フォントを指定する、という条件分岐が必要になる。

任意のフォントがローカルにインストールされているかどうかを検出するには、グリフの幅が 0 のフォントを利用する手法が良さそうだったので、僕も FontDetect という簡単なライブラリを書いてみた。やっているのは、

幅が 0 の A だけのフォントを作り、Data URI で CSS に埋め込む
A のテキストをダミーとして HTML に挿入し、1 のフォントを指定する
目的のフォントファミリを指定し、幅が 0 より大きくなれば true

という流れで、最終的にその結果をModernizr みたいに html 要素のクラス属性に書き込んでいる。

FontDetect.test('mincho', ['Hiragino Mincho ProN', 'Yu Mincho', 'YuMincho']);

この場合、ヒラギノ明朝か游明朝のいずれかが利用できれば mincho、なければ no-mincho というクラス名が html 要素に追加されるので、これをもとに CSS を書き分ければいい。

html {
    font-family:
        "Helvetica Neue", "Arial",
        "Hiragino Kaku Gothic ProN", "Meiryo",
        sans-serif;
}

html.mincho {
    font-family:
        "Times", "Times New Roman",
        "Hiragino Mincho ProN", "Yu Mincho", "YuMincho",
        serif;
}

ウェブフォントの時代になり、こと欧文フォントについては、ユーザーのローカル環境を以前ほどには気にかけることが少なくなった。和文ウェブフォントはまだ気軽に使える状況ではないけど、一方で Windows と Mac に游書体が搭載されたり、源ノ角ゴシックがリリースされたりなど、ローカルでの高品位な和文フォントの選択肢は増えてきている。こういった、ウェブでの和欧混植にまつわる新しい状況を、より効果的に利用する方法のひとつとして考えてみた。

擬似要素を利用したベースライン・グリッド

2014-11-08T00:00:00Z

Fig 1: 擬似要素を利用してテキストをベースライン・グリッドに揃える

CSS でテキストをベースライン・グリッドに揃えるとなると、ベースラインの高さに応じて上下のパディングやマージンを調整するアプローチがよく見受けられますが、あまり実用的なものとは言いがたかったと思います。

p {
    padding-top: 0.30116em;
    padding-bottom: 0.19884em;
    /* ... */
}

しかし、::before と ::after 擬似要素を利用すると、かんたんにベースライン・グリッドに合わせることができます (Fig 1)。

/* Vertical rhythm unit: 0.5rem */

p {
    line-height: 1.5rem;
    margin: 0.5rem 0;
}

p::before,
p::after {
    content: "";
    display: inline-block;
    height: 1.5rem; /* same as line-height */
}

p::before {
    vertical-align: 0;
}

p::after {
    vertical-align: -1rem; /* margin-bottom - line-height */
}

まず最初に、ページを通じて基準になる高さの「単位」を決めます。ここでいう単位は CSS の length の unit ではなく、ページの「縦のリズム」を構成する最小単位のことです。0.5 rem などがわかりやすくて良いと思います。

ボックスの line-height と上下のマージン、パディングは、つねにこの単位の整数倍で指定します。この時点でボックス自体はベースライン・グリッド上に乗りますが、ベースラインの位置は通常のフローのまま (Fig 2)。

Fig 2: 通常のフローでの配置

最初の行の先頭にある ::before 擬似要素が inline-block としてベースライン上に配置されていて、かつ line-height と等しい高さを持つので、行ボックスが上方向に押し広げられるかたちで、最初の行のベースラインがグリッドに合います。

2 行目以降も、line-height が「単位」の整数倍であるため、ベースラインはつねにグリッド上に来ることになります。

そして最後の行の末尾にある ::after の vertical-align に「単位」の負の整数倍を指定して行ボックスを下方向に押し広げるのに加え、下マージンまたはパディングもやはり「単位」の整数倍とすることで、後続するボックスの上辺をグリッドに揃えることができます。

なお、::before と ::after には幅を指定する必要がなく、横方向のレイアウトには影響を与えません。ただし、リスト項目をインライン化したリスト要素 (ol、ul、dl) などでマークアップに改行があると、行頭にスペースが生じる場合があります。これはリスト項目のマークアップの改行を除去したり閉じタグを省略したりすれば回避できます。

もしテーブル要素などでボーダーがあってリズムがずれる場合は、擬似要素の vertical-align をボーダー幅の分だけ調整します (ただし、テーブル要素はボーダーのスタイリングにブラウザーごとの細かな違いがけっこうあり、完璧に揃えるのは難しいかも)。

th,
td {
    border-bottom: 1px solid silver;
    line-height: 1rem;
    /* ... */
}

th::before, th::after,
td::before, td::after {
    content: "";
    display: inline-block;
    height: 1rem;
}

th:before,
td:before {
    vertical-align: -1px;
}

th::after,
td::after {
    vertical-align: -0.5rem;
}

かんたんなデモも用意しました。G キーでガイドラインをトグルできます。

Demo: CSS baseline grid using pseudo elements

この擬似要素を使ったアプローチの難点として、::before と ::after の両方をつねに必要としてしまうところが挙げられます。もしこれらをほかのスタイルに利用している場合はマークアップを追加するしかないです。

また、画像までベースライン・グリッドに揃えるのはおそらく CSS だけでは無理で、vertical-align を middle などにしたうえで、JavaScript で高さを単位の整数倍に調整するなどのアプローチが必要だと思います。

こういったレイアウトは、やりはじめるとパラノイアックに追求したくなりがちですが、やはりやりすぎはよくないです。すべての要素を完全にベースライン・グリッドに合わせるのは、かなりシンプルなページでも難しいし、もしそれができたとしても、その結果として読みやすいものになるかどうかはまた別なので。

CSS コンポーネント試案

2014-12-07T00:00:00Z

pixivのCSSで使われるクラス名ルールを読んで、僕もここ最近 CSS のコンポーネント設計について似たようなことを考えていたので書いてみる。いまのところ試案で、実際のプロジェクトで実践したことはまだない。

ここでいう「コンポーネント」とは独立したスタイルのブロックの意味で、たとえばヘッダーのナビゲーションとか画像のスライダーとかブログ記事のボディとかを指す。このアプローチの狙いとしては前出の記事とほぼ同じで、これらコンポーネントの「ルート」を明確にし、コンポーネント名が衝突しないようにすること。また管理や共有を考え、特殊な命名規則や不自然なマークアップなどはなるべく避けたいというのもある。Sass などの CSS プリプロセッサーを使う前提だけど、なくてもある程度は使える。

まずマークアップでは、コンポーネントのルートとなる要素に、クラス名と同時に data-component という属性を指定する。コンポーネントのルートもその子孫要素も、クラス名に特別な命名規則は設けない。

<div class="imageSlider" data-component>
    <div class="viewport"> ... </div>
    <div class="nav"> ... </div>
</div>

CSS セレクターはつねにコンポーネントをルートにして書き、かつクラス名だけではなく、必ず [data-component] という属性セレクターも指定する。

// _imageSlider.scss
.imageSlider[data-component] {
    overflow: hidden;
    ...

    .viewport { ... }
    .nav { ... }
}

そして、すべてのコンポーネントをそれぞれ個別のパーシャルとし、ファイル名はそのコンポーネントのクラス名とする。たとえば .imageSlider のスタイルは _imageSlider.scss というファイルに定義する。これらのパーシャルを同一ディレクトリに格納すれば、コンポーネントを追加するときにコンポーネント名の衝突を防ぐことができる。

// main.scss
@import "component/heroUnit";
@import "component/imageSlider";
@import ...

コンポーネント名の衝突さえ防げれば、コンポーネント内のセレクターとして要素型 (ul とか em とか) や「素朴な」クラス名 (.title とか .description とか) も使いやすくなる。これらコンポーネント内のセレクターの衝突まで完璧に防ぐのは難しいけど、これは :not() 擬似クラスと > 結合子を使えばできなくはない。

.imageSlider[data-compnent] :not([data-component]) ul,
.imageSlider[data-compnent] > ul {
    list-style-type: none;
    ...
}

こう書けば子孫コンポーネントへの望まない継承を避けられるけど、さすがにすべてのコンポーネントに対してここまでやるのはちょっとやりすぎの感がある。入れ子になる可能性のあるコンポーネントについて個別に対応した方がいいかもしれない。

僕は CSS が壊れやすいものということは承知しているつもりだけど、かといってカスケーディングと継承を忌避したりするようなことはしたくないと思っている。ふつうのセレクターを使ってふつうの CSS が書きたい。またマークアップは簡潔にしたいという気持ちも依然として強いし、class 属性に過剰な役割を追わせるのも気が進まない。というようなことを考えながら、ここらへんが落としどころとして良さそうなのではないかと思いはじめているのがこのアプローチ。

#767676

2015-03-22T00:00:00Z

僕はウェブデザインでグレーのテキストを使うとき、背景色が白（#ffffff）なら、前景色を#767676かそれより暗くするようにしています。これがWCAG 2.0の達成基準「最低限のコントラスト（レベルAA）」を満たすもっとも明るいグレーだからです。

ちなみに、背景色が黒（#000000）のとき上記達成基準を満たすもっとも暗いグレーは#757575です。つまり、#767676または#757575のテキストは、背景が白でも黒でも最低限のコントラストを確保できます。またこれらの背景色と前景色を入れ替えても同様で、#767676または#757575の背景ならテキストが#ffffffでも#000000でもOKです。

フォントのサイズやウェイトによってはこの限りではないし、背景色が真っ白や真っ黒でない場合はツールなどを使って検証する必要がありますが、とりあえずこの#767676という値を覚えておくとけっこう便利です。

游とMerriweather

2015-04-30T00:00:00Z

少し前にこのサイトのデザインをちょっと変えて、「本文は明朝、ただし見出しや強調などはゴシック」というスタイルにしています。と言っても、本文が明朝で表示されるのは游明朝体かヒラギノ明朝体が使える場合だけで、それ以外の環境ではゴシックになるはずです。

欧文書体は和文の従属欧文ではなくMerriweatherです。セリフとサンセリフのファミリーがあることと、エックスハイトが高く和文との相性が良いことから選びました。ウェイトは和文とのバランスから400ではなく300を使っています。MerriweatherはGoogle FontsやTypekit、Font Squirrelなどで入手できます。

CSSの指定としては、まずデフォルトがMerriweather Sansとゴシック体の組み合わせ。そして游明朝体またはヒラギノ明朝体が使えるかどうかをJavaScriptで検出し、もし使えれば本文でMerriweather（serif）と組み合わせます。ただし、見出しやテーブル、ボールドになる部分などはサンセリフとゴシックです。明朝体が使えるかどうかの検出には、FontDetectという自作のライブラリを利用しています。明朝が使える場合はhtml要素にminchoというクラス名がつくので、これでスタイルを分岐させます。

$font-family-serif:  "Merriweather";
$font-family-sans:   "Merriweather Sans";
$font-family-mincho: "Yu Mincho", "YuMincho", "Hiragino Mincho ProN";
$font-family-gothic: "Yu Gothic", "YuGothic", "Hiragino Kaku Gothic ProN", "Meiryo";

html {
    font-family: $font-family-sans, $font-family-gothic, sans-serif;
}

.mainBody {
    .mincho & {
        font-family: $font-family-serif, $font-family-mincho, serif;

        h2, h3, h4, h5, h6,
        blockquote, dt, figure,
        em, strong, dfn, i, b,
        table {
            font-family: $font-family-sans, $font-family-gothic, sans-serif;
        }
    }
}

けっこう気に入ってます。

ペンケース

2015-06-06T00:00:00Z

こないだはじめてTOEICを受験したんだけど、当日の持ち物を準備してるとき、まともなシャーペンやペンケースを持ってないことに気づいて、ちゃんと買うことにした。

シャーペンは製図用が良いらしいと聞いて、ぺんてるのグラフギア500にしてみた。がっしりしてるし適度に重くて書きやすい。店頭でいくつか試したけど、グラフギア1000は重心が高い気がしたし、ステッドラー925はちょっと軽い気がした。ここ数年、自前の筆記具はLamyのSafari万年筆と、ほぼ日手帳のおまけについてくるジェットストリームの3色ボールペンぐらいしか使ってなくて、シャーペン買うのもたぶん20年ぶりとかだと思う。

ペンケースはBuilt NYのMakeup Brush Caseというのがちょうど良さそうだったので取り寄せてみたらぴったりだった。Builtの製品はMacBookのスリーブを買って以来かなり好きで、小物入れのようなものとかKindleのスリーブとかも愛用してる。

中身がシャーペンと消しゴムだけなのはさびしいので、定規とかスティックのりとかちょっとずつ買い揃えてる。いままで文具にそこまでの関心はなかったんだけど、なんか楽しくなってきた。

input要素のline-height

2015-08-06T00:00:00Z

FirefoxのUAスタイルシートではinput要素のline-heightプロパティにnormal !importantという値が指定されていた。このため製作者がline-heightをコントロールできず、フォーム部品のスタイリングが難しい原因のひとつになっていた。これは修正される見込みがなく、「死ぬまで付き合うことになりそう」とまで言われていたが、2014年6月にリリースされた Firefox 30で!importantが削除され、上書きできるようになっていたらしい。

長生きはするものだという感想。

行の長さ

2015-08-30T00:00:00Z

ウェブページの和文横組みの本文で、適切な行の長さはどのくらいか。もちろんこれは一概に言えるものではなく、内容、デバイス、書体、行間など、様々な要素に左右されます。しかし多くの場合、読みやすい行の長さは24字から40字程度で、長くても48字程度までにすると良い、というのが僕の意見です。これは僕の感覚もありますが、以下のようなガイドラインや実例を参考にしています。

まず欧文の場合、『The Elements of Typographic Style』にある「45字から75字」というガイドラインがスタンダードとして広く受け入れられているらしく、ウェブ・デザインについての書籍やブログ記事でも多く参照されています。

Anything from 45 to 75 characters is widely regarded as a satisfactory length of line for a single-column page set in a serifed text face in a text size. The 66-character line (counting both letters and spaces) is widely regarded as ideal. For Multiple-column work, a better average is 40 to 50 characters.

If the type is well set and printed, lines of 85 or 90 characters will pose no problem in discontinuous texts, such as bibliographies, or, with generous leading, in footnotes. But even with generous leading, a line that average more than 75 or 80 characters is likely to be too long for continuous reading.

ウェブではWCAG 2.0にテキストブロックの幅についてのガイドラインがあり、行の長さが80字（CJKの場合は40字）を超えないように、としています（1.4.8 Visual Presentation）。

For people with some reading or vision disabilities, long lines of text can become a significant barrier. They have trouble keeping their place and following the flow of text. Having a narrow block of text makes it easier for them to continue on to the next line in a block. Lines should not exceed 80 characters or glyphs (40 if CJK), where glyphs are the element of writing in the writing system for the text.

Kindle電子書籍リーダーには、文字のサイズやページの余白をコントロールする機能があります。手元のKindle Voyageでは、和文横組みの書籍を横画面モードで表示し、文字サイズとページ余白をともに最小にしたとき、1行は45字でした（ちなみに縦組み・縦画面では46文字）。

日本語で書かれたデザインの本でも和文横組みのガイドラインを探してみましたが、あまり見つけられていません。『デザインの教室手を動かして学ぶデザイントレーニング』では20字から30字程度が読みやすいとし、15字は「少し短い」、40字は「あまり推奨できない」、50字は「限界を超えている」とのことです。『タイポグラフィの基本ルール』では、30字から40字程度が最長、13字から15字程度を最短としています。

また、手元にあったオライリー・ジャパンの技術書のいくつかで実際の文字数をカウントしてみたところ、もっとも短いもので42字、長いものは48字でした。和書としてはやや長めの印象を受けます。

ちなみに、42字の『メンテナブルJavaScript』と48字の『JavaScript 第6版』を比較すると、判型は同じであるため、文字サイズは当然後者の方が小さいのですが、ページあたりの行数はどちらも38でした。つまり行が長いほど行間が広くとられていることになります。これはウェブ・デザインでも同様で、行が多少長くても行間を広くすることで読みやすくできるし、逆にモバイルなどで行の長さが制限される場合は行間を詰めると良いです。

以上をざっくり総合して、読みやすい上限は40字程度かな、と考えました。個人的な感覚から言ってもだいたいそのくらいです。これを「45字から75字程度が読みやすいが、場合によっては90字程度もあり」という欧文のスタンダードに当てはめてみると、「24字から40字程度が最適、長くても48字程度まで」という和文横組みのガイドラインが導き出されます。実際には、内容やほかのデザイン要素を考慮して調整することになりますが、おおむねこのあたりを基準にして良さそうな気がします。

庭

2015-10-31T00:00:00Z

千葉から東京へ引っ越してきてひと月ほどたつ。

新しい住まいには狭い庭があって、いまこれを書いている部屋からも障子のむこうに見える。とは言えまだなにも置いていないので、少し雑草の生えた地面と古いブロック塀しか見えない。殺風景なのでなにか緑を植えたい。

この庭をたまに猫が横切っていく。こちらに気づいても一瞥をくれるだけで通り過ぎ、隣家のエアコンの室外機の上に腰を落ち着けるのがいつものパターン。そしていつの間にかいなくなってる。見かけると少しうれしい。

こないだ、晴れて暖かかった日、縁側に腰掛けて靴の手入れをしているとき、ああここに住んで良かったなと思った。

CSSカスタム・プロパティへの期待

2016-02-29T00:00:00Z

“Why I’m Excited About Native CSS Variables”という、CSSカスタム・プロパティ（CSS変数）を紹介する記事を日本語に翻訳し、「僕がネイティブなCSS変数にわくわくする理由」として公開した。元記事から3カ月近くたってしまい、旬を逃した感もあるけど、近々カスタム・プロパティがChromeとSafariの安定版でもサポートされるというタイミングなので、まあいいかと思って公開した。

僕はこの記事を読むまで、CSSカスタム・プロパティの存在は知っていたもののほとんど注意を払っておらず、当面はSassがあるしべつにいいやと思っていたという、まさに記事の想定読者の典型だったと言える。でもこれを読んで考えをあらためました。個人的には、Sassにはじめて触れたとき以来と言っていいくらいの驚きがあった。

記事の例にあるように、レスポンシブ・デザインやコンテクスチュアル・スタイリングなどにおいて威力を発揮するのは間違いないけど、僕がとくにうれしいのはレスポンシブなタイポグラフィが実現しやすくなるという点だ。現状ではメディアによってフォントサイズを変更するくらいは容易だけど、行間やスペーシング、見出しのバランスなど、サイズではなくプロポーションをレスポンシブにするのはものすごく骨が折れる。このサイトではなんとか頑張ろうとしてるけど、絶望的にめんどくさい。これがカスタム・プロパティによってようやく可能になるというか、カスタム・プロパティが利用できるようになるまではレスポンシブなタイポグラフィはあきらめたほうがいいんじゃないかと思いはじめている。

ただ実際問題としては、フォールバックを書くのがかなり大変というかどう書きゃいいんだというのがある。なにしろCSS設計の根幹をなすところなので、慎重にならざるを得ないというのもある。でもFirefoxではもうサポートされてるし、さっき書いたとおりChromeとSafariももうすぐ、そしてなにより多くの問題を解決する可能性を持った強力なフィーチャーなので、少しずつプロジェクトに取り入れていく方法を探ってみたい。

というわけで、僕もCSSカスタム・プロパティにわくわくしてます。少なくとも、CSSの未来を明るくしてくれるもののひとつだと思う。

ウェブサイトでシステムフォント

2016-05-05T00:00:00Z

GoogleのRobotoや、AppleのSan Franciscoなど、OSベンダーが独自のフォントを開発し、自社製品のUIにシステムフォントとして採用する、という事例が相次いでいます。これらのフォントは、プラットフォームの特性を考慮して最適化されたもの（あるいは最適なものとして選ばれたもの）と言え、かつ今後のOSのアップデートにともなってさらに改善されることも期待できます。また、ユーザーがそのシステムを操作するときにもっとも頻繁に触れる、つまりもっとも見慣れているフォントでもあります。というわけで、これらシステムフォントをウェブサイトのUIに採用するというのはかなり良いアイデアに思えます。

一方で、システムフォントはあくまでUIのためのもので、長い文章などには向かない場合もあるので、コンテンツ部分は別のフォントを指定すると良いかもしれません。たとえばMediumなどではそのようなアプローチをとっています。ただそういった場合、欧文なら本文にウェブフォントを採用することが多いですが、和文ではその方法にかなりのコストがかかります。ローカルのフォントを指定するにしてもスタックが複雑になりがちで、テストもたいへんです。そこで、sans-serifなどのジェネリックな指定にとどめ、ユーザーエージェントの設定に委ねるという選択肢を検討しても良いと思います。つまり、UIはシステムに寄せて、コンテンツはユーザーに寄せる、という方向です。

/* For UI */
html {
  font-family: -apple-system, BlinkMacSystemFont,
    "Segoe UI", "Helvetica Neue",
    "Hiragino Sans", "Hiragino Kaku Gothic ProN", "Meiryo",
    sans-serif;
}

/* For content */
.ArticleBody {
  font-family: sans-serif;
}

このコード例では、デフォルトはシステムフォントで、本文のみユーザーエージェントに応じたサンセリフ体で表示されることを意図しています。UbuntuやFirefox OSなんかも考えるともうちょっと追加する必要があるかもしれませんが、だいたいはこんな感じでカバーできると思います。以下、CSSでシステムフォントを指定する際のポイントをいくつか。

MacとiOSでSan Franciscoを指定するには-apple-systemというキーワードを使うが、MacのChromeのみBlinkMacSystemFontキーワードが必要1
MacのChromeとFirefoxでは@font-familyのsrcディスクリプタで-apple-system/BlinkMacSystemFontキーワードを利用できない
Mac Yosemite以前のためのフォールバックとしてHelvetica Neueを指定
MacでSan Franciscoとウェイトを合わせるためヒラギノ角ゴに優先してHiragino Sansを指定
Widnows 10の日本語システムフォントはYu Gothic UIだが、あまり評判が良くないらしいので、メイリオの方が良さそう
Android 6.0のシステムフォントはRobotoとNoto Sans CJK JPだが、RobotoとNoto Sans CJK JPというフォント名は無効で、sans-serifキーワードで指定2

ここ数年、ウェブフォントが普及したり、MacとWindowsに游書体という共通のフォントが搭載されたりなど、デザイナーの意識が「ことなる環境でも同じフォントで表示できる」という方向に向かいやすい状況だったように思います。しかし言うまでもなく、環境がことなれば最適なタイポグラフィもことなるし、またユーザーの好みが様々であることも依然として変わりません。ここで紹介したアプローチは、プロモーションやブランディングを目的としたサイトなど、UIも含めてページ全体の印象をコントロールしたいような場合はちょっと違うかも知れませんが、とくにアプリケーション寄りやメディア系のサイトなどでは、有力な候補のひとつになるのではないかと思います。

脚注

Mojik

2016-07-20T00:00:00Z

Mojikという、ウェブにおける和文の文字組みをコントロールするためのJavaScriptライブラリを公開しました。いまのところ、以下のパターンでの「アキ」を調整できます。

連続する約物のアキ
行頭の始め括弧のアキ
欧文間のアキ

Mojik.compose()メソッドの引数にCSSセレクターを渡すと、マッチする要素から上記に該当する箇所を検出し、それぞれマークアップが挿入されるので、CSSでアキ量を調整します。以下のページに実際に動いているデモがあるので、ぜひ見てみてください。

Mojikデモ

ウェブページの本文やタイトルなどで使われることを想定しているので、HTMLタグがあっても問題なく動作することは必須条件でした。基本的に、まずHTML文字列をテキストとタグに分けて、正規表現でテキストの検索を繰り返す、という方法を採っています。ここらへんはkotarok/jQuery.waokonなどを参考にさせてもらいました。

そのほかとくに面倒だったのは、行頭始め括弧の検出です。括弧の位置を親要素と比較して、左端にあれば行頭と見なし左マージンに負数を指定する、というところまではいいのですが、マージンを調整した結果、場合によっては始め括弧が前の行の行末に収まってしまうことがあります。そこで、括弧の前に空のspan要素を挿入し、括弧が行頭に来たときにはCSSの擬似要素で改行することで括弧を行頭に固定する、ということをしています。そしてもちろん、この処理はウィンドウのリサイズごとに再計算されます。

これを本格的に作り始めたのは、YakuLigaと約猫に触発されたことがきっかけでした。言うまでもなく、こういったことはブラウザーがうまいことやってくれればそれに越したことはないわけですが、それでもいまあるもので可能な限りなんとかしてみよう、という試みとして作ってみました。

バージョンはまだ0.1で、アクセシビリティやパフォーマンスのテストもできてないし、デフォルトのアキ量が適切かどうかなど自信のないところもあります。機能ももうちょっと充実させたくて、とくにオプションはうまいこと指定できるようにしたいです。というわけで、issueやpull requestは大歓迎です。お待ちしています。

Mojik on GitHub

リンクのURLを欄外に配置して印刷する

2017-07-05T00:00:00Z

印刷向けCSSの手法のひとつに、擬似要素とattr()関数を使ってリンクテキストの後ろにURLを挿入する、というものがあります。BootstrapやHTML5 Boilerplateなどでも取り入れられているものです。

a[href]::after {
  content: " (" attr(href) ")";
}

簡単かつ効果的ではありますが、挿入されるURLによってテキストが分断されてしまうので、どうしても本文が読みにくくなりがちです。URLが長い場合はとくに。

そこで、URLをページの欄外に配置し、番号を振ってリンクテキストと結び付ける、という「傍注」形式にすれば、本文が読みやすく、かつURLも必要に応じて参照できて良いのではないかと思います。

これはカウンターとフロートを利用した簡単なCSSで実現が可能です。main要素内のリンクを対象にする場合のコードのうち、必要最低限の部分を抜き出すと以下のようになります。

/* カウンターの初期化と余白の確保 */
main {
  counter-reset: sidenote;
  margin-right: 14rem;
}

/* カウンターのインクリメント */
main a[href] {
  counter-increment: sidenote;
}

/* リンクテキストに番号を振る */
main a[href]::after {
  content: counter(sidenote);
}

/* リンクURLを生成し欄外に配置 */
main a[href]::before {
  content: counter(sidenote) ". " attr(href);
  clear: right;
  float: right;
  margin-right: -14rem;
  width: 12rem;
  overflow-wrap: break-word;
}

a要素ごとにインクリメントしたカウンターの数値を、::afterと::beforeそれぞれで利用するところがポイントです。::afterでリンクテキストに番号を振り、::beforeで同じ番号とともにURLを生成します。生成したURLを欄外に配置するには、mainのマージンまたはパディングで左右どちらかにスペースを作った上で、floatでその方向に浮動化し、負のマージンで位置を調整します。またURLの折り返しを許容するためにoverflow-wrapプロパティも指定しています。

リンクのURLだけでなくabbrやdfn要素のtitle属性なども同様に表示できます。その場合、複数の要素で同じカウンターをインクリメントすることになります。

main a[href],
main abbr[title],
main dfn[title] {
  counter-increment: sidenote;
}

main a[href]::after,
main abbr[title]::after,
main dfn[title]::after {
  content: counter(sidenote);
}

main a[href]::before {
  content: counter(sidenote) ". " attr(href);
}

main abbr[title]::before,
main dfn[title]::before {
  content: counter(sidenote) ". " attr(title);
}

いまやウェブページを印刷したいという需要はかなり減ったように思いますし、印刷向けCSSというものが話題に上ることもあまりないですが、このサイトのCSSを久しぶりに書き直すうちに思いついたので書いてみました。

Mojik v0.3.0

2017-07-12T00:00:00Z

Mojikのv0.3.0をリリースした。新しい機能として、連続したダッシュ（U+2014 EM DASHまたはU+2015 HORIZONTAL BAR）をつなげるという、いわゆる2倍ダッシュのオプションを追加した。つなげると言っても、実際にはCSSで2つのダッシュのうち一方を横に広げて、もう一方を隠す、という実装。ちなみに源ノ角ゴシック・源ノ明朝はダッシュが連続するとリガチャになる。そっちの方がスマートでいいので、この機能はデフォルトで無効にしてある。そのほかの変更は、印刷時にリフローするようにしたり、欧文扱いになってた米印を和文扱いにしたりとか。

最近このサイトで実際に採用してドッグフーディングするようにしたところ、色々とあらが見えてきた。昨年の夏頃からしばらく開発が滞ってたけど、もうちょっと本腰を入れるつもりです。

Disco é Cultura

2017-09-04T00:00:00Z

Disco é Culturaという、友人のラバーガード・レコードが主催するDJイベントのウェブサイト作りをお手伝いしました。なにしろ時間がなかったので作りはちょっと粗いんですが、CSS Gridをはじめて実戦で使えたのは良かったです。イベントは9月18日、場所は代官山ユナイスです。ご興味のある方はぜひ。

San Franciscoと日本語フォント

2018-07-25T00:00:00Z

CSSでSan Franciscoフォントを指定しようとすると、特定の状況で日本語フォントがHiragino Kaku Gothic Interfaceというフォントに固定され、日本語フォントが指定できなくなる、という問題があります。たとえば以下のようなCSSの場合、日本語がヒラギノ角ゴではなくHiragino Kaku Gothic Interfaceになります。

body {
  font-family:
    -apple-system, BlinkMacSystemFont,
    "Hiragino Kaku Gothic ProN", sans-serif;
}

このHiragino Kaku Gothic Interface（正式名称不明）は、おそらくヒラギノ角ゴをSan Franciscoに調和するよう調整したものと思われます。一見ヒラギノ角ゴと見分けがつかないのですが、文字サイズがひとまわり小さいのが問題です。つまり、16pxを指定した文字の幅が16pxにならないないのです。

現時点で僕が把握している限り、SafariとChromeでこの現象が見られます。それぞれの発生条件について解説します。

Safari

SafariでSan Franciscoを表示するにはfont-familyプロパティにsystem-uiもしくは-apple-systemキーワードを指定します。しかしこれらのキーワードのいずれかを指定すると、和文フォントがHiragino Kaku Gothic Interfaceに固定されます。どうやらiOS 11、macOS 10.13（High Sierra）からの仕様のようです。

Chrome

ChromeでSan Franciscoを表示するにはfont-familyプロパティにBlinkMacSystemFontキーワードを指定します。lang属性の値がjaかzhの場合は問題ないのですが、それ以外（enなど）の場合、和文フォントがHiragino Kaku Gothic Interfaceに固定されます。たとえば、GitHubのサイトはlangがenなので、ChromeとSafariでは日本語のフォントサイズがFirefoxに比べてひとまわり小さく見えます。

対策

そもそも環境によって文字サイズが違って見えても気にならない、と言うならそのままでもいいでしょう。また、もしSan Franciscoを使う箇所に日本語がない、もしくはごく少ないという場合もあまり問題にならないかもしれません。ただ、日本語の本文などでSan Franciscoを指定している場合、実際に表示を比べるとその違いは明らかで、もしデザイナーが綿密に文字サイズを設計しているなら、許容できる範囲を超えているように思います。

解決策として、unicode-rangeを使って欧文にだけSan Franciscoが適用されるようにするという手もあります。

@font-face {
  font-family: "SF Latin";
  src: local(-apple-system);
  unicode-range: U+0000-00FF;
}

body {
  font-family: "SF Latin", sans-serif;
}

この方法はSafariには有効ですが、残念ながらFirefoxは@font-faceルールのsrcディスクリプタで-apple-systemが無効になってしまいます。環境がiOSに限られるならありかもしれません。

結論

個人的には、San Franciscoはとても優れたフォントだと思うので、ぜひウェブでも使いたいものの、少なくとも日本語のサイトでは採用を見送るのが無難と思っています。ちなみに代替としてはRobotoが使いやすくて好きです。

参考資料

ios11以前と以降での、-apple-systemの表示 - Qiita

Sassで角度の単位を変換

2018-09-04T00:00:00Z

Sassで角度の単位を変換する関数を書いてた。

$PI: 3.141592653589793;

@function convert-angle($angle, $to-unit) {
  $from-unit: unit($angle);
  $from-value: strip-unit($angle);
  $factors: (
    rad: 1,
    deg: 180 / $PI,
    grad: 200 / $PI,
    turn: 0.5 / $PI
  );

  @if not map-has-key($factors, $from-unit) {
    @warn '`#{$angle}` is not an <angle>.';
    @return false;
  }

  @if not map-has-key($factors, $to-unit) {
    @warn '`#{$to-unit}` is not a valid <angle> unit.';
    @return false;
  }

  $rad-value: $from-value / map-get($factors, $from-unit);
  @return $rad-value * map-get($factors, $to-unit) + $to-unit;
}

@function strip-unit ($number) {
  @if unitless($number) {
    @return $number;
  } @else {
    @return $number / ($number * 0 + 1);
  }
}

単位を取り除いた上でいったんrad単位の値に変換し、さらにそこから指定の単位に変換する、という実装。

でも実は、知らなかったんだけど、Sassはネイティブで単位の異なる角度の演算ができる。

@debug 180deg + 0.25turn + 100grad; // 360deg

演算結果は最初に登場した単位になる。これを応用して、値が0の角度を使えば単位の変換はごく簡単にできる。たとえばdegからradへ変換するにはこう。

@debug 0rad + 180deg; // 3.14159rad

つまり冒頭の関数はまったく不要。どうやら4年前のSass 3.4からの話のようで、<angle>と同じように<time>、<frequency>、<resolution>も単位の異なる演算ができる。半日無駄にした。

従属欧文のイタリック

2019-04-20T00:00:00Z

和文フォントはイタリックの従属欧文が含まれないことがけっこうある。たとえばヒラギノ明朝や源ノ明朝にはイタリックの欧文がなく、CSSでfont-style: italic;としても、ブラウザが擬似的に傾けるだけの、いわゆる「にせイタリック」になってしまう。そういった場合は欧文フォントを使うことになるが、ウェブでは欧文のサイズやウェイトを和文と調和するよう調整するのが難しいので、できれば従属欧文をそのまま使いたい。

最近はそういった要望に応えてくれるような、イタリックの従属欧文を持つ和文フォントが増えてきたようだ。ただ、CSSでイタリックを指定する方法はフォントによって異なり、font-familyプロパティを使うものとOpenType機能を使うものがある。

WindowsのメイリオやAdobe Fontsの貂明朝・貂明朝テキストなどはシンプルで、font-styleの値をitalicとすれば、和文は傾かずに欧文だけがイタリックになる（というか通常の和文とイタリックの欧文を組み合わせたフォントが選択される）。イタリック体がファミリー内のいちフォントとして用意されているので、ウェブフォントサービスの書体リストなどを見たときにイタリックの存在がわかりやすい。

em, i {
  font-style: italic;
}

一方、Macの游明朝体、Adobe Fontsの秀英明朝や凸版文久ゴシックなどは、OpenType機能のitalによるイタリックが使える。これらのフォントではfont-style: italic;を指定しても「にせイタリック」になってしまうため、まずnormalで立体にした上で、font-feature-settingsプロパティにitalキーワードを指定する。もちろんイタリックになるのは欧文だけで、和文は変化しない。

em, i {
  font-style: normal;
  font-feature-settings: "ital";
}

OpenType機能はフォントごとにどれが使えるのか分かりづらく、だいたい実際に試してみるまで気づかない。僕も游明朝体でitalが使えるのを今日はじめて知った。

アスペクト比の異なる画像を同じ面積で表示する

2019-05-23T00:00:00Z

ブログ記事の本文などで幅100%の画像を配置する場合、縦長の画像がやたらでかくなってしまったりなど、画像のアスペクト比によってその印象が大きく違ってしまうことがある。これをアスペクト比に関わらず大きさが揃って見えるようにしたい。それには各画像の面積が同じになるように幅をコントロールできればいいのではと考え、CSSでやってみた。

まず基準になる画像として、もっとも横長な画像のアスペクト比を決める。ここでは例として16 : 9とする。この16 : 9画像の幅を100%として、それ以外のアスペクト比の画像の相対的な幅を求めていく。

HTMLでは、各img要素のstyle属性に、アスペクト比を分数形式にしてカスタムプロパティとして指定する。

<img src="cat.jpg" style="--aspect-ratio: 16/9;">
<img src="dog.jpg" style="--aspect-ratio: 1/1;">
<img src="cow.jpg" style="--aspect-ratio: 2/3;">

次にCSSで、画像の面積とアスペクト比ををもとに幅を指定する。面積がSでアスペクト比がa : bの画像の幅xを求めるとすると、

x * x/(a/b) = S

なので、すなわち

x = √(S * (a/b))

となる。つまりCSSで平方根を求める必要がある。これにはvar()とcalc()を使って「バビロニアン・メソッド」と呼ばれるアルゴリズムを実装する。

img {
  --w: 16;
  --h: 9;
  --s: calc(var(--w) * var(--h) * var(--aspect-ratio));
  --x0: calc(var(--s) / 2);
  --x1: calc((var(--x0) + var(--s) / var(--x0)) / 2);
  --x2: calc((var(--x1) + var(--s) / var(--x1)) / 2);
  --x3: calc((var(--x2) + var(--s) / var(--x2)) / 2);
  --x4: calc((var(--x3) + var(--s) / var(--x3)) / 2);
  --x5: calc((var(--x4) + var(--s) / var(--x4)) / 2);
  --x6: calc((var(--x5) + var(--s) / var(--x5)) / 2);
  width: calc(100% * var(--x6) / var(--w));
}

--wと--hは基準の画像の相対的な幅と高さ。この面積と対象の画像のアスペクト比をかけ合わせた数値--sの平方根が、求める画像の相対的な幅になる。まず--x0でざっくりとした初期値を設定し、--x1以降の計算で精度を上げていく。だいたい5回もやればかなりの精度で求められるっぽい。ちなみに最初何も考えずに24回とかやってたらブラウザのタブが死んだ。

最後に、求められた平方根--x6は基準の16 : 9画像の幅に対する相対的な幅なので、これをパーセンテージ値にする。そしてこれが完成版のデモ。

ただまあ、現実的にはこんな面倒なことはせず、利用する画像のアスペクト比をあらかじめ数パターン決めておいて、クラス名で指定するのが賢明と思われる。

img.aspect-16x9 { width: 100%; }
img.aspect-3x2 { width: 91.854% }
img.aspect-4x3 { width: 86.602%; }
img.aspect-1x1 { width: 75%; }
...

というかそもそも面積が同じなら同じ大きさに見えるかと言うとそういうことではなさそうな気もする。ほんとに印象を揃えたいなら、なんかそういう認知的なファクターみたいなものを加味するべきなのかも。

font-feature-settingsとカスタムプロパティ

2019-11-22T00:00:00Z

font-feature-sttingsプロパティは便利だけど、値の意図しない上書きが発生しやすいという扱いづらさがある。たとえば「ページ全体でloclを有効にした上で、h1要素ではpaltを有効にしたい」というようなとき、以下のようなCSSを書いてしまいがちだ。

body {
  font-feature-settings: "locl" 1;
}

h1 {
  font-feature-settings: "palt" 1;
}

しかしこのときh1のpalt機能タグはbodyから継承されたlocl機能タグに追加されるのではなく、これを上書きしてしまう。つまりh1ではloclが無効になる。これは正しくは以下のように書かないといけない。

body {
  font-feature-settings: "locl" 1;
}

h1 {
  font-feature-settings: "locl" 1, "palt" 1;
}

このように、font-feature-settingsプロパティを指定するときはどのような値が継承されているかをつねに把握し、そこに値を「重ねて」指定する必要がある。機能タグが2つとか3つとかのうちはまだいいけど、ちょっと複雑なことをしようとすればすぐに管理しきれなくなるだろう。

こういった煩雑さを回避する方法として、ユニバーサルセレクターとカスタムプロパティ（CSS変数）を利用する方法を考えてみた。

*,
*::before,
*::after {
  font-feature-settings:
    "locl" var(--locl, 1),
    "palt" var(--palt, 0);
}

h1 {
  --palt: 1;
}

まずプロジェクトで利用しているすべての機能タグをユニバーサルセレクターで列挙し、デフォルトで有効か無効か（0か1、またはonかoff）をvar()関数のフォールバック値として定義しておく。その上で機能タグを有効（または無効）にしたいセレクターでカスタムプロパティを指定する。こうすることで、カスタムプロパティを指定したセレクター以外ではフォールバック値が適用されることになる。注意すべきなのは、機能タグを追加するときに該当のセレクターだけではなくユニバーサルセレクターにもデフォルト値とともに追加しないといけないという点。

そもそもfont-feature-settingsプロパティは低レベルAPIであり、可能な限りfont-variant系プロパティを利用することが推奨されている。こういった値の継承にともなう扱いの難しさを考えても、それが望ましい。しかし一方で、とくにCJKについてはfont-variant系の仕様と実装が十分ではないという現状があり、font-feature-settingsに頼らざるを得ない場面は少なからずある。その利用には慎重になるべきという前提のもと、思わぬバグを生まないための工夫として、このカスタムプロパティを使う手法はそれなりに有効な気がする。

福岡2019

2019-12-31T00:00:00Z

先日、「フロントエンドカンファレンス福岡2019」というイベントでお話をする機会をいただきました。僕のプレゼンテーションのタイトルは「音楽、数学、タイポグラフィ」で、ウェブタイポグラフィを音楽と数学の視点を交えて考察するものです。

イベントの現場はとても雰囲気が良くて、こういった場があまり得意ではない僕も気後れせず参加することができました。打ち上げもすごく楽しかった。福岡に行ったのははじめてだったんですが、すごく暮らしやすそうなところという印象を持ちました。また行ってみたいです。

登壇依頼のメールを見返すと、運営の皆さんとしてはUIデザインについて話してほしかったようなんですが、結果としてあまりそういったものにはならず、自分の話したいことを話してしまいました。すみません。そのかわりイベントの「新しい視点を見つけよう」というテーマはけっこう意識していて、こういうものの見方もありますよ、という提示はできたんじゃないかと考えてます。

僕の話の内容は期せずして、ここ数年にわたって考えてきたことを総括するようなものになりました。イベントの本番前は、こんなわけのわからない話をいったい誰が聞くんだろう、と控室でふるえていたんですが、終わってみると思った以上に好評でほっとしました。また話した内容を書き起こして記事にしたところ、予想外に多くの方々に興味を持っていただけたようで驚いています。いままで自分がやってきたことはそんなに見当違いなものでもなかったのかなと、少し自信が持てたことが最大の収穫でした。本当に参加できて良かったと思います。声をかけてくれた運営の皆さん、どうもありがとうございました。

読まれるために

2020-06-25T00:00:00Z

『ウェブタイポグラフィ――美しく効果的でレスポンシブな欧文タイポグラフィの設計』という本の監訳を担当しました。書店の店頭では今週、Amazon.co.jpなどオンライン書店では来週に発売される予定です。

原書である『Web Typography』は2017年にKickstarterでのクラウドファンディングを経て出版されました。僕も出資者のひとりとして本書を手にしたわけですが、当時も今も、ウェブタイポグラフィをこれだけのヴォリュームで網羅的に解説した本はまだないのではないでしょうか。

本書のテーマはタイポグラフィによって読み手の体験をより良いものにすることです。そのメッセージは何度も明快に繰り返されます。正直に言って多少まわりくどいところもある本ですが、それはすぐれたタイポグラフィを実現するために避けて通れない、複雑に絡み合う様々な事柄に真正面から取り組んだ結果であると思います。ですから、すぐに使えるテクニック集のようなものをお探しの方には、残念ながら本書は期待に沿うものではないかもしれません。しかしタイポグラフィの基本をじっくりと学んでみたいという方には、長く役に立つガイドブックとしておすすめできる本です。

本書は3つの章から構成されています。

1章「読まれるための組版」では「行」を中心に組版を解説しています。まず行の組版からはじめるというのは、何よりも読み手の体験を重視するという本書らしい構成と言えます。相対的なサイズ体系をもとに、文字サイズ、行長、行間、行揃えについて検討します。ジャスティフィケーションとハイフネーションの解説にもかなりの紙幅を割いていて、本格的な欧文組版のガイドラインとしても実用に耐える内容です。

2章「タイポグラフィのディテール」では、スペースやアクセント記号、約物、合字、スモールキャップなど、まさに細かなディテールについて学びます。和文の中で欧文を扱うときの参考にもなるでしょう。また文字サイズのスケールについても実践的な考察がなされていますが、これは日本語の文献ではこれまであまりなかったものではないでしょうか。そして段落や引用、リスト、テーブルなど、ウェブページの本文を構成する主要な要素のデザイン手法のほか、バーティカルリズムやグリッド、マルチカラムなど、レイアウトに関しても触れています。もちろんこれらはすべてレスポンシブデザインを前提にしています。

3章「フォントの選択と使用」では、書体の歴史や活字のディテールを学びながら、本文や見出しなどそれぞれに適切なフォントを選ぶための考え方を紹介しています。様々な角度から書体を解剖した、デザイナーにインスピレーションを与えてくれる内容です。加えて、アンチエイリアスなど画面でのレンダリングの仕組みや、ウェブフォントなどについての解説も充実していて、あくまで現在のウェブタイポグラフィでの実践を重視しています。

また原書にはないページとして、和文組版についてごく簡単に解説したコラムと、索引を新たに収録しています（原書は索引がなくて読むのに苦労したんです）。

本書の巻末には欧文の参考文献リストがありますが、ここに日本語版を作るにあたって参考にした日本語の文献を挙げておきます。本書でタイポグラフィに興味を持った方の読書ガイドになれば幸いです。

小林章『欧文書体　その背景と使い方』美術出版社、2005
小宮山博史（編）『タイポグラフィの基礎』誠文堂新光社、2010
ヤン・チヒョルト『アシンメトリック・タイポグラフィ』鹿島出版会、2013
フレット・スメイヤーズ『カウンターパンチ』武蔵野美術大学出版局、2014
サイラス・ハイスミス『欧文タイポグラフィの基本』グラフィック社、2014
ヨースト・ホフリ『ディテール・イン・タイポグラフィ』Book & Design、2017
髙岡昌生『増補改訂版　欧文組版　タイポグラフィの基礎とマナー』烏有書林、2019
スティーブン・コールズ『図解で知る欧文フォント100』ビー・エヌ・エヌ新社、2019

監訳という仕事は今回がはじめてでした。実際に取りかかってみると思っていたよりはるかに大変で、引き受けたことを何度か後悔しましたが、なんとか完成してほっとしています。

なかなか良い本が出来たと思います。ぜひ手にとってみてください。

コラム幅を文字サイズの整数倍にする

2021-05-23T00:00:00Z

日本語の組版ではコラム幅を文字サイズの整数倍にするのが基本だ。そうすれば全角等幅の活字を字間なく並べたとき、コラム幅と行長がぴったり合い、行末の位置が揃うことになる。ただしプロポーショナル文字（ラテン・アルファベットやアラビア数字など）や行頭行末の禁則の影響で行長にばらつきが出るので、その場合は調整が必要になる。

このコラム幅についての原則はウェブでも同様だと僕は考えている。ブラウザーではInDesignとは違って行ごとの緻密な調整はできないが、それでもやはり、コラム幅はなるべく文字サイズの整数倍にするのがよいと思う。そうしておけば、行長のばらつきが起こったとしても、その変化は「短くなる」方向でしか発生しない。コラムの右端を見たとき（横組みの場合）、おおむね縦に揃っているがときおりくぼんだ箇所が発生する、という格好になるわけだ。一方コラム幅が文字サイズの整数倍になっていないと、行長が意図した幅より長くも短くもなるので、行末が不揃いになりやすい。

CSSでコラム幅を文字サイズの整数倍にするには、任意のブロックのwidthプロパティにem単位の整数値を指定すればよい。1emはすなわち全角幅なので、指定した数値がそのまま1行の文字数になる。ただし幅を固定してしまうとそれより狭い画面に収まらないので、min()関数とvw単位などを使って最大幅を制限することも必要。以下の例では、広い画面ではmainの幅が全角36文字分、狭い画面ではビューポートの90%になる。

main {
  width: min(36em, 90vw);
}

ただこのやり方では、mainの幅が40em未満の場合（36em ÷ 0.9）、コラム幅は文字サイズの整数倍ではなく半端な幅になってしまう。たとえばビューポートの幅が550pxで、文字サイズが16pxだったとする。mainの幅は495pxになり（550 × 0.9）、1行には30文字が収まるが、行末に15pxの余りが生じることになる（16 × 30 ＋ 15 ＝ 495）。この15pxの半端なスペースは、前述のとおり、行長のがたつきを招いてしまう。

こうした事態を避け、いかなるビューポート幅であってもコラム幅を意図どおりにコントロールする方法としては、単純にメディアクエリのブレイクポイントを複数用意するというのが考えられる。

@media (min-width: 20em) {
  :root { --measure: 18em; }
}

@media (min-width: 22.5em) {
  :root { --measure: 20em; }
}

@media (min-width: 25em) {
  :root { --measure: 22em; }
}

...

@media (min-width: 45em) {
  :root { --measure: 36em; }
}

main {
  width: min(var(--measure, auto), 90vw);
}

ビューポート幅が20em以上ならコラム幅は18文字分、22.5emあれば20文字……というふうに、任意の間隔で複数のブレイクポイントを設定し、それぞれに対してコラム幅を定義していく。この方法ならビューポートに応じた緻密なコントロールが可能だし、じっさい意図通りに動作する。このサイトでも以前はこのようにしていた。しかしこれはきりがないというか、設計するのも維持するのもたいへんなうえ、特定のデヴァイスを想定したデザインになりがちという欠点もある。

そのかわりに、CSSグリッドのrepeat()関数とauto-fit値を使うと、コラム幅をビューポートに対してリキッドにし、かつ文字サイズの整数倍に制限できる。メディアクエリは不要。以下の例では、mainの子要素の幅が90vwもしくは36em以内でつねに文字サイズの整数倍になる。

main {
  display: grid;
  grid-template-columns: repeat(auto-fit, 1em);
  justify-content: center;
  margin-inline: auto;
  width: min(36em, 90vw);
}

main > * {
  grid-column: 1 / -1;
}

まず親要素のグリッドで1em単位のコラムをスペースが許す限り生成し（grid-template-columns: repeat(auto-fit, 1em)）、その子要素をグリッドの両端に合わせて配置する（grid-column: 1 / -1）。そうすることで子要素の幅を1em単位、つまり文字サイズの整数倍に制限している。justify-contentとインライン方向のマージンは、ボックス全体を中央寄せにするためのものなので、左寄せにするなら不要。repeat()関数のauto-fitはauto-fillに変えても結果が変わらないように思うんだけど、この場合にはどっちを使うのが適切か確信が持てなかったので、ひとまず短く書けるauto-fitを採用している（auto-fitとauto-fillのどちらが適切かについて、記事の公開後に@_yuheiyの指摘を受けた。今回の使い方ではどちらでも結果は変わらないが、minmax()関数を使ったときの挙動を考えるとauto-fillの方がコードの意図が伝わりやすいのでは、とのこと。たしかに、ここでのグリッドの使い方は典型的なものではないこともあり、より結果がイメージしやすい方を選ぶというのは理にかなっていると思う。コード例ではauto-fitを使ってますが、やっぱりauto-fillを使った方がよさそうです）。

この方法がとくに効果を発揮するのは、やはりスマホなど狭い画面においてだろう。左右に最低限のマージンを確保しつつ、コラム幅は文字サイズの整数倍でとりうる最大値にするということが、実際のデヴァイスのサイズを考慮せずとも可能になる。

描写から構成へ

2021-11-28T00:00:00Z

ヘイドン・ピカリングとアンディ・ベルの共著『Every Layout』が日本語に翻訳された。光栄なことに僕も出版前のレビュワーのひとりとして、微力ながらお手伝いさせていただいている。

タイトルが示すとおり、本書はCSSによるウェブデザインのうち「レイアウト」の問題に焦点を絞ったものだ。レイアウトといってもページ全体のグリッドのことだけではなく、ボタンやアイコンのような小さな部品に至るまで、CSSが「ボックス」として扱うあらゆる要素を対象としている。

テーマの根底にあるのは「コンポジション」というコンセプトだ。CSSによってインターフェイス部品を形づくるとき、それらひとつひとつを独自の、独立したものとして捉えるのではなく、基本的で小さなレイアウトの組み合わせたコンポジションとして捉えるべきである、と著者は主張する。そしてそのように組み合わされる小さなレイアウトを「レイアウト・プリミティヴ」と名づけ、それらを再利用しやすい形で定義し、カタログとしてまとめている。

デザインにおけるコンポジション――日本語でいうところの「構成」とは、すでにある素材をただ組み上げることではない。構成には効率化や合理化といったものを超えた、より重要な意味がある。高安啓介は近代デザインにおける構成の概念について次のように述べている（『近代デザインの美学』、みすず書房、2015年）。

近代デザインは、二十世紀のはじめに二つの流れが合流したところで見出されてきたものであり、二つの流れを含みながら発展してきた。その一つは、産業の流れで、そこでは、製品を装飾するよりも製品自体をいかに構成するかが強く意識された。もう一つは、美術の流れで、そこでは、対象を描写するよりも平面や立体それ自体をいかに構成するかが強く意識された。したがって、近代デザインにおいて構成はもっとも重要な理念だったといえる。

装飾や描写から構成へ、という運動が近代デザインの中心にあったわけである。『Every Layout』が主張するコンポジション指向のCSSも、まさにこの流れを汲むものといっていい。では構成がそこまで重要な概念であるのはなぜか。高安は構成とは素材に対する外部からのコントロールであると同時に、素材による内部からの運動を引き出すための行為でもあると指摘する。

構成とは何かをより掘り下げて考えてみるならば、構成とは素材をまとめあげる行為であるかぎり、素材にたいして何かを強いる行為であるにちがいない。誇張していうと、構成という行為には、支配がはらまれており、それゆえに、暴力がはらまれている。ただしそうみるときに、私たちは、内からの構成という理想をかかげることができる。すなわち、構成とはたしかに素材にたいして何かを強いる行為であるが、それでも、素材からの働きかけに応じながら、素材のなかから秩序をもたらす可能性にかけることはできる。そしてそれがもし成し遂げられたなら、支配という能動はなお維持されるにしても、素材にしたがうかぎり、模倣という受動がはらまれることになる。さらにまた、内からの構成がなしとげられたときには、作り上げられた形象の内部において、生きた交通がみとめられるはずである。すなわち、要素どうしの自由な相互作用がみとめられるはずである。

「描写よりも構成を」というと、造形が無機質で無個性なものになるのではないかと懸念する向きもあるかもしれないが、そうではない。むしろコンテンツの力を最大限に引き出し、さらにはコンテンツどうしの相互作用を促すのが、構成というものの本来の意図である。『Every Layout』が提唱している、コンテンツ自身によって内在的にレイアウトを決定させるという手法も、レイアウトという行為は絶対の命令ではなく意図の提示であるべきという視点も、まさに高安のいう「内からの構成という理想」を実現するためのものにほかならない。

CSSの仕様と実装の進歩は目覚ましい。作り手にとってCSSは、ブラウザーにこと細かな指示を与えるためのものではなく、デザインの意図を表現するためのものになりつつある。『Every Layout』の実例の数々は、ブラウザーが備える優れたアルゴリズムをごくシンプルなCSSによって引き出せることの鮮やかな証明だ。

それが何であるかを描写するためのCSSから、それがどのような形であるべきかを示すためのCSSへ。本書はそんな新しい視点を与えてくれる一冊と言える。

意外と読めた

2022-06-12T00:00:00Z

ここ最近は休日に仕事と関係のないことがしたくて、本を読んでいる。いつしか休日でも仕事について考えたり手を動かしたりすることが多くなって、これはちょっとよくないなと感じたので。もちろんいままでも本は読んでたけど、仕事につながる実用的なものばかり読むようになってきて、読書を楽しむという感じじゃなかった。それでも仕事が順調なときは別にいいんだけど、残念ながらいつでもすべてがうまくいくわけではないし。

いつだったか買ったけど読まずにいたトマス・ピンチョンの『V.』上下巻（小山太一／佐藤良明訳、新潮社、2011年）が本棚にあったので、手にとった。小説を読むこと自体がずいぶん久しぶりで、しかもピンチョンだし、はたして読めるだろうかと少し心配だったけど、意外と読めた。何日かかけて上巻を読み終わったところ。

『V.』がどんな本か説明するのはちょっと難しいんだけど、おかしくて、いろんな読み方ができる小説だと思った。なんというか、ただテクストがあって、ただそれを目で追うだけ、ということが面白くて、本を読む楽しさを思い出した感じ。

即物的

2022-06-19T00:00:00Z

デザインについて書かれたものを読んでいると、たまに「即物的」という言葉に出くわすことがあります。たとえばヨゼフ・ミューラー゠ブロックマンの『グリッドシステム』（古賀稔章訳、ボーンデジタル、2019年）にも、こんなふうに何度か出てきます。

これはデザイナーという職業に対する信念の表明なのである。つまり、デザイナーの仕事は、数学的思考に基づいて明白でわかりやすく、即物的かつ機能的でなければならず、また、美的な質を備えていなければならない、という信念である。

僕は以前、この即物的という言葉をネガティヴな意味で捉えていました。深い考えのない短絡的な行動や、精神的な充足よりも物質的な豊かさを重んじる態度といった、あまり感心しないあり方を指すものだと。「即」の字が即席や即効といった言葉を連想させ、そこから手っ取り早い安易な手法のようなイメージにつながるのかもしれません。

もちろんそういった悪い意味で用いられることもありますが、しかし辞書を引いてみると必ずしもそういう言葉ではありません。即物的とは文字どおり「物に即して」、つまり観念的・抽象的・主観的にではなく、客観的に実際の事物を見ることをいいます。ですからデザインにおける即物的な態度とは、対象となる素材や媒体をあるがままにとらえるということであって、それはデザイナーとしてじつにまっとうな姿であるわけです。

僕が即物的という言葉をネガティヴな意味にしか捉えられていなかった背後には、具体的なものごとよりも抽象的な概念の方がより価値が高い、という思い込みがあるように思います。そしてそういう思い込みは僕だけのものではなくわりと一般的なもので、しかもそれがいろんなところに影響を及ぼしている気がします。どこで植えつけられるんでしょうね、こういうの。

2020年版テーマ

2022-12-19T00:00:00Z

このサイトでは現在、2020年の春頃にデザインしたスタイルを採用している。近ぢか新しいテーマに差し替える予定なので、今さらではあるけれど、この2020年版デザインの意図などを（思い出せる範囲で）書いておこうと思う。

まず、すべてのテクストは同じ書体、同じ文字サイズ、同じ行送りにするというルールを設定している。書体は筑紫ゴシックのRとB、文字サイズは16pxで、行送りは28px。見出しやキャプションなど、ふつうなら異なる書体や文字サイズを使う要素でも、余白や行揃えなどを工夫することで表現した。これはうまくいっている部分もそうでない部分もあり、たとえば見出しの階層構造なんかはややわかりづらくなってしまったかもしれない。

なぜこんな制限を課すのかといえば、それはこのサイトをウェブ・デザインの実験や修練の場として捉えているためである。とはいえ読みやすさを考慮しないわけではもちろんなく、制限の中でいかに読みやすさを実現するかを意識している（少なくともそのつもり）。

本文の行長は最大36字。本文ブロックは左寄せで、6字分のマージンを持たせている。中央ではなく左寄せの配置にしているのは、ブラウザーのエッジをデザインの要素として取り込むことで、段落や引用ブロックなどの字下げをより際立たせたいという意図がある。

段落の切れ目は空行ではなく字下げで表現している。見出しや図版の直後など、先行する段落がなければ字下げはせず、段落が連続する場合の2つめ以降の先頭行を2字下げるというルールである。下げ幅を1字ではなく2字としているのは、行末が不揃いになりがちだったり、始め括弧類の行頭天つきが実現できなかったりするウェブにおいて、1字下げでは段落の境界として弱いと考えたため。中国語の組版にならったというのもある。

縦方向のグリッドはすべて行送り28pxの整数倍で構成。ヘッダーとタイトルの間やタイトルと本文の間、本文とフッターの間などの余白は、行送りにフィボナッチ数（1、2、3、5……）をかけたものになっている。

フッターの先頭には本文との区切りとして中点（・）を置いた。こういう部分にボーダーや画像ではなく約物を使うのが個人的な好み。ブログをデザインしていると、「記事本文はここで終わりですよ」ということを示すのが意外と難しくて、いつもけっこう悩んでしまう。

ちなみにこういうデザインにしようと思ったのは、たしか印刷博物館の「世界のブックデザイン」展でなんかの本を見て触発されたからだった気がする。

ナンバー・ナイン

2022-12-25T00:00:00Z

約3年ぶりにこのウェブサイトをリデザインした。Gitの履歴が整理されていないうえ記憶も定かではないが、おそらく9代目のテーマのはず。書体選定やタイポグラフィとグリッドの設計、文書構造などについて解説してみたい。

本文書体は筑紫明朝のLBで、キャプションや小見出しは筑紫ゴシック。明朝体は横画が細いため、書体によってはスクリーンでかすれて読みづらくなってしまうことがある。とくにスマホやタブレットではサブピクセル・レンダリングの特性上、その傾向がより顕著だ。しかしこの筑紫明朝のLBというスタイルは全体的にストロークが太めにデザインされていることもあり、スクリーンにおいても可読性が高いと考え、本文書体として採用した。

本文の文字サイズは17.067px、行送り32pxで、これがページを構成するグリッドの基本単位となっている。各要素の文字サイズは本文を中心に調和数列を構成するよう設計していて、タイトルは本文の5 / 3、中見出しは5 / 4、小見出しとキャプション、フッターなどは5 / 6とした。

	文字サイズ	行送り
タイトル（`h1`）	28.444px (5/3)	40px
中見出し（`h2`）	21.333px (5/4)	32px
本文	17.067px (1)	32px
小見出し（`h3`）	14.222px (5/6)	24px
キャプション	14.222px (5/6)	24px

文字サイズのスケール（デスクトップ）

これら文字サイズと行送りを決定するにあたっては、まず本文の行送りを32pxとするところから出発している。これは現在のウェブ・デザインにおいて標準的な本文サイズである15pxから18px程度のテクストが読みやすく、かつ垂直方向のグリッドを構築するうえで取り扱いやすい数値として選択した。文字サイズはピクセル単位よりもプロポーションを重視し、行送りの8 / 15とした。その結果が17.067pxという数値である。

これらのサイズはすべてルート要素に対する相対値として指定している。幅の狭い画面ではルートの文字サイズをデフォルトの15 / 16に設定し、全体がひとまわり小さいスケールで表示されるようにした。

行長は最大36字。本文ブロックは左寄せで、6字分のマージン。CSSグリッドを使って、幅がつねに本文サイズの整数倍になるようにしている。段落先頭は2字下げ、ただし先行する段落がなければ字下げなし。リストや引用ブロック、コード・ブロックは全体を2字下げ。body要素上下のマージン8pxをデフォルトのまま残しているのは、Mosaicブラウザーから続く伝統に敬意をはらってのこと――というのはあとから考えた理屈だけれど、半分本気でもある。

ブログ個別ページではtitle要素にサイト名を入れず、記事タイトルのみとした。article要素も廃し、bodyがそのまま記事のルートであるという、シンプルな構成になった。記事をサイトの中の個別ページとするのではなく、それぞれが独立したウェブページであると捉えなおそうと考えた結果である。

画面上端にはサイト名と記事の公開日を小さく配置している。これらの要素はブック・デザインでいうところの柱とノンブルとして捉え、本文に付随してその属性を示すものとして扱っている。書体は本文の等幅書体としても使っているLucasFontsのTheSansMono Condensedで、オールドスタイルの数字がノンブルにふさわしいと考えて採用した。

このあたりの文書構造を再考するにあたっては、Hail2uの「雑記記事からarticle要素を削除」や、ゆうへいの「yuheiy.com-v6」といった記事、およびそれらサイトのソースコードも参考にさせてもらった。

いわゆるダーク・モードにも対応した。明るいテーマでは#ffffffの背景に#1c1d1fのテクスト、暗いテーマでは背景を#1c1d1f、テクストを#dfe1e2としている。暖色系の組み合わせも試してみたものの、最終的には一般的なブラウザーやOSの色味に合わせ、ブルー寄りのグレースケールに落ちついた。

ファビコンも新たにSVGで作り、ボディと同様に色が反転するようにしてみた。

今回のデザインは「自分がブログを読むならこういうデザインで読みたい」という考えを、かなりストレートにそのまま形にしたものと言える。その点ではなかなか満足している。一方でより個人サイトらしいサイトにしたいという狙いもあり、たとえばソーシャル・メディア関連のメタ要素を削除したのもその一環なのだけれど、そのあたりはまた別の機会にあらためて書きたい。

千駄木から金沢へ

2023-02-02T00:00:00Z

東京の千駄木から石川の金沢へ引っ越すことになった。いまはその準備を少しずつ進めているところで、役所に書類を出したり、ガス会社に連絡したり、ギターやCDを処分したりしている。

千駄木は好きな町だった。治安が良くて、にぎやか過ぎず、どことなく文化的な雰囲気のあるところだ。千駄木という名前もいい。5年半ほど住んだけど、なかなか名残り惜しい思いがする。もしまた東京に住むことがあったら、やっぱりこのあたりで家を探すかもしれない。

ところで金沢に移り住むと言うと、北陸の冬は厳しいから覚悟したほうがいいと親切に教えてくれる人がある。天の邪鬼なので、そうした助言を僕はなんだか複雑な気持ちで聞く。ありがとう、うまくいくかわからないけど頑張ってみるよ、というのが半分。ほうっておいてくれ、これは僕の人生なんだから、というのが半分。

いまのところとてもいい

2023-04-29T00:00:00Z

金沢に引っ越してきて2か月になる。今のところ新しい暮らしにはとても満足している。

なにしろ近所で買える魚や野菜がどれもおいしい。それだけでも引っ越してよかったと感じる。行ってみたい寿司屋や居酒屋やなんかもたくさんあるけれど、家で食べるのが楽しいというのもあって、まだほとんど行けずにいる。だからもし金沢でおいしいお店を教えてほしいと言われても、残念ながらあまり気のきいた提案はできそうにない。

前に住んでいた東京の家はかなり古く（たしか築50年とかそのくらい）、間取りや設備などの面でかなりの不満があった。対して新しい住まいはそこそまで古くないふつうのマンションで、そういったストレスはほとんどない。なるほどこれが現代のふつうのマンションかと感心している。今の生活を快適と感じるのは、金沢という場所だけではなく住居によるところも大きい。

仕事はこれまでと変わらずリモートで、ただ年に数回は東京と福岡のオフィスに出社するつもりでいる。会社には働き方について柔軟に対応していただき、たいへん感謝しています。

rlh単位

2023-12-23T00:00:00Z

11月リリースのFirefox 120でCSSのrlh単位がサポートされ、すべての主要なブラウザーで使えるようになった。

rlhはルート要素のline-heightに対する相対単位である。html要素で本文の文字サイズとともに行送りを定義しておけば、たとえば「引用ブロックは前後に1行分のアキをとり、全体の行頭を2文字分下げる」といった指定を以下のように書ける。

html {
  font-size: 120%;
  line-height: 1.875;
}

blockquote {
  margin-block: 1rlh;
  margin-inline: 2rem 0;
}

このように水平方向は文字サイズ基準のrem、垂直方向は行送り基準のrlhという単位の使い分けができ、タイポグラフィを中心に据えたレイアウトをよりシンプルに記述できるようになった。このサイトにもさっそく導入している。

2024年の石井ゴシック

2024-12-01T00:00:00Z

先日リリースされた石井ゴシックが良い。このサイトでもさっそく全面的に採用した。とても気に入っている。

石井ゴシックはもともと、写研が1930年代から70年代にかけて開発した、写真植字機用の書体である。90年代頃まで広く使われていたが、デジタル化されなかったために2000年代以降は目にする機会が減っていった。その後2020年代に入り、写研とモリサワ、字游工房の3社によって写研書体をOpenTypeフォントとして改刻するプロジェクトが発足。石井ゴシックは2024年に復活することとなった。

わたしは1970年代生まれなので、まさに写研の書体に触れて育った世代だが、しかしそれらの書体に特別な思い入れがあるわけではない。たとえば石井ゴシックで組まれた80年代の雑誌をいま見ても、そう言われてみれば見覚えがあるような気もする、という程度のものである。当時のわたしは活字や組版といったものにそこまで興味があったわけではないし、書体の違いを気に留めることもなかったはずだ。だから今回の石井ゴシックのリリースをわたしは、懐かしい書体との再会ではなく、ただ新しい書体の登場として受け止めた。そしてじつに魅力的な書体だと感じたのだ。

字面が小ぶりで、軽やかな読みやすさがある。とくに漢字の造形が絶妙。欧文グリフもなかなか可愛い。いわゆるオールドスタイル・ゴシックだが、ことさらにアナログでレトロな雰囲気を強調せず、あくまで現代の書体として使いやすいものが目指されている。これからのスタンダードなゴシック体として、たとえば游ゴシック体やこぶりなゴシックに代わる有力な選択肢になる書体だと思う。

写研書体のOpenType化計画はこれからも続き、最終的に100書体がリリースされる予定だという。個人的には石井丸ゴシックの改刻ファミリー化に期待している。

ワイアード、サーカムオーラル、オープンバック

2024-12-21T00:00:00Z

ヘッドフォンを買った。ゼンハイザーのちょっといいやつ。5年近く勤めた会社を辞めたところだったので、転職祝いとしてこのくらいの贅沢は許されるだろうと自分に言い聞かせて。

オーディオ機器と呼べるものを買うのはずいぶん久しぶりだ。最後にヘッドフォンを買ったのはいつだったかも思い出せない。おそらく前世紀のことだと思う。当時はかなり貧乏だったけど、音楽を聴くためのシステムにはそれなりのお金と手間をかけていた。アンプにスピーカー、ターンテーブル、CDプレイヤー、カセットデッキ。それが今ではもっぱらスマホとワイヤレス・イヤフォンの組み合わせになり、音質やなんかはあまり気にしなくなってしまった。

中学生の頃からか、ずっと音楽を聴きつづけてきた。映画をしばらく観ない時期があったり、読書の意欲がわかないことがあったりしても、音楽への興味を失うことだけはなかった。いつだって何かを聴いている。だったら音楽を聴くこと自体をもっと大事にしてもいいんじゃないか、とあらためて思う。

新しく買ったヘッドフォンは有線で据え置き型のDACに接続している。だから聴いているあいだはどこへも行けない。このつながれた感覚がなんだか嬉しい。

terkel.jp

こんにちは、世界!

Mac 版 Firefox 3 はデフォルトのフォントサイズが 16px に

のっちメソッド: One pixel notched corners

「右クリック禁止」に戸惑う

(要素に) 名前をつけてやる

Google サイトマップを Movable Type で生成

Movable Type 4.12 にアップグレード

再起動

戦争は終わった

ときには真珠のように

CSS ハックをフォーマット

さよなら

mt:SetVars

768 グリッド・システム

この数値文字参照がすごい! 2008 年版

第 1 位: 〜 (&#12316;)

第 2 位: ※ (&#8251;)

第 3 位: ' (&#39;)

編集後記

WordPress 2.7 “Coltrane”

jQuery のセレクタ機能を拡張する

jQuery で外部サイトへのリンクをコントロール

No Line on the Horizon: U2

Electric Arguments: The Fireman

Best of 2008: 映画

Best of 2008: 音楽

さよなら、2008 年!

Pop Life: Life Without Buildings

JavaScript と CSS を使った「このページを印刷」リンク

スクロールで背景画像が変化する (ように見える) トリック

jQuery 1.3、リリース!

スペースの幅

jQuery と CSS を使った Apple 風パンくず

1. マークアップ

2. スタイルシート

3. スクリプト

4. 再びスタイルシート

お誕生日おめでとう、World Wide Web!

チェック/ペケ

インライン要素に背景画像を指定する

link か @import か

小学校 8 年生

空がまた暗くなる

僕が HTML 4.01 を選ぶ理由

jQuery Counter Plugin

Demo

Download

Usage

Options

ToDo

非置換要素の幅を明示せずにフロート

のっちメソッド 2: なりゆき幅で横並び

青いスウェードの靴

YouTube が IE6 にサヨナラ

横並びにしたリスト項目の区切り

自由

要素を非表示化するスタイル

09-09-09

みんなで IA: CSS Nite LP, Disk 7

Rubbergard Record

HootSuite で鉄道の運行状況を知る

フロントエンド Web 開発のためのローカル・ブックマーク

The Stone Roses: 20th Anniversary

エディションの比較

マテリアルの詳細

The Stone Roses

The Extras

The Lost Demos

DVD

Lemon USB

どのエディションを買うべきか？

オルタネイト・ヴァージョン

Movable Type から WordPress へ

パーマリンクの移行

プラグイン

リデザイン

Menlo と Mac の等幅フォント

Courier、Courier New、Consolas

CSS のみで吹き出し

第 1 位: 〜 (`〜`)

第 2 位: ※ (`※`)

第 3 位: ' (`'`)