ウィンドウや画面のサイズに合わせて文字の大きさを自動的に変更するテクニックは、俗にレスポンシブ・タイポグラフィーまたはフルイド・タイプと呼ばれている。当初は僕も良いアイディアだと思い多用していたが、重要なのはビューポートの大きさではなくデバイスとの距離だろうと思い直したためもうほとんど使うことはない。当初から嫌いといっていた人はこの辺にしっかりとした意識があったのだろう。 使うことをやめた理由は、単純に技術的制約によってユーザーとデバイスの距離を知るすべがないからに過ぎない。レスポンシブ・タイポグラフィーが目指す、適切な文字の大きさを環境ごとに提示することそのものについては正しい考え方であると思う。ただ今利用されている「ビューポートが768px以下なら文字を小さめにする」というようなアバウトな実装だと問題がある。もちろんvw単位を使ったフォント・サイズ指定でも同じだ。 なぜならばデスクトッ

6月24日発売のWEB+DB Press Vol.81にて「イマドキHTML/CSS開発」というタイトルで特集を執筆した。特集では機器や周辺技術の変化と進化がもたらす多様性に、今までのような現状の機器への逐次対応という視点ではなく、未来のそれらを見据えた形で相対するにあたっての考え方や実装方法を解説している。具体的には検証可能な「コンポーネント」という単位をどう作り、それをどう扱うか、だ。 「マルチデバイス」というイマドキの事情 独立性を重視した設計 コンパクトな開発サイクル デバイスの特徴を活かしたUI 環境に左右されない画像 特集はこのような形で構成されている。現状の説明から始まり、コンポーネントの設計から、その実装をまず解説し、それらの自動化・最適化・効率化について、コンポーネントごとに実装から検証までを行う小さなサイクルを中心に据えたワークフローへの変革を絡めて触れていくという形に

SassConfに合わせたのか、Sassの3.3 RC.1が出た。これで3.3での追加機能も固まったようなので、CHANGELOGをちゃんと読んだところ、1か月ほど前に取り込まれていた新しいデータ型であるマップについてもちゃんと入っていた。マップは、いわゆるハッシュとか連想配列とかいう名前で呼ばれるもの。 マップの書き方はリストとほとんど同じで、リストの各要素にコロン(:)区切りでキーと値をワンセットで書く、というようなもの。例として、プロ野球セ・リーグの各チーム色を背景色にしたクラスを吐くもの作ってみる。 $team-colors: ( giants: #f90, tigers: #fc0, carp: #f00, dragons: #009, baystars: #269, swallows: #03c ); @each $team, $color in $team-colors {