Fluid～では、Responsive Web Designでは回転により描画領域が拡大した時に画像等のサイズを追随させるがフォント・サイズはそのままなことが多いため、画像と文字のレイアウトのバランスが崩れるという問題が起きることを指摘している。この問題は16:9の縦横比を採用しているタブレット(例えばGalaxy Tab)などで顕著になり、Media Queriesで細かくレイアウトを調整するにも限界があるので、描画領域に合わせてフォント・サイズを調整することにより解決すると良いのではないかと結論づけている。

この解決法を否定するのはごく簡単だと思う。デザイン上の都合でユーザーに制御不能な変化を押し付けているとかそんな感じでぶった斬れる。でも、それはあまりにも浅い気がする。デザインとコンテンツはどちらが先でどちらが後などというものではなく、良いデザインを採用することでコンテンツをより良い形で提供できるというような相関関係にあるはずだ。そういう意味ではこの描画領域のサイズによる画像と文字のレイアウトのバランスの変化を最小限に抑えるためにフォント・サイズを変更するというアイディアそれ自体は素晴らしいものだと思う。

問題なのは回転時にそれを行うことと、デバイスへの対応の限界を知っていながらiPadを強く意識したpx単位でのブレークポイント(which in my case 768px - an iPad in portrait orientation)を採用したこと。

回転時に行うのはまずそう

前に書いたエントリでも触れたようにフォント・サイズの変化にユーザーの目がついていかない可能性があるという問題がまず挙げられる。特にタブレットは紙の新聞のように目に近い位置で持たれるものだし、老眼はもちろん強めの乱視持ちとかでもクリティカルな問題になるんじゃないかと思う。それに回転したい時というのはそのレイアウトでは読みづらいので、今より画面を広く(狭く)して読みやすくしたいという時のはず。となると回転時にレイアウトを維持しようというこのテクニックはちょっとユーザーには的外れのテクニックなんではないだろうか。

iPad以外のタブレットが不燃ゴミなのは確かだけど

これはもう「Androidデバイスへの対応がメンドイのでiPadだけ対応してみました～」以外の何者でもない印象を受ける。現実的な妥協案だとは思うけど、それならばコンテンツのレイアウトを根拠にしたブレークポイントを採用した方が良さそう。特にエントリーで取り上げられているような縦方向でのバランスを取る時にはフォント・サイズだけではなく行ボックスの高さ(line-heightプロパティー他)の調整も必須になってくるはずなので、それを考えるともっとレイアウトに注目してブレークポイントを探った方が読みやすいデザインになるはず。

とは言うものの回転時にMedia Queriesを発火させない方法などはなかなか難しいと思う(ちょっと思いつかない)ので、現状では最良に近い解の一つではあるような……。という所あたりまで考えて、もしかしたら回転時にスケーリングが狂うバグとみなされているiOSの挙動は、ここらへんのことを考えて練りに練られた仕様なんじゃないかとか少し思った。

コメットさんにも華がある

川原泉の「がある」シリーズの二巻目。川原泉のは惰性で買っているといっても良いけど、安定して楽しい。リア充マンガな気はする。

妖怪アパートの幽雅な日常 (1)

原作は知らない。シリウスで連載されるマンガは嫌いなのがほとんどで、ごく稀にツボる。これはもちろんツボの方。

妖怪HUNTER

妖怪続いた。諸星大二郎を期待して買って愕然とする感じが逆にカタルシス。井上淳哉の書く化物は好きなので、そうじゃないだろ！とかぶつくさ言いながらも楽しく読んだ。

つづきはまた明日 (3)

少女マンガだとだいたい不幸スパイラルに陥りそうな設定だけど、バーズで紺野キタなのでそうならない。

足洗邸の住人たち。 (11)

「バール」のような物。マイケル・J・○ォックスかオマエは。オレさ！帰ったらプロポーズするんだ！といったような凝ったセリフが繰り広げられるマンガ。

妖怪ものが特に好きなわけじゃなくて、妖怪ものが世に多いだけです。

スマートフォンはまぁともかく、タブレットでは端末を回転させるとかなり描画領域に変化が起こる。適当にブレークポイントを設定してフォント・サイズを変更するようにしていると、回転させたらフォント・サイズが大きく(小さく)なってしまうことがありうる。場合によってはタブレットを持つ手を動かして、タブレットと目の距離を調節させることになる。老眼が始まってたりする場合は、読みやすくするために回転させたのにも関わらず、フォント・サイズが変わったせいでピントが合わなくなって読めなくなったりしそう。

タブレットといってもいろいろあるのでそれらに対応などはとてもじゃないが無理。勿論iPad先生にフォーカスを当てるのもそれはそれでアレなので……。

Webではデバイスを意識する必要はないと思うし、そうあるべきだと思う。けれどもデバイス固有の機能を邪魔しないような工夫は最低限必要なのかもしれない。

一番使いそうなmarginプロパティーでの利用を考えてみる。まずまとめて指定するケース。

h1 {
  margin: 3rem 0 0 0;
  font-size: 250%;
}

これだとmarginプロパティーで指定した値全てが無視されてしまう。非対応ブラウザでのフォールバックを考えると先にem等で書いておいて、remで上書きする必要がありそう。

h1 {
  margin: 1.2em 0 0 0; /* 1.2 = 3 / 2.5 */
  margin-top: 3rem;
  font-size: 250%;
}

単なる計算なのでSassがあるなら$ratioとかいう変数を用意して書くとメンテナンスしやすそう。

h1 {
  $ratio: 2.5;
  margin: (3em / $ratio) 0 0 0;
  margin-top: 3rem;
  font-size: percentage($ratio);
}

rem使う意味ない……。

フォールバックを考えない、つまりIE8以下を無視する場合では便利で見通しの良いCSSを書けるようになることは確かなんだけど、rgba()などとは違って所詮は計算でどうにかなる程度のものでしかないことを考えると……。ブラウザーのデフォルト・スタイルシートですら使われてないし、まだちょっと使用には踏み切れない感じかなぁ。

ということ(？)でvim-css3-syntaxを更新して、remを始めとした新単位等に対応したりしました。これでcss3-values-20110906には追いついたと思う。正直忘れてた。cycle()とかなにこれカッコイイ。この更新でcss3-functions.vimからcss3-values.vimにファイル名を変えたので、HTMLやSassにシンタックス定義を追加している人はそちらも合わせて更新する必要がある。空で残しておこうかと思ったけどそれもアレなので消した。

コミット・メッセージにつづりミスを発見するのはなぜいつもpushした後なのだろう……。

まずその大きさだが、px単位系だと3で割った余りが1の場合は間のスペースが増え、余りが2の場合は枠線の太さが増える。仕様では決められてないが、大体どの実装でも同じようだ。

間のスペースが大きい状態(3で割った余りが1の時)は不恰好になりがちなので、調整できるなら3で割り切れる数にするのが無難。

次は間のスペースの色の話。こちらも仕様では特に触れられていないが、どの実装もtransparentになっている。ただし枠線と同時にbackground-colorプロパティーで背景色も指定されていた場合、スペースの色は背景色と同じになる……というより枠線の下まで背景色で塗られるのでそれが見える。そのため背景色を塗りつつ枠線の間を透過させるというようなことはそのままではできない。

.test {
  background-image: linear-gradient(
    top,
    #396 0,
    #396 100%
  );
  background-size: 100% 100%;
  background-repeat: no-repeat;
}

段落間のマージンを省きインデントすることのキモは文章を連続した塊にすることができること。それにより一気に文章を読ませることができる……というよりも、段落間のマージン(bounding)は思考をも分断しIslands of Thoughtを産み出してしまうという欠点があるということへの対策のようだ。

実装はネタ元と同じように以下のように兄弟セレクタを使っただけ。

p + p {
  margin-top: 0;
  text-indent: 2em; 
}

このWebサイトのスタイルではブロックで上下にマージンを確保していたのでちょっとアレな感じのコードになった……。これを機会にブロックのマージンはmargin-topプロパティーだけを使うようにしたりすると楽かもしれないとかちょっと思ってる。マージンのとり方を変更してシンプルなルールで実装できるようにした。

グリフが矩形にびっちり詰まっている日本語の文章ではマージンがあった方が読みやすいと思う。元ネタのエントリーにあるBookmarkletを使っていくつかの日本語Webサイトをみたりしてみたけど、やっぱりマージンが必要な感じだった。抑えめのマージンと抑えめのインデントを組み合わせたりするのが良さそうな感じだけど、そこまでするくらいなら普通にマージンをとった方が慣れてて読みやすそう。

opacityプロパティーで1以下が指定された要素はその重なり順が変化するという仕様があるようだ。擬似要素を複数組み合わせて紙をずらして重ねたようにロゴをちょっと改悪した時に初めて知った。いつものChromeのバグかと思った……。

仕様ではpositionプロパティーがstatic以外の要素でopacityプロパティーを1以下にするとz-indexプロパティーが0であるとみなされるようになっている。そのためその要素でz-indexプロパティーを-1にして背面に移動するようにしたり、100等で意識的に手前に持ってきたりするようにしている場合、その重なり順が壊れてしまう。

と、こう書くと結構単純な感じなんだけど、実際には0とみなされた上で新たな重なり順が作られるので、いくつかの要素をまとめて半透明にして重ねまくってたりすると、どういう重なり順になるかとてもイメージしにくい。ので余程の理由がない限りはopacityとz-indexプロパティーの組み合わせには近寄らない方が良さそう。

追記

例えば最初のスクリーンショットは件のopacityとz-indexプロパティーを組み合わせて作ったもの。a要素とa::before、a::afterでそれぞれ正方形を作りTransformさせて重ねているだけ。

1. a要素の文字(hail2u.net)
2. z-index: -1のa::before
3. z-index: -2のa::after
4. a要素の背景

という重なり順になる。普通に-1等を使うとa要素の背景より後ろになるはずだがならない。かといって単純に上に重ねられるわけでもなく、背景と文字列の間に挟まっている。ややこしいですね！

カラム定義

カラムは本文を9カラムで48em程度にしたかったので以下のようにした。

$column: 3.5em;
$gap:    1em;

これで9カラムで47.5emになる。Style Guideだとそこらでダブルクリックするとカラムがオーバーレイ表示されるようになってる(_grid-overlay.scss使った)。12カラムが収まる場合はマルチカラム……にしたかったけど、とりあえずはタイトルや日付けをちょっとずらすだけにした。マルチカラムにまだ慣れてなくて、間に画像やpre要素が挟まるとうまくスタイル書けない。ちゃんとセクショニングしてしっかりマークアップしとくとマルチカラムにしやすそうだなぁ。

文字サイズの調整

文字の大きさの切り替えはあまり細かく考えずに計算で誤魔化した。

body {
  // Decrease font size
  $too-narrow: $safe-for-content * 0.875 * 0.875;

  @media screen and (max-width: $too-narrow) {
    font-size: 87.5%; // 14px
  }

  // Increse font size more
  $wide-enough: $safe-for-full * 1.25 * 1.25;

  @media screen and (min-width: $wide-enough) {
    font-size: 125%; // 20px
  }
}

使うサイズを先に決めて、その倍率の二乗をかけたサイズに横幅が到達したら切り替えている(4段階)。根拠はない。ただこの処理もemを使って振り分けているので、実装によってはおかしくなりそう(切り替えぎりぎりのあたりだと条件を満たして切り替えた後に条件が満たされなくなって元に戻るの無限ループとかありえそう)で不安がある。ここだけはpxにした方が安全そう。

リリース版のSassではまだMedia Queriesで変数を利用することができないので、こういう書き方をするためには開発版をインストールする必要がある。

$ gem install --prerelease sass

開発版では%fooという@extend専用のプレースホルダー・セレクターも書けるようになったりしててとても楽しいと思うので、大体Sass覚えたよーという人は試すとライフチェンジングするはず。

他

フォントはあまり変えていないけど、見出しに使っていたAndikaはやめた。Operaでのバグの件でLucidaスタックに戻したい感じではある……。

後はフッターのアイコンを_corporate-colors.scssを使ってオンマウスで色が変わるようにしたくらい。あんま意味ないので最初からカラフルでもいいかも。

emにした理由は主に二つある。

今のところpxはほぼ絶対的なサイズとして扱えてて、かつ、cmのように非直感的な単位ではないのでだいたい期待した通りに動いてくれるけど、今後のデバイスとOSやブラウザーの実装次第ではpxでは駄目になるんじゃないかと思っていることがひとつ。画面サイズとドットピッチ、DPI、最後にスケーリングという様々な要素が絡みあう世界をpxだけでどうにかされることを期待するのはあまりに甘いと思う。emとfont-sizeの%指定を組み合わせなら、そのあたりはブラウザー側で(結果的に)吸収してくれることになり……そう……というかなって欲しい。

勿論DPI等を意識しないという意味では%で全部やっても良いと思うんだけど、%ではどうしてもデバイス(というかブラウザー)の描画領域を強く意識することになる。そもそもの基準が描画領域になるので、このサイズに収まるようなレイアウトという考えから脱却できない。

つまりもうひとつは1行の文字数を基準にしてレイアウトしたくなったということ。今までも全角50文字前後になるようにしてたつもりだけど、px単位に置き換えてやってた。Sass使い始めてからはSassでやればいいかなーと思ってたけど、せっかくem単位あるんだしそれ使うのがいいよね！とかそういう軽い感じ。

emだと安心とかそういうことはありえないけど、この1pxへのこだわりを捨てられた感じはちょっと開放感ある。ただ最初にも書いたけどやはりcalc()がないと辛そう。違う単位を混ぜられて簡単便利っていうのも勿論あるんだけど、無いとどうしてもem単位をpx単位等に脳内で置き換えてイメージしてからCSSを書きがちになる。それではemを使う意味が薄れてしまうので、emであるべきところはem、pxであるべきところはpxで書けるcalc()は重要になるんじゃないかと思う。

無駄に長くなった。emの話はまた別に書こうかな。%を使ったカラム・レイアウトはダメそうとかそういうのも含めていろいろ書けそう。などと書くとだいたい書かない法則。

追記

em単位でのMedia Queriesで無限ループになりそうという心配は杞憂だった。

For example, in HTML, the ‘em’ unit is relative to the initial value of ‘font-size’.

と書いてあるのでbody要素の文字サイズを変更しても影響ない。

View Demo: Opera and Web Fonts

デモではJunctionというフォントをWebフォントとして使った。フォーマットによって違う可能性も指摘されたので、TTFとEOT、WOFF、SVGの4つのフォーマットで試している。

.test {
  font-family: "Junction <format>", "Helvetica Neue", "Arial", sans-serif;
}

という指定なので、対応しているフォーマットだった場合は英数字がJunction、それ以外がブラウザーの設定に従ってsans-serifで表示される……はずだが、Operaでは日本語の部分が明朝体、WindowsだとＭＳ Ｐ明朝(多分)になってしまう。

Webフォントの扱いにバグがあり、まったくフォールバックされないということみたい。

.test {
  font-family: "Junction <format>", "Meiryo", "メイリオ", "Helvetica Neue", "Arial", sans-serif;
}

などとして、メイリオを期待しても無駄でＭＳ Ｐ明朝御大がファンブル召喚される。

今、このサイトでは本文のフォントにOpen Sansを使っているので、ばっちりこのバグを踏んでる……。どうにかしてあげたいところだけどどうにもならないのでバグレポートだけした。適切にフォールバックされないというのは非常に困るので今すぐたちどころに直ってほしい。

• t.coがクソでサイト名が勝手にt.coされるのでサイト名変えたい
• Death Cab for Cutieは大好きなバンドなんだけど、聴いてもテンションはまったく上がらないどころか下がる
• 単純な好き嫌いが批判にとらえられてしまうインターネット
• 全てが過剰
• 好きなマンガが載っている雑誌に必ず死ぬほど嫌いなマンガが載ってて読むのが辛い
• マンガ雑誌をカスタマイズしたい
• Pinterestへのマーケッターの群がり方が尋常じゃなくて、使ってると恥ずかしい感じになりつつある気がする
• AKB48とかの画像集めはGoogle+でやれ
• 考えると常に何らかのソーシャル・メディアに翻弄されてて死にたい
• インターネットで死にたい
• この言葉が気に入ったんけど、どういう文脈で考えだしたのか思い出せない
• Who to followに9割以上の確率で@davewinerのアイコンが出てくる
• まとめられたくない
• はてなスターがつかなくなって朝9時が辛い
• Jekyll(やblosxom)はフラット・ファイルだから良いのではなくて、お気に入りのエディターでエントリーを扱えるのが良いだけだと思う
• DropBoxに置いたテキスト・ファイルをDBにガシガシつっこんでサクサク表示してくれるツールとかのが良さそう
• 全エントリをずらっと並べたページ作りたいので作る

あー。

さすがに3ヶ月ハイペースでエントリ書いてると頭おかしくなってくる。