賞賛の声

新世代のCSSに対応した、新世代の解説書です。今日のCSSはW3Cによる80以上の仕様から成り立っており、リッチで強力かつ深く複雑な生態系です。以前のように、ブラウザごとのややこしいハックや一時しのぎと併用するシンプルな言語ではありません。この新しいCSSを正しく理解し、問題解決に役立つデザインの指針を示してくれるのは、著書Lea Verouをおいては他にはありません。私の知る限り、彼女は本当にすばらしいコード書きの1人です。

Jeffrey Zeldman
『Designing with Web Standards』著者

Lea Verouは本書で、自らが持つ随一の博識を気前よく分け与えてくれました。本書を読めば、思いつく限りすべてのことがCSSで可能になるということを理解できるでしょう。CSSについて隅々まで知っているという読者も、まだ気づいていなかったCSSの秘密にきっと出会えるはずです。

Jeremy Keith
Shepherd of Unknown Futures、Clearleft

CSSに関する魅惑的なテクニックやスマートなベストプラクティス、その他のとてもすごいことについて深く知りたいなら、本書の購入をためらってはいけません。私のお気に入りの1冊です。

Eric A. Meyer

Leaは抜きん出てすばらしいコード書きです。本書には、クレバーで便利なアイデアが文字どおり満載されています。CSSをよく知っているという読者にも、本書は役立つでしょう。また、本書では当たり前の常識を超えたアプローチが推奨されています。読者は日常の作業の中にも、クレバーさを実感できるようになるでしょう。

Chris Coyier
CodePen

『CSS Secrets』はあっという間に、定番書の地位を獲得しました。すばらしいヒントやコツの数々は、読者のUXデザインを即座に向上させてくれるはずです。

Christopher Schmitt
『CSS Cookbook』著者

Lea Verouの『CSS Secrets』よりも多くの実践的なテクニックを紹介してくれる本は、ほとんどありません。本書には、デザイン関連のよくある課題に対して数十もの解決策が詰め込まれています。物事を速く上手にこなすためのヒントとコツの数々はとても貴重です。CSSを知りつくしているという読者にもおすすめします。

Vitaly Friedman
共同創設者兼編集長、Smashing Magazine

Lea Verouの著作はいつも、私に新しいことを学ばせてくれます。『CSS Secrets』も例外ではありません。本書の内容は理解しやすいように短く小分けされており、それぞれに興味深い知識が詰め込まれています。将来実現するであろう事柄の解説も含まれてはいますが、今すぐ各自のプロジェクトに適用できそうなヒントが満載です。

Jonathan Snook
Webデザイナー、Web開発者

すばらしい本です。LeaはCSSを飼い慣らし、仕様の執筆者さえも想像していなかったであろうと思われる事柄にも適用しています。読み進めてゆけば、さまざまな表示効果を複数のやり方で実現できるようになるでしょう。そして読者はきっと、Leaが紹介したテクニックが自らの業務にも完全に当てはまっていることに気づくでしょう。しかも、これらのテクニックで画像データが必要になることはほとんどありません。グラフィックは保守しやすいCSSとして記述されているためです。しかも彼女のテクニックは楽しく、実践的でありながら予想もできないようなものです。

Nicole Sullivan
プリンシパルソフトウェアエンジニア、OOCSSの考案者

Lea Verouの『CSS Secrets』は単にCSSのヒント集として便利なだけでなく、CSSでの問題を解決するための教科書でもあります。それぞれのシークレットに至る思考のプロセスも詳しく紹介されており、CSSにまつわる問題を自ら解決できるようになるでしょう。また、イントロダクションの章も必読です。CSSでの重要なベストプラクティスが紹介されています。

Elika J. Etemad （通称fantasai）
Invited Expert、W3C CSS作業グループ

世界中で開かれるWeb開発関連のイベントで、Leaのプレゼンテーションは常に必聴です。『CSS Secrets』には長年にわたる彼女の経験が凝縮されており、Webデザインに関する面倒な問題に対してCSSを使ったエレガントな解決策を示してくれます。フロントエンドに関わるすべてのデザイナーと開発者にとって、本書は間違いなく必読です。

Dudley Storey
デザイナー、開発者、著述家、Web教育のスペシャリスト

CSSについてかなり理解していると思い込んでいましたが、Lea Verouによる本書を読んで考えが変わりました。CSSに関する知識を次のレベルに引き上げたいなら、本書は必携です。

Ryan Seddon
チームリード、Zendesk

『CSS Secrets』は、今までに筆者が読んできたCSS関連の書籍の中でも群を抜いてテクニカルです。LeaはCSSというシンプルな言語で、あたかも魔法のようにその能力の限界を押し広げることに成功しました。決して初心者向けではありませんが、CSSについてすべて理解したと思っているすべての人々に強くおすすめします。

Hugo Giraudel
フロントエンド開発者、Edenspiekermann

CSSとは魔法のようだと思うことがよくあります。少しのルールを記述するだけで、味気ないページを美しく作り替えることができます。『CSS Secrets』でLeaは、この魔法をさらに新しいレベルへと引き上げてくれました。彼女はCSSの大魔法使いであり、新しい魔法の世界を我々に示しています。本書を読みながら、何度「クールだ!」と叫んだことでしょうか。本書に問題が1つだけあるとしたら、他のことに手がつかなくなって一日中CSSでいろいろ試してみたくなることぐらいです。

Elisabeth Robson
WickedlySmart.com共同創設者、『Head First JavaScript Programming』共著者

すべてのWeb開発者は、『CSS Secrets』を本棚に備えるべきです。本書でのヒントやコツを活用すれば、CSSは想像もしなかったようなたくさんの表現を可能にしてくれます。私を何年もの間悩ませてきた問題の多くが、筆者のシンプルでエレガントな水平思考によって解決されました。

Robin Nixon
Web開発者、オンラインインストラクター、CSS関連の書籍を数冊著す

デザイナー兼プログラマーでもあるLea Verouの本は、彼女のコードと同様に美しく思慮深いものです。CSSにまだ慣れていなくても、CSS3関連の細かい事柄に精通していても、誰もが本書から何かを得られるでしょう。

Estelle Weyl
オープンWebエバンジェリスト、『CSS: The Definitive Guide』著者

この本の素晴らしいことのひとつは、美しい本のデザインがCSSで作られているということです。いわば「CSSのCSSによるCSSのための本」であり、CSSがWebのデザインとともに本のデザインにも十分使えるものであることを示してくれています。Webの標準技術であるCSSで誌面を自由にデザインできることには、これまで人類が築いてきた『活字文化』を引き継ぐという非常に重要な意味があります。この本の著者と出会えたこと、間接的ながら共同で英語版と日本語版の両方の本作りに関わることができたことに感謝します。

村上真雄(Shinyu Murakami)
株式会社ビブリオスタイル（Vivliostyle）会長兼CTO

はじめに

ここ数年の間にCSSは、2004年ごろにJavaScriptが経験したのと同じような変革を迎えました。能力も限られていたきわめてシンプルなスタイル設定言語から、草案も含めると80以上に上るW3Cの仕様から構成される複雑なテクノロジーへと進化しました。そして独自のエコシステムが生まれ、専門のカンファレンスが開催され、固有のフレームワークやツールも開発されました。このような長足の進歩には、仕様のすべてを1人で把握するのが事実上不可能になったという側面もあります。CSSを定義したW3CのCSS作業グループでさえ、CSSのすべての側面に精通しているメンバーはいません。すべてをそこそこ知るということさえ困難です。ほとんどの作業グループのメンバーは特定の仕様にのみ詳しく、自身が関わらない仕様についてはほぼまったく知らないというのが実状です。

2009年ごろまでは、言語自体への知識はCSSに関する専門性を測る指標ではありませんでした。CSSに対して真剣に取り組むなら、言語への知識は当然の前提でした。ブラウザのバグと回避策をどれだけ知っているかという点を基準にして、能力が評価されていました。しかし年月は流れ、ブラウザは標準に対応した設計を行うようになったため、浅薄なブラウザ依存のハックは今やひんしゅくを買っています。避けられないような非互換性の問題も残されてはいますが、今日ではほとんどのブラウザが自動更新の仕組みを取り入れており状況の変化がとても速くなっています。そのため、このような互換性の問題を書籍にまとめるというのは時間の無駄になりつつあります。

近年のCSSでは、一時的なブラウザのバグへの対処が技術的課題になることはほとんどありません。真の課題は、CSSの機能を創造的に活用し、DRYで保守しやすく柔軟で軽量なソリューションを生み出し、かつ可能な限り標準に準拠するという点にあります。そして、正にこれらの点について解説したのが本書です。

CSSに含まれる特定の機能について、隅々まで解説してくれる書籍ならたくさん出回っています。しかし幸か不幸か、本書はこのような書籍ではありません。本書の目的は、一般のリファレンス資料をひととおりマスターした後に直面するであろう知識のギャップを埋めることにあります。読者がすでに知っている機能の新しい活用法に気づいてもらうことや、あまり目立たないけれどもとても便利でもっと使われてほしい機能について知ってもらうことも目指しています。しかし最大の目的は、CSSを使った問題解決の方法について読者に学んでもらうことです。

本書はレシピ集でもありません。それぞれのシークレットは、何らかの効果を得るための決まった手順を紹介するのが目的というわけではありません。すべてのテクニックについて、背後にある考え方も詳しく紹介するように努めました。解決策自体よりも、解決策を発見するまでのプロセスを理解することのほうがはるかに価値が高いと筆者は信じます。本書で紹介したテクニックと自分の業務との関連が薄くても、解決策に到達する方法を学ぶことには意義があります。まったく異なる分野の課題に取り組む場合でさえも、本書で学んだことが役立つでしょう。言い換えるなら、本書ではよく知られている魚をたくさん手に入れられますが、本書の真の目的はこれらの魚の捕まえ方を知って一生暮らしていくということにあります。

謝辞

素晴らしい人々の助けとサポートがなければ、本書を完成させるのはきっと不可能でした。心からの感謝を捧げたい方々を紹介します。

筆者の仕事をサポートしてくださった皆様。あなたがたがいなければ、本書を執筆するチャンスが与えられることもなかったでしょう。筆者のブログ（lea.verou.me）やTwitter （twitter.com/leaverou）などの読者、そして筆者の処女作である本書の読者の皆様にも感謝します。筆者によるオープンソースのコード（github.com/leaverou）のユーザーや、コードを寄贈してくださった皆様にも感謝します。
今までに筆者を講演やワークショップに推薦してくれた、カンファレンスの主催者の皆様。中でもDamian WielgosikとPaweł Czerskiは、筆者を初めてカンファレンス（2010年のFront-Trends）に招待してくれました。同じく2010年にVasilis Vassalosは、Athens University of Economics and BusinessでのWeb開発についての講義を筆者に任せてくれました。これらの経験は、教えるということについて多くの知識を与えてくれました。技術書も、その目的は何かを教えるということにあります。
筆者をInvited Expertとして指名してくれた、CSS作業グループの皆様。Web技術一般そしてCSSに対する見方が、ここで変わりました。
本書の編集を担当したMary TreselerとMeg Foley。出版へのプロセス全体を筆者にコントロールさせてくれただけでなく、締め切りを何度も守れなかった筆者に対して驚くほどに寛容でした。
プロダクションエディターのKara Ebrahim。レイアウト関連の問題をたびたび修正してくれたほか、本書で使われたPDF生成プログラムでのCSSの描画にまつわるバグや制約を手作業で回避するべく奮闘してくれました。
テクニカルエディターのElika Etemad、Tab Atkins、Ryan Seddon、Elisabeth Robson、Ben Henick、Robin Nixon、Hugo Giraudel。実際に誤りを正してくれただけでなく、文章のわかりやすさについて有意義なフィードバックをいただきました。
Eric Meyer。本書への序文を引き受けてもらえたことが、いまだに信じられません。
研究面でのアドバイザーDavid Karger。本書の執筆中に、予定より大幅に遅れてマサチューセッツ工科大学を訪れた時にも、彼は理解を示してくれました。彼の辛抱強さがなかったら、本書の先行きは暗いものでした。
筆者の父Miltiades Komvoutis。筆者が幼少の頃から、芸術と美について教えてくれました。彼がいなかったら筆者がデザインやCSSに興味を持つことはなく、本書はきっとC++やカーネルプログラミングの解説書になっていたことでしょう。
筆者のおじであり父代わりでもあったStratis Verosと、すてきな奥様Maria Brere。本書の執筆中に不機嫌になることもあった筆者を見守ってくれました。そして夫妻の娘LeonieとPhoebeにも感謝します。世界一かわいらしいこの子たちがいなかったら、本書の執筆は1ヶ月くらい早く終わっていたかもしれませんね。
筆者の誇りでもある、亡き母Maria Verou。本書を彼女に捧げます。ともに生きた27年の間、彼女は親友であり最大の支援者でした。彼女の人生はインスピレーションの源でした。ギリシャの女性のほとんどが大学に進学していなかった1970年代に、彼女は未知の世界へと飛び出し、マサチューセッツ工科大学の大学院で研究を始め、しかも優秀な成績で学位を取得しました。彼女は筆者に熱意や思いやり、誠実さ、自立そして広い心を教えてくれました。そして何よりも、人生をあまり深刻にとらえてはいけないということが彼女から得た最大の教訓です。彼女の不在に、さみしさが募ります。

写真の出典

寛容なCreative Commonsライセンスの下で写真を公開している素晴らしい方々にも感謝します。彼らがいなかったら、本書に登場する画像は筆者の飼い猫だらけになっていたことでしょう（何か所かでは、実際に飼い猫に登場してもらっていますが）。本書で利用しているCreative Commonsライセンスの画像と、それぞれの出典を示します。

メイキング

本書（英語版）は自己完結的に執筆されています。クリーンなHTML5と、O’ReillyのHTMLBook規格（oreillymedia.github.io/HTMLBook）で定義されたいくつかのdata-属性を使って記述しました。つまり、本書で目にするものすべて（レイアウトや画像そして色も含む）はCSSを使ってスタイルが指定されています。画像についても、SVGを使って描画したものやSVGのデータURI （SCSSを使って生成しました）を利用したものが多数あります。一部の数式はLaTeXを使って記述し、内部でMathMLに変換しています。ページ番号や章番号、シークレットの番号はCSSのカウンターを使って生成しています。

近年では、O’Reillyが出版する書籍の多くで同様の仕組みが取り入れられています。このシステムは「Atlas」と名づけられています（atlas.oreilly.com）。AtlasはO’Reilly社内で使われるだけでなく、誰でも利用できるという特長があります。

ただし、本書はAtlasの典型的な利用例というわけではありませんでした。筆者の知る限り他に例のないやり方で、印刷用のCSSの限界に挑んだのが本書です。AtlasやAntenna House （Atlasが内部で利用するPDF生成プログラム）に多数のバグが発見されたほか、印刷関連のCSSの仕様自体にも問題点がたくさん見つかりました。もちろん、仕様の問題点はCSS作業グループに報告しました。

「Webの技術を使ってこのような本を作るには、どのくらいのコードが必要なのだろう」と思われたかもしれません。執筆段階での数値ですが、いくつか紹介します。

4,700行のSCSSからコンパイルされた3,800行のCSSによって、本書のスタイルは設定されました。
1万行あまりのHTMLが記述されました。
本書の中に図は322個ありますが、そのうち画像ファイル（SVG形式の画像やスクリーンショットを含む）は140個だけです。残りについては、単なるdivにCSSでスタイルを指定したものです。なお、本書のCSSとSCSSのうち65％は図のために使われています。

本書ではAtlas以外にも以下のようなツールが使われています。

バージョン管理のためのGit
CSSのプリプロセッサ向け言語SCSS
本書の原稿すべてを記述するのに使われたテキストエディターEspresso （macrabbit.com/espresso）
SCSSをCSSにコンパイルするCodeKit
オンラインデモや、そのスクリーンショットで使われたDabblet （dabblet.com）
手作業では記述できないSVGベースの画像を作成するのに使われたAdobe Illustrator
必要に応じてスクリーンショットを修正するために使われたAdobe Photoshop

英語版では、見出しにRockwellフォントが使われ、本文とコードにはそれぞれFrutigerとConsolasが使われました。献辞や多くの図ではBaskervilleも使われています。

本書は13インチのMacBook Airを使って執筆されました。また、ギリシャ、ケニア、オーストラリア、ニュージーランド、フィリピン、シンガポール、チリ、ブラジル、アメリカ、フランス、スペイン、イギリス（ウェールズ）、ポーランド、カナダ、オーストラリアなどさまざまな国と地域で執筆が行われました。

日本語版について

日本語版（本書）も原書にならい、HTMLやCSS、SVGなどで組版を行いました。従来のDTPシステムを使ってレイアウトを再現することはもちろん可能でしたが、こだわり抜かれた原書のデザインと「他に例のないやり方で、印刷用のCSSの限界に挑んだ」というこの『CSS Secrets』の要となるコンセプトを外した本作りをするわけにはいかなかったからです。

そこで、Vivliostyle （ビブリオスタイル）社の全面協力のもと、原書のデータをもとに日本語用のCSSを作成することになりました。Atlas用に書かれたソースを再現するため、Vivliostyle社がAtlasのオープンソースの部分を再利用してRuby （約600行）で開発したHeracles （仮称）とPDF生成エンジンVivliostyle Formatter （vivliostyle.com/ja/products/）の組み合わせを、原書で使われた膨大なCSSに対応させることに成功しました。これにより本書のページレイアウト、目次や索引の相互参照、ページ番号参照、日本語組版に対応した文字組みなどがHTML+CSSで実現しています。その上、HTML+CSSであることを利用してWebサイトの形でサンプル版（vivliostyle.com/ja/samples/css-secrets/）等を出せるようにもなりました。

また、日本語版のフォントはWebサイトでも利用できるよう、オープンソースフォントを採用しました。見出しと本文にSource Han Sansを、欧文の見出しにRokkittを使用しています。コードと多くの図にはそれぞれConsolasとBaskervilleを使用しています。これらはオープンソースではないため、Web版では代わりにSource Code ProとLibre Baskervilleを使用しています。

本書について

対象とする読者

本書の主なターゲットは、中級から上級のCSS開発者です。入門的な解説を省略し、最新のCSSの機能やその組み合わせの例を多数紹介します。以下のような読者を本書では前提としています。

CSS2.1に関する十分な知識と、数年間の利用経験を持っていること。例えば、要素の位置を難なく指定できることや、冗長なマークアップや画像に頼らずに必要なコンテンツを生成してデザインを強化できることなどが求められます。このような読者なら、特定度や継承そしてカスケードについて理解しており、コード内に!importantを散乱させるようなことはないでしょう。ボックスモデルの構成要素についても理解し、マージンの減少に惑わされることもないはずです。長さの単位やその使い分けについても理解が求められています。
オンラインの資料や書籍を通じて、CSS3の機能のうち主なものについてはすでによく理解していること。たとえ個人的なプロジェクトであっても、これらの機能を実際に試していることが望まれます。これらを深く学んだことはないという場合でも、角の丸め方やbox-shadowの使い方、線形グラデーションの構文などについては知っているべきです。基本的な2次元トランスフォームを試してみたことがあり、トランジションやアニメーションを使ってインタラクションを拡張したこともあるとよいでしょう。
SVGを目にしたことがあり、その用途を知っていること。自分でSVGを記述できることまでは求めません。
基本的なJavaScriptのコードを読み、理解できること。要素の生成や属性の操作、ドキュメントへの要素の追加などに関する知識が必要です。
CSSのプリプロセッサについて、用途などを知っていること。実際に利用している必要はありません。
ある程度の数学の知識を持っていること。平方根、ピタゴラスの定理、サインやコサイン、対数などについて知っていることが求められます。

これらの条件をすべて満たすわけではない読者も本書を楽しめるように、一部のシークレットでは冒頭に「知っておくべきポイント」という項を設けています。下のように、対象のシークレットを理解するために必要なCSS関連の知識や既出のシークレットを示しました。なお、この項が長くなりすぎるのを防ぐために、CSS2.1関連の機能については紹介していません。

知っておくべきポイント

box-shadow、基本的なグラデーション、「さまざまな楕円形」

こうすることによって、未知の事柄について調べてから本書に戻ってくるというのが容易になります。ここで指示されていない限り、それぞれのシークレットはどのような順序で読んでもかまいません。ただし、シークレットは順序を意識して執筆されています。初めから順に読めば、最も多くの効果を得られるでしょう。

先ほど、想定される読者として「CSS開発者」と述べ、デザインのスキルを求めていないのには理由があります。本書はデザインの手引書ではありません。やむを得ない箇所ではデザインの原則に触れ、UXの改善策を明らかにすることもありますが、本書『CSSシークレット』にとっての第一の目標はコーディングを通じて問題を解決することにあります。SVGやWebGL、OpenGL、JavaScriptのCanvas APIなどは、コードでありデザインではありません。同様にCSSも、出力は視覚的ですが実体はコードです。柔軟で正しいCSSを記述するためには、プログラミングで必要になるのと同様の論理的な思考が求められます。今日ではほとんどの人々がCSSとプリプロセッサを併用しており、変数や数式、条件分岐、ループなども記述されています。つまり、CSSは今やプログラミング言語であるとも言えます。

ただし、デザイナーは本書を読むべきではないというわけでもありません。CSSのコードをある程度記述したことがあるなら、誰でも本書のメリットを享受できるはずです。有能なデザイナーの中には、優れたCSSのコードを記述できる人もたくさんいます。一方、本書を読めば副次的な効果としてWebサイトの視覚的デザインやユーザビリティを向上できるかもしれませんが、これら自体は本書の目標には含まれていません。

表記のルール

本書は7つのトピックに分類された47個の「シークレット」から構成されます。それぞれのシークレットはある程度独立しており、依存関係のないものについては好きな順番で読んでもかまいません。また、シークレットを紹介するデモのページは完全なWebサイトではなく、サイトの一部ですらありません。理解しやすいように、それぞれのデモは可能な限り小さくシンプルなものになっています。本書では、自分が実現しようとしていることについて読者は理解しているものとします。本書は読者に、デザイン上のアイデアではなく実装可能なソリューションを提供します。

すべてのシークレットは複数の節に分割されています。1つ目の節「課題」では、我々が解決しようとするCSSでのよくある問題を明らかにします。不適切だが広く使われている解決策（多量のマークアップが必要、値がハードコードされる、など）がここで紹介されることもあります。そして、「よりよい解決策はないのか?」という問いかけが続くことになります。

課題の紹介に続いて、1つまたは複数の解決策が示されます。本書は筆者がさまざまなカンファレンスで行ったCSS関連の講演を元にしており、可能な限りインタラクティブな形で解説を進めていきます。それぞれの解決策はいくつかの画像とともに提示され、視覚的な変化を段階的に示します。すべての画像を該当する本文に隣接して表示させるのは不可能なため、画像にはできるだけ番号をつけて参照できるようにしています。例えば、この文には図例.1への参照が含まれています。

本文中のコードはmonospace textのように記述されます。#f06のように、色を表すコードでは小さなプレビュー表示も追加されます。コードのブロックは次のように示されます。

 
background: url("adamcatlace.jpg");

もう1つ例を示します。

 
<figure>
	<img src="adamcatlace.jpg" />
	<figcaption>Sir Adam Catlace</figcaption>
</figure>

見てのとおり、CSS以外の言語で記述されたコードのブロックでは右上隅に言語を示しています。また、対象のコードに要素が1つしか記述されておらず、擬似クラスや擬似要素も必要ない場合には、セレクタや{}を省略しています。

本書でのJavaScriptのコードはすべて純粋なJavaScriptであり、フレームワークやライブラリは使用していません。ただし、ヘルパー関数として$$()を定義し利用しています。あるセレクタにマッチしたすべての要素に対して同じ処理を繰り返すために、この関数が使われています。定義は以下のとおりです。

 
function $$(selector, context) {
	context = context || document;
	var elements = context.querySelectorAll(selector);
	return Array.prototype.slice.call(elements);
}

すべてのシークレットにはオンラインのデモが用意されており、短く覚えやすいURLとともにplay.csssecrets.ioで公開されています。例を示します。

紹介されているテクニックがわかりにくかった場合などには、ここで紹介されているデモにアクセスしてみることを強くおすすめします。

ほぼすべてのシークレットでは、関連する仕様のリストを末尾で紹介しています。

ここには、シークレットの中で言及されている仕様がすべて掲載されます。ただし「知っておくべきポイント」の項と同様に、CSS2.1 （w3.org/TR/CSS21）についてはすべてのシークレットで明らかに参照されているため省略します。つまり、CSS2.1の機能だけを利用している少数のシークレットでは、「関連する仕様」の項がないということになります。

ブラウザの対応状況と代替案

本書の中で最も奇妙と思われるであろう点は、各ブラウザでの互換性を示す表がまったくないことです。これは意図的な判断にもとづいています。今日のブラウザはリリースの周期がとても短いため、執筆時点での最新の情報も、本書が書店に並ぶ頃には陳腐化していると考えられます。このような不正確な情報は誤解の元であり、何も掲載しないほうがまだましです。

とはいえ、ほとんどのシークレットはかなりのブラウザでサポートされており、そうでない場合にも代替の表現を用意するよう心がけています。紹介されているテクニックに対応したブラウザが少ない場合には、上のように「不完全なサポート」のアイコンが表示されます。このアイコンとともに示されているテクニックを利用する際には、各ブラウザの対応状況をチェックするとともに、非対応の場合のために適切な代替表示を用意しましょう。

各機能への最新の対応状況が掲載されたWebサイトが多数あります。その中の一部を紹介します。

ある機能を複数のブラウザで利用できるけれども、ブラウザ間でふるまいが多少異なるというケースもあります。例えばベンダーの接頭辞が必要だったり、少しだけ構文が異なるといった場合が考えられます。本書では、接頭辞なしの標準に準拠した構文だけを掲載しています。もちろん、複数の構文を併記し、どの構文が使われるかについてはカスケードの仕組みに任せてもかまいません。例えばyellowからredに変化する上下方向の線形グラデーションを記述する場合、本書では以下のように標準にもとづく構文だけを示します。

 
background: linear-gradient(90deg, yellow, red);

しかしかなり古いブラウザもサポートしたいなら、次のようなコードが必要になるでしょう。

 
background: -moz-linear-gradient(0deg, yellow, red);
background: -o-linear-gradient(0deg, yellow, red);
background: -webkit-linear-gradient(0deg, yellow, red);
background: linear-gradient(90deg, yellow, red);

各ブラウザでの対応状況と同様に、ふるまいの差異も常に流動的です。以降では、これらの点について本文中で言及することはありません。CSSの機能を利用する際には、常にこれらの点に関するチェックを読者に求めたいと思います。

たとえ見苦しいものだとしても、代替案を用意して古いブラウザでも正しく表示されるようにするというのはよいことです。本書の読者はカスケードの仕組みを理解しているはずであり、ことさらに詳しく解説するということはありません。例えば上のグラデーションの例では、単色での塗りつぶしをまず記述するべきです。次のように、グラデーションで使われている色の中間色（ここでは、rgb(255, 128, 0)）を指定するのがよいでしょう。

 
background: rgb(255, 128, 0);
background: -moz-linear-gradient(0deg, yellow, red);
background: -o-linear-gradient(0deg, yellow, red);
background: -webkit-linear-gradient(0deg, yellow, red);
background: linear-gradient(90deg, yellow, red);

しかし、カスケードを使っても適切な代替案を提供できないこともあります。最後の手段として、Modernizr （modernizr.com）などのツールを利用するということも考えられます。これを使うと、ルート要素（<html>）にtextshadowやno-textshadowといったクラスが追加されます。これらのクラスを参照して、以下のように特定の機能がサポートされている（あるいは、されていない）場合だけに適用されるスタイルを記述できます。

 
h1 { color: gray; }

.textshadow h1 {
	color: transparent;
	text-shadow: 0 0 .3em gray;
}

代替案を用意しようとしている機能が最近のものなら、@supportsというルールを記述できます。ここでは、Modernizrと同等の機能がネイティブに提供されます。例えば上のコードは、@supportsを使って次のように書き換えられます。

 
h1 { color: gray; }

@supports (text-shadow: 0 0 .3em gray) {
	 h1 {
		color: transparent;
		text-shadow: 0 0 .3em gray;
	}
}

しかし現時点では、@supportsの利用には注意が必要です。上のように記述されたルールが効果を持つのは、単にテキストの影に対応したブラウザではなく、@supportsというルールにも対応したブラウザでなければなりません。そして、この@supportsに対応しているブラウザはまだ少数です。

どんな場合にも、数行のJavaScriptを記述して対応状況を検出するということは可能です。Modernizrと同様に、検出結果はクラスとしてルート要素に追加します。検出対象としては、任意の要素でのelement.styleオブジェクトを利用できます。コードの例を示します。

 
var root = document.documentElement; // <html>

if ('textShadow' in root.style) {
	root.classList.add('textshadow');
}
else {
	root.classList.add('no-textshadow');
}

複数のプロパティについて調べる必要があるなら、以下のような関数を用意してもよいでしょう。

 
function testProperty(property) {
	var root = document.documentElement;

	if (property in root.style) {
		root.classList.add(property.toLowerCase());
		return true;
	}

	root.classList.add('no-' + property.toLowerCase());
	return false;
}

特定のプロパティの値に対応しているかどうか調べるには、実際に値をセットし、その後で同じ値が保持されているかをチェックします。ここでは特定の値への対応を調べたいだけであり、実際にスタイルを設定したいわけではありません。そこで、下のようにダミーの要素を使うのがよいでしょう。

 
var dummy = document.createElement('p');
dummy.style.backgroundImage = 'linear-gradient(red,tan)';

if (dummy.style.backgroundImage) {
	root.classList.add('lineargradients');
}
else {
	root.classList.add('no-lineargradients');
}

このコードも、下のように関数にできます。

 
function testValue(id, value, property) {
	var dummy = document.createElement('p');
	dummy.style[property] = value;

	if (dummy.style[property]) {
		root.classList.add(id);
		return true;
	}

	root.classList.add('no-' + id);
	return false;
}

個々のセレクタや@ルールへの対応状況をチェックするのはもう少し面倒ですが、基本的な方針は共通です。先ほどと同様に、ブラウザは自らが理解できないものをすべて破棄するという性質を利用します。チェックしたい機能を動的に適用し、その値が破棄されずに残っていれば対象の機能がサポートされていると判断できます。ただし、ブラウザがある値を解釈できるからといって、その機能が正しく実装されている（あるいは、そもそも実装されている）とは限りません。

意見と質問

本書（日本語翻訳版）の内容は最大限の努力をして検証・確認していますが、誤り、不正確な点、バグ、誤解や混乱を招くような表現、単純な誤植などに気が付かれることもあるかもしれません。本書を読んでいて気付いたことは、今後の版で改善できるように私たちに知らせてください。将来の改訂に関する提案なども歓迎します。連絡先は以下に示します。

株式会社オライリー・ジャパン
電子メール　　 japan@oreilly.com

本書についての正誤表や追加情報などは、次のサイトを参照してください。

http://www.oreilly.co.jp/books/9784873117669/ （和書）
http://shop.oreilly.com/product/0636920031123.do （原著）
http://lea.verou.me/ （著者）

オライリーに関するその他の情報については、次のオライリーのWebサイトを参照してください。

http://www.oreilly.co.jp/
http://www.oreilly.com/ （英語）

Webサンプル版について

Webブラウザから読める本書のサンプルページをご用意しました。書籍版同様のページレイアウト、目次や索引の相互参照、ページ番号参照、日本語組版に対応した文字組みなどをWebブラウザ上でご確認いただくことが可能です。

http://vivliostyle.com/ja/samples/css-secrets/

イントロダクション

Web標準は敵か？味方か？

標準化のプロセス

「Web標準とかけてソーセージと解く。その心は、作っている現場は見ないほうがよい」――匿名のW3C作業グループメンバー

一般的な思い込みとは異なり、W3C （World Wide Web Consortium）は標準を「作って」いるわけではありません。W3Cは利害関係者が集まるフォーラムであり、実際の活動はW3Cの作業グループで行われます。もちろん、W3Cは単なる傍観者ではなく、基本的なルールを定めるとともに標準化のプロセスを監督しています。ただし、（主に）仕様を執筆しているのはW3Cのスタッフではありません。

CSSの仕様は、CSS作業グループ（CSS Working Group＝CSS WGと略されることもよくあります）のメンバーによって作成されています。本書執筆時点では、CSS作業グループには98名が参加しており、その内訳は以下のとおりです。

86名 （88％）……W3Cの会員である企業からのメンバー
7名（7％）……Invited Expert （筆者も含む）
5名（5％）……W3Cのスタッフ

作業グループのメンバーのうち88％という大多数が、W3Cに加入している企業によって占められています。これらの企業には、ブラウザベンダーや著名なWebサイト、研究機関、その他一般のテクノロジー企業などが含まれており、それぞれがWeb標準の普及に関して利害関係を持っています。W3Cにとっての収入の大部分は各企業が納める年会費であり、仕様は無料かつオープンに公開されています。一方、このような収入源を持たない他の標準化団体では、仕様が有償で公開されることもあります。

CSS作業グループの構成。
企業のメンバー
Invited Experts
W3Cのスタッフ

Invited Expertとは、標準化プロセスへの参加を要請されたWeb開発者です。議論に参加するための幅広い知識と、貢献の表明が求められます。

そしてW3Cのスタッフは実際にW3Cに勤務しており、作業グループとW3Cの調整を受け持ちます。

Web開発者の間に広まっている誤解のひとつに「W3Cは見下すように標準を定義し、弱い立場のブラウザベンダーは否応なしに追従しなければならない」という話があります。これはまったく事実ではありません。仕様に何を盛り込むかという点について、ブラウザベンダーはW3Cよりもはるかに多くの発言権を持っています。先ほどの数値を見れば、このことは明らかです。

標準は密室の中で作られるというのも誤解です。CSS作業グループは透明性を重視しており、すべてのコミュニケーションは公開されています。そして以下のように、さまざまな手段でのレビューや関与が促されています。

ほとんどの議論はメーリングリスト「www-style （lists.w3.org/Archives/Public/www-style）」上で行われます。アーカイブは公開されており、参加も自由です。
週に1度、1時間の電話会議が開催されます。作業グループのメンバー以外は参加できませんが、リアルタイムに議事録が作成されてW3CのIRCサーバー（irc.w3.org/）の#cssチャネルで公開されています。この議事録は清書され、数日後にメーリングリストに投稿されます。
四半期ごとに、対面で行う会議も開かれます。電話会議の場合と同じ要領で議事録も公開されます。作業グループの議長から許可を得れば、傍聴も可能です。

このようなプロセスはすべてW3Cで定義されており、意思決定の基礎になります。一方、意思決定の結果を実際の仕様として表現するのはSpec Editorの役割です。Spec EditorはW3Cのスタッフかもしれず、ブラウザベンダーやInvited Expertかもしれません。公共の利益をめざして標準化プロセスを前進させようと、企業に勤めながら専任で執筆を行うようなメンバー企業の従業員もいます。

仕様は複数の段階を経て、誕生から完成へと向かいます。

Editor’s Draft （ED）： この段階では、Spec Editorが単にアイデアをまとめただけであり、とても乱雑な状態です。この段階の仕様には、満たすべき要件はまだありません。また、作業グループは仕様の内容について何も保証しません。しかし、すべてのバージョンに先立つのがこのEditor’s Draftです。すべての変更はまずEditor’s Draftとして作成され、そして公開されます。
First Public Working Draft （FPWD）： 作業グループによるレビューが可能な状態になり、初めて公開されたバージョンの仕様です。
Working Draft （WD）： 作業グループやより広いコミュニティーからフィードバックを得て、少しずつ改善を繰り返しながら何度もこのWorking Draftが公開されます。この段階で初めて実装が作成されることが多いのですが、より早い時点から試験的な実装が行われることもなくはありません。
Candidate Recommendation （CR）： かなり安定したバージョンです。実装やテストに適した状態です。完全なテストと、2つ以上の独立した実装が用意されるまでは次の段階に進めません。
Proposed Recommendation （PR）： W3Cメンバーの企業が仕様への反対を表明するには、この段階が最後のチャンスです。しかしこの段階まで到達していれば、反対はほとんど見られません。次の段階への到達は、単に時間の問題です。
Recommendation （REC）： W3Cによる仕様としての最終段階です。

作業グループのメンバーのうち1人または2人が議長を務めます。議長は会議の運営や電話会議の調整、時間の管理、その他さまざまな点で進行役として機能します。議長というのは多くの時間と体力を消耗する役職で、あたかも猫の群れを引率するかのようです。もちろん、標準化に関わる人々はみな、このようなたとえは不適切だということを知っています。実際には、猫の引率のほうがずっと楽です。

CSS3、CSS4、そしてその他の創造物たち

CSS1はとても短くシンプルな仕様でした。1996年に、Håkon Wium LieとBert Bos によって執筆されました。仕様全体が1つのHTMLページに収まっており、A4の紙に印刷してもわずか68ページでした。

1998年に公開された CSS2 （CSS Level 2）では、より厳密な定義が行われました。Chris Lilleyと Ian Jacobsという2名のSpec Editorが加わり、強力な仕様になりました。この時点で、仕様書を印刷すると480ページにも上り、1人でそのすべてを記憶するのは困難でした。

このCSSという言語は大きくなりすぎ、1つの仕様書に収めるのは困難だという結論がCSS2の公開後に導き出されました。巨大な仕様は理解するのも執筆するのも難しいだけでなく、CSS自体の進歩も妨げています。仕様が最後の段階に進むためには、仕様に含まれるすべての機能について2つ以上の独立した実装と完全なテストが必要だというルールを思い出してください。この条件を満たすことは、もはや非現実的でした。そこで、CSSを複数の仕様つまりモジュールに分割し、それぞれに独自のバージョン番号が付与され改訂されていくということになりました。CSS2.1で定義されている機能を拡張したものについては、3というレベル（バージョン）番号が与えられました。主なモジュールは以下のとおりです。

CSS Syntax （w3.org/TR/css-syntax-3）
CSS Cascading and Inheritance （w3.org/TR/css-cascade-3）
CSS Color （w3.org/TR/css3-color）
Selectors （w3.org/TR/selectors）
CSS Backgrounds & Borders （w3.org/TR/css3-background）
CSS Values and Units （w3.org/TR/css-values-3）
CSS Text （w3.org/TR/css-text-3）
CSS Text Decoration （w3.org/TR/css-text-decor-3）
CSS Fonts （w3.org/TR/css3-fonts）
CSS Basic User Interface （w3.org/TR/css3-ui）

一方、まったく新しい概念を表すモジュールには1というレベル番号が与えられました。例えば以下のようなモジュールが定義されています。

CSS Transforms （w3.org/TR/css-transforms-1）
Compositing and Blending （w3.org/TR/compositing-1）
Filter Effects （w3.org/TR/filter-effects-1）
CSS Masking （w3.org/TR/css-masking-1）
CSS Flexible Box Layout （w3.org/TR/css-flexbox-1）
CSS Grid Layout （w3.org/TR/css-grid-1）

CSS 3という言葉は流行していますが、CSS3そのものを定義した仕様はどこにもありません。この点は、CSS2.1やそれ以前の仕様とは異なります。ほとんどの場合、レベル3の仕様の一部といくつかのレベル1の仕様をまとめたものがCSS3と呼ばれています。どの仕様を「CSS3」に含めるかについては、合意が形成されつつあります。しかし、それぞれのモジュールが異なるペースで進歩していくということを考慮すると、CSS3やCSS4などといった言葉を定義して意味を広く理解してもらうのはますます困難になっていくでしょう。

ベンダー接頭辞の物語

標準化プロセスには常に、大きなジレンマが伴います。実際の開発でのニーズを反映した仕様を作成するために、作業グループは開発者からの意見を求めています。しかし、一般的なWeb開発者は実運用環境で利用できない機能には興味を示しません。そこで、実験的な機能を実運用環境で広く利用できるようにしてしまうと今度はこの実験的なバージョンを保持することを迫られます。仕様を変更すると、この仕様を利用している既存のWebサイトが機能しなくなってしまうためです。初期段階の標準を試用できるというメリットが、帳消しになってしまいます。

この矛盾した状況に対する解決策は多数考えられてきましたが、いずれも完全なものではありません。誰もが忌み嫌うベンダーごとの接頭辞も、解決策の1つです。ここでの考え方は、機能の名前にベンダーごとの接頭辞（ベンダープレフィックス）をつければ、実験的な機能を（あるいはプロプライエタリな機能でさえも）実装してかまわないというものです。Firefoxでは-moz-、IEでは-ms-、Operaでは-o-、SafariやChromeでは-webkit-という接頭辞が使われています。開発者はこのような接頭辞つきの機能を自由に利用でき、その結果を作業グループにフィードバックできます。このフィードバックは仕様に反映され、機能の設計は少しずつ向上するでしょう。また、最終的な標準では接頭辞なしの名前が使われるため、接頭辞つきの機能を使い続けても競合が発生することはありません。

この説明だけを聞くととてもすばらしい仕組みのように思えますが、現実は理想からかけ離れています。接頭辞つきの実験的な機能を使い始めた開発者は、以前なら込み入った一時しのぎのマークアップが必要だった機能を簡単に実現できることを知り、至る所でこのような機能を使い始めました。そして接頭辞つきの機能は、あっという間にCSSでの主流になってしまいました。チュートリアルが執筆され、StackOverflowに質問と回答が投稿され、ほぼすべての著名なCSS開発者もそこかしこで接頭辞つきの機能を使うようになりました。

既知の接頭辞つきの機能だけを使っていると、他のブラウザが同じ機能を実装するたびに宣言を追加しなければならないということに開発者たちは気づきはじめました。しかも、どの機能にどの接頭辞が必要かを常に把握しておくというのはきわめて困難です。そこで、当初からすべての接頭辞を加えた機能を記述し、保険として最後に接頭辞なしの機能も追加するということが横行するようになりました。具体的には次のようなコードが使われます。

 
-moz-border-radius: 10px;
-ms-border-radius: 10px;
-o-border-radius: 10px;
-webkit-border-radius: 10px;
border-radius: 10px;

この例では、-ms-border-radiusと-o-border-radiusの2つは完全に無駄です。IEとOperaは初めからborder-radiusを接頭辞なしで実装しており、接頭辞つきのものはまったく存在しません。

すべての機能を最大5回も繰り返し記述しなければならないというのは面倒であり、保守も困難です。そこで当然のように、こういった記述を自動化できるツールが生まれました。いくつか例を紹介します。

CSS3, Please! （css3please.com）やpleeease （pleeease.io/playground.html）などのWebサイトを利用すると、接頭辞なしのコードを元にしてすべての接頭辞を含むコードを生成できます。接頭辞を自動的に加えるための手法としてはごく初期のものです。他の方法と比べて負荷がとても高いため、現在ではあまり使われていません。
Autoprefixer （github.com/ai/autoprefixer）は、Can I Use... （caniuse.com）のデータベースを利用して必要な接頭辞だけを追加します。プリプロセッサのように、追加はローカルで行われます。
筆者が作成した-prefix-free （leaverou.github.io/prefixfree）は、ブラウザ上で対象の機能の有無をチェックし、どのような接頭辞が必要かを判断します。必要な情報（プロパティのリストなども含む）はすべてブラウザから取得するため、アップデートがほとんど必要ないというメリットがあります。

LESS （lesscss.org）やSass （sass-lang.com）などのプリプロセッサは、デフォルトでは接頭辞の追加は行えません。しかし、頻繁に接頭辞が追加される機能については多数のミックスインが作成されており、このようなミックスインを集めたライブラリも公開されています。

将来にわたって機能を利用し続けられるようにするために、開発者は接頭辞なしの機能を利用しがちです。しかしそうすると、一度定義された機能は変更がほぼ不可能になります。我々は中途半端な未完成の仕様に縛られ、限られた範囲の変更しか許されない状況に陥っています。ベンダーの接頭辞という仕組みが壮大な失敗に終わったことは、間もなく誰の目にも明らかになるでしょう。

最近では、試験的な実装のためにベンダーの接頭辞が使われることはあまりありません。代わりに、ブラウザ上で設定を変更しないと試験的な機能を利用できないようになってきています。ユーザーに対してブラウザの設定変更を求めるのは現実的ではないため、試験的な機能を実運用環境で利用することは事実上不可能になりました。これには試験的な機能が使われにくくなる側面もありますが、依然として十分な（かつ、おそらく質の高い）フィードバックを得ることができ、接頭辞にまつわる問題からは解放されます。ただし、接頭辞によって引き起こされた問題が完全に収束するには長い時間がかかるでしょう。

CSSコーディングのコツ

重複を最小限に抑える

コードをDRYで保守しやすい状態に保つことは、ソフトウェア開発での最大の課題の1つです。これはCSSにも当てはまります。保守の容易なコンポーネントが1つだけあれば、変更が必要になった場合に修正しなければならない箇所の数を最小にできます。例えばあるボタンの大きさを変える際に複数のルールで10箇所も変更が必要だとしたら、変更し忘れた箇所が残ってしまう可能性があります。もしそれが他人によるコードなら、変更忘れの可能性はさらに高まります。たとえ変更点が明確だったとしても、あるいは最終的にはすべての変更点を発見できたとしても、他のことのために利用できたかもしれない時間が浪費されることになります。

しかも、このような手間は修正の際にだけ発生するわけではありません。柔軟なCSSは一度作成すれば、ほんの少しの変更を加えるだけでさまざまなバリエーションを作成できます。上書きしなければならない値の数がとても少ないためです。例を見てみましょう。

Yes!

この節での説明の例として利用するボタン

図 1.4のボタンでは、次のCSSがスタイル指定に使われています。

 
padding: 6px 16px;
border: 1px solid #446d88;
background: #58a linear-gradient(#77a0bb, #58a);
border-radius: 4px;
box-shadow: 0 1px 5px gray;
color: white;
text-shadow: 0 -1px 1px #335166;
font-size: 20px;
line-height: 30px;

このコードには、保守のしやすさに関して修正するべき点がいくつかあります。最初に直すべきなのは、フォントに関する指定です。例えばより重要な意味を持ったボタンを作成するために、フォントサイズを変えたくなったとしましょう。この場合、行の高さも合わせて変更しなければなりません。両者がともに絶対的な値として指定されているためです。また、行の高さにはフォントサイズとの関係がありません。つまり、フォントサイズを変えたら適切な行の高さを計算しなおさなければなりません。このように、相互依存している値については、コードの中で両者の関係を表すようにしましょう。上のコードでは、行の高さはフォントサイズの1.5倍です。したがって、次のようにすれば保守性を大幅に向上できます。

 
font-size: 20px;
line-height: 1.5;

Yes!

フォントサイズを大きくしたら、値が絶対指定されている他の効果（角の丸めなど）が崩れた

さて、フォントサイズについても絶対指定する必要はないことに気づかれたでしょうか。絶対指定の値は記述が容易ですが、変更が必要になるたびに代償を払わされることになります。例えば親要素でのフォントサイズを大きくしたい場合、フォント関連のルールのうち値が絶対指定されているものをすべて変更しなければなりません。パーセンテージ（下記コード参照）またはemを使えば、この問題を回避できます。

 
font-size: 125%; /* 親要素でのフォントサイズが16pxの場合 */
line-height: 1.5;

こうすれば、親要素のフォントサイズが変更された場合にボタンも自動的に追従します。しかし、現状のボタンは図 1.5のように外見が大きく変わってしまっています。いくつかの表示効果が小さいボタン向けにデザインされており、拡大されなかったためです。これらについても長さをem単位で指定すれば、フォントサイズに合わせて伸縮するようになります。つまり、ボタンのサイズ関連のすべての値を1か所で変更できます。

ここではフォントサイズやその他の値を親要素でのフォントサイズに対する相対値として指定するために、emを指定しています。一方、ルート要素（<html>）でのフォントサイズに対する相対値として指定を行いたい場合も考えられます。このような場合、emを使って指定しようとすると面倒な計算が必要になることがあります。ここでremという単位を代わりに使うと、ルート要素に対する相対値を記述できます。CSSでの相対指定の機能は便利ですが、何に対する相対値なのかという点については注意する必要があります。

 
padding: .3em .8em;
border: 1px solid #446d88;
background: #58a linear-gradient(#77a0bb, #58a);
border-radius: .2em;
box-shadow: 0 .05em .25em gray;
color: white;
text-shadow: 0 -.05em .05em #335166;
font-size: 125%;
line-height: 1.5;

Yes!

ボタンの大きさに連動して、表示効果も適切に伸縮した

こうすれば、ボタンは元のものを拡大したのと同じように表示されます（図 1.6）。なお、上のコードでは一部に絶対指定の値が残っています。これは、どの長さをボタンに合わせて伸縮し、どれを固定値のまま保つべきかという判断の結果です。具体的には、ボーダーの太さはボタンの大きさに関わらず1pxのままであるべきと判断しました。

ただし、変更の可能性があるのはボタンの大きさだけではありません。色も変更の対象として重要です。例えば、緑色のOKボタンや赤いキャンセルボタンを作る場合について考えてみましょう。このためには、ボタンで使われる各種の色（メインの色である#58aと、これを明るくあるいは暗くしたバリエーション）を適切に変更するのに加えて、現状のコードの中で4か所（border-color、background、box-shadow、text-shadowに修正が必要です。また、白以外の背景にボタンを配置する場合についても考慮しなければなりません。grayで指定した影の色が意図したとおりに表示されるのは、背景が白の場合だけです。

このような色の値の再計算は、簡単に回避できます。半透明の白または黒をメインの色に重ねることによって、より明るいまたはより暗い色を表現できます。

 
padding: .3em .8em;
border: 1px solid rgba(0,0,0,.1);
background: #58a linear-gradient(hsla(0,0%,100%,.2),
                                 transparent);
border-radius: .2em;
box-shadow: 0 .05em .25em rgba(0,0,0,.5);
color: white;
text-shadow: 0 -.05em .05em rgba(0,0,0,.5);
font-size: 125%;
line-height: 1.5;

Cancel

背景色を変更するだけで、さまざまなボタンを作成できる

こうすれば、下のようにbackground-colorを上書きするだけで別のボタンを作成できます（図 1.7）。

 
button.cancel {
	background-color: #c00;
}

button.ok {
	background-color: #6b0;
}

現状でも、ボタンのコードはかなり柔軟です。しかし、コードをDRYな状態に保つために可能なことはまだあります。以下の節で、ヒントをいくつか紹介します。

保守の容易さと簡潔さの両立

保守性と簡潔さが相容れない関係になることがあります。先ほどの例でも、最終的なコードは当初のものより大きくなりました。別の例として、左側以外に幅10pxの太いボーダーを描画するための下のコードを見てみましょう。

 
border-width: 10px 10px 10px 0;

ここには宣言は1つしか記述されていません。しかし、ボーダーの太さを変更するためには3か所に修正が必要です。下のように宣言を2つに分けたほうが修正しやすく、読みやすさも向上します。

 
border-width: 10px;
border-left-width: 0;

currentColor

最初の変数はcurrentColorではなく、font-sizeの値を表すemだという意見もあります。この意味では、（面白みはありませんが）パーセンテージで表された値も変数と言えるでしょう。

CSS Color Level 3 （w3.org/TR/css3-color）では、例えばlightgoldenrodyellowのように色を表すキーワードが多数追加されましたが、これらにはあまり使い道はありません。しかし同時に、SVGが起源のcurrentColorという新しいキーワードも定義されています。これは特定の色を静的に表すのではなく、現在のcolorプロパティの値を表します。実質的に、このcurrentColorはCSSでの初めての変数です。用途はとても限られていますが、れっきとした変数です。

例として、横の区切り線（<hr>要素）がすべてテキストと同じ色になるようにしてみましょう。currentColorを使うと、次のように表現できます。

 
hr {
	height: .5em;
	background: currentColor;
}

既存のプロパティの多くでも、同様の効果が適用されていることに気づかれたかもしれません。例えば色を指定せずにボーダーを表示させた場合、自動的にテキストと同じ色が適用されます。実は、色に関する多くのプロパティ（border-color、text-shadowやbox-shadowの色、outline-colorなど）でデフォルト値としてcurrentColorが設定されています。

将来的に、CSSの中でネイティブに色を操作する関数が用意されたなら、currentColorにもバリエーションが生まれてさらに便利になるでしょう。

継承

ほとんどの開発者はinheritというキーワードを知っているはずですが、しばしば忘れ去られています。このキーワードはCSSのすべてのプロパティで利用でき、親要素（擬似要素では、適用対象の要素）で実際に算出された値を表します。例えばフォームの要素をページ内の他の要素と同じフォントにしたい場合、このフォントの設定を繰り返し記述する必要はありません。以下のように、inheritを使って記述できます。

 
input, select, button { font: inherit; }

同様に、ハイパーリンクのテキストの色を他の部分と揃えたい場合には次のようにします。

 
a { color: inherit; }

inheritキーワードは背景へのスタイル設定でも効果的です。例えば、（図 1.8）のような吹き出しで、突き出た部分の背景とボーダーの設定を吹き出し本体から継承できます。

左側の図では、茶色の四角形は正確に縦方向の中央に配置されているが、そうは見えない。一方右側では、中央よりも少し上に茶色の四角形が配置されているが、人間の眼にとってはより中央に近いものとして認識される

 
.callout { position: relative; }

.callout::before {
	content: "";
	position: absolute;
	top: -.4em; left: 1em;
	padding: .35em;
	background: inherit;
	border: inherit;
	border-right: 0;
	border-bottom: 0;
	transform: rotate(45deg);
}

数字ではなく自分の眼に頼る

人間の眼は、入力装置としてはとても不完全です。正確に値を指定しても不正確な見た目になってしまうことがあり、この点を踏まえたデザインが求められます。例えば、我々の眼は縦方向の中央に配置したものをずれて認識してしまうことがよく知られています。中央にあると認識させるためには、計算上の中央よりも少し上に対象を配置する必要があります。図 1.9を自分の眼で見て、確かめてみましょう。

円は小さく見えるが、外周のボックスは左側の四角形とまったく同じ大きさである

タイポグラフィーの世界でも、同様の錯覚が知られています。丸い形状は実際よりも小さく認識されがちであるため、Oなどの字は角張った字よりもわずかに大きく表現する必要があります。実例を図 1.10に示します。

yolo

コンテナの四辺で同じ幅のパディング（ここでは.5em）を指定しても、上下のパディングは大きく感じられる

yolo

左右のパディングを増やす（ここでは.3em .7em）と、均等に見える表示を得られる

このような錯覚は、視覚的デザインの分野ではしばしば見られます。我々には錯覚を考慮に入れたデザインが求められます。例えば、テキストを含むコンテナでのパディングはとても頻繁に使われています。ここでの問題は、テキストの量（単語1つかもしれず、複数の段落かもしれません）にかかわらず発生する点です。4つの辺で同じパディングの幅を指定すると、図 1.11のように不釣り合いな表示になってしまいます。アルファベットの横線より縦線のほうが長いため、上下のスペースが余分なパディングとして知覚されています。したがって、等しい幅に見せるためには上下のパディングを若干少なくする必要があります（図 1.12）。

レスポンシブWebデザイン

レスポンシブWebデザイン：RWDはここ数年の間に熱狂的な話題になっています。しかし、Webサイトを「レスポンシブ」にすることだけが重視され、本当のレスポンシブWebデザインとは何なのかという点に対する検討は軽んじられています。

一般的には、さまざまな解像度の下でWebサイトを表示させ、問題が生じたらメディアクエリを使って解決を試みる方式がとられています。しかし、メディアクエリが増えると、後でCSSに変更が必要になった場合の手間も増大します。安易にメディアクエリを追加するべきではありません。CSSを変更する場合には、すべてのメディアクエリについても必要に応じて修正を加えなければなりません。メディアクエリへのチェックは忘れられがちで、しばしばレイアウトが崩れることになります。メディアクエリを追加するたびに、CSSのコードは不安定さを増します。

ただし、メディアクエリが悪いものだというわけではありません。正しく使えば、欠かせないツールとして役立つでしょう。しかし、他のすべての試みが失敗した場合や、ビューポートの状態に応じて完全にデザインを切り替えたい（例えば、サイドバーを横長に表示するなど）場合のための最終手段としてメディアクエリを位置づけるべきです。なぜなら、メディアクエリは問題の全体を解決してくれるわけではありません。メディアクエリは特定の境界値（ブレークポイント）の範囲内にしか関心がありません。コードに柔軟性がないなら、メディアクエリを使っても特定の解像度での表示が修正されるだけで、本質的な問題が覆い隠されてしまいます。

メディアクエリではピクセル数の代わりにemを使いましょう。こうすれば、テキストの表示倍率に応じてレイアウトを変更できます。

もちろん、メディアクエリでの境界値は特定のデバイスではなくデザインそのものにもとづいて決定するべきです。デバイスの種類が多すぎて（今後もさらに増えるでしょう）これらのすべてに対応するのが難しいだけでなく、デスクトップ上では任意のサイズのウィンドウでWebサイトが表示される問題もあります。そもそも、どんなサイズのビューポートでも正しく表示されるようなデザインでは、特定のデバイスが持つ特定のサイズを気にすることはないでしょう。

「重複を最小限に抑える」で紹介した原則も役立つでしょう。メディアクエリの中で上書きされる宣言の数を減らせば、負荷の上昇を防ぐことにもつながります。

不必要なメディアクエリを回避するためのヒントをいくつか紹介します。

幅は固定値ではなくパーセンテージで指定しましょう。これが不可能な場合は、ビューポートに対する相対値を表す単位（vw、vh、vmin、vmax）を使いましょう。これらを使うと、ビューポートの幅や高さに対する比率を表現できます。
高い解像度のデバイス上では固定幅の表示にしたい場合、widthの代わりにmax-widthを使いましょう。メディアクエリを使わなくても、小さな画面に対応できます。
置換要素（replaced element）。img、object、video、iframeなど）では、max-widthとして忘れずに100%を指定しましょう。

背景画像がコンテナ全体を覆う必要がある場合、background-size: coverと指定するとコンテナのサイズを記述する必要がなくなります。ただし、ネットワークの帯域幅には限度があります。モバイル向けのデザインでは、CSSを使って大きな画像を縮小するのが正しいとは限りません。

グリッドのセルの中に画像やその他の要素を配置する際には、ビューポートの幅に従って列の数が増減するようにしましょう。具体的には、Flexbox （Flexible Box Layout）やdisplay: inline-block;あるいは通常のテキストの折り返しを利用します。

段組みを使ってテキストを配置する場合、小さな画面では1段組みで表示するようにしましょう。column-countではなくcolumn-widthを指定します。

大まかに言うと、メディアクエリでのブレークポイントの前後で相対的なサイズ設定を保ち、リキッド（流動的）なレイアウトを実現しようというのがここでの考え方です。デザインが柔軟なら、2つか3つの簡単なメディアクエリを追加するだけでレイアウトをレスポンシブにできるでしょう。プロジェクト管理ソフトウェアBasecampのデザイナーは、まさにこのトピックについて2010年末に次のように語っています。

「多様なデバイスでレイアウトを機能させるには、完成したデザインに対してメディアクエリをいくつか追加するだけでよいのです。このためには、あらかじめレイアウトをリキッドなものにしておくことが重要です。そうすれば、小さな画面への対応が容易になります。例えば余白を削ったり、サイドバーを表示できるだけの幅がない場合にレイアウトを修正したりできます。」
Experimenting with responsive design in Iterations （signalvnoise.com/posts/2661-experimenting-with-responsive-design-in-iterations）

小さな（あるいは、大きな）画面への適応のために大量のメディアクエリが必要になってしまった場合には、1歩戻ってコードの構造を見直してみましょう。レスポンシブ性の欠如以外にも、きっと別の問題が見つかるでしょう。

短縮記法を賢く使う

もう知っている読者もいるかと思いますが、次の2つのコードは等価ではありません。

 
background: rebeccapurple;

 
background-color: rebeccapurple;

上のコードは短縮記法であり、必ずrebeccapurpleの背景色が表示されます。一方下のコードでは、表示されるのはピンクのグラデーションかもしれず、猫の画像かもしれません。対象の要素に指定されているbackground-imageの値が、引き続き有効であるためです。短縮記法を使わない場合には、この点に注意が必要です。リセットされずに残るプロパティのせいで、期待した効果が得られないことがあります。

短縮記法を一切使わずに、すべてのプロパティを毎回記述してもかまいません。しかしそうすると、漏れが生じる可能性があります。また、CSS作業グループが新しいプロパティを定義した場合、短縮記法を使っていない既存のコードはこの新しいプロパティをリセットできません。したがって、短縮記法の利用をためらうべきではありません。特定のプロパティだけを意図的に変更したい場合（「重複を最小限に抑える」でのボタンの色の例を参照）を除いて、短縮記法は安全策として優れており、今後の変化にも対応が容易です。

短縮ではない記法を短縮記法の補助として使うのも便利です。backgroundのようにカンマ区切りのリストを指定できるプロパティで、記述をよりDRYにできます。例を見てみましょう。

 
background: url(tr.png) no-repeat top right / 2em 2em,
            url(br.png) no-repeat bottom right / 2em 2em,
            url(bl.png) no-repeat bottom left / 2em 2em;

background-sizeとbackground-repeatについて、同じ値がそれぞれ3回も繰り返されています。CSSのリストでは、1つしか値が指定されていない場合にはその値が必要な回数だけ繰り返されます。この仕組みを利用して、下のように繰り返される値だけを短縮ではない記法で指定します。

 
background: url(tr.png) top right,
            url(br.png) bottom right,
            url(bl.png) bottom left;
background-size: 2em 2em;
background-repeat: no-repeat;

こうすれば、background-sizeやbackground-repeatを変更したい場合に1か所を修正するだけで済みます。同様のテクニックは、本書全体を通じて何度も使われることになります。

変わった短縮記法の構文

先ほどの例で、短縮記法のbackgroundの中でbackground-sizeを指定する場合の記述に奇妙な点がありました。デフォルト値から変更しない場合でもbackground-positionを合わせて指定しなければならず、両者の間にはスラッシュ（/）を記述する必要があります。なぜ、このような奇妙な構文が採用されたのでしょうか。

このような構文は、あいまいさを解消するために使われることがほとんどです。上のコードでは明らかに、top rightはbackground-positionを指し、2em 2emはbackground-sizeを指しています。たとえ順序が逆でも、両者は確実に識別できます。しかし、50% 50%と指定されていた場合はどうでしょう。これはbackground-sizeかもしれず、background-positionかもしれません。ここで短縮でない記法を使えば、CSSパーサー（解析器）に意図を正しく伝えられます。一方短縮記法では、プロパティ名という手がかりなしに50% 50%という値の意図を解釈しなければなりません。そこで、スラッシュが必要になるのです。

ほとんどの短縮記法のプロパティでは、このようなあいまいさの問題は発生せず、任意の順序で値を記述できます。しかし、予期しない結果を招かないように、正しい構文について知っておくことは重要です。正規表現や構文解析に詳しい読者は、仕様を読んで正確な構文を調べるのがよいでしょう。順序について知るには、これが一番の方法です。

プリプロセッサを使うべきか

LESS （lesscss.org）やSass （sass-lang.com）あるいはStylus （stylus-lang.com/）などのプリプロセッサについて聞いたことがある読者も多いでしょう。これらは、CSSを記述するための便利な機能を提供しています。例えば変数、ミックスイン、関数、入れ子構造のルール、色の操作などの機能を利用できます。

CSS単体では大規模プロジェクトでコードの柔軟性を保つのは困難ですが、プリプロセッサを適切に利用すればこれが可能になります。頑健で柔軟かつDRYなCSSを記述しようとしても、CSSの仕様自体に努力を妨げられることがあります。ただし、プリプロセッサも以下のような問題を抱えています。

CSSのファイルサイズや複雑さをコントロールできなくなります。簡潔に記述された小さなコードが、巨大なCSSへとコンパイルされてブラウザに送りつけられるようになるかもしれません。
ブラウザ上で解釈されたり開発者ツールに表示されたりするCSSは開発者自身が書いたものではないため、デバッグが難しくなります。ただし、多くのデバッガでSourceMapsがサポートされるようになれば、この問題は解消に向かうでしょう。SourceMapsとは、プリプロセッサによる処理前のCSSと処理後のCSSとの対応関係を行単位で示してくれるテクノロジーです。
開発のプロセスが多少遅延することになります。コードをCSSにコンパイルするのは高速ですが、数秒間は待たなければなりません。

どんな種類の抽象化にも、作業を始めるための苦労が伴います。共同作業が必要になったら、利用しているプリプロセッサに習熟している人を選ぶか、プリプロセッサの使い方を教えてあげなければなりません。共同作業の相手が限られるのも、トレーニングにコストを費やすのも、最適な状態ではありません。

不完全な抽象化の法則（Law of Leaky Abstractions）に注意が必要です。これは、「すべての抽象化には不完全さが伴う」というものです。プリプロセッサも作成したのは人間であり、人間が作成してきたすべてのプログラムと同様にバグはつきものです。CSSに関して問題が発生した場合、プリプロセッサのバグも疑わなければならないのは非常に面倒です。

これらの問題に加えて、開発者が特定のプリプロセッサに依存するようになってしまう問題もあります。たとえ小規模なプロジェクトでも、同じプリプロセッサの利用が恒常化するでしょう。主な機能がネイティブなCSSに取り込まれても、プリプロセッサが使われ続けるかもしれません。実際に、プリプロセッサに影響を受けた機能がCSS本体に多く採用されています。例を紹介します。

実験的なプリプロセッサ「Myth」（myth.io）では、プロプライエタリな構文を使わずにCSSの新しい機能を擬似的に再現できる。実質的にCSSのポリフィルとして機能する

変数と同様の性質を持ったカスタムプロパティが検討されており、仕様の草案がCSS Custom Properties for Cascading Variables （w3.org/TR/css-variables-1）としてすでに公開されています。
CSS Values & Units Level 3 （w3.org/TR/css-values-3）で定義されているcalc()関数は、とても強力な計算の機能を提供します。しかも、幅広いブラウザですでに利用可能です。
CSS Color Level 4 （dev.w3.org/csswg/css-color）では、色の操作のためのcolor()関数が定義されています。
ルールの入れ子に関する真剣な議論がCSS作業グループの中で何度か行われており、Editor’s Draft （ED）が作成されたこともあります。

この種の機能がネイティブに取り入れられた場合、動的であるためにプリプロセッサによって提供される機能よりも大幅に強力なことがよくあります。例えば、プリプロセッサには100% - 50pxの値がいくつになるかわかりません。パーセンテージの値が実際にどの程度になるかは、ページを描画してみないとわからないためです。一方CSSのネイティブなcalc()は、問題なくこのような数式を計算できます。また、下のように変数を利用するのもプリプロセッサには不可能です。

 
ul { --accent-color: purple; }
ol { --accent-color: rebeccapurple; }
li { background: var(--accent-color); }

このコードでは、番号なしの箇条書きの背景色をpurpleにし、番号つきの箇条書きでは背景色をrebeccapurpleにすることを意図しています。プリプロセッサでは、このような動的に値が決まる形式の指定は行えません。もちろん、子孫セレクタを使えば上のような指定は必要ありませんが、ここでは動的な変数の例として紹介しました。

ここまでに述べたCSSのネイティブな機能の中には、まだ十分にサポートされていないものも多くあります。したがって、保守の容易さが求められる場合にはプリプロセッサの利用は避けられず、むしろ積極的に利用するべきです。どんなプロジェクトでもまずは純粋なCSSを使い、DRYな状態を保てなくなってきたらプリプロセッサに切り替えるという方針をおすすめします。過度にプリプロセッサに依存したり、不必要な箇所にもプリプロセッサを利用するのは避けるべきです。プリプロセッサの導入には慎重な検討が必要であり、単に採用すればよいというものではありません。

万が一「メイキング」を読んでいない読者のために繰り返すと、本書でのスタイルはSCSS言語を使って記述されています。しかし、当初はCSSだけを使って記述されており、保守していけないほど複雑になってきた時点でSCSSに移行しました。CSSやプリプロセッサは出版にも活用できるのです。

背景とボーダー

半透明なボーダー

知っておくべきポイント

RGBAとHSLAを使った色指定

課題

rgba()やhsla()を使って、CSSで半透明色を試してみたことがある読者も多いでしょう。これらは2009年に定義され、大きな変革をもたらしました。以前も半透明色は不可能ではありませんでしたが、一時しのぎの代替案やシム（shim）あるいはIEのフィルターを使った格好悪いハックなどが必要でした。なお、半透明色は背景色として指定されることがほとんどでした。これにはいくつか理由があります。

いち早く半透明色を利用した開発者は、その形式が#ff0066やorangeなどの通常の色と同じだことを認識していませんでした。そのため、半透明色を画像と同様に扱い、もっぱら背景に利用していました。
他のプロパティと比べて、背景色は代替案を用意するのがとても簡単でした。例えば、大きさが1pxの半透明の画像を用意すれば、半透明の背景色を代替できます。他のプロパティでは、不透明な色で塗りつぶすくらいしか代替案がありませんでした。
他のプロパティ（ボーダーなど）で半透明色を指定するのが困難な場合がありました。詳しくは後ほど解説します。

24ways.orgは2008年の時点で、いち早くデザインに半透明色を取り入れていた。ただし、半透明色はもっぱら背景で利用された。デザイン: Tim Van Damme

Can I haz semi-transparent borders? Pretty please?

半透明のボーダーを作成する最初の試み

白の背景色が設定されたコンテナ要素に対して、半透明の白のボーダーを指定し、本文の背景が透けて見えるようにしてみましょう。まずは下のようなコードを作成した読者もいるのではないでしょうか。

 
border: 10px solid hsla(0,0%,100%,.5);
background: white;

背景とボーダーについてよく理解していない読者は、このコードの表示結果（図 2.2）に納得がいかないことでしょう。ボーダーに半透明色を指定したら、半透明のボーダーが表示されるべきです。ボーダーはどこに行ってしまったのでしょうか。

解決策

デフォルトでは、背景はボーダーの領域に入り込む

表示されていないようにも見えますが、ボーダーはきちんと存在します。デフォルトでは、背景にはボーダーの領域も含まれます。背景が指定されている要素に対して、昔ながらの破線のボーダーを指定すれば、このことがよくわかります（図 2.3）。不透明な単色のボーダーでは問題にはなりませんが、今回のような例ではデザインが大きく変化してしまいます。本文の素敵な背景を見せるために半透明のボーダーを指定したのですが、実際には白いコンテナの背景に重ねて半透明の白でボーダーが描画されてしまいました。不透明な白でボーダーを表示するのとほとんど変わりありません。

CSS 2.1では、背景の仕組みはまさにこのとおりで、我々は仕様を受け入れ仕様に沿って開発するしかありませんでした。しかしBackgrounds & Borders Level 3 （w3.org/TR/css3-background）では、必要に応じてふるまいを変更できるようになりました。ここではbackground-clipプロパティが使われます。初期値はborder-boxで、要素のボーダーまでが背景になります。背景とボーダーが重ならないようにするには、このプロパティにpadding-boxという値を指定します。例えば下のようにすると、背景はボーダーの内周までになります。

Can I haz semi-transparent borders? Pretty please?

background-clipによる、期待どおりの表示

 
border: 10px solid hsla(0,0%,100%,.5);
background: white;
background-clip: padding-box;

図 2.4のように、意図したとおりの表示が行われます。

複数のボーダー

知っておくべきポイント

基本的なbox-shadowの使い方

課題

Backgrounds & Borders Level 3 （w3.org/TR/css3-background）がまだ草案だった頃に、CSS作業グループでは背景画像と同じように複数のボーダーを認めるかどうかについて議論が続いていました。しかし当時の結論は、十分な数のユースケースがまだないというものでした。そして開発者は、border-imageを使って同じ効果を得るように強いられていました。開発者はCSSのコードの中でボーダーを調整できることを望んでいましたが、CSS作業グループはこの点を軽視していました。その結果、複数の要素を使って複数のボーダーを擬似的に再現するといったみにくいハックが横行しました。ただし、このように無駄な要素に頼ってマークアップを汚さなくても、同等の効果を得る方法があります。

box-shadowを使った解決策

ほとんどの読者は、box-shadowを利用（あるいは多用）して影を表示したことがあるでしょう。しかし、このプロパティに4つ目のパラメーターを記述して「拡散半径」を指定できることはほとんど知られていません。正の値を指定すると影が広がり、負の値では影も狭まります。オフセットとぼかしの半径をゼロにし、拡散半径として正の値を指定すると、影ではあるけれども実線のボーダーのように見える表示を得られます（図 2.5）。

box-shadowを使ってアウトラインを再現する

 
background: yellowgreen;
box-shadow: 0 0 0 10px #655;

borderプロパティを使っても同等のボーダーを表示できるため、上のコード自体にはさほど意味はありません。しかし、box-shadowには値をカンマ区切りで何個でも指定できるというメリットがあります。例えば次のように、2つ目のdeeppinkの「ボーダー」を簡単に追加できます。

box-shadowを使って2つのボーダーを再現する

 
background: yellowgreen;
box-shadow: 0 0 0 10px #655, 0 0 0 15px deeppink;

このように複数の値を指定する場合、それぞれの影は重なって表示され、最初に指定されたものが最も手前に表示されるという点に注意が必要です。つまり、拡散半径の値は重なりを意識して指定しなければなりません。上のコードでは、外側のボーダーの幅を5pxにしたかったので、内側のボーダーの幅つまり10pxに5pxを加えた15pxを拡散半径として指定しました。必要なら、これらのボーダーに続けて通常の影を指定することもできます。例えば次のようにします。

ボーダーに続けて通常の影を追加する

 
background: yellowgreen;
box-shadow: 0 0 0 10px #655,
            0 0 0 15px deeppink,
            0 2px 5px 15px rgba(0,0,0,.6);

このようにbox-shadowを使った解決策はほとんどの場合でうまく機能しますが、いくつか問題点もあります。

影は完全にボーダーと同じというわけではありません。例えば、影はレイアウトに影響を与えず、box-sizingプロパティの設定は無視されます。ただし、パディングやマージン（どちらを使うかは、影が内側と外側のどちらに表示されるかによります）を適切に指定すれば、ほぼボーダーと同様に影を表示できます。
以上のコードでは、要素の外側に擬似的なボーダーを表示しているにすぎません。このボーダーの部分では、ホバーやクリックなどのマウスイベントは発生しません。イベントを発生させたい場合には、insetキーワードを指定して影が要素の内側に描かれるようにします。なお、適切な余白を得るためには追加のパディングが必要です。

アウトラインを使った解決策

outline-offsetに負の値を指定して破線のアウトラインを表示すると、簡単な縫い目のような表示を得られる

ボーダーが2本だけ必要という場合には、通常のボーダーとoutlineプロパティによるアウトライン（こちらが外側に表示されます）を組み合わせるという方法もあります。box-shadowを使う場合は実線のボーダーしか表示できませんでしたが、アウトラインを使えばより柔軟にスタイルを指定でき、破線も表示できます。図 2.6のボーダーは、outlineを使うと次のように記述できます。

 
background: yellowgreen;
border: 10px solid #655;
outline: 15px solid deeppink;

outlineプロパティを使って表示したボーダーでは、角丸が考慮されない。ただし、今後この挙動が変更される可能性もある

アウトラインには、outline-offsetを使って要素からの距離を指定できるというメリットもあります。負の距離も指定できます。これを活用すると、さまざまな表現が可能になります。例えば図 2.8では、縫い目のようなボーダーが表示されています。

ただし、アウトラインにも制約はあります。

先ほどにも述べたように、ボーダーは2つまでしか表示できません。outlineでは複数の値は指定できません。3つ以上のボーダーが必要な場合は、box-shadow以外に方法はありません。

アウトラインでは角丸（border-radius）が考慮されません。図 2.9のように、丸めが指定されていてもアウトラインは直角の四角形として描画されます。ただし、このふるまいはCSS作業グループもバグとして認識しており、将来的には正しくborder-radiusを参照するようになるでしょう。
CSS User Interface Level 3 specification （w3.org/TR/css3-ui）では、アウトラインの表示は四角形とは限らないとされています。ほとんどの場合には四角形が表示されると思われますが、アウトラインを使う場合には各種のブラウザで十分にテストを行うようにしましょう。

柔軟な背景の位置指定

課題

Code Pirate

画像は端から間隔を空けずに配置されるため、background-position: bottom right;による表示は美しくないことがある

背景画像を配置する際に、左上以外の隅（例えば右下など）からのオフセットを指定したいことがよくあります。CSS2.1では、左上からのオフセットか、その他の隅を表すキーワードしか指定できませんでした（図 2.10）。のような表示を避けるために、左上以外の隅についてもパディングのような余白を指定できることが望まれていました。

コンテナ要素の大きさが固定の場合、面倒ですが回避策はあります。望む位置に画像を配置した場合の左上からのオフセットを、自分で計算して指定するという方法があります。ただし、中にコンテンツが含まれるなどの理由で大きさを決定できないコンテナ要素では、この方法は利用できません。そこで、100%よりも少し小さい値（95%など）がbackground-positionとしてしばしば指定されています。近年のCSSには、よりよい方法が用意されています。

background-position拡張を使った解決策

CSS Backgrounds & Borders Level 3 （w3.org/TR/css3-background）ではbackground-positionプロパティが拡張され、すべての隅からのオフセットを指定できるようになりました。ここではキーワードに続けてオフセットを記述します。例えば、右端から20px下端から10pxの位置に背景画像を表示させたい場合には、次のように指定します。

 
background: url(code-pirate.svg) no-repeat #58a;
background-position: right 20px bottom 10px;

Code Pirate

左上以外の隅からのオフセットを指定した表示。オフセットの効果を示すために、背景画像の周囲に破線を表示した

Code Pirate

古いブラウザでこのような表示になってしまうのを避けるために、代替案も合わせて提供する必要がある

表示は図 2.11のようになります。ただし、適切な代替案も用意する必要があります。現状では、この拡張された構文をサポートしていないブラウザを使うと、上のように指定された背景画像は左上隅に表示されます。期待する結果を得られないだけでなく、図 2.12のようにテキストが読めなくなってしまうこともあります。ここでの代替案とは、短縮記法であるbackgroundプロパティの中で従来からのbottom rightを指定するという方法です。具体的には次のように記述します。

 
background: url(code-pirate.svg)
            no-repeat bottom right #58a;
background-position: right 20px bottom 10px;

background-originを使った解決策

Code Pirate

背景画像のオフセットとして、パディングと同じ値を指定する

コンテンツのパディングに合わせて背景画像も表示したいというのが、隅からのオフセットが必要とされる主な理由です。拡張されたbackground-positionの構文を使うと、コードは次のようになります。

 
padding: 10px;
background: url(code-pirate.svg) no-repeat #58a;
background-position: right 10px bottom 10px;

図 2.13がその表示結果です。確かに期待どおりの表示ですが、あまりDRYとは言えません。パディングの値を変更しようと思ったら、3か所も修正して同じ値を指定しなければなりません。しかし、この問題へのシンプルな解決策が用意されています。オフセットの値を繰り返し指定しなくても、パディングの値に追従した表示が自動的に行われるようになります。

Content Box

ボックスモデル

あなたは今までに、background-position: top left;のようなコードを何度も記述してきたことでしょう。その際に、「左上隅とはどこのことか?」と疑問に思ったことはないでしょうか。すでに知っている読者もいると思いますが、すべての要素にはボーダーボックス、パディングボックスそしてコンテンツボックスという3つのボックスがあります（図 2.14）。background-positionの基点は、どのボックスの隅でしょうか。

デフォルトでは、background-positionはパディングボックスの隅を原点として指定されます。そのため、ボーダーが背景画像の上に重なってしまうことはありません。一方、Backgrounds & Borders Level 3 （w3.org/TR/css3-background）ではこのふるまいを変えるためのbackground-originというプロパティが導入されました。もちろん、デフォルト値はpadding-boxです。これを下のようにcontent-boxに変更すると、位置を表すキーワードがコンテンツボックスの各辺を意味するようになります。その結果、背景画像にパディングと同じ幅のオフセットが設定されたような表示になります。

 
padding: 10px;
background: url("code-pirate.svg") no-repeat #58a
            bottom right; /* または100% 100% */
background-origin: content-box;

こうすることによって、図 2.13と同等の表示をDRYなコードで記述できました。background-originとbackground-positionを組み合わせるというのも可能です。つまり、パディングの値を基準としてさらにオフセットを指定できます。

calc()を使った解決策

calc()では、+と-の演算子の前後に必ず空白文字を記述する必要があります。こうしないと、正しい数式として解釈されません。この一見奇妙な約束事は、将来的な互換性のために定められました。今後の仕様では、calc()の中でハイフン（-）を含むキーワードを指定できるようになるかもしれないためです。

当初の課題は、右から20px下から10pxの位置に背景画像を配置することでした。これを左上からのオフセットとして解釈すると、左から100% - 20pxで上からは100% - 10pxと表せます。calc()関数にはこのような数式を指定でき、下のようにbackground-positionとの組み合わせも可能です。

 
background: url("code-pirate.svg") no-repeat;
background-position: calc(100% - 20px) calc(100% - 10px);

角の内側を丸める

知っておくべきポイント

box-shadow, outline, 「複数のボーダー」

課題

I have a nice subtle inner rounding, don’t I look pretty?

角の内側だけが丸められたアウトラインを持つコンテナ要素

図 2.15のように、ボーダーやアウトラインの外側は直角のままで、内側だけを丸めたいというケースが考えられます。これは興味深い表示で、まだあまり使われていません。次のように要素を2つ追加すれば、望む表示を得られます。

 
<div class="something-meaningful"><div>
	I have a nice subtle inner rounding,
	don’t I look pretty?
</div></div>

 
.something-meaningful {
	background: #655;
	padding: .8em;
}

.something-meaningful > div {
	background: tan;
	border-radius: .8em;
	padding: 1em;
}

これでも確かにうまく表示されますが、本質的に要素は1つあれば十分なのに2つ目の要素が必要になってしまいます。1つの要素だけで同じ表示を得られないでしょうか。

もっと読みたい！
本書は『CSSシークレット』のWeb公開版です。詳細をご確認いただくには、オライリー・ジャパンのウェブショップ（oreilly.co.jp/books/9784873117669/）より製品版（書籍もしくはPDF版）をご購入ください。

Lea Verouリアヴェルー著

牧野聡まきのさとし訳

2016年07月発行

ISBN 978-4-87311-766-9

原書：CSS Secrets （shop.oreilly.com/product/0636920031123.do）

ストライプ模様の背景

知っておくべきポイント

線形グラデーション、background-size

課題

Webに限らずどんな視覚的デザインでも、さまざまなサイズや色そして傾きを持ったストライプ模様が見られます。雑誌から壁紙に至るまで、ストライプは幅広く使われています。しかし、Web上でストライプを実現するための方法は理想からは程遠いものです。通常はビットマップ画像が使われ、変更のたびに画像編集ソフトウェアが必要になります。ビットマップの代わりにSVGが使われることもありますが、これも別個のファイルとして記述する必要があり、構文も非常に複雑です。CSSだけを使ってストライプを記述できたら、非常に便利です。このための方法を知った読者はきっと驚くでしょう。

複雑な背景のパターン

知っておくべきポイント

CSSグラデーション、「ストライプ模様の背景」

課題

「ストライプ模様の背景」では、CSSグラデーションを使ってさまざまなストライプを作成しました。しかし、背景のパターンはストライプだけではなく、幾何学的なパターンにもさまざまなものがあります。例えば格子、水玉、市松模様などがよく使われます。

CSSグラデーションを使うと、これらの多くを生成できます。あまり実用的ではないものもありますが、ほとんどの幾何学的なパターンはCSSグラデーションを使って実現できます。ただし、不注意に作成すると、保守の困難なコードが大量に生まれてしまうこともあります。複雑さが増すたびに、コードのDRYさは減少します。CSSを使ってパターンを生成する際には、Sass （sass-lang.com）などのプリプロセッサを使い、繰り返しの回数を減らすのがよいでしょう。

このシークレットでは、比較的作りやすく利用頻度も高いと思われるものをいくつか紹介します。

筆者によるCSS3 Patterns Gallery （lea.verou.me/css3patterns）では、2011年の時点でのCSSグラデーションを使って実現できたデザインを多数紹介している。その後2012年にかけて、CSSグラデーションに関するほぼすべての記事や書籍、講演などでこのサイトが紹介された。一部のブラウザベンダーも、自らのCSSグラデーションの実装を微調整するためにこのサイトでの例を利用した。ただし、ここで紹介されているパターンの中には実運用に適さないものもある。CSSグラデーションを使えば可能であることを示すだけのために、極端に長く繰り返しの多いコードが使われることもある。これらについては、SVGを使って実現することが望ましい。SVGでのパターンについては、いわばCSS Patterns GalleryのSVG版である、SVG Patterns Gallery （philbit.com/svgpatterns）を参照するとよいだろう

（ほぼ）ランダムな背景

知っておくべきポイント

CSSグラデーション、「ストライプ模様の背景」、「複雑な背景のパターン」

課題

幾何学的なパターンの繰り返しは美しいのですが、やや退屈です。自然界では、まったく同じパターンが繰り返されるはほぼありません。繰り返しの中にも、何らかの変化や無作為が見られるものです。例えば花畑では、均一さがもたらす美しさとランダムさによる面白みが共存しています。まったく同じ花は1つもありません。我々にとっての背景のパターンも同様に、自然さを追求し、かつ繰り返されるタイルの継ぎ目に気づかれにくいようにしています。しかしこれらの目標は、ファイルサイズを減らしたいという願望とは相容れません。

固有の特徴（例えば木目の中の節など）が等間隔に何度も現れたとしたら、それは自然界のランダムさに反しており、ユーザーが抱く幻想は崩されてしまいます。

Alex Walker, The Cicada Principle and Why It Matters to Web Designers （sitepoint.com/the-cicada-principle-and-why-it-matters-to-web-designers）

CSSには乱数の機能が用意されていないため、ランダムさを表現するのは簡単ではありません。例えば、色（ここでは4色とします）や幅がさまざまに異なる縦方向のストライプを作成し、タイルの間には目に見えるすき間が生じないようにしてみましょう。まず思いつくのは、以下のように4色からなる1つのグラデーションを作るという方法です。

 
background: linear-gradient(90deg,
              #fb3 15%, #655 0, #655 40%,
              #ab4 0, #ab4 65%, hsl(20, 40%, 90%) 0);
background-size: 80px 100%;

ランダムなストライプを生成しようとする最初の試み。それぞれの色が線形グラデーションを使って繰り返し現れる

しかし、これでは図 2.21のように繰り返されていることが明白です。background-sizeで指定された80pxごとに、同じ色が何度も現れています。よりよい方法はないでしょうか。

1つの画像によるボーダー

知っておくべきポイント

CSSグラデーション、基本的なborder-image、「ストライプ模様の背景」、基本的なCSSアニメーション

課題

パターンや画像を、背景ではなくボーダーとして表示させたいことがあります。例えば図 2.24では、画像を切り抜いた装飾的なボーダーが表示されています。また、対象の要素のサイズに合わせて画像は伸縮することが望まれます。このようなボーダーは、CSSを使って生成できるでしょうか。

「border-imageを使えばいいに決まっているじゃないか。問題なんて起こるはずがない」と思われるかもしれませんが、早まってはいけません。border-imageの仕組みを思い出してみましょう。???のように、border-imageでは画像は9つに分割され、それぞれがボーダーの辺や角に当てはめられます。

画像を分割して、図 2.24のようなボーダーは作れるでしょうか。要素の大きさとボーダーの幅が決まっているなら、それに合わせて注意深く分割することも可能です。しかし、その分割位置の設定は別の要素ではうまく適用できません。ここで問題になっているのは、画像の中でどの部分がボーダーの角に位置するのか決まっていないという点です。要素の大きさやボーダーの幅に応じて、角の位置に表示される画像は異なります。自分で試してみれば、border-imageでは可変サイズの要素に対応できないことがわかるでしょう。そうだとしたら、我々はどうするべきでしょうか。

I have a nice stone art border, don’t I look pretty?

I have a nice stone art border, don’t I look pretty? Bacon ipsum dolor amet fatback alcatra tenderloin chicken shank, sausage pork meatball leberkas tri-tip spare ribs salami filet mignon ball tip cow.

高さの異なる要素に対して、画像をボーダーとして適用した結果

最も簡単な方法は、HTMLの要素を2つ用意するという方法です。以下のコードのように、1つでは背景画像を表示し、もう1つではコンテンツのために白い背景を指定して背景画像を覆い隠します。

 
<div class="something-meaningful"><div>
	I have a nice stone art border,
	don’t I look pretty?
</div></div>

 
.something-meaningful {
	background: url(stone-art.jpg);
	background-size: cover;
	padding: 1em;
}

.something-meaningful > div {
	background: white;
	padding: 1em;
}

こうすれば図 2.24のような「ボーダー」を正しく表示できますが、余分な要素が必要になるという問題があります。これは望ましい状態ではありません。マークアップとスタイル設定が混在してしまっています。また、何らかの事情でHTMLは変更できないという場合も考えられます。要素を追加せずに、同じ効果を実現しましょう。

形状

さまざまな楕円形

知っておくべきポイント

基本的なborder-radiusプロパティ

課題

サイズが固定の要素から生成された円。サイズの半分の値がborder-radiusに指定されている

どんな四角形の要素も、十分に大きな値をborder-radiusに指定すれば円形になることに気づいた読者も多いでしょう。例えば次のようなCSSを使って表現されます。

 
background: #fb3;
width: 200px;
height: 200px;
border-radius: 100px; /* >= 辺の長さの半分 */

ここで100px以上の値をborder-radiusに指定しても、表示は変わらず円形のままです。その理由は、仕様の中で説明されています。

隣接するボーダーの半径の和がボーダーボックスのサイズを上回る場合、ユーザーエージェントはボーダーの重なりがなくなるまですべてのボーダーの半径を縮小します。

CSS Backgrounds & Borders Level 3 （w3.org/TR/css3-background/#corner-overlap）

横長の要素に先ほどのコードを適用した結果。破線はborder-radiusによる円を表す

しかし、コンテンツの大きさが事前にわからないことも多く、ここで具体的な値を指定できないことがよくあります。すべてのコンテンツがあらかじめ用意されている静的なWebサイトでも、後で変更が生じたり、形状の異なる代替のフォントで表示されたりする可能性もあります。また、縦横の長さが等しい場合には円を表示し、異なる場合には楕円を表示することが望まれます。しかし、上のコードではこうはなりません。例えば幅が高さより大きい場合、表示は図 3.2のようになります。柔軟なサイズ指定も、楕円の表示もborder-widthでは無理なのでしょうか。

平行四辺形

知っておくべきポイント

基本的なCSSの変形処理

課題

平行四辺形

平行四辺形とは、向かい合う2組の辺がともに平行な四角形のことです（図 3.4）。長方形も平行四辺形の一種です。デザインをダイナミックにし、動きの感覚を与えるために平行四辺形はよく使われます（図 3.5）。

CSSを使って、平行四辺形のボタンを作ってみましょう。まずは、図 3.6のように通常の長方形のボタンとシンプルなスタイル設定を組み合わせたものを作ります。そして、下のようにskew()トランスフォームを適用して平行四辺形へと変形させます。

 
transform: skewX(-45deg);

しかし、こうするとコンテンツにもトランスフォームが適用され、読みにくいテキストになってしまいます（図 3.7）。コンテナだけをトランスフォームし、コンテンツはそのままにすることは可能でしょうか。

Click me

トランスフォームを適用する前のボタン

Click me

単純なトランスフォームを適用したボタン。テキストが読みにくい

ひし形の画像

知っておくべきポイント

CSS transformプロパティ、「平行四辺形」

課題

視覚的デザインの世界ではひし形に切り抜かれた画像をよく目にしますが、CSSだけを使ってこれを実現するのは容易ではありません。最近までは、これは基本的に不可能でした。Webデザイナーがひし形の画像を表示させようとしたら、画像編集ソフトウェアを使ってあらかじめ切り抜かれた画像を用意しなければなりませんでした。言うまでもなく、このようなやり方は保守に適していません。画像のスタイルを変更するたびに新しい画像が必要になり、大量の画像が残されます。

しかし今日では、よりよい方法がなんと2つも考えられています。

2013年に新しいデザインが採用された24ways.orgでは、本書で紹介するテクニックを使って執筆者のプロフィール画像をひし形に切り抜いている

角の切り落とし

知っておくべきポイント

CSSグラデーション、background-size、「ストライプ模様の背景」

課題

角を切り落とされたボタン。矢印の形状を通じて、ボタンの意味をアピールできる

角を切り落とされた四角形は、印刷物でもWebでもよく見られます。ここでは、要素が持つ角のうちの1つまたは複数が45度に切り落とされます。近年ではフラットデザインがスキューモーフィズム（実物に似せたデザイン）に取って代わりつつあり、このような角の切り落としの使われる機会が増えてきました。右上と右下の角で、それぞれ要素の高さの半分になるように切り落としを行うと、ボタンやパンくずリスト（breadcrumb）などでよく使われる矢印の形状になります（図 3.11）。

しかし、これを簡単な理解しやすいコードだけで実現できるような方法は現状のCSSには用意されていません。ほとんどの開発者は、背景画像を使って角の切り落としを表現しています。例えば三角形を使って角を隠したり（背景が単色の場合のみ適用できます）、すでに角が切り落とされた画像を背景に指定したりしています。

これらの代替案は明らかに柔軟性を欠いており、保守が困難です。HTTPリクエストの回数やデータ量が増える問題もあります。他によい方法はないでしょうか。

角の切り落としが使われているWebサイトの例。半透明の「Find & Book」ボックスの左下の角が切り落とされ、デザインの効果を高めている

台形のタブ

知っておくべきポイント

基本的な3次元トランスフォームプロパティ、「平行四辺形」

課題

Trapezoid

擬似要素のボーダーを使って表現された台形。濃い色の部分が擬似要素を表す

平行四辺形をさらに一般化したのが台形で、向かい合う辺のうち1組だけが平行です。もう1組の辺については、平行でなくてもかまいません。台形はしばしばタブなどに利用されていますが、CSSを使って生成するのがとても難しい図形として知られていました。手間をかけて背景画像を用意するか、長方形の左右に擬似要素を使ったボーダーとして三角形を加える（図 3.14）といった方法がとられていました。

このボーダーによるアプローチでは画像が必要ありません。そのためHTTPリクエストの回数を節約でき、異なるサイズの台形にも対応できます。しかし、理想的なアプローチとは言えません。擬似要素を2つ消費してしまうほか、スタイルの柔軟性が損なわれます。例えば、この台形にボーダーや背景のテクスチャーあるいは角の丸めを追加するといったことはおそらく不可能です。

台形を生成するための既存のテクニックはいずれも、かなり煩雑で保守が困難です。そのため、実世界でのタブの多くは両側の辺が斜めになっているにもかかわらず、Webでのタブはほとんどが長方形です。台形のタブを作るための、クリーンで柔軟な方法はないでしょうか。

Cloud9 IDE （c9.io）では、開かれたドキュメントに台形のタブが割り当てられる

かつてのcss-tricks.comのデザイン。辺が斜めになっているのは片側だけだが、台形のタブが使われていた

シンプルな円グラフ

知っておくべきポイント

CSSグラデーション、基本的なSVG、CSSアニメーション、「ストライプ模様の背景」、「さまざまな楕円形」

課題

集計結果の表示からプログレスインジケーターやタイマーに至るまで、円グラフはとても多くの用途に使われています。しかし、従来のWebテクノロジーでは最もシンプルな2色の円グラフでさえ作成は面倒でした。

円グラフを表示するには、値を表す扇形を1つずつあらかじめ用意するか、はるかに複雑なグラフにも対応したJavaScriptライブラリに頼るのが一般的です。

グラフの作成は以前ほど困難ではなくなりましたが、1行ですべてをシンプルに記述できるようなライブラリはまだありません。一方、今日では保守も容易なよりよい方法が複数考えられています。

視覚効果

単方向の影

課題

Q&Aサイトでbox-shadowについて見かける質問の多くは、1つ（あるいは、まれに2つ）の辺だけに影を表示するにはどうすればよいかという質問です。stackoverflow.comでざっと検索してみたところ、1,000件近くもの質問がヒットしました。1方向に伸びる影のような表示効果はあまり目立ちませんが、実世界での現象に即しています。不満を持った開発者はしばしば、CSS作業グループのメーリングリストでbox-shadow-bottomのようなプロパティの追加を求めています。しかし、慣れ親しんだbox-shadowプロパティだけでもうまく使えば単方向の影を表現できます。

不規則な形状のドロップシャドウ

知っておくべきポイント

box-shadow

課題

長方形やborder-radiusを使って作成された形状については、box-shadowを指定すると正しくドロップシャドウが表示されます（「さまざまな楕円形」でいくつか例を紹介しています）。一方、擬似要素などを使った半透明の装飾が加えられているとbox-shadowは期待どおりには機能しません。透明度が考慮されないためです。例えば次のようなケースが該当します。

半透明の画像や背景画像あるいはborder-image （写真を飾る額のような画像など）
背景がない（またはbackground-clipがborder-boxではない）場合の、点線や破線または半透明のボーダー
吹き出し状の表示で、突き出た部分に擬似要素が使われているもの
切り落とされた角「「角の切り落とし」参照）
折り返された角「「ひし形の画像」参照）の大部分
clip-pathを使って定義された形状「「ひし形の画像」など）

スタイルの指定された要素に`box-shadow`を適用し、失敗した例。左から吹き出し、点線のボーダー、角の切り落とし。`box-shadow`の値は`2px 2px 10px rgba(0,0,0,.5)`

これらに対してbox-shadowを適用すると、図 4.2のように失敗します。解決策はあるのでしょうか、それともあきらめるべきでしょうか。

色調の調整

知っておくべきポイント

HSLカラーモデル、background-size

課題

グレースケールの画像に対して特定の色のティント（濃淡）を加えるテクニックは、それぞれ大きく異なる写真に視覚的な統一感を与えるためによく使われています。グレースケールの効果が静的に適用され、ホバーやその他のインタラクションの発生時にのみ効果が解除されるのも一般的です。

従来は、画像編集アプリケーションを使って2つのバージョンの画像を用意し、簡単なCSSを使って両者を切り替えながら表示していました。正しく動作はしますが、データ量やHTTPリクエストの回数が増加し、保守も困難になります。例えばグレースケールの画像の色を変えようと思ったら、既存のすべての画像について新しいバージョンを作りなおさなければなりません。

別のアプローチとしては、画像の手前に半透明の色を重ねたり、不透明度が指定された画像を単色の塗りつぶしの手前に配置するといったものがあります。しかし、これらはティントの定義に反します。画像中のすべての色がターゲットの色のティントへと変換されるわけではなく、コントラストが大幅に低下する問題もあります。

画像をcanvas要素に変換した上で、この画像にティントを適用するようなスクリプトもあります。正しいティントの表示を得られますが、制限が多く動作は低速です。

CSSConf 2014のWebサイトでも、同様の表示効果が使われている。ホバーされたりフォーカスを得たりしている状況では、フルカラーの画像が表示される

より簡単に、CSSの中から直接ティントを適用できることが望まれます。

曇りガラスの効果

知っておくべきポイント

RGBAとHSLAを使った色指定

課題

半透明色の最初の利用例の1つに、写真や込み入った柄の背景画像に重ねて半透明の背景色を表示する例がありました。ここでは、テキストを読みやすくすることが意図されています。とても印象的な効果を得られますが、背景色の透明度が高い場合や背景画像が派手な場合などには依然としてテキストは読みにくいままです。例えば図 4.6では、main要素に対して半透明の白色の背景が指定されています。マークアップは以下のとおりです。

 
<main>
	<blockquote>
		“The only way to get rid of a temptation[…]”
		<footer>—
			<cite>
				Oscar Wilde,
				The Picture of Dorian Gray
			</cite>
		</footer>
	</blockquote>
</main>

そしてCSSは以下のようになります（抜粋）。

 
body {
	background: url("tiger.jpg") 0 / cover fixed;
}

main {
	background: hsla(0,0%,100%,.3);
}

見てのとおり、テキストがとても読みにくくなってしまっています。背後の画像が込み入っているのと、背景色の不透明度が30％しかないのが原因です。背景色のアルファ値を増やせばもちろん読みやすくなりますが、図 4.7のようにつまらない表示になります。

印刷物向けの伝統的なデザインでは、テキストの背後にある画像の一部をぼかす手法がしばしばとられます。ぼかされた画像はより落ち着いた表示になるため、テキストは読みやすくなります。ぼかしの処理には大量の計算が必要になるため、かつてはWebサイトやUIのデザインでこのテクニックを使うのは非現実的でした。しかし今日ではGPUの処理能力は向上し、ハードウェアアクセラレーションがさまざまなデバイスで利用されるようになってきています。その結果、ぼかしの効果が使われることもかなり増えてきました。AppleのiOSやOS X （図 4.8）だけでなく、近年のバージョンのMicrosoft Windowsでもぼかしが取り入れられています。

ここ数年の間に、背景をぼかした半透明のUIが広く使われるようになった。かつては負荷が高すぎる処理だったが、処理能力の向上に伴って実現可能になった
左：iOS 8.1
右：OS X Yosemite

CSSには、ぼかしを行うためのblur()フィルターが用意されています。SVGで定義されているぼかしのフィルターを移植し、ハードウェアアクセラレーションに対応させたものです。ただし、上の例でblur()フィルターを適用すると、図 4.9のように要素全体がぼかされてテキストがまったく読めなくなってしまいます。要素に重なっている部分の背景だけを対象にして、ぼかしを行えないでしょうか。

角の折り返し

知っておくべきポイント

CSSトランスフォーム、CSSグラデーション、「角の切り落とし」

課題

1つの角（一般的には右上または右下）が折り返されたような表示のスタイルは、装飾としてとても広く使われています。折り返しの角度はさまざまです。

CSSだけを使ってこのような表示を行う方法がいくつか考案されています。初めて発表されたのは2010年のことで、擬似要素を極めた Nicolas Gallagher （nicolasgallagher.com/pure-css-folded-corner-effect）によるものでした。多くの方法では、2つの三角形が使われます。1つは折り返された形状のために、もう1つはメインの要素の角を隠すためにそれぞれ使われます。そして、これらの三角形は古くからあるボーダー関連のテクニックを使って生成されるのが一般的です。

かつてのcss-tricks.comでのデザイン。記事を表すボックスの角が折り返されている

当時はとても印象的に思えましたが、制約も多く、以下のような場合には対応できません。

対象の要素の背景が単色でなく、パターンやテクスチャーや写真あるいはグラデーションなどの場合。
45度以外の角度で折り返す場合や、完全には折り返さない場合。

これらの場合にも対応した、柔軟な表示効果を実現できないかどうか考えてみましょう。

タイポグラフィー

ハイフンの追加

課題

デザイナーは行末を揃えるのが大好きです。きれいにデザインされた雑誌や本を見れば、行末揃えは至る所で行われているのがわかります。しかしWeb上では、経験を積んだデザイナーも行末揃えはほとんど使っていません。CSS1の時代からtext-align: justify;を指定すること可能だったのに、利用されていないのはなぜでしょうか。

その答えは図 5.1に隠されています。行末を揃えた結果、表示がスペースだらけになってしまいました。見た目が悪く、読みやすくもありません。印刷物では、行末揃えは常にハイフネーション（ハイフンの追加）と組み合わせて適用されます。ハイフネーションを行えば単語を音節単位に分割できるため、挿入されるスペースを大幅に少なくできます。そして、テキストをより自然に表示できます。

近年までは、Web上のテキストにハイフンを追加するための別の方法があるにはあったのですが、それは解決策とはとても呼べないようなひどい代物でした。サーバーサイドのプログラムやJavaScriptやWebサービス、あるいは手作業でソフトハイフンの文字（。ハイフネーションが可能な位置を表します）をすべての音節の間に挿入する、とても面倒な処理が必要でした。このような手前は割に合わず、デザイナーたちは他の方法のレイアウトを利用していました。

改行の挿入

課題

Name:: Lea Verou
Email:: lea@verou.me
Location:: Earth

名前と値の組が1行にまとめられた定義リスト

CSSを通じて改行が挿入されるケースはいくつかあります。定義リスト（dlタグ）を使っていると特に、改行を意識せずにはいられません。単に名前と値の組をいくつか表示したいだけの場合でも定義リストを使い、タグの意味に即してマークアップを記述するよいインターネット市民をめざすことも多いでしょう。例えば次のようなマークアップについて考えてみましょう。

Name:: Lea Verou
Email:: lea@verou.me
Location:: Earth

名前と値が別の行に表示された定義リスト

 
<dl>
	<dt>Name:</dt>
	<dd>Lea Verou</dd>

	<dt>Email:</dt>
	<dd>lea@verou.me</dd>

	<dt>Location:</dt>
	<dd>Earth</dd>
</dl>

このマークアップを使い、図 5.3のような表示を得るのがここでの目標です。まずは、以下の基本的なCSSを適用してみましょう。

 
dd {
	margin: 0;
	font-weight: bold;
}

Name:: Lea Verou
Email:: lea@verou.me
Location:: Earth

display: inlineを指定した場合。表示は悪化した

残念ながら<dt>と<dd>はブロック要素なので、図 5.4のように名前と値が別の行に表示されてしまいます。次の試みとしては、<dt>か<dd> （あるいは両方）のdisplayプロパティの値を変えてみることも考えられます。少しやけになって、適当な値を指定してしまうかもしれません。いずれにせよ、結果は図 5.5のようになるでしょう。

頭をかきむしってCSSを呪ったり、関心の分離をあきらめてマークアップに手を入れたりする前に、正気とコードのモラルをともに保つ方法はないか探ってみましょう。

ゼブラストライプ

知っておくべきポイント

CSSグラデーション、background-size、「ストライプ模様の背景」、「柔軟な背景の位置指定」

課題

数年前に擬似クラスの:nth-child()や:nth-of-type()が導入された時、これらは主にゼブラストライプ（図 5.7のように、2つの色が行ごとに交互に現れる模様）の表を作るのに使われていました。かつては、このような模様の生成にはサーバーサイドのコードやクライアントサイドのスクリプトあるいは手作業でのハードコードが必要でした。しかし現在は下のように、わずかなコードだけでゼブラストライプを作れるようになりました。

 
tr:nth-child(even) {
	background: rgba(0,0,0,.2);
}

各行がゼブラストライプになっている表は、行が長くなっても見やすい。そのため、印刷物だけでなくUIデザイン（画面はOS X Yosemiteでの例）でもよく使われている

:nth-line()という擬似要素の追加リクエストがCSS作業グループに届くこともよくあるのですが、パフォーマンス上の理由から却下されています。

しかし、表ではなく通常のテキストに対してはこのような効果は適用できません。例えばプログラムのコードを1行おきに違う背景色で表示できたら、とても読みやすくなるでしょう。ここで多くの開発者は、それぞれの行を<div>要素で囲んで:nth-child()のテクニックを適用しようとしがちです。構文のハイライト表示と組み合わせると、マークアップはさらにみにくいものになります。JavaScriptはスタイル設定に関与するべきではないという理論上の問題も、あまりに多くの要素が含まれるDOMは動作が遅いという実際的な問題もここにはあります。しかも、この方法は柔軟ではありません。例えば、文字を大きくして行からはみ出たといった場合への対処が面倒になります。もっとよい方法はないでしょうか。

タブのインデント幅の調整

課題

while (true) {
	var d = new Date();
	if (d.getDate()==1 &&
	    d.getMonth()==3) {
		alert("TROLOLOL");
	}
}

デフォルトの8文字分の幅で表示されたタブ

ドキュメントやチュートリアルなどのようにソースコードが多く表示されるWebページには、スタイル設定に関する固有の問題があります。コードを表示させるための<pre>要素や<code>要素には、下のようなデフォルトのスタイルが適用されます。

 
pre, code {
	font-family: monospace;
}

pre {
	display: block;
	margin: 1em 0;
	white-space: pre;
}

しかし、このようなスタイルがすべてのコードに適しているわけではありません。例えば、タブはコードのインデントには適していますが、Webではあまり使われません。ブラウザ上では、タブは空白8文字分として表示されるためです。このような広すぎるインデントは、図 5.9のようにひどい表示をもたらします。ボックスに収まらなくなってしまうことも多いでしょう。

リガチャー

課題

fi fi

fl fl

ffi ffi

ほとんどのセリフつきフォントで見られる常用リガチャー

人間関係と同じように、グリフ（フォントを構成する文字）にもうまくいかない組み合わせがあります。例えばセリフ（いわゆる「ひげ」）つきのフォントで、「f」と「i」が続く場合について考えてみましょう。図 5.11の左上の例のように、fの上部とiの点が重なるため美しくない表示になってしまいます。

そこで、フォントのデザイナーはリガチャー（合字）と呼ばれるグリフをフォントに追加しています。リガチャーとは2つまたは3つの文字を組み合わせてデザインしたもので、組版ソフトウェアは該当する一連の文字をリガチャーに置き換えます。図 5.11は一般的に使われる常用リガチャー（common ligature）の例です。右側がリガチャーです。

また、任意リガチャー（discretionary ligature）と呼ばれる種類のリガチャーもあります。これはデザイン上の代替として用意されたものです。任意リガチャーが使われなくても、特に問題はありません。図 5.12に例を示します。

ただし、デフォルトではブラウザ上で任意リガチャーが使われることはありません（これは正しいふるまいです）。常用リガチャーが使われることもあまりありません（これはバグです）。つい最近まで、種類を問わずリガチャーを明示的に利用するにはUnicode文字を指定する必要がありました。例えば、「fi」をリガチャーとして表現するには「ﬁ」と記述しなければなりませんでした。以下のように、このやり方は問題だらけです。

明らかにこのマークアップは読みにくく、記述するのはさらに大変です。例えば、「deﬁne」が何を指しているかすぐに把握できるでしょうか。

st st

ct ct

任意リガチャーの例。巧みにデザインされたセリフつきのフォントで見られる

現在使われているフォントに該当のリガチャーが含まれていなかった場合、脅迫状のような奇妙な表示になってしまいます（図 5.13）。
すべてのリガチャーに対応してUnicode文字が定義されているとは限りません。例えば「ct」のリガチャーはUnicodeで定義されていません。このリガチャーをフォントに含めるには、Unicodeの「PUA」に配置する必要があります。
テキストのアクセシビリティに悪影響が及びます。コピー＆ペーストや検索、読み上げなどが正しく機能しなくなります。多くのアプリケーションはリガチャーを考慮した処理を行えますが、そうではないアプリケーションもあります。

piﬄe

リガチャーのグリフが含まれないフォントでの表示例。リガチャーをUnicode文字としてハードコードすると、ひどい表示になることが多い

近代的なよりよい解決策が、きっとあるはずです。

しゃれた「&」

知っておくべきポイント

基本的な@font-faceルールを使ったフォントの埋め込み

課題

ほとんどのコンピューターで、きれいな「&」をデフォルトで利用できる。左からBaskerville、Goudy Old Style、Garamond、Palatinoの各フォント。すべてイタリック

タイポグラフィーの中で控えめに使われる「& （アンパサンド）」は、しばしば賞賛の対象になります。エレガントさを即座に与えてくれる文字として、「＆」に勝るものはありません。最も素敵な「&」を含んだフォントを探すためだけのWebサイトがあるほどです。しかし、最も優れた「&」を含むフォントが他の文字にも適しているとは限りません。見出しに美しさと洗練をもたらしてくれるのは、きれいなサンセリフ（セリフなし）フォントと複雑なセリフつきフォントでの「&」とのコントラストです。

Webデザイナーもこのことに気づいてはいるのですが、実現のためのテクニックは粗野で煩雑です。下のように、スクリプトあるいは手作業ですべての「&」を<span>要素で囲むといった作業が行われています。

 
HTML <span class="amp">&amp;</span> CSS

そして.ampの要素に対して、次のようなフォントのスタイルが指定されます。

 
.amp {
	font-family: Baskerville, "Goudy Old Style",
	             Garamond, Palatino, serif;
	font-style: italic;
}

HTML & CSS

「&」のフォントを変える前後のテキスト

図 5.16に示すように、この方法は確かに正しく機能します。しかし、コードが汚くなってしまうだけでなく、CMS （コンテンツ管理システム）が使われておりHTMLのマークアップの変更が難しい場合にはそもそも適用できません。

下線のカスタマイズ

知っておくべきポイント

CSSグラデーション、background-size、 text-shadow、「ストライプ模様の背景」

課題

デザイナーというのは面倒な職業です。思い描いたものにできるだけ近づけるために、いろいろなものをカスタマイズして注意深く作り上げます。そして、より直感的で使いやすいデザインを目指して常に苦心しています。デフォルトのままでも十分によいということは、ほとんどありません。

テキストへの下線は、我々デザイナーがカスタマイズしたがる対象の1つです。デフォルトの下線も便利ですが、目立ちすぎであり、しかも描画方法はブラウザごとに異なります。下線はWebの黎明期からありましたが、カスタマイズする方法はまったく用意されてきませんでした。CSSが現れた後も、下のようにオンとオフを切り替えるしかできませんでした。

 
text-decoration: underline;

必要なツールがなければ、我々はハックしてツールを作り出します。下線をカスタマイズする方法がなかったので、下のようにボーダーを使って下線を模造しました。CSSへのハックの中でも、最も初期に考えられたものの1つです。

 
a[href] {
	border-bottom: 1px solid gray;
	text-decoration: none;
}

“The only way to get rid of a temptation is to yield to it.”

border-bottom を使って擬似的に表現された下線

border-bottomを使って下線を擬似的に表現すれば、色や太さなどのスタイルをコントロールできます。しかし、この方法も完全ではありません。図 5.18のように、「下線」はテキストから離れすぎています。「y」や「p」の下にはみ出た部分よりも、さらに下に描画されてしまっています。そこで、次のようにdisplayにinline-blockを指定し、line-heightの値をより小さくしてみます。

“The only way to get rid of a temptation is to yield to it.”

ボーダーを使った下線での問題を解決しようとしたが、行の折り返しの表示が台無しになった

 
display: inline-block;
border-bottom: 1px solid gray;
line-height: .9;

こうすると、下線はテキストに近づきます。しかし図 5.19のように、テキストの折り返しが正しく機能しなくなってしまいます。

最近では、内向きのbox-shadowを使って下線を再現する試みも見られます。

 
box-shadow: 0 -1px gray inset;

こうするとわずかにテキストに近づいて描画されますが、その他の問題点は解決されないままです。下線をカスタマイズするための、適切で柔軟な方法はないでしょうか。

リアルなテキストの表示効果

知っておくべきポイント

基本的なtext-shadow

課題

テキストへの効果の中には、Web上で広く使われるようになったものもあります。例えば凹凸状の表示、マウスオーバー時のぼかしの追加、飛び出したように見える表示（錯視）などです。これらは影を使って表現されるのが一般的です。また、錯覚を利用しているものも多く、我々の目のはたらきに対するある程度の理解も必要です。仕組みを知ってしまえば簡単に作れるのですが、ブラウザの開発者向けツールを使ったリバースエンジニアリングは容易ではないこともあります。

このような表示効果について、いくつか紹介することにします。「これは一体どういう仕組みなのだろう」と途方に暮れなくても済むようになるでしょう。

このような表示効果を適用しようとする際には、アクセシビリティを軽視しがちである。十分なコントラストが得られるかのチェックを忘れてはならない。leaverou.github.io/contrast-ratioで公開されているツールは、CSSで利用できる任意の色の形式に対応している

円に沿ったテキスト

知っておくべきポイント

基本的なSVG

課題

特によく使われるわけではありませんが、円に沿って短いテキストを配置したいことがあります。このような場合、CSSは無力です。これを可能にしてくれるようなCSSのプロパティはありません。無理に実現しようとすると、考えるだけで気分が悪くなるようなハックだらけのコードになってしまいます。画像にも頼らず、我々の正気と自尊心を保ってくれるような解決策はあるのでしょうか。

juliancheal.co.ukの左側（カーソル位置付近）にあるボタンで、円に沿ったテキストが使われている。実世界でのボタンのメタファーとして表示されており、中央部分には穴と糸があるためテキストを表示できない

ページの構造とレイアウト

内在的なサイズ設定

課題

ご存知のとおり、高さが指定されていない要素はコンテンツに合わせて上下方向に伸縮します。widthについてもこのようなふるまいをさせることは可能かどうか、考えてみましょう。例として、下のようなマークアップを持つHTML5の<figure>要素を取り上げます。

 
<p>Some text […]</p>
<figure>
	<img src="adamcatlace.jpg" />
	<figcaption>
		The great Sir Adam Catlace was named after
		Countess Ada Lovelace, the first programmer.
	</figcaption>
</figure>
<p>More text […].</p>

我々のマークアップでのデフォルトの描画（説明のためにボーダーやパディングを追加）

これに対して、画像周囲のボーダーなどの基本的なスタイルを設定することにします。デフォルトでは、図 7.1のように表示されます。</figure>要素の幅を画像（サイズはさまざまです）と揃え、横方向の中央に配置しようとしています。しかし、</figcaption>要素のテキストの幅が画像よりも大きく、現状の表示は期待からかけ離れています。親要素ではなく画像の幅にもとづいて、</figure>要素の幅が決まるようにしたいと思います*CSSの仕様での用語を使うと、我々は幅を内在的（intrinsically）に決定しようとしています。対義語は外的（extrinsically）です。。このような目的のために、読者は今までに以下のようなスタイルを指定してきたのではないでしょうか。しかし、これらにはいずれも副作用が伴います。

`display: inline-block`を指定しても、期待どおりの表示を得られない

<figure>をフロート指定すれば、幅を指定できます。しかしこうすると、図 7.2のようにレイアウトが大幅に変わってしまいます。
<figure>にdisplay: inline-blockを指定すれば、コンテンツにもとづいてサイズが設定されます。しかし、これも我々の期待とは異なります（図 7.3）。また、たとえ幅がたまたま期待どおりになったとしても、この要素を中央に配置するのは大変です。親要素にtext-align: center;を指定し、この親要素の子になるすべて要素（p、ul、ol、dlなど）にtext-align: centerを指定しなければなりません。
最終手段として、<figure>に固定値の幅やmax-widthを指定し、figure > imgにmax-width: 100%を指定しようとするかもしれません。しかしこうしても、空いているスペースは十分に使われず、とても小さい画像ではうまく表示されず、レスポンシブでもありません。

<figure>の幅を動的に指定するようなスクリプトを書かなければならないのでしょうか。それとも、CSSだけでよい解決策を作れるのでしょうか。

テーブルの列幅を自在に指定する

課題

我々は遠い昔にテーブルを使ったレイアウトを放棄しましたが、テーブル自体は近年のWebサイトでも引き続き使われています。例えば統計データや電子メール、メタデータの一覧などでテーブルがしばしば見られます。table以外の要素も、display要素にテーブル関連のキーワードを指定するとテーブルのようにふるまうようになります。このやり方は便利なようにも思えますが、動的なコンテンツを含む場合に予期できないレイアウトが行われることがあります。ここでは、列の幅はコンテンツに応じて調整されます。幅を明示的に指定しても、単なるヒントとしてしか機能しません。表示の例を図 7.5に示します。

その結果、たとえ表形式のデータであっても別の要素を使うか、レイアウトの不安定さを受け入れるかという選択を我々は迫られています。テーブルを行儀よくふるまわせる方法はあるのでしょうか。

さまざまなコンテンツを含む、2列のテーブル。デフォルトのアルゴリズムを使ってレイアウトした結果。破線はこれらのテーブルのコンテナ要素を表す。

兄弟要素の個数にもとづくスタイル指定

課題

兄弟要素の個数に応じて、異なるスタイルを指定したいケースは多数あります。主な利用例としては、長さが可変のリストが考えられます。リストが長くなった場合に、ウィジェットを非表示にしたりそれぞれの項目を小さくしたりして、表示領域を節約するとともにユーザーエクスペリエンスを向上できます。具体的をいくつか紹介します。

電子メールなどのテキストベースの項目からなるリスト。項目が少ない場合、各項目は大きなプレビュー領域とともに表示されます。項目が増えたら、プレビュー領域の行数を減らします。そしてリスト全体の高さがビューポートの高さを超えたら、プレビュー領域を非表示にし、ボタンを小さくします。こうすることによって、ユーザーがスクロールしなければならない量を削減します。

To Doリストアプリケーション。項目が少ない間は大きなフォントで表示し、増えてきたら徐々にすべての項目を小さなフォントで表示するようにします。

カラーパレットアプリケーション。それぞれの色はウィジェットとして表示されます。色数が増えるのに合わせてウィジェットを小さくし、占有するスペースを減らします（図 7.7）。
複数の<textarea>を持つアプリケーション。新しく追加されるたびに、すべての<textarea>の列数を少しずつ小さくします。bytesizematters.comなどでこの手法が使われています。

色数の増加に合わせて利用可能なスペースが減少するので、ウィジェットを徐々に小さく表示する。1色だけの場合には、削除ボタンを非表示にする追加の処理も行われている。
Adobe Color （color.adobe.com）で定義されている、以下の2種類のパレットを利用して配色した

Agave （color.adobe.com/agave-color-theme-387108）

Sushi Maki （color.adobe.com/Sushi-Maki-color-theme-350205）

li:nth-child(4),
 li:nth-child(4) ~ li

を指定した場合に選択される要素

しかしCSSのセレクタでは、兄弟要素の数にもとづいて要素を選択するのは容易ではありません。例えば、自身も含めた兄弟要素の総数が4個の要素に対してスタイルを設定したいとします。li:nth-child(4)を使えばリストの中で4番目の要素を選択できますが、我々が望む結果はこれではありません。総数が4個のリストについて、すべての項目を選択する必要があります。

一般兄弟セレクタ（generalized sibling combinator）の~と:nth-child()を組み合わせるアイデアも考えられます。例えば、li:nth-child(4), li:nth-child(4) ~ liのように指定できます。しかしこうすると図 7.8のように、項目の総数にかかわらず4つ目以降の項目が選択されてしまいます。後方参照を行って、以前の兄弟要素を選択できるようなセレクタはありません。CSSを使った解決をあきらめたくなりますが、もう少し頑張ってみましょう。

流動的な幅の背景と固定幅のコンテンツ

課題

ここ数年の間に、Webデザインの世界で人気を得るようになってきたトレンドが1つあります。それは、筆者が「流動的（fluid）な幅の背景と、固定幅のコンテンツの組み合わせ」と呼んでいるものです。このパターンには、次のような特徴があります。

ページには複数のセクションがあります。それぞれはビューポートの幅全体を占め、異なる背景が適用されます。
コンテンツの幅は固定されています。メディアクエリによって、解像度ごとに異なる幅が適用されることもあります。セクションごとに幅が異なってもかまいません。

???や（若干わかりにくいですが）図 7.11のように、ページ全体でこのパターンが適用されることもあります。しかし図 7.10のように、一部のセクション（特に、フッター領域）だけにこのパターンを適用するのがより一般的です。

このような表示を得るために最もよく使われているのは、セクションごとに要素を2つずつ用意する方法です。1つは流動的な幅の背景に使われ、もう1つは固定幅のコンテンツに使われます。コンテンツの要素にはmargin: autoが指定され、横方向の中央に表示されます。例えばフッターでは、次のようなマークアップが記述されるでしょう。

旅行予約サイト KAYAK （kayak.com）。わかりにくいが、ページ全体にこのパターンが適用されている

 
<footer>
	<div class="wrapper">
		
	</div>
</footer>

このマークアップに対して、例えば以下のCSSが適用されます。

 
footer {
	background: #333;
}
.wrapper {
	max-width: 900px;
	margin: 1em auto;
}

見覚えがある読者も多いでしょう。WebデザイナーやWeb開発者のほとんどは、このようなコードを一度は書いたことがあると思われます。要素が1つ余計ですが、これは最新のCSSを使えば回避できるのでしょうか。それとも、避けられない必要悪なのでしょうか。

縦方向の中央揃え

課題

人類が月面に到達したのは44年も前なのに、CSSではいまだに縦方向の中央揃えもできていません。

James Anderson （twitter.com/jsa/status/358603820516917249）

CCSSを使って要素を横方向に中央揃えするのはとても簡単です。インライン要素であればその親要素でtext-align: center;を指定し、ブロック要素ならその要素自身にmargin: autoを指定するだけです。一方、要素を縦方向に中央揃えしようとしたら、考えるだけで気分が悪くなってくるかもしれません。

数年にわたって、縦方向の中央揃えは手の届かない目標のひとつでした。フロントエンド開発者の間では、これを行おうとしてもただのジョークとしか扱われませんでした。以下のような事情も重なって、縦方向の中央揃えは特別扱いされています。

とても頻繁に必要とされます。
きわめて簡単かつシンプルに実現できそうに思えます。
しかし実際には、信じられないほど達成が困難でした（特に、サイズが可変の場合）。

ここ数年の間、フロントエンド開発者たちは知恵を絞ってこの難問に取り組んできました。しかし、編み出された解決策のほとんどは、ハックとしか言いようのないものばかりでした。このシークレットでは、最新のテクニックにもとづいて汎用的な縦方向の中央揃えを実現します。以下のテクニックもよく使われますが、ここでは利用しません。

テーブル形式のレイアウト（display: table;など）では、HTMLの要素が余分に必要になります。
inline-block を使った手法は、ハックの度合いが強すぎると筆者は考えます。

これら2つの手法にも興味がある読者は、Chris Coyierによる優れた記事『Centering in the Unknown』（css-tricks.com/centering-in-the-unknown）を読むとよいでしょう。

特に明記された場合を除いて、ここではbody要素の中に次のようなマークアップが記述されているものとします。しかし、これから紹介する解決策はコンテナ要素の有無にかかわらず正しく機能します。

 
<main>
	<h1>Am I centered yet?</h1>
	<p>Center me, please!</p>
</main>

最初の表示

また、表示をわかりやすくするために背景やパディングなどを設定しています（図 7.13）。

もし…	セルの幅を指定しないと、多くのコンテンツを含む列が広くなる。
複数の行を持つテーブルでは、すべての行のコンテンツを元に幅が算出される。	上の例と幅が異なる場合がある。

著者	Lea Verou （リア・ヴェルー）
訳者	牧野聡（まきのさとし）
発行人	ティム・オライリー
制作	株式会社ビブリオスタイル
印刷	日経印刷株式会社
発行所	株式会社オライリー・ジャパン〒160-0002　東京都新宿区四谷坂町12番22号 Tel （03）3356-5227 Fax （03）3356-5263 電子メール japan@oreilly.co.jp
発売元	株式会社オーム社株式会社オーム社〒101-8460東京都千代田区神田錦町3-1 Tel （03）3233-0641 （代表） Fax （03）3233-3440

CSSシークレット

CSSシークレット

Better solutions to everyday web design problems

賞賛の声

仕様ごとのシークレット

推薦の言葉

はじめに

謝辞

写真の出典

メイキング

日本語版について

本書について

対象とする読者

知っておくべきポイント

表記のルール

ブラウザの対応状況と代替案

意見と質問

Webサンプル版について

イントロダクション

Web標準は敵か？ 味方か？

標準化のプロセス

CSS3、CSS4、そしてその他の創造物たち

ベンダー接頭辞の物語

CSSコーディングのコツ

重複を最小限に抑える

保守の容易さと簡潔さの両立

currentColor

継承

数字ではなく自分の眼に頼る

レスポンシブWebデザイン

短縮記法を賢く使う

プリプロセッサを使うべきか

背景とボーダー

半透明なボーダー

知っておくべきポイント

課題

解決策

複数のボーダー

知っておくべきポイント

課題

box-shadowを使った解決策

アウトラインを使った解決策

柔軟な背景の位置指定

課題

background-position拡張を使った解決策

background-originを使った解決策

calc()を使った解決策

角の内側を丸める

知っておくべきポイント

課題

もっと読みたい！

ストライプ模様の背景

知っておくべきポイント

課題

もっと読みたい！

複雑な背景のパターン

知っておくべきポイント

課題

もっと読みたい！

（ほぼ）ランダムな背景

知っておくべきポイント

課題

もっと読みたい！

1つの画像によるボーダー

知っておくべきポイント

課題

もっと読みたい！

形状

さまざまな楕円形

知っておくべきポイント

課題

もっと読みたい！

平行四辺形

知っておくべきポイント

課題

もっと読みたい！

ひし形の画像

知っておくべきポイント

課題

もっと読みたい！

Web標準は敵か？味方か？