レスポンシブ・タイポグラフィーなど
ウィンドウや画面のサイズに合わせて文字の大きさを自動的に変更するテクニックは、俗にレスポンシブ・タイポグラフィーまたはフルイド・タイプと呼ばれている。当初は僕も良いアイディアだと思い多用していたが、重要なのはビューポートの大きさではなくデバイスとの距離だろうと思い直したためもうほとんど使うことはない。当初から嫌いといっていた人はこの辺にしっかりとした意識があったのだろう。 使うことをやめた理由は、単純に技術的制約によってユーザーとデバイスの距離を知るすべがないからに過ぎない。レスポンシブ・タイポグラフィーが目指す、適切な文字の大きさを環境ごとに提示することそのものについては正しい考え方であると思う。ただ今利用されている「ビューポートが768px以下なら文字を小さめにする」というようなアバウトな実装だと問題がある。もちろんvw単位を使ったフォント・サイズ指定でも同じだ。 なぜならばデスクトッ
minimist - Weblog - Hail2u.net
Node.jsでCLIツールを作る時に使えるコマンドライン・オプションのパーサーとしてminimistをよく使うようになった。なかなかの好感触。同様のものとしてoptimistやその後継のyargsが有名で、しっかりと作るならそっちの方がよく出来ているけど、数個のオプションの切り替えと余りの抽出くらいならminimistの方が楽。 インストールしたら以下のようにパースしたいコマンドライン・オプションの配列を渡すと、良きに計らってくれたオブジェクトが返ってくるので、それを使うことになる。 #!/usr/bin/env node 'use strict'; var minimist = require('minimist'); var argv = minimist(process.argv.alice(2), { string: ['output'], boolean: [ 'sourcem
max-widthを否定するクエリー
モバイル・ファーストが浸透して久しくなり、めっきりmin-widthクエリー以外を見かけることはなくなった。そんな中、not (max-width: 768px)という書き方を見かけて、なるほどなと思った。現状のブラウザーにおける実装(と安定した仕様)では768pxを含まずそれより大きいという表現がmin-widthでは書くことができないが、notキーワードとmax-widthを組み合わせることで実現できる。 Demo: Negation of max-width query 特定のデバイスや解像度を強く意識したクエリーの是非はとりあえず脇へ置いておいて、iPhone 5s以下やらiPad Airやら一般的なノートブックやらを意識してクエリーを書くことはままある。多くの場合はそれら特定のデバイスのサイズからを区切りにしてクエリーを書くわけだが、それらのサイズまでで書くとなると少し曖昧な記述
git grepをVimで使う
Gitのgrepサブコマンドは通常Gitリポジトリーでしか使えない。しかし--no-indexオプションを付けると、Gitリポジトリーではないディレクトリーでも検索できる(もちろんGitリポジトリーでも)。Vimからももちろん使えるので、ackちょっと遅い、ag入れるのが面倒くさい、MSYS上で使ってるとjvgrepの出力が稀におかしい、などの理由でgrepに戻ったりしてる人はgit grepを使うのも良さそう。 set grepprg=git\ grep\ --no-index\ -I\ --line-number grepformatを編集しないで済ませるためには--line-numberオプションを追加して、行番号を表示させる必要がある。僕はバイナリ・ファイルを無視する-Iオプションも合わせて追加しておいた。パフォーマンスをあげるために--no-colorオプションを付けるのも良さそ
Vimのrenderoptionsオプション
最近のKaoriYa版のWindows向けgVimではどうやらrenderoptionsオプションを適切に設定すると、DirectWriteを使った描画に切り替えられるようだ。一年ほど前からパッチとして含められるようになっていたらしい。 有効にしただけではあまり劇的な効果を上げることは出来ないようだけど、追加で細かく設定を行える。例えば上のスクリーンショットのようにブワッとアンチエイリアスをかけたい場合は~/vimfiles/gvimrcなどで以下のようにすれば良い。 set encoding=utf-8 if has('win32') set guifont=MigMix_1M:h12 set renderoptions=type:directx,renmode:5 endif わかりやすそうなのでMigMix 1Mを例にした。デフォルトのGDI下では、上のスクリーンショットの様に特に縦
rsyncをGit for Windowsに混ぜる
Windowsでrsyncをインストールする方法はいくつかあって、一番簡単なのはmingw-getでパッケージとして導入する方法。またはrsyncは諦めてChococaltely経由でcwRsyncパッケージをインストールするのが簡単。両者ともrsyncのためだけに入れるには大仰なので、既に導入されているGit for WindowsにMinGWパッケージと手作業で混ぜてインストールするのも悪くない。 必要な物は以下の4つの実行ファイルとDLLファイル。 rsync.exe(rsync-*-bin.tar.lzma より) msys-iconv-2.dll (libiconv-*-dll-2.tar.lzma) msys-intl-8.dll (libintl-*-dll-8.tar.lzma) msys-popt-0.dll (libpopt-*-dll-0.tar.lzma) それぞれ
mit-license.org
Open Source InitiativeのMITライセンスのページのURLを使ってMITライセンスと明示している人は結構多いと思います。ライセンス全文コピペするの面倒ですしね……。ただその場合は権利者の名前等を予め書き、ライセンス条項については以下のURLを参照……などと注意書きも含めた方が無難です。そういうのを「忘れるし！ 面倒だし！」と思ったRemy Sharpがmit-license.orgというウェブサービスを作ってくれました。 登録するとユーザー名をサブドメインとしたURLが確保されます。例えば僕の場合はhail2u.mit-license.orgです。このページを見るとわかるように権利者の名前と発行年、オプションとしてWebサイトのURLにリンクを張れたりもします。 curlでJSONを送りつけるという方法でも登録できるみたいですが、JSONファイルの登録とバッティングした
CSSポストプロセッサー時代の到来
SassやLESSといったCSSプリプロセッサーは市民権を得たと言って良いと思う。しかしそれらCSSプリプロセッサーは開発という段階にのみ利をもたらすもので、今のところはそれ以上ではない。CSSを実際にユーザーに届けるまでには、開発だけではなくレビューとリリースという段階もある。レビューとリリースも確実性を持って効率的に行うためには、CSSポストプロセッサーと総称されるようなツール群が必要になるだろう。 この文書はFrontrend Advent Calendar 2013の4日目への記事として寄稿した。明日は@hilokiさんがスタコラサッサと書くようだ。 目次 CSSポストプロセッサーとは CSSプリプロセッサーの出力するCSS CSS Lint 開発用とレビュー用、リリース用のCSS CSSポストプロセッサーのユースケース ベンダー拡張プリフィックスの付加 Media Queries
ファビコン・カンニング・ペーパー
Translation of: favicon-cheat-sheet ファビコンのサイズや形式についての読むと頭が痛くなる偏執的なカンニング・ペーパーです。以下のURLを参考にしました: rel="shortcut icon" considered harmful · Mathias Bynens <-- special thanks @mathiasbynens Everything you always wanted to know about touch icons · Mathias Bynens <-- special thanks @mathiasbynens Jonathan T. Neal | Understand the Favicon Favicon - Wikipedia, the free encyclopedia Making a Good Favicon -
フォントの読み込み完了を検知する
TypeKitとかがやってるWebフォントの読み込みが終わったらhtml要素にクラス名を振るアレの話。TypeKitがオープンソースでリリースしているWebFont Loaderを使う方法が安全で安定。Googleがホスティングしているのもあるので手軽でもある。でも読み込み完了の検知以外にも機能があってパワフルすぎる気がするので、Adobe Blankを使って自前で書いてみることにした。 Adobe Blankのサイズ削減 Adobe Blankはそのまま使うと30KB以上ある。読み込み完了検知だけなら幅0のグリフが1つあればそれで良いので、まずはサブセット化してサイズを抑えることから。aだけのWOFFなAdobe Blankを作ればちょうど1KBくらいになる。 Download: adobe-blank.woff @font-face定義の追加 外部リクエストにすると意味が薄れるのでDa
Hashbang(#!)なURLの恐怖
諸方面からお叱りの言葉しかいただけない#!なURLは様々な問題をはらんでいますが、来るべき未来(もうすぐですよ！)におけるメンテナンス性という問題についてAdactioで取り上げられていました。#!の表面的な凶悪さに思考停止していて、こういった本質的な問題についてはまったく考えていなかった気がします。 その問題というのは、#!なURLからHistory APIなどを利用してクリーンなURLに乗り換えよう(戻そう)としても、古い#!なURLを有効なままにするためにはサーバー側の何か(単純なリダイレクトやmod_rewriteなど)ではどうしようもないので、クライアント側での(JavaScriptを利用した)リダイレクトを提供する機能を提供し続けなければならないというメンテナンス性の悪さです。 この#!なURLのメンテナンス性の悪さという問題は、URLの#以降はクライアント側の扱いなので、クラ
Media Queriesではemを使おう！
v6.15とかでちょっとem単位を使うようにした話を書いた。そこで書いたのは「描画領域に収まるレイアウト」ではなくて「文章の収まりを意識したレイアウト」にしたかったとかそういう話だった。id:vantとかu:studiomohawkなどがブックマークしてたThe EMs have it: Proportional Media Queries FTW!ではもうひとつのem単位を使うメリット、Media Queriesでem単位を使うとユーザーのズーム(スケーリング)に対応できる点を解説していた。 em単位をMedia Queriesで使うとpx単位と違いユーザーのズームが考慮されて計算される(ただしウィンドウサイズを変更した時などとは違い即座に反映されるわけではないのでリロードが必要)。1emが16pxな環境で200%にズームしていると1emが32px相当になり、それを基準にMedia Qu
Sassの存在意義への補足
Sassの存在意義の話があんまりうまく伝わってない感じなので、3の別々に書けてSassで関連付けられるということについて少しだけ書く。抽象的な概念の話なので具体的な説明というのもなかなか難しいけど、CSSフレームワークを使う時にどうなるかみたいなことを取り上げる。 Twitter Bootstrapを始めCSSフレームワークはいくつもあるが、それらはだいたいユニークなクラス名を持っている。例えばTwitter Bootstrapで2カラムレイアウトを作る場合は以下のようなHTMLにしなくてはならない。 <div class="row"> <div class="span4">...</div> <div class="span8">...</div> </div> div要素はsectionやaside要素などを使っても良いが、クラス名はこうでなくてはならない。Sass (やLESS)があ
git logを見やすく
git log --graph --onelineをメインに使っていたんだけど、現在時刻に対する相対的な時刻とかコミッターの名前とか表示したくなったので色々いじってた。%C(white bold blue)とかでターミナルの色を参照して文字色と背景色を指定することができるということを理解するまでが長かった……。 上記スクリーンショットのようなgit logは以下のようなコマンドで実現できる。 $ git log --graph --pretty='format:%C(yellow)%h%Cblue%d%Creset %s %C(black bold)%an, %ar%Creset' %dで参照名(ブランチやタグ、リモートブランチ)を、%anでコミッターの名前を、%arでコミットの相対的な日付を表示するようにして、%Cで色を変えている。%Credと%Cblue、%Cgreen以外を使う場合は
vim-css3-syntax v0.3
@hokacchaから@mediaブロック内でのクラス名のハイライトがうまくいっていないバグの修正を貰ったのでそれを反映させ、他いくつか漏れていたCSS3モジュールへの対応を行い、vim-css3-syntaxを0.3にした。 ついでにREADMEにHTMLやSCSSでのCSSの構文強調にも反映させる方法も書いておいた。Media Queriesだけコメントアウトしているのはネストの表現がまずくて、ハイライトが吹っ飛ぶことがあるので。 ベンダー拡張プリフィックスへの対応とかも貰ったが、メンテナンスが大変そうだし、変わったものはともかく消えたものをどうするか考えるのも面倒くさいので、今のところ対応する気はない。-webkitなどの部分だけを強調する仕組みを考えてみようかと思っているが、Vimのシンタックス・プラグインを書くスキルが低すぎて目鼻がつかない。そもそもそれじゃシンタックス・ハイライ
Google ChromeでＭＳ ＰゴシックをArial+メイリオに置換する
最近のブラウザではWebフォントの利用を可能にする@font-faceをサポートしており、使われているサイトもよく見かけるようになった。@font-faceはWebフォントの利用に限らず、ローカルのフォントの再定義にも使えるので、ユーザースタイルシートで利用すればＭＳ Ｐゴシックをメイリオに置換することが出来る(Chromeでも)。これに留まらず@font-faceデスクリプターのunicode-rangeプロパティを利用すれば、英数字はArialで日本語部分はメイリオで置換するなどというわがままなことが出来る。 unicode-rangeプロパティはグリフのコードを範囲指定することによってsrcプロパティで指定されているフォントのどの部分を利用するかを決定するもの。つまりArialから英数字(PDF: Basic Latinと呼ばれる範囲)を取ってきてＭＳ Ｐゴシックを置換する場合はGo
VimのCSS3シンタックス・ファイルみたいな何か
VimでCSSを書いていると、最近のCSS3プロパティでもやもやした感じになるのはまぁしょうがないかな……と見ないふりをしていた。が、@mediaでブロックを作った時に最初のセレクタのハイライトに失敗するのとかにムキーとなって、もうこれは駄目だと思ったので、既存のCSSシンタックス・ファイルをCSS3に対応させた感じにする追加シンタックス・ファイルを作成した。はじめてのVimシンタックスファイル(もどき)。 Media Queriesでブロック化した時に以下のような感じで最初の行のハイライトが失敗する。 最初のセレクタだけなのだけど、どうも落ち着かない。これを、 とMedia Queriesの条件式も含めてちゃんとハイライトされるようにする。 他はHTML5の新しい要素やCSS3のプロパティや、値のキーワード、calc()やhsla?()などの関数などになんとなく対応させただけ。確認は十分
CSSでアイコンをデザイン
ものすごく大雑把に言うと今まで画像編集ソフトでやっていた、角を丸くするとか背景をグラデーションにするなどという作業をCSSでやってしまおうというお話。もちろんCSSでできないことは多くあるので万能というわけではないが、できることに限って言えば数行のCSSコードでスクリーンショットのような効果を柔軟に適用することができる。 Demo: Design icon with CSS ul li a { display: block; width: 32px; height: 32px; background-image: url("icons-w.png"); background-repeat: no-repeat; text-indent: -10000px; } 各アイコンになるa要素へのスタイルは以上のような単純なものがベースになる。icons-w.pngがアイコンの前景をつなげたスプライ
枠線付きの吹き出し
ミニブログの隆盛以降ウェブ上でよく見かける吹き出しをCSSで作るお話。単色のものはかなり前に書いた。今回はそれに枠線をつけてみよう！ みよう！ みよう！ Demo: Bordered Speech Bubble 枠線は単なるsolidなborderで少し角を丸めただけ。 尻尾を付ける :before擬似要素を使う。デモの3番目のサンプルのように、まず枠線と同じ色で三角形を作る。三角形は以前のエントリで書いた手法と同じで、左右のborderをtransparentにすることによって作る。 .speech-bubble:before { border-top-width: 16px; border-right-width: 16px; border-bottom-width: 0; border-left-width: 16px; border-color: #369 transparent;
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
git push --delete