今年の夏はTシャツの入れ替え期という感じだった。計4着買った。柄物の気分ではなかったので、ポケット付きばかり買っていた。夏に普段着るものがすべて無地のポケット付きTシャツになった(なってしまった)。 Tシャツの生地感は色々ある。僕は厚手で柔らかいものが一番好きだ。でもそういうのを買おうとするとかなり高い。外出用に1着か2着持つくらいならいいが、そういうのは日常使いにはしづらい。となると厚さと柔らかさのどちらを優先するかということになる。 HanesのBeefyは国内モデルは本当にダメなやつだが、並行輸入がそこそこ見つかるのでそちらの方が良い。ポケット付きは国内モデルにはないので、自然と並行輸入ものになる。ただしサイズがおかしいことが多いので、ネット通販で買うのは賭けになる。特に小さい方に失敗すると脱げないかもしれないというくらい生地が硬い。ただ1500円くらいだと思うので、失敗してもそれほ
いわゆるバーティカル・リズム(vertical rhythm)がウェブページでも重要なのではないかと言われてから随分と経つ。僕の記憶が確かなら10年にはなるだろう。しかし当初から僕は懐疑的だった。もちろん一貫性のある余白は重要だが、バーティカル・リズムにまでなるとウェブページでは思うように機能しないのではないだろうか。 バーティカル・リズムはページ単位でどのようにコンテンツが美しく、そして読みやすくレイアウトされるかというための概念だ。それは紙媒体のような固定寸法にコンテンツを流し込む時には非常に有効に働く。常に一定のリズムで視線を動かしていけばスラスラと読んでいけるからだ。 しかし、ウェブページは横に制限があるが、縦には制限がない。そのためスクロールという機能がカギとなっている。古くはスクロールバーをクリックやドラッグすることでしかその機能を使うことはできなかったが、ホイール・マウスによ
ベスト・プラクティスは多くの人には固定的なものだ。しかし本来は流動的なもので、革新者によって大きな変化が起きる。ウェブ制作におけるベスト・プラクティスも変化しており、その過程でいくつも失われていった。 ウェブ制作においては、技術革新の多い世界であることと、他の世界の変革に対応しなければならないことから、よりいっそう変化が速いとも言えるだろう。だからといってベスト・プラクティスが意識するに留めておけば良いという程度のものというわけではない。例えば<!DOCTYPE html>について考えてみよう。 <!DOCTYPE html> これはHTML5が産声を上げた時期に先駆者である人々が編み出した魔法の言葉だ。これによりほとんどすべてのブラウザーでウェブ標準に準拠した形でHTMLが表示されることが保証される。つまり個々のブラウザーで大幅に違う挙動になることはなくなり、予期せぬ問題の発生を大幅に低
今までは主にアニメーションGIFで作られていたローディング・アイコンをCSSアニメーションで作るみたいなのが流行っている。面白いとは思うし、ちゃんと作ればスケーラブルなので便利そうでもある。けれどもローディング・アイコンを表示するための空要素が必要になり、かつ後にそれを消さなくてはならない。CSSだけだと面倒くさそうだ。 どういうローディング・アイコンかはこの際問題ではないので、とりあえずmain要素以下に何かしら(仮にサムネイルとする)をロードするまでローディング・アイコンを表示することを考えてみる。普通はJavaScriptでローディング・アイコンの追加→サムネイルのビルド→ローディング・アイコンの削除→サムネイルの追加とやるわけだけど、ローディング・アイコンの追加と削除でDOM操作を伴うのはコストがある気がする。 <main id="result"> <div class="spin
英単語の間であっても自動改行されるように、word-breakプロパティーでbreak-allを採用しているウェブサイトが地味に増えているような印象だ。コスメティックな理由で見出しやサムネイルの付記などに使うのは悪くない妥協だと思うが、本文にもわりと気軽に使われていてかなり気になる。 日本語では特に単語の切れ目という論理的な箇所は存在せず、ブラウザーではどこでも自動改行される。せいぜい句読点が行頭にならないように制御されるくらいだ。word-breakプロパティーではこの自動改行における単語の禁則処理を制御できる。値としてbreak-allを指定すると禁則処理が解除され、現在のブラウザーの実装では以下のような事象が起こる。 英単語の間で改行される 行頭でも記号が許可される 前者がわかりやすく、これを目的としていることが多い。こうすることによってタイポグラフィーでいうところのflush le
Translation of: Bulletproof Accessible Icon Fonts by Filament Group アイコン・フォントを利用する場合、あらゆるユーザーに適切にアイコンを提供しようとすると、かなり気をつける必要があります。そのフォントが読み込まれなかった時にどうなりますか？@font-faceがまだサポートされていないブラウザーでは？ どうすれば安全に(bulletproofに)アイコン・フォントを利用できるかをこれから解説したいと思います。 効率的で機能的なウェブサイトを制作するという、この終わることのない探求において、ベクター形式のアイコンを提供する手段として、簡便であるフォントを利用することが何度も提案されてきました。対して私達は通常ベクター形式のアイコンとしてSVGをIan Featherがブログ書いたような理由から選んで(また、薦めて)おり、既に
アプリケーションの世界ではセマンティック・バージョニングが広く受け入れられた……かどうかはわからないが、採用例はすごく増えている印象だ。ウェブデザインではどうかというと、ウェブ・アプリケーションのバージョニングに追随しているだけであったり、そもそもバージョニングされていなかったりするような気がする。ウェブデザイン、主にCSS(とCSSプリプロセッサー)においてセマンティック・バージョニングを導入するとすると、どのようなタイミングでメジャー、マイナーそしてパッチ番号を増やせば良いのだろうか。 セマンティック・バージョニングの中心となる概念は後方互換性だ。後方互換性が: 失われる: メジャー 失われない新機能の追加: マイナー 失われない修正: パッチ 数語でまとめるとこのようになるだろう。ウェブデザインにもこれを当てはめるとすると、ウェブデザインにおける後方互換性とは何なのかということをまず
Webフォントの読み込みは@importだと色々まずいので、主にlink要素を使って並列に読み込むわけだけど、これもまた貴重なHTTPリクエスト数を消費するとか、CSSのパース完了が少し遅れるなどあって、完璧な解というわけじゃない。それを非同期にWebフォント定義の含まれるCSSファイルを読み込むようにして、Webフォントのロードをページのレンダリングと並行して行わせるのはどうか、という試み。 非同期化することによりWebフォント定義の含まれるCSSファイルのリクエストとパースが、ページのレンダリングと並行して行われるようになる。head要素内でlink要素を直接書いた場合は、Webフォント定義の含まれるCSSのリクエストとパース後にページのレンダリングが始まることが多いので、体感速度(ページのレンダリングの開始までの所要時間)は向上する可能性が高い。 動的なlink要素の追加 いわゆるソ
HTML Standardの4.8.1.1 Requirements for providing text to act as an alternative for imagesをざっと把握できるように日本語で箇条書きにしただけのものです。最終的には原文をしっかりと読むべきでしょう。 基本 必ず定義されるべきである その値は空であってはならない その画像に代わりになる最適な文字列である ページ上の全ての画像をそのalt属性の値で置き換えてもページの意味合いが変わってはならない 画像のキャプションや題名、銘とみなされるような補助的な説明を意味するものであってはならない 前後で解説されている情報の繰り返しであってはならない 画像以外に何も含まれていないリンクやボタンで使われる場合 リンクやボタンの目的を明確に伝える文字列を指定する わかりやすく説明するために文章ではなく画像のチャートやグラフを
ブラウザーはviewportによって折り返しを自動で行なってくれるわけだけど、場合によっては適切ではない位置で行われてしまうのをコントロールしたいという話。見出しをセンタリングしているようなケースで幅によっては一文字だけ次の行になってかっこ悪い！ みたいなのを解消したいということであったり、逆にびろ～んと間延びしないようによさそうな位置で改行を入れたいということであったり。一年くらい前にResponsive Line Breaksと呼ばれるようになった。 具体的なものはResponsive Line Breaksにあるデモやこのウェブログの日付表示の部分とかがそれ。ここではviewportの幅が広い時に良い位置で改行が入るようになっている。 article footer br { display: none; } @media (min-width: 60em) { article foo
背景画像をbackground-sizeプロパティーで縦横サイズを制限して敷き詰めるというのは昔id:hitode909がやってた。それをCSS Transitionsで元のサイズに戻したらどうなるかなーとやってみたらそこそこ面白かった。きっかけは96x96.netを見たことで、こっちはborder-imageプロパティーを組み合わせていて、widthプロパティーをtransitionしている。 Demo: background-size Transition CSSは至って普通。background-positionプロパティーでセンタリングすると中央からブワッとなる。どちらかというと縦に並べた方がカッコイイ気がする。 .test { width: 640px; /* 背景画像の横幅 */ height: 360px; /* 背景画像の縦幅 */ background-image: ur
Translation of: Learn You a Flexbox for Great Good! | The Haystack. written by Stephen Hay Flexboxについて知っていますか？ 多分、名前は聞いたことがあるでしょう。もしかしたらチュートリアルくらいは読んだことがあるかもしれません。既に試していたりしますか？ Flexboxという代物についてあまり聞いたことがなかったり、前に試してから随分と経つなら、そのFlexboxに関する知識のことは一旦全て忘れてしまいましょう！ 現時点での最新版である2011年11月29日にリリースされた仕様では完全に別物になっています。 訳注 2012年3月22日に新しく公開されたWorking Draftでもまた大きな変更が加わり、この文書の一部はそのWDにそぐわないものになっています。大筋は変わりませんし、2012年3
少し前にFixing browsers’ broken monospace font handlingをNice Web Type経由で読んだんだけど、「単純に初期設定が違うだけだろ……%指定すれば大丈夫じゃね？」とか高をくくってたら大間違いだった。font-size: 100%がうまく動かなかったり、pre要素はともかくcode要素辺りでの実装のずれとか、monospaceだけだとWebKitでおかしくなるバグとかも絡んできてかなりの魔窟のようだ。この記事では触れられていないけど、言語設定によって等幅フォントの初期サイズが違うこともあるので更なるカオス。 記事で最初に挙げられているコードでも良いのだけど、normalize.cssではこの問題への対処がちゃんとなされているので、細かいことは余り考えずにnormalize.css使うのが手っ取り早い。記事の最後に挙げられているコードのように
Translation of: Getting Started with Sass - A List Apart CSSの持つその簡明さは欠かせない特徴の一つで、それは最も歓迎されている点でした。CSSによるスタイルシートは、セレクターといくつかの適用したいスタイル情報を含むルールを羅列したものに過ぎません。しかし、WebサイトやWebアプリケーションが巨大に、そして複雑になり、様々なデバイスや画面サイズに対応せざるを得なくなった現在、この簡明さという特徴―fontタグやテーブル・レイアウトの淘汰に大いに役にたったもの―が大きな足かせになっています。 簡単な計算機能や変数を追加するなどといったCSSの修正案が過去に提示されましたが、どれもブラウザー・ベンダーには採用されませんでした。仮にこういった新しく素晴らしい拡張されたCSSがあるブラウザーに実装されたとしても、それが実用に耐える程度に
せめてWebKitに実装されてからとか思ってたけど、CSS Image Values and Replaced Content Module Level 3がLast Callになったのでいい機会ということにしてelement()関数についてエントリを書く。element()関数は任意のIDを引数に取ることができ、その要素を画像として参照できるというなかなかの荒業な関数。具体的には画像のサムネイルを簡単に作成できるとかそういうものをイメージするとわかりやすいと思う。 Demo: Filmstrip View いわゆる「フィルムストリップ」のようなものを作るデモだけど、element()はまだFirefox 4以降でしかサポートされていないので、ChromeやSafariなどでは意図した通りに動かない。Firefoxなら下に並んだサムネイルをクリックすると大きな画像が表示される。切り替えやア
間のスペースが大きい状態(3で割った余りが1の時)は不恰好になりがちなので、調整できるなら3で割り切れる数にするのが無難。 次は間のスペースの色の話。こちらも仕様では特に触れられていないが、どの実装もtransparentになっている。ただし枠線と同時にbackground-colorプロパティーで背景色も指定されていた場合、スペースの色は背景色と同じになる……というより枠線の下まで背景色で塗られるのでそれが見える。そのため背景色を塗りつつ枠線の間を透過させるというようなことはそのままではできない。 が、背景画像の場合はbackground-originプロパティーのデフォルトがpadding-boxになっていることもあり、間のスペースから背景画像が見えることはない。つまりlinear-gradient()を使って単色の背景画像を作ってやれば、上記URLの2番目の例のように間のスペースを透
画像に続けてfigcaptionをそのまま普通に表示するといまいちなことが多いです。それでも英語ならイタリック体にするとかでなんとなくその文字列がfigure要素に係っているものだということが表現できるような気がしますが、日本語の斜体はいろいろアレなので使いたくないです(よね！)。そこで画像にキャプションを綺麗に重ねる方法を模索してみました。 Demo: Smooth Caption まずは画像のHTMLです。 <figure> <a href="http://example.com/"> <img src="http://example.com/images/logo.png"> </a> <figcaption>Example.com's Logo</figcaption> </figure> このHTMLに対してどんなサイズの画像にも対応できるようにCSSを書いていきます。a要素には
基礎以上ベスト・プラクティス未満。 CSSハックのことは忘れる CSSハックの多くは便利で強力なものだが、それに頼るのは危険だ。まずは普通にCSSを書くことに注力するべきだろう。その上で条件付きコメントやModernizrを使うかCSSハックをあえて使うか決めると良い。 色の書き方は統一する キーワードによる色の指定や#rrggbb、rgb()といくつかの方法で色を指定することができるが、#rrggbbの桁を合わせることも含めていずれかに統一した方が可読性とメンテナンス性が上がるだろう。 %は長さの単位ではない border-widthなどで使用できない理由はそれだ。他にも使用することができないプロパティがいくつかある。また%はコンテキストによって基準になる単位が大きく変わる他継承においてもある意味不可解な挙動を起こすことがある(line-heightなど)ので、使用には注意を払う必要があ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
