続:CSSフレームワークGumbyとFoundationを触ってみた

意外にも続報が早めに書けました。といってもGridとRetina Imagesの2つについてぐらいだけれども。

1. Gridなど

基本的なGridの作り方は、rowの中にcolumnsを突っ込む感じでほぼ同じ。

Gumbyの場合
http://foundation.zurb.com/docs/components/grid.html

小さい画面になると基本的に全カラムが全幅になる感じ。
カラム数が12と14とか、混在させたりも出来るけれど使うところあるのかな・・・。

画像とテキストの組み合わせだと、

Vertical Alignment
http://gumbyframework.com/docs/components/#!/vertical-alignment

を使うと小さい画面でも綺麗に並ぶ。(ずらっと並べるタイル表示は別に方法がある)

あとは

FitText
http://gumbyframework.com/docs/extensions/#!/fittext

というのもあって、画面サイズによってフォントサイズを変えることも可能。

・・・細かいのは自分で作れ、というかそういうデザインには合わないのかな。確かに余程のことがないと小さい画面でグリッド分けるのは避けるべきだなあと思うのでこれで良いのかもしれない。そこがいい感じに見えるキモかもしれない。・・・もしかしたら他に方法があるかも知れないけれど、多分そんな感じ。

Foundationの場合
http://foundation.zurb.com/docs/components/grid.html

画面サイズをSmall、Medium、Largeの3段階で表示するカラム数を選べる。
前の記事にGumbyのMixinのことを書いたけれど、やっぱりFoundationにもたくさんMixinが用意されていてCSS内で完結することも出来そう。
・・・やれることが多すぎて書くことがありません。

2. Retina Images

(予めRetina用の画像を用意して@2xつけて保存しておく。)

Gumbyの場合
http://gumbyframework.com/docs/components/#!/retina-images

retina用の画像を同じフォルダに入れてgumby-retinaて書くだけ。

<img src="/images/logo.png" gumby-retina />

シンプルで便利なんだけどバリデーションしたら無論怒られる。(Gumbyはバリデーションで怒られる前提で使う勇気が必要だ。)

Foundationの場合
http://foundation.zurb.com/docs/components/interchange.html#using-retina-images

Foundationは独自データ属性のdata-interchangeで画像の切り替えを扱っていてretina対応も含まれているらしい。

<img src="/images/logo.png" data-interchange="[/images/logo@2x.png, (retina)]">

という感じかな。(ちゃんと実機で検証してない)

以下のフォーラムも参照するとよさげ。

Images, Interchange, and small Retina devices | Foundation Forum from ZURB
http://foundation.zurb.com/forum/posts/2594-images-interchange-and-small-retina-devices

感想など

・・・どちらも公式サイトをバリデーションするとちょっと残念な感じなんですが、最近はそういうものなのでしょうか。

Gumbyは「オレサマコード!どうだロックだろ!」みたいなイメージかなあ。ソースドーンと落としてぱっぱっと書き換えればいい感じなのがするっと出来る感じ。でもバリデに怒られる。嫌いじゃないというかむしろ好きだけれど、受託案件で使う気はしないです。でも、JSのライブラリとか色々とぱく・・・参考になりまくるソースがあるので美味しくいただきたいと思います。

Toggles & Switches
http://gumbyframework.com/docs/components/#!/toggles-switches

とか

Parallax
http://gumbyframework.com/docs/extensions/#!/parallax

とか美味しそうです。

Foundationは、さすが企業が作ってるって感じで痒いところに手が届く。デザインテンプレートも豊富でまだまだ成長する感じだから、ある程度時間をかけて勉強してもいいと思う。でも頼りすぎると自分がダメになる気がします。

Off Canvas
http://foundation.zurb.com/docs/components/offcanvas.html

ていうサイドバーのオンオフが出来るやつも入ってて便利です。

・・・で、私としてはHTML5 BoilerplateにFoundationをのっけて、Gumbyのエッセンスを所々に使う、のが良さそう。かなー。

CSSフレームワークGumbyとFoundationを触ってみた

第二子出産してる間に、こういうのをCSSフレームワークと呼ぶようになったんですね。CSSのフレームワークにしてはCSS以外の要素が多過ぎる気がしなくもない・・・。
まあどんなフレームワークも、実際に使うかどうか分からなくても、ちょっと触ってみるだけで有益なtipsが沢山得られるので少しだけでも触ってみるのが良いと思っています。
・・・とはいえ時間に限りもあるので、2つに絞って触ってみました。

Bootstrapより癖がない、との評が多い

Foundation
http://foundation.zurb.com/

と、カスタム前提で作られているという

Gumby
http://gumbyframework.com/

です。
それぞれ私目線で比べながら触ってみました。

1.ダウンロードとインストール

Gumbyはダウンロードボタンを押すと、ごっそり一式ダウンロードできてSassファイルも入っているのであとはCodekit(2が出てますね!まだチェックしてない!)に読み込ませるだけで良いのが気楽。

FoundationはSassを使いたければ、

Getting Started With Sass
http://foundation.zurb.com/docs/sass.html

に従ってコマンドラインでゴソゴソする必要があります。といっても数行なのですぐ終わります。

2. 基本の設定(CSS)

Gumbyはダウンロードする前に

Customize
http://gumbyframework.com/customize

でカスタマイズをしてからダウンロード出来ますが、どうせダウンロードしてからも弄るので

/sass/var/_settings.scss

の設定ファイルに慣れるのが早い気がします。

// Welcome to Gumby 2.0 Settings.
// Happy Tinkering!

// Grid Settings
$row-max-width: 940px !default;    				// 940px
$gutter-in-px: 20px !default;      				// 20px
$cols: 12 !default;              				// 12 Column Default Grid
$hybrid: 16 !default;							// 16 Column Default Hybrid Grid

// Responsiveness Settings
$min-device-width: 320px; 						// iPhone Portrait
$tablet-device-width: 768px;					// iPad Portrait
$document-width: $row-max-width;				// Default Document
$max-device-width: 2880px;						// Max Document Size

みたいな設定値がずらっとあるので該当箇所をいじってみると

css/style.css

に書きだされて

ui.html

に反映されるのでわかりやすいです。

Foundationも同じく、サイト上でカスタムしてからダウンロードできますが、
Sassで使う場合には上に書いた方法でインストールすると、

/scss/_settings.scss

というファイルがあってコメントを読みつつ必要な箇所をコメントアウトしてカスタムしていく感じです。すると

css/app.css

に圧縮して書き出されます。

・・・うーん、最初から圧縮して書き出すのはどうなの?最終的には圧縮するかも知れないけれども。
GumbyはConfig.rbすぐ見つかるから良いけれど、・・・!

とか思ったら私FoundationのほうをGrunt + Libsassとやらのほうで作ってたのでした。
ちゃんと読んで無いのバレバレだ・・・。

えーと、Compassのほうで作ると、
Sassファイル弄る前は該当のCSSは書き出されておらず、設定すると、

stylesheets/app.css

というファイルが生成されます。
しかもちゃんと圧縮されずに。。。

index.html

が反映先ですが、全部のパーツが見たかったら、

Kitchen sink
http://foundation.zurb.com/docs/components/kitchen_sink.html

をDLしてみるのが良いのかな。

3. HTMLとブラウザ対応

どちらも配布ソースでは、HTML5ながらdivタグのみ。

Gumbyはpaulirish.comのhtmlタグハックが付いてるけれど、

http://gumbyframework.com/docs/#!/browser-compatibility

IE8以上ということになってます。

Foundationはhtmlタグはまっさらながら

http://foundation.zurb.com/docs/v/2.2.1/qa.php

をみるとIE7以上なのかな。
でもどうやって個別対応するんだろうか・・・。

あと、GumbyにはSemantic Gridという手法もあって、
Sassのmixinを使ってCSS内で完結する感じが素敵。
(Foundationでもsectionなんかのタグは使えるけれど、classとかidとかは残念な感じのまま。)

・・・って書いてみたものの、2つともドキュメントが膨大過ぎて機能の半分も把握出来てない気が。
やっぱりもうちょっと実際の開発作業に突っ込んでみないと分からないので、いつ出るかわからない続報にご期待ください・・・。

CompassでSprite画像の書き出しをちょこっとカスタマイズ

Compassの大きな魅力のひとつ、Sprite画像の書き出し。
凄く素敵な機能ですが、
画像名からclass名が自動生成されちゃうのとかちょっとイヤなので、
もう少し私好みに出力してもらうためのカスタマイズ。

sprite/ 以下に対象のpng画像を入れておきます。
ここではimg_a.png、img_b.png、img_a_hover.png、img_b_hover.png、の4ファイルが入っている想定です。

$sprites: sprite-map("sprite/*.png");
$sprites-img:sprite-url($sprites);
@mixin sprite-background($name) {
 	height: image-height(sprite-file($sprites, $name));
 	width: image-width(sprite-file($sprites, $name));
 	background-position: sprite-position($sprites, $name);
}
@mixin sprite-background-pos($name) {
 	background-position: sprite-position($sprites, $name);
}

とmixinを書いて、
お目当てのところに

a {
    display: block;
    background-image: $sprites-img;
    &.class_a {
        @include sprite-background(img_a);
        &:hover {
            @include sprite-background-pos(img_a_hover);
        }
    }
    &.class_b {
        @include sprite-background(img_b);
        &:hover {
            @include sprite-background-pos(img_b_hover);
        }
    }
}

という感じに指定。
高さや幅も一定だったら、それもmixinに入れずに書くのが良いかも。

参照:

CSS Sprite Helpers for Compass | Compass Documentation
Compassでスプライト画象を高速に書き出す方法[to-R]

CakePHP2.xとPHP5.4でStrict Errorが出た場合の対処法

PHPでは、error_reportingの設定により出力するメッセージを変更可能ですが、PHP5.4からE_ALLにE_STRICTが含まれるようになりました。
通常、E_ALLからE_STRICTを除いてエラーを出力したい場合、php.iniで

error_reporting = E_ALL & ~E_STRICT

とすることで制御可能になります。
エラーレベルについては、マニュアル参照
http://www.php.net/manual/ja/errorfunc.constants.php

但し、CakePHPでは、フレームワーク中でerror_reportingを定義している為、php.iniの設定が反映されません。

その設定が、
cakephp/lib/Cake/bootstrap.php

error_reporting(E_ALL & ~E_DEPRECATED);

で設定されています。

但し、これはフレームワーク本体のプログラムですので、ここを修正すべきではありません。

Cake 2.x では Error コンフィギュレーションが設定ファイルで定義出来るようになりましたので、これを利用します。
cakephp/app/Config/core.php

Configure::write('Error', array(
   'handler' => 'ErrorHandler::handleError',
   'level' => E_ALL & ~E_DEPRECATED,
   'trace' => true
 ));

のlevel部分に~E_STRICTを追加します。

Configure::write('Error', array(
   'handler' => 'ErrorHandler::handleError',
   'level' => E_ALL & ~E_DEPRECATED & ~E_STRICT,
   'trace' => true
 ));

これで、E_Strictのエラーが表示されなくなります。

尚、error_reportingは、PHP5以降で下記の様に変わっています。

バージョン 説明
5.4.0 E_STRICT が E_ALL に含まれるようになりました。
5.3.0 E_DEPRECATED と E_USER_DEPRECATED が追加されました。
5.2.0 E_RECOVERABLE_ERROR が追加されました。
5.0.0 E_STRICT が追加されました (これは E_ALL には含まれません)。

エラー処理なんて、そんなに変わる所でもないと思うのですが。。。メジャーバージョンアップ毎に変わっていくのがPHPらしいですね。

MacにSass、Compass、CodeKitを導入する

codekit_logo

Sassは知っていたけれど、
いちいちコンパイルするほど大規模サイトやらないし、と思って使っていませんでしたが。
そんなついつい黒い画面を避けちゃうあなたに朗報、
CodeKitの存在を知って早速(っていうか今頃)導入してみました。

導入の流れをおさらいします。

0. そもそも何それ?

SassはCSSの入力を構造的にし、変数などを使ってより書きやすくしてくれるツールです。
Rubyで出来ていますが、Rubyを知らなくても使えます。
CompassはSassを拡張し、より便利にしてくれるツールです。

というわけでWebのフロントをやる人にはとてもステキなツールなのですが、
いかんせんコマンドラインベースなので

Sassのファイルを書く→保存する→コンパイルする→ブラウザで見る

という流れが

CSSを修正→Codaで即確認

という流れよりもどうしても助長に感じてしまう
小規模サイト開発者(私)のような人にはあんまり踏み込む意義を見いだせずにおりました。
書いたらすぐ確認したくなっちゃう人なんです、私。

が、CodeKitのお陰で、
コンパイルする、という作業が必要なくなったのです、わーいわーい!
その他、CodeKitの凄さについてはこちらの記事が秀逸です。

Web制作者の覚醒剤CodeKitでマンモスうれぴー(はぁと | WP-D

Sassだけじゃなくて、これはもう次世代のWEBフロントエンド開発に不可欠になりそうな感じ。
というわけで、

1. インストール

macにはrubyが入っているので、ターミナルなどで

sudo gem install sass

sudo gem install compass

をしてそれぞれをインストール。

CodeKitは公式サイトから入手してタブルクリックする(そしてApplicationフォルダに移す)。

簡単ですねー。

2. 動かしてみる

CodeKitをたちあげて、監視してもらいたいプロジェクトフォルダをドラック&ドロップ。
Sassを使うだけなら、これだけでOK。

Compassを使うには、使いたいプロジェクトのポップアップメニューからCompassを選んで
Use Compass for this projectを選択。

コマンドラインから何もしてなければ、No Configuration File っていうポップアップ画面が出るので、
Install Compass をクリック。すると、
Install Compass In Project という設定画面が出るので、
それぞれのフォルダ名や書き出し方法を設定して、Add Compass To Projectをクリックする。

(Compassの使い方がまだ良くわかっていなくて、ieやらprintやらscreenやらとCSSを分けて出力されちゃうのを何とかしたいところ)

そうすると、フォルダ直下にconfig.rbという設定ファイルが出来るのでそれを直接編集することもできます。

3. CSSを書きだしてみよう

Coda2はLessもSassも対応しているのですぐ書けます。
デフォルトではsassというフォルダにSass(拡張子は.scss)ファイルが入っているので、
それを開いて編集(書き方は以下参照)し、保存するとすぐにCSSファイルが生成されます。

Growlを入れていたら、コンパイルに成功したよ(もしくは失敗したよ)とお知らせまで出ます。

エラーログを吐いてくれるのが何ともステキです。惚れます。

Compassについては、

An introduction to Compass from Lorin Tackett on Vimeo.

これを参照に書き始めてみましょう。

日本語ですとココがわかり易かったです。

CSS書くならCompass使った方がいいよ。SASS使ってる人なら特に。 | howtohp

その前にSassの書き方っていう人はこちらなどを。

【Sassを覚えよう!Vol.4】Sassの基本的な記述方法 – CSS HappyLife

というわけで、私のCSSライフがかんなり快適になりました。
Macさいこー。って気分になりますね。

YouTubeをJavaScriptで制御する(iframe 埋め込み式)

自作のスライダーに入れ込んだYouTube動画がクリックされたときに自動スライドを止めたい、ということがあったのでメモ。
まあ、最初から仕様が決まっていれば動画対応のスライダーを使うところですが。

がっつりYoutubeプレイヤーをJavascriptで作りたいんじゃなくて、
ちょっと止めたいだけだったんだけれど、公式読んでもすぐに分からなくて困ったのでメモ。

//youtube player
var tag = document.createElement('script');
tag.src = "https://www.youtube.com/iframe_api";
var firstScriptTag = document.getElementsByTagName('script')[0];
firstScriptTag.parentNode.insertBefore(tag, firstScriptTag);
var player;
function onYouTubeIframeAPIReady() {
  player = new YT.Player('player', {
    height: '表示したい高さ',
    width: '幅',
    videoId: '表示したい動画のID',
    playerVars: {
        rel: "0"
    },
    events: {
      'onStateChange': onPlayerStateChange
    }
  });
}
var slide_stop = false;
function onPlayerStateChange(event) {
  if (event.data == YT.PlayerState.PLAYING) {
    slide_stop = true;
  }
}

として、slide_stopをフラグにしてスライダーの動きを制御しました。

参照:
YouTube Player API Reference for iframe Embeds – YouTube — Google Developers
https://developers.google.com/youtube/iframe_api_reference?hl=ja

Google Japan Developer Relations Blog: iframe 埋め込み式 YouTube Player 向け JavaScript Player API のご紹介
http://googledevjp.blogspot.com/2011/01/iframe-youtube-player-javascript-player.html

WORDPRESSのDBをローカルに落とした時に変更する箇所

wordpressのDBを本番サーバーからコピーしてローカルに突っ込んでテストする、ということがありますが、
そのままだとローカルのwordpressではなく本番サーバーのwordpressにログインしてしまうので
2箇所ほどDBを弄る必要があります。

とっても簡単で、テーブル名「wp_options」の「home」と「siteurl」を本番のURLからローカルのURLへと書き換えるだけ。

なんだけれど、忘れやすいのでメモ。