ヘイドン・ピカリングとアンディ・ベルの共著『Every Layout』が日本語に翻訳された。光栄なことに僕も出版前のレビュワーのひとりとして、微力ながらお手伝いさせていただいている。 タイトルが示すとおり、本書はCSSによるウェブデザインのうち「レイアウト」の問題に焦点を絞ったものだ。レイアウトといってもページ全体のグリッドのことだけではなく、ボタンやアイコンのような小さな部品に至るまで、CSSが「ボックス」として扱うあらゆる要素を対象としている。 テーマの根底にあるのは「コンポジション」というコンセプトだ。CSSによってインターフェイス部品を形づくるとき、それらひとつひとつを独自の、独立したものとして捉えるのではなく、基本的で小さなレイアウトの組み合わせたコンポジションとして捉えるべきである、と著者は主張する。そしてそのように組み合わされる小さなレイアウトを「レイアウト・プリミティヴ」と

日本語の組版ではコラム幅を文字サイズの整数倍にするのが基本だ。そうすれば全角等幅の活字を字間なく並べたとき、コラム幅と行長がぴったり合い、行末の位置が揃うことになる。ただしプロポーショナル文字（ラテン・アルファベットやアラビア数字など）や行頭行末の禁則の影響で行長にばらつきが出るので、その場合は調整が必要になる。 このコラム幅についての原則はウェブでも同様だと僕は考えている。ブラウザーではInDesignとは違って行ごとの緻密な調整はできないが、それでもやはり、コラム幅はなるべく文字サイズの整数倍にするのがよいと思う。そうしておけば、行長のばらつきが起こったとしても、その変化は「短くなる」方向でしか発生しない。コラムの右端を見たとき（横組みの場合）、おおむね縦に揃っているがときおりくぼんだ箇所が発生する、という格好になるわけだ。一方コラム幅が文字サイズの整数倍になっていないと、行長が意図し

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に調和するよう調整したものと思われます。一見ヒラギノ角ゴと見分けがつかないのですが、文字サイズがひとま

ウェブページの和文横組みの本文で、適切な行の長さはどのくらいか。もちろんこれは一概に言えるものではなく、内容、デバイス、書体、行間など、様々な要素に左右されます。しかし多くの場合、読みやすい行の長さは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 s

FirefoxのUAスタイルシートではinput要素のline-heightプロパティにnormal !importantという値が指定されていた。このため製作者がline-heightをコントロールできず、フォーム部品のスタイリングが難しい原因のひとつになっていた。これは修正される見込みがなく、「死ぬまで付き合うことになりそう」とまで言われていたが、2014年6月にリリースされた Firefox 30で!importantが削除され、上書きできるようになっていたらしい。 Firefox 30 for developers - Mozilla | MDN Site Compatibility for Firefox 30 - Mozilla | MDN 長生きはするものだという感想。

pixivのCSSで使われるクラス名ルールを読んで、僕もここ最近 CSS のコンポーネント設計について似たようなことを考えていたので書いてみる。いまのところ試案で、実際のプロジェクトで実践したことはまだない。 ここでいう「コンポーネント」とは独立したスタイルのブロックの意味で、たとえばヘッダーのナビゲーションとか画像のスライダーとかブログ記事のボディとかを指す。このアプローチの狙いとしては前出の記事とほぼ同じで、これらコンポーネントの「ルート」を明確にし、コンポーネント名が衝突しないようにすること。また管理や共有を考え、特殊な命名規則や不自然なマークアップなどはなるべく避けたいというのもある。Sass などの CSS プリプロセッサーを使う前提だけど、なくてもある程度は使える。 まずマークアップでは、コンポーネントのルートとなる要素に、クラス名と同時に data-component という

近々リリース予定の 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 に置換することで

ウェブページにおけるアイコンの実装方法はさまざまです。マークアップに img 要素を配置する方法もあるし、CSS から背景画像やアイコン・フォントを使う方法もあります。そういった中からどの方法を採用すべきかを判断するには、HTML Standard の Requirements for providing text to act as an alternative for images にあるとおり、「そのアイコンの意味を伝えるテキストが付随するかどうか」を考える必要があります。 テキストが付随しないアイコン 家のアイコンだけでホームページへのリンクを表す場合など、ラベルとしてのテキストが存在しないアイコンは、自分自身でその意味を伝える必要があります。こういったアイコンの実装方法は限られていて、ほぼ 1 つしかありません。alt 属性に代替テキストとしてラベルを指定した img 要素をマー

文書の特定箇所をターゲットとするハイパーリンク、いわゆる「ページ内リンク」で、<a href="#top">Top of the Page</a> のように top というフラグメント識別子を指定すると、それは文書の先頭へのリンクになります。このとき top という名前を持った要素がページの先頭に存在する必要はありません (もし存在すればその要素へのリンクになる)。 …という仕様があることを、つい最近 MDN 経由ではじめて知りました。どうやらもともと一部のブラウザーの独自仕様だったものが HTML5 において仕様に定められた、という経緯のようです。 文書の先頭へのリンクの実装方法としては、コンテンツ全体をラップする #wrapper や #container、あるいは文書の最上部に位置する #header といったフラグメントへのリンクというかたちで実現する例がよく見られます。しかしこれ

擬似要素と content プロパティを利用した画像置換テクニックの NIR (Nash Image replacement) と、いわゆる Retina ディスプレイ向けの高解像度画像 (sprites@2x.png みたいなやつ) を組み合わせる方法について。まずは 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: -

WordPress の次期デフォルト・テーマ、Twenty Twelve の CSS を見ていたら、body 要素に text-rendering: optimizeLegibility という見慣れないプロパティが指定されていたのでちょっと調べてみました。 The ‘text-rendering’ property – SVG 1.1 (Second Edition) text-rendering | Mozilla Developer Network Cross-browser kerning-pairs & ligatures CSS Text-Rendering | Trent Walton text-rendering プロパティは CSS ではなく SVG の仕様に定義されています。現在のところ利用できるブラウザは Firefox、Chrome、Safari。指定できる値は a

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

先月あたり、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