Codekitを使ってみたら超絶便利だった件。

最近CSSメタ言語を使用している人が増えていると思いますが、コンパイルする環境を整えるのが面倒だったり苦手で手を出してない人も多いのではないでしょうか?

SassだとRubyを入れて、Stylusだとnode.jsを入れて、、など環境整えるのって僕も苦手です。

そこでMac Lion以降のみ対応ですが、Codekitというアプリが超絶便利すぎるので使い方をまとめてみました。

ブログを書いている時点でのCodekitのバージョンはVersion 1.0 (6010)

Codekit

コンパイルできるファイル

  • less
  • sass/scss
  • stylus
  • haml
  • jade
  • javascript
  • coffee script

これだけの言語?をコンパイルすることができます。とりあえず入れとけ!って感じの対応数です。

ブラウザの自動リロード

これだけの為に入れてもいいくらい便利な機能です。対象ファイルが変更されると自動でSafariかChromeで開いている該当ページで変更のあったファイルをリロードしてくれます。

CSSやJSの場合は読み込んでいるファイルのみリロードしてくれるので無駄な待ち時間も発生しません!

guard-livereloadを使って同じことをしてましたが、こちらの方が簡単でいいです。

コンパイルでデバッグ!

当たり前なのかもしれませんが、Sass/Less/Stylusなどコンパイル時にエラーがあれば分かりやすく表示してくれます。

コンパイルしないJSやCSSのも監視対象に入れておけば、ファイル変更時にエラーがあれば表示してくれます。
オプションでデバッグ内容をある程度細かく指定出来たり、使っているライブラリを選ぶとそのライブラリの記述用のデバッグもしてくれるみたい。

いろいろオプションがあるので把握しきれてないですが、GUIが分かりやすいのでちょっと使えばすぐ覚えそうな感じです。

コンパイルオプションで圧縮

sassやらlessやら使っている人にはおなじみかと思いますが、コンパイル時に圧縮するかどうかもチェックボックス一つで選ぶことができます。

圧縮もファイルによって選べる内容が違うので好みに設定しておくといいかもです。

まとめ

ざっくりまとめてみましたが、めちゃくちゃ便利です。

今のところベータ版なのでフリーで使うことができますが、シェアになっても間違いなく買っちゃいますね。

似たようなアプリにLiveReloadというのもありましたが、シェアウェアで試用も出来ないのが残念。。。

余談ですが、FAQのここが個人的にツボでした。

I’m on Windows. What do you recommend I use to work with Less/Sass/CoffeeScript, etc?

A Mac.

Codekitを使ってみたら超絶便利だった件。

input type=fileの使用可否判定

html5のfile apiを使えば、ローカルに保存されてる画像などのファイルへアクセスする事が出来ますが、現時点でのiOSではhtml5のinput type=”file”が使えないので画像をアップする、みたいなUIが提供出来ない。

で、input type=”file”が使えるかどうかの判定を使用として、ちょっぴり躓いたのでメモ。

最初に、file apiが使えるかどうかで判別しようとしてみた。

if(window.file){
 alert('hoge')
}

が、iOSでもwindow.fileはtrueが返ってきたのでこれだと駄目。。。

なんやかんやで、input type=fileの要素をhtml上に隠しておいておいて、disabledかどうかで判定を行うとうまくいった。

var check = document.getElementById('test').disabled;
alert(check)
<input type="file">

iOSではinput type=fileのUIはdisabledの状態になっていて、htmlのコードが下記のようになっている。

<input type="file" disabled="">

なので、getAttributeなどで属性値を参照しようとすると空文字が返ってくるが、プロパティにアクセスすれば適切な値が返ってくるみたい。

なんか他にいい方法があるのかなぁ、、、

input type=fileの使用可否判定

Androidのposition:fixed;とz-indexのバグ?

Android2.2以降のブラウザでは、position:fixed;が使えるのですが、かぶさった下の要素がクリッカブルな場合、z-indexを無視して下の要素が反応してしまうという腐ったバグにハマったのでメモ。

※確認はAndroidの標準ブラウザで

念のため、下になる要素をいろいろ用意して、absoluteとfixedで比較をしてみました。

検証端末

  • IS03(OS2.1)
  • IS06(OS2.3.3)
  • GARAXY S(OS2.2)
  • 007SH(OS2.)

同端末、OSのバージョン別は調べてません。

IS03はfixedで下の要素は全く反応しなかった。

結果

absolute fixed
a (inline) 枠・バイブ
a (block) 枠・バイブ
input type=text
input type=button バイブ
input type=submit バイブ
button (inline) バイブ
button (block) バイブ
select 枠・バイブ・選択box表示
label (inline) 対象要素に枠&フォーカス
(IS03のみ)
label (block) 対象要素に枠
onclick 枠・バイブ 枠・バイブ

あまり多くの端末ではみてませんが、端末による差もあるようです。。

fixedだけかと思ったら、absoluteで重なっている場合のclickも反応してました。
というよりも、ここで挙げてない端末ではabsoluteでもリンクにフォーカスがされてしまうようです。

回避策

cssのtap-highlight-colorで枠線をとったとしても、バイブが反応するためよろしくない。
また、select要素に限っては選択ボックスがちゃんと出てきちゃう始末。

javascriptでフォーカスがあたっららprevent.defaultとかしてみましたが、そもそもフォーカスのイベントが発火されてない。。。
どうしようかと思ったら、同じ悩みを無理矢理回避していらっしゃる方の記事があったので、こういう形で対応するしかないですかね。。

Android のブラウザのフォーカスが z-index を無視しているバグがなおらない

Androidのposition:fixed;とz-indexのバグ?