ReworkとPostCSS
AutoprefixerやMyth経由で話題になったRework。そしてAutoprefixerが乗り換えたPostCSS。両者はどのようなことに主眼を置いているライブラリなのか、SassやLESSとの関係はどうなのか、そしてどのようなツールを書く時にそれらを使うべきなのだろうか。 ReworkはCSSをプリプロセスするためのライブラリということになっている。サポートされているかどうかよくわからない最先端の標準仕様のドラフトに従って書かれたCSSをブラウザーがちゃんと解釈できるようにするとか、特殊な記法を展開するとか、だ。こういった現実世界ではうまく動かないCSSをプリプロセスしてちゃんと動くCSSに変換するツールを作るためのものということになる。 SassやLESSと同じ立ち位置のものを作るためのものなので、共存させることにはあまり意味が無い(まったく無いわけではない)。現状のSassや
Cloudflareにおけるメール・ソリューションとしてのMailgun
Value Domainで取得したドメインをCloudflareの提供するネームサーバーでGitHub Pagesに向けてやるのは、低コストでウェブサイトをホスティングする優れた手段だ。問題はメールだ。Cloudflareではメール関係の機能はまったく用意されていない。またValue Domainで無料で取得できるXREAのアカウントはメールだけの利用は禁止されている。本道としては別にメール・サーバーを用意するわけだが、転送だけで良いのなら無料枠内で利用することができるMailgunを使うのが良さそうだ。 Mailgunではアカウントを取得後、まずドメインを追加する。すると計5つのDNSレコードが提供される。 認証用のTXTレコードが2つ 送信メールでのトラッキングに使われるリソースのためのCNAMEレコードが1つ 受信用のMXレコードが2つ これらDNSレコードをCloudflareのコ
“マークアップ”するということ ～ HTML5勧告に寄せて ～
HTMLを適切な要素を使って書いていくことは実はそれほど難しくはない。しかし過剰に要素を使わずに、かつスタイリングすることも意識して、と適切に“マークアップ”するのはなかなかの修練を必要とする。いったい“マークアップ”するということはどういうことなのだろうか、そしてどのような思考の元に行えば良いのだろうか。 HTML5での変化 著作権表示のマークアップ small要素 footer要素とsmall要素 p要素とdiv要素 footer要素とp要素 スタイリングとの兼ね合い マークアップするということ HTML5での変化 コンテンツに則した素直な形でマークアップできること。 HTML5で変わることや変わったことは多くあるが、それらをおおまかに俯瞰するとこのような言葉に集約できる。そのために様々な要素や属性が追加され、既存の実装をなるべく壊さない形で要素の意味に変更が加えられた。これらの変化は
失われたウェブ制作のベスト・プラクティス
ベスト・プラクティスは多くの人には固定的なものだ。しかし本来は流動的なもので、革新者によって大きな変化が起きる。ウェブ制作におけるベスト・プラクティスも変化しており、その過程でいくつも失われていった。 ウェブ制作においては、技術革新の多い世界であることと、他の世界の変革に対応しなければならないことから、よりいっそう変化が速いとも言えるだろう。だからといってベスト・プラクティスが意識するに留めておけば良いという程度のものというわけではない。例えば<!DOCTYPE html>について考えてみよう。 <!DOCTYPE html> これはHTML5が産声を上げた時期に先駆者である人々が編み出した魔法の言葉だ。これによりほとんどすべてのブラウザーでウェブ標準に準拠した形でHTMLが表示されることが保証される。つまり個々のブラウザーで大幅に違う挙動になることはなくなり、予期せぬ問題の発生を大幅に低
Gitのfetch/pullサブコマンドで--pruneオプションをデフォルトにする
Gitではbranch -aでリモート・リポジトリーも一覧できる。この一覧には既にリモートでは消されたリモート・リポジトリーも表示される。この一覧を更新するにはfetch --pruneを使うわけだが、いちいちそうするのは面倒くさい。どうやらfetch.pruneをtrueにするとデフォルトで--pruneを付けてfetch(及びpull)を実行してくれるようだ。 $ git config --global fetch.prune true $ git fetch From https://github.com/hail2u/example x [deleted] (none) -> origin/deleted-branch グローバルに設定して良い場合はこれで常に--prune付きでfetchとpullが実行されるようになる。この設定はプロジェクト・ローカルで特定のリモートに対してのみ
書きやすい・読みやすい・優しい
およそコーディングにおいては書きやすさが重視される傾向が強い。例を挙げるまでもないだろう。しかし、その書きやすさは主観的なものであることが多く、他人の読みやすさへは寄与しない。読みやすさにも主観的な面はあるが、それでも落とし所というものはある。ただ、そういった読みやすさは人間へのもので、機械とそれを通して利用することになるユーザーに優しいとは言えないことが多い。これらすべてを満たす夢の書き方みたいなものは、特にフロントエンド開発においては、なかなか存在しない。 開発においては以下の様な形でワークフローを構築したい。それぞれの段階で対象になる人が違うことが重要だ。 自分が書きやすい形でのコーディング 他人が読みやすい形でのレビュー ユーザーに優しい形でのデプロイメント CSSの開発においてこれらに対応するものを具体的に挙げると以下の様になるだろう。 Sass・CSSCombなど ウェブ標準仕
Vimmers 2
手が空いた時にやってた作業が一段落したので、ペライチというかHTMLとCSSとJavaScriptを普通に書きたくなった。ので、vim-jp.orgにあったVimユーザーの一覧ページのカラフルな奴を作った。カラフル。 オリジナルのVimmersが密度が高かったので、ゆとりを持ってそれぞれをカードっぽくなるようにした。この時点で既にコンセプトを誤解してて駄目な感じだった……。 フォントはLatoを使った。x-heightが高く、ディセンダが小さめで、開きが大きいので、余白の多いカード的なものにはおさまりが良い。ウェイトも豊富なので使いやすいけど、WindowsのChromeだと一部サイズでまだガタつきがあるかも。 カラーは当初Pantoneから幾つか選定してたんだけど、青と橙がFlat UI Colorsとほぼ同じものになってしまったので、こちらをそのまま利用させてもらうことにした。赤緑橙青
CSSポストプロセッサー時代の到来
SassやLESSといったCSSプリプロセッサーは市民権を得たと言って良いと思う。しかしそれらCSSプリプロセッサーは開発という段階にのみ利をもたらすもので、今のところはそれ以上ではない。CSSを実際にユーザーに届けるまでには、開発だけではなくレビューとリリースという段階もある。レビューとリリースも確実性を持って効率的に行うためには、CSSポストプロセッサーと総称されるようなツール群が必要になるだろう。 この文書はFrontrend Advent Calendar 2013の4日目への記事として寄稿した。明日は@hilokiさんがスタコラサッサと書くようだ。 目次 CSSポストプロセッサーとは CSSプリプロセッサーの出力するCSS CSS Lint 開発用とレビュー用、リリース用のCSS CSSポストプロセッサーのユースケース ベンダー拡張プリフィックスの付加 Media Queries
pushState()とhead要素の子
ページの一部だけ差し替えてpushState()で表示されるURLだけを更新という手法が広まりしばらく経った。全般的に素晴らしい仕組みで、みんなどんどん使えば良いと思うのだけど、head要素の子のことをちょっと気にして欲しいかなと思う。 よく見る駄目なケースはRSS Auto-discoveryが死ぬもの。例えばMediumのトップページにはRSS Auto-discoveryはないので、Firefoxの購読ツールバー・ボタンはもちろん無効のまま。そこからカテゴリやユーザーのページに移動しても無効のままなので、RSSが無いように見えるが実際はある。コンテンツ部分の差し替えのみで、rel="alternate"を指定したlink要素が追加されないため、有効にならない。これではRSSを購読しようと思ってもなかなか難しい。 また、FirefoxでMediumで特定のカテゴリを直接開いた場合は購読
ID使っても別に問題ない
CSSでID使うの良くない……どころか、ID使うのはゴミクズカスみたいな風潮で辛い。その根拠はいくつかあり、それらはCSSだけをただそのまま書く場合には納得出来ないこともないかなーと思うので余計に辛い。特にOOCSSのようなアプローチではIDは混ぜるな危険。だからといってIDを使わないのがベスト・プラクティスなわけじゃない。 CSS Lintの利用が広まり、これがID使うなって怒るのも原因の一端な気がする。Disallow IDs in selectorsではIDの問題点として以下のようなものを取り上げている。 However, IDs have a downside: they are completely unique and therefore cannot be reused. つまりユニークなため再利用できないというマイナスの面がある、と。確かに再利用できない。でもこれはマイナス
ファビコン・カンニング・ペーパー
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 -
Gruntのグロブとfilterプロパティ
Gruntのグロブでは普通のグロブと同じように特にファイルとディレクトリの区別はされない。Gruntプラグイン側でパスの存在チェックまではしてくれるの多いけど、間違えてディレクトリ投げると大体はエラーを吐いて止まる。のでファイルを投げるものならfilterプロパティも使ってファイルであることを保証してやった方が良い。 例えばgrunt-contrib-sassのタスク設定なら以下のようにしておく。 sass: { options: { precision: "3", style: "compressed", unixNewlines: true }, main: { expand: true, src: ['styles/*.scss', '!styles/_*.scss'], filter: 'isFile', ext: '.min.css' } } こうしておくとstyles/foo.
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)があ
_ellegant-button.scss
このサイトでも使っているSVGのグラデーションを利用したボタンをミックスインにしてscss-partialsに追加しておいた。:hoverで少し暗くなり、:activeで凹むようになっている。button要素でもa要素でも使える。あと、だいたいスケーラブル。 Demo: _ellegant-button.scss Demo .test { @include ellegant-button(#39c, #fff); } として背景色と前景色を指定してインクルードするだけ。SVGを使っていたり、枠線の色や1pxのハイライト等はすべてrgba()でどうにかしたりしているので、FirefoxやChrome、Safariでないとスクリーンショットのようにはならない。 scss-partialsには_context-reset.scssという実験的なpartialも追加した。これはインクルードしたセレ
(S)CSSの書き方メモ
HTML5時代に向いていそうな(S)CSSの書き方を模索しています。SCSSで書くのでモジュール式に色々分割した方が良さそうだな……とか色々試してますが、なかなかこれ！ というものに辿りつけません……。ということで、ここ最近の書き方をメモがてら晒してみる試みです。 実際にこのサイトで使っているSCSSファイルを抜粋しつつ列記していきます。 style.scss style.cssになるSCSSファイルではCSSは書かないようにします。ただし例外としてCSS文法での@importルールはその必要性からここに書きます。Webフォントなんかで使いますね。それ以外はSCSSの@importでモジュール化した各種SCSSファイルを読み込んでいきます。 @import url("http://fonts.googleapis.com/css?family=Pacifico"); @import "va
Reset vs Normalize
CSSの記述法として、ブラウザごとの違いを「Reset」して一から指定するという方法が長らくマジョリティを占めていました。まだまだその方向で書いている人が大半ですが、「Normalize」するという方法を採る人達も増えています。なぜリセットではなくノーマライズなのかというような話をなんとなくダラダラ書いてみたい感じです。 以下、リセットはYUI 2のCSS Resetを、ノーマライズはNormalize.cssをイメージして読んでみてください。 リセットとノーマライズ まずは両者の違いから。リセットはなかったことにするというもので、ほぼ全ての要素に対するスタイル指定を排除しブラウザごとの違いを吸収するものです。対してノーマライズはブラウザのデフォルト・スタイルシートを生かしつつ、各ブラウザ間の挙動を擦り合わせるものです。リセットが負の方向で統一しているとすれば、ノーマライズは正の方向で統一
CSSとJavaScriptで文章をメモ書き風に
または和文フォントから仮名部分のみ抜き出してサブセット化したものとYahoo! Japanのルビ振りAPIを組み合わせて、ユーザー環境やサーバー性能に左右されずに比較的自由なフォント表現を行うためのイロハ。おれ ここ めも かき なぐる！ Demo: Scribble My Tweet #3 フォントのサブセット化 ここでいうサブセット化とはつまりフォントから必要な部分のみ抜き出して再構築すること。Webフォントとして使えるからといって、サブセット化までは許されていないことがあったりするので、それには気をつける必要がある。例として新BSDライセンスで提供されている、きろ字 プロポーショナルを取り上げる。 サブセット化に留まらないWebフォントのジェネレーターとしてFont Squirrelの@font-face Generatorが利用できるが、アップロードするフォントのサイズ制限が厳しい
SCSSでの落とし穴
SassをSCSSで書いていてはまった落とし穴についてのメモ。 プロパティのネスト h1 { font { family: "Gabriola", sans-serif; size: 400%; } } とうっかり書いてしまうと、 h1 font { family: "Gabriola", sans-serif; size: 400%; } となる。プロパティのネストを使う時はコロンが必要で、他の部分と記述が違うので注意が必要。 h1 { font: { family: "Gabriola", sans-serif; size: 400%; } } SCSSではこの記述のみがCSSと比較するとかなり特異なので、使わないと決めてしまうのも良さそう。 負の値の計算 $gutter: 20px; margin: 0 0 0 -$gutter; だと、 margin: 0 0 -20px; にコン
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
