ReworkとPostCSS
AutoprefixerやMyth経由で話題になったRework。そしてAutoprefixerが乗り換えたPostCSS。両者はどのようなことに主眼を置いているライブラリなのか、SassやLESSとの関係はどうなのか、そしてどのようなツールを書く時にそれらを使うべきなのだろうか。 ReworkはCSSをプリプロセスするためのライブラリということになっている。サポートされているかどうかよくわからない最先端の標準仕様のドラフトに従って書かれたCSSをブラウザーがちゃんと解釈できるようにするとか、特殊な記法を展開するとか、だ。こういった現実世界ではうまく動かないCSSをプリプロセスしてちゃんと動くCSSに変換するツールを作るためのものということになる。 SassやLESSと同じ立ち位置のものを作るためのものなので、共存させることにはあまり意味が無い(まったく無いわけではない)。現状のSassや
厚いレイヤー
Sitepointに書かれたBEMやSMACSSを使っている開発者たちからのアドバイスを読んでいた。僕は今いかにして命名規則をなくすかといったことを考えている最中のため否定的に読んだが、それでもここに書かれたアドバイスは正しいとは感じた。BEMやSMACSSが概ね想定以上に機能することは確かだし、スケールするし、指揮もとりやすい。 僕が避けたいのは何かしらへの強い依存だ。薄いレイヤーならともかく、厚いレイヤーの場合は重度の依存をもたらす。その依存はこれからもそのまま通用するのかというと、不安が大きい。厚いレイヤーとは心中する覚悟が必要というのは正しいが、多くの場合心中する羽目になるのは導入した人ではなかったりもする。もっと薄いレイヤーでウェブ標準(など)に寄せた形の解があれば安心できるはずだ。 HTML 4.01に対するHTML5を始めとして、CSS 2.1に対するCSS 3、いわゆるJa
EDJOの(デ)メリット
Every Declaration Just Once (以下EDJO)アプローチの最大のメリットはなんだろうかということについて考えていた。情報設計と重なるところがまるでないため、設計思想としては完全に成立しない。つまりCSSを設計することを放棄し、設計されたHTMLに対してスタイルを割り当てていく手法としてのみ存在しうる。このことがすなわちメリットなのではないだろうか。 CSSの限られた文法が情報設計に基づく複雑な構造の表現に適さないことは明白だ。OOCSSではHTMLとCSSを設計のもとに平等に扱っていたが、どうしてもCSSにおいては限界があり、複雑な命名規則やCSSプリプロセッサーの登場となったのではないかと思う。CSSプリプロセッサーの高機能化により実現可能になりつつあるが、それと同時に高度に抽象化された複雑さも氾濫しつつある。 EDJOにおいてはその書かれ方を見ればわかる通り、
OOCSSの欠点とEvery Declaration Just Onceのもたらすもの
昨日も少し書いたEvery Declaration Just Onceアプローチ(以下EDJOと略す)について、皆が目を瞑っているOOCSSの欠点、CSSが持つ特徴、HTMLとの兼ね合いという点からもう少し書いてみたい。これについては未だ誰ともちゃんと議論していない。機会があったらこの記事をベースにでも誰かと話してみたい。 上記Googleの文書は、主にパフォーマンスの観点で書かれている。どうしても長くなりがちな定義を分散して書くよりも、能動的に短くすることができるセレクターを分散して書いた方が、プロダクションにおいてリリースされるCSSファイルのサイズを小さくすることが可能だろうというものだ。同時にこの文書の筆者は自身のブログで、より自然にCSSを書くための手法(原文: 「The Natural Way of Writing CSS」)としてこのEDJOという手法について述べている。 僕
CSSプリプロセッサーの必要性
やはりSassは必要だと考えている。あるいはLESSでもStylusでも良い。それはCSS Variablesの実装が落ち着き、行き渡っても、だ。もちろんその時にはCSSプリプロセッサーの変数を使わずに、CSS Variablesを使って書いた方が良いけれども。 CSSプリプロセッサーの変数やネスト、そしてミックスインはショートカット記法に過ぎない。DRYを加速させるだけで、それ以上特に付け加えられる何かはあまりない。変数への命名規則の採用による意味付けやネストでの構造化は有用・有益であることには気づくが、本質的な意味付けや構造化をもたらすものではない。これらの機能はCSSの貧弱さと比較すると輝かしく見えるものの、プリプロセッサーを使ってまで利用する価値があるかというと疑問が残る。 ならばなぜ必要だと考えるのか。 それはウェブページの要素間でのルールセットの共有ではなく、セレクター同士での
wildfire.vimでVim力を下げる
wildfire.vimという、カーソルがある辺りのテキストオブジェクトをなんとなく選択してくれるVimプラグインを使い始めた。Vim力が下がる代わりに魂の平穏が得られる。ような気がする。 デフォルトではノーマル・モードで<Enter>を押すとカーソルのある辺りのテキストオブジェクトを選択してくれる。HTMLファイルを編集中なら属性値の上で発動させると、クオートの間を選択してくれる。その状態でもう一回<Enter>を押すとその上位にあるテキストオブジェクトをなんとなく選択してくれる。属性値のクオートの間を選択した状態だと、HTMLタグで括られた全体(など)まで拡大される。 逆方向に縮小することも出来るので、適当にタカタカ<Enter>を押して拡大しつつ、広げ過ぎたら<BS>で狭めるみたいな感じで使えて、とてもいい加減に使える。僕は狭める方だけを<S-Enter>に変えて、サクサク感を上乗せ
Sassの変数命名規則とBEM
$type-subtype-component-contextというような形でSassの変数を命名していたけど、これにもBEMを使うかという感じになってきた。ただでさえ長いのが、セパレーターで更に長くなるけど、元々そんなに短くないので気にしないことにした。BEMをクラス名で使うような形で単純に利用するケースと、3.3で導入される予定のマップを使って構造化して定義し、複雑に参照するケースを比較して検証している。 検索ボックスに使う、以下の8つの色の変数定義を例にする。 検索フォーム 背景色 入力フォーム 文字色 背景色 枠線色 フォーカス 枠線色 ボタン 文字色 背景色 オンマウス 枠線色 BEMを使った簡単な実装 $color-bg_searchbox: #f9f9f9; $color-fg_searchbox__input: black; $color-bg_searchbox__inp
Sassの変数名での-と_
SassでBEMを利用して変数名を付けようとして、今までハイフンのみでどうにかしていた変数名を書き換えていた時に気づいたんだけど、Sassの変数名ではハイフン(-)とアンダースコア(_)が同一視される。バグだと思ってIssue立てたら、3.0.0でSCSS記法を追加した時に入れた仕様だという返事だった。 -と_が同一視されるということはどういうことかというと、以下の変数はすべて同じとみなされるということで、すべての変数の値は最後に定義した変数の値になる。 $foo--bar: "foo--bar"; $foo-_bar: "foo-_bar"; $foo_-bar: "foo_-bar"; $foo__bar: "foo__bar"; .test-foo--bar { content: $foo--bar; } .test-foo-_bar { content: $foo-_bar; }
VimのSassでのgfを改善する
Vimの標準ランタイムに入っているftplugin/sass.vimではincludeexprやsuffixesaddが適切に設定されているので、多くの場合はそのままで快適にgfできる。けれど同じディレクトリにfooというディレクトリと_foo.scssというファイルがある場合、@import "foo";でgfするとディレクトリの方が開かれてしまう。それをラッパー関数を書いて、_foo.scssを優先させようという試み。 Download: sass-goto-file.vim インストールは~/.vimrcにコピペするだけ。以下のような順で開くべきファイルを探している。 普通にファイルを探す _を頭に付けてファイルを探す 普通にディレクトリを探す 見つからなかったらエラー タブで開きたい場合は、最後にeditを使って開いているところをtabeditにする。 includeexprによる
BEMを使ったSassファイルの整理
このウェブサイトのSassファイル群はずっとフラットなファイル構成でやっていた。主にSassが相対パスの修正を行うことができないことが理由だったけど、最近はポストプロセスすればどうにでも出来そうな感じなので、あまり気にせず整理することにした。単純にカテゴリ分けするだけでも良いのだけど、BEMを応用してやってみている。 CSSのクラス名及び変数やプレースホルダー・クラスにはまだ手を付けず、まずはBEMツリーとルールセットの配置の対応を作るところから始めた。 ファイル名でブロック ディレクトリでブロックのネスト セレクターの1段階のネストでエレメント &を使ったセレクターのネストでモディファイア 以上のようなルール付けの元にやってる(未完成)。 ブロック scss/ ├ _header.scss └ header/ ├ _logo.scss └ _site-navigation.scss ファ
ウェブデザインにおけるセマンティック・バージョニング
アプリケーションの世界ではセマンティック・バージョニングが広く受け入れられた……かどうかはわからないが、採用例はすごく増えている印象だ。ウェブデザインではどうかというと、ウェブ・アプリケーションのバージョニングに追随しているだけであったり、そもそもバージョニングされていなかったりするような気がする。ウェブデザイン、主にCSS(とCSSプリプロセッサー)においてセマンティック・バージョニングを導入するとすると、どのようなタイミングでメジャー、マイナーそしてパッチ番号を増やせば良いのだろうか。 セマンティック・バージョニングの中心となる概念は後方互換性だ。後方互換性が: 失われる: メジャー 失われない新機能の追加: マイナー 失われない修正: パッチ 数語でまとめるとこのようになるだろう。ウェブデザインにもこれを当てはめるとすると、ウェブデザインにおける後方互換性とは何なのかということをまず
Gruntプラグイン: selector4096
IE9以下で4096個以上のセレクターがあるとスタイルが反映されなくなるバグのチェックを行うGruntプラグイン、selector4096を作った。CSSプリプロセッサーでネストしつつ@extendするとぽんぽんセレクター増えていくので、最近はまめにチェックするようにしている。自己最多記録は3400くらいで、バグに引っかかったことはまだない。 npmで普通にインストールした後、Gruntfile.jsに以下のように書いて準備完了。 grunt.initConfig({ selector4096: { all: ['src/css/**/*.css'] } }); grunt.loadNpmTasks('grunt-selector4096'); 読み取り専用タスクなので、destとかは必要ない。 $ grunt selector4096:all 実行すると、src/css/以下のすべてのC
CSSポストプロセッサー時代の到来
SassやLESSといったCSSプリプロセッサーは市民権を得たと言って良いと思う。しかしそれらCSSプリプロセッサーは開発という段階にのみ利をもたらすもので、今のところはそれ以上ではない。CSSを実際にユーザーに届けるまでには、開発だけではなくレビューとリリースという段階もある。レビューとリリースも確実性を持って効率的に行うためには、CSSポストプロセッサーと総称されるようなツール群が必要になるだろう。 この文書はFrontrend Advent Calendar 2013の4日目への記事として寄稿した。明日は@hilokiさんがスタコラサッサと書くようだ。 目次 CSSポストプロセッサーとは CSSプリプロセッサーの出力するCSS CSS Lint 開発用とレビュー用、リリース用のCSS CSSポストプロセッサーのユースケース ベンダー拡張プリフィックスの付加 Media Queries
SVGのanimateTransform要素
SVGのanimateTransform要素は、その親要素をアニメーションさせながら変形したり動かしたりするためのもの。fromとto要素だけでもちょっとしたことならできるけど、複雑なことをやるにはvaluesとkeyTimes属性とを組み合わせるようだ。 Move 300px in 2s, Sleep 2s, Move -300px in 2s, Sleep 2s 均等にシーンを割り当てる場合はvalues属性を書くだけで良い。 <animateTransform attributeName="transform" attributeType="XML" begin="0s" dur="8s" repeatCount="indefinite" values="0; 300; 300; 0; 0" type="translate"/> values属性に指定した値の個数から1を引いた数でd
CSSでフォント・ファミリーのショートカットを作る
最近のブラウザーではlocal()を使ってフォント・ファミリーのショートカット(的なもの)を作ることができる。CSS Fontsモジュール仕様のsrcプロパティーの項にも思いっきり書いてあるんだけど、今まではそんなに必要なかったのであまり使われていない。5ウェイト展開なヒラギノ角ゴのiOS 7へのバンドルと、3ウェイト展開の游ファミリのWindowsへのバンドルにより必要性が少し増えた気がする。 特に游(ゴシック|明朝)はWindows 8.1とOS X 10.9でファミリ名が違う上、少し古いFirefoxでのアレとか、OS Xには細字がないとかもあるので、色々考慮するとfont-familyプロパティーではややこしいフォント指定を行う必要が出てくる。そうやって出来た長いリストのfont-familyは読みづらく、デバッグのしづらさにつながる。local()を使ってフォント名を作り直してや
ウィジェットのクラス名
最近、Twitterのリンク共有ボタンのクラス名が変わった。twitter-share-buttonというのが追加されたかなんかしたのだと思う。このクラス名を自分のウェブサイトの別の所でも使っていたので、表示が崩れてしまった。こういう衝突はなかなか避けられないものだとは思うけど、ウィジェット提供側で少し気をつけてくれるとその機会は大きく減るんじゃないかと思う。 Twitterのリンク共有ボタンはtwitter-、Facebookのいいねボタンはfb_というプリフィックスをそれぞれ付け、いくつかクラス名を振っているだけ。対して、Googleの+1ボタンはクラス名はなく(設置コードにあるg-plusoneというのは消える)、代わりにIDがあり、更に頭にアンダースコアを3つ付けた___plusone_というプリフィックスを使っている。この実装だと、まずかぶるということはない。 サービス固有である
Sass 3.3の新しいデータ型: マップ
SassConfに合わせたのか、Sassの3.3 RC.1が出た。これで3.3での追加機能も固まったようなので、CHANGELOGをちゃんと読んだところ、1か月ほど前に取り込まれていた新しいデータ型であるマップについてもちゃんと入っていた。マップは、いわゆるハッシュとか連想配列とかいう名前で呼ばれるもの。 マップの書き方はリストとほとんど同じで、リストの各要素にコロン(:)区切りでキーと値をワンセットで書く、というようなもの。例として、プロ野球セ・リーグの各チーム色を背景色にしたクラスを吐くもの作ってみる。 $team-colors: ( giants: #f90, tigers: #fc0, carp: #f00, dragons: #009, baystars: #269, swallows: #03c ); @each $team, $color in $team-colors {
Mediumのネガティブさ
主にシステムとして、書く人のメリットがあまりない点などがMediumの欠点として挙げられることが多い。そういうのもあるだろうけど、そもそも「喜んでタダ働きをしようとする何百万もの人々」がいるのだから、その点はあまり問題にならないと思う。それよりも、多くの記事がバッシングや自身の不満をぶつけるものに偏ってて、Medium自体がネガティブなものに見えてしまうあたりの方が気になる。 こまめに読んでいるDesign/UXカテゴリの記事では、ここ3か月ほどiOS 7についての様々な記事が公開されている。そういった記事を書いた人たちがどの程度の専門家かはわからない(わかりづらい)けど、自分の好みを理論武装してぶつけているだけのようなものが多かった。その理論には見るところもあったりして、ネガティブなものの興味深いものを含んでいるとは思う。その一方で自身が責任をもって管理するウェブサイトではないため、強い
box-shadowとradial-gradientで画像をポラロイド写真風に
CSS3のbox-shadowプロパティではinsetという値を取ることができ、その場合ブロックの内側に影が付く。これをある工夫と共に利用すると写真の端に影がつけられる。更にradial-gradientでセピア色のグラデーションを重ねてやれば、良い具合に古ぼけさせることもできるので、両方の効果を重ねてやればポラロイド写真風に見えないこともない？ Demo: Polaroid effects using inset box-shadow and radial-gradient キモは以下のようにz-indexを使って画像を背面に回してやること。そうすれば親のブロック要素でのbox-shadowやbackground-imageを画像の上に重ねることができる。 .polaroid { float: left; width: 400px; height: 400px; background-i
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Fira