はてなブックマーク

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

ブログ記事の本文などで幅100%の画像を配置する場合、縦長の画像がやたらでかくなってしまったりなど、画像のアスペクト比によってその印象が大きく違ってしまうことがある。これをアスペクト比に関わらず大きさが揃って見えるようにしたい。それには各画像の面積が同じになるように幅をコントロールできればいいのではと考え、CSSでやってみた。 まず基準になる画像として、もっとも横長な画像のアスペクト比を決める。ここでは例として16 : 9とする。この16 : 9画像の幅を100%として、それ以外のアスペクト比の画像の相対的な幅を求めていく。 HTMLでは、各img要素のstyle属性に、アスペクト比を分数形式にしてカスタムプロパティとして指定する。 <img src="cat.jpg" style="--aspect-ratio: 16/9;"> <img src="dog.jpg" style="--a

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

印刷向けCSSの手法のひとつに、擬似要素とattr()関数を使ってリンクテキストの後ろにURLを挿入する、というものがあります。Boot­strapやHTML5 Boiler­plateなどでも取り入れられているものです。 a[href]::after { content: " (" attr(href) ")"; } 簡単かつ効果的ではありますが、挿入されるURLによってテキストが分断されてしまうので、どうしても本文が読みにくくなりがちです。URLが長い場合はとくに。 そこで、URLをページの欄外に配置し、番号を振ってリンクテキストと結び付ける、という「傍注」形式にすれば、本文が読みやすく、かつURLも必要に応じて参照できて良いのではないかと思います。 これはカウンターとフロートを利用した簡単なCSSで実現が可能です。main要素内のリンクを対象にする場合のコードのうち、必要最低限の部分

Mojikという、ウェブにおける和文の文字組みをコントロールするためのJavaScriptライブラリを公開しました。いまのところ、以下のパターンでの「アキ」を調整できます。 連続する約物のアキ 行頭の始め括弧のアキ 欧文間のアキ Mojik.compose()メソッドの引数にCSSセレクターを渡すと、マッチする要素から上記に該当する箇所を検出し、それぞれマークアップが挿入されるので、CSSでアキ量を調整します。以下のページに実際に動いているデモがあるので、ぜひ見てみてください。 Mojikデモ ウェブページの本文やタイトルなどで使われることを想定しているので、HTMLタグがあっても問題なく動作することは必須条件でした。基本的に、まずHTML文字列をテキストとタグに分けて、正規表現でテキストの検索を繰り返す、という方法を採っています。ここらへんはkotarok/jQuery.waokonなど

GoogleのRobotoや、AppleのSan Franciscoなど、OSベンダーが独自のフォントを開発し、自社製品のUIにシステムフォントとして採用する、という事例が相次いでいます。これらのフォントは、プラットフォームの特性を考慮して最適化されたもの（あるいは最適なものとして選ばれたもの）と言え、かつ今後のOSのアップデートにともなってさらに改善されることも期待できます。また、ユーザーがそのシステムを操作するときにもっとも頻繁に触れる、つまりもっとも見慣れているフォントでもあります。というわけで、これらシステムフォントをウェブサイトのUIに採用するというのはかなり良いアイデアに思えます。 一方で、システムフォントはあくまでUIのためのもので、長い文章などには向かない場合もあるので、コンテンツ部分は別のフォントを指定すると良いかもしれません。たとえばMediumなどではそのようなアプロ

“Why I’m Excited About Native CSS Variables”という、CSSカスタム・プロパティ（CSS変数）を紹介する記事を日本語に翻訳し、「僕がネイティブなCSS変数にわくわくする理由」として公開した。元記事から3カ月近くたってしまい、旬を逃した感もあるけど、近々カスタム・プロパティがChromeとSafariの安定版でもサポートされるというタイミングなので、まあいいかと思って公開した。 僕はこの記事を読むまで、CSSカスタム・プロパティの存在は知っていたもののほとんど注意を払っておらず、当面はSassがあるしべつにいいやと思っていたという、まさに記事の想定読者の典型だったと言える。でもこれを読んで考えをあらためました。個人的には、Sassにはじめて触れたとき以来と言っていいくらいの驚きがあった。 記事の例にあるように、レスポンシブ・デザインやコンテクスチュア

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

少し前にこのサイトのデザインをちょっと変えて、「本文は明朝、ただし見出しや強調などはゴシック」というスタイルにしています。と言っても、本文が明朝で表示されるのは游明朝体かヒラギノ明朝体が使える場合だけで、それ以外の環境ではゴシックになるはずです。 欧文書体は和文の従属欧文ではなくMerriweatherです。セリフとサンセリフのファミリーがあることと、エックスハイトが高く和文との相性が良いことから選びました。ウェイトは和文とのバランスから400ではなく300を使っています。MerriweatherはGoogle FontsやTypekit、Font Squirrelなどで入手できます。 CSSの指定としては、まずデフォルトがMerriweather Sansとゴシック体の組み合わせ。そして游明朝体またはヒラギノ明朝体が使えるかどうかをJavaScriptで検出し、もし使えれば本文でMerr

僕はウェブデザインでグレーのテキストを使うとき、背景色が白（#ffffff）なら、前景色を#767676かそれより暗くするようにしています。これがWCAG 2.0の達成基準「最低限のコントラスト（レベルAA）」を満たすもっとも明るいグレーだからです。 ちなみに、背景色が黒（#000000）のとき上記達成基準を満たすもっとも暗いグレーは#757575です。つまり、#767676または#757575のテキストは、背景が白でも黒でも最低限のコントラストを確保できます。またこれらの背景色と前景色を入れ替えても同様で、#767676または#757575の背景ならテキストが#ffffffでも#000000でもOKです。 フォントのサイズやウェイトによってはこの限りではないし、背景色が真っ白や真っ黒でない場合はツールなどを使って検証する必要がありますが、とりあえずこの#767676という値を覚えておくと

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

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: ""; displa

CSS によるフォントの和欧混植は、たいがいの場合、font-family プロパティを使ったシンプルな実装で間に合う。ファミリ名をカンマ区切りのリストとして指定すれば、ユーザーのローカル環境に応じて利用可能なフォントが適切に選択される。 html { font-family: "Helvetica Neue", "Arial", "Hiragino Kaku Gothic ProN", "Meiryo", sans-serif; } しかし、こういったシンプルなアプローチでは実現できないケースもある。「特定の和文フォントが利用可能な場合に、特定の欧文フォントと組み合わせて利用したい」というのがそれ。たとえば、「ヒラギノ明朝か游明朝のいずれかが利用できるなら Times と組み合わせて使いたいが、どちらの明朝体も利用できないなら Helvetica とゴシック体の組み合わせを使いたい」とか

近々リリース予定の 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 要素をマー

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; } @me

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

図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: 5

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 =

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

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 ファイルに直接定義するのとは違って別フ

CSS で角度を扱う機会が増えてきたので、三角関数を中心にいくつかの数学関数を Sass 関数として実装してみてる。「三角関数を中心に」とかさらっと書いてるけど、書いてる本人はタンジェントとか高校で習ってないと言い張る程度の理解なので注意。書いてるうちに芋づる式に増えて手に負えなくなってきたところで GitHub に公開することにした。 terkel/mathsass · GitHub ほんとは Ruby のモジュールで書けば簡単かつ精度も高いだろうし、将来 Sass のネイティブに実装されれば用なしになるわけだけど、勉強になるのでやってて満足度は高い。 これ系の Sass 実装でまとまったものは adambom/Sass-Math と Team-Sass/Sassy-math ぐらいしか見つけられなかったし、これらの中でもものによってバグってるっぽいのもあったので、ほかに 404 Blo

Kraken というフロントエンドのフレームワークのコードを見ていたら、なるほどと感心する CSS セレクターの書き方を見つけた。grid-one、grid-two みたいな接頭辞つきのクラス名にマッチするセレクターで、こんな感じ: [class^="grid-"], [class*=" grid-"] { /* ... */ } 単純に考えると [class*="grid-"] でいけそうな気がするけど、それだと foo-grid- みたいに頭に余計なものがついていてもマッチしてしまう。そこでホワイトスペースを接頭辞の前に置いて [class*=" grid-"] とすることでそれを避けている。すると今度は class="grid-one" みたいに class 属性の先頭で頭にホワイトスペースがない場合にマッチしないので、[class^="grid-"] という前方一致のルールを追加。

擬似要素と 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: -