HTML Best Practices (または普通のHTMLの書き方)に解説を追加し始めた。in-detailというフォルダーに1ファイル1プラクティスで置いてある。解説を書いていないプラクティスにも空ファイルも用意してしまったのでわかりにくいが、ようやく90%といったところだ。 解説と言ってもあまり長くはない。長くて4段落くらいで、短めのブログ記事くらいにとどめた。例示のみの方を見てもらって、なんでだろうとなったらサッと参照する程度のものにしたかった。完全で包括的な知識はもはや誰も持ってはいない(し、main要素のように劇的に変わる)ので、本当のところは定期的に仕様を読んで想像するしかない。この解説は僕の想像を文書化したものに過ぎない。 まずはとにかく書く。今週中に終えて、7月末までかけて手直しをしようと考えている。そして「HTMLを書く最後の世代に向けて」とかいうサブタイトルを付けて

CSSWringではfont-familyプロパティーでできうる限り引用符を削除しようとしている。逆に必要な場合は付けるようにもなっている。今までその値にvar()を使われることを想定していなかったため、var()が引用符で括られてしまうというバグがあったようだ。修正してv4.2.2をリリースした。 font-familyプロパティーの値で引用符が必要かどうかは簡単だが、誤解も多い。大まかにいえば識別子の連続のセットならば引用符はいらない。 .test { font-family: Helvetica, Arial, sans-serif; } 識別子の連続とは、ASCIIの記号を除いたものと考えると近い。つまりカタカナや漢字が含まれていても引用符で括る必要はない。ただし数字やハイフン2つ、そしてハイフンに続いて数字では始めることはできないというような規則もある。 .test { font

floatプロパティーで柔軟なレイアウトを行うことは可能だが、それには熟練と標準化されていない知識が必要になる。Flexible Box Layoutは標準化されていないという問題は解決するが、限られた矩形を基準にレイアウトをすること由来の独特のおまじないという熟練は必要になる(heightプロパティーの工夫)。レイアウトには様々なパターンがあり、Flexboxが解決するのはその一部分でしかない。 問題はFlexboxの能力(とCSSにおける様々な単位の汎用性)が意外に高く、cross sizeが想定されているパターン以外にも流用できることだ。このことはfloatプロパティーが本来フローコンテンツが回り込むように浮かせるものだったのにも関わらず、その汎用性から万能ツールのように扱われてしまったことと似ている。ウェブ開発者たちからもそのもっとすごいやつといった扱いになっていると言って良いだろ

ウェブページにおいて図であったり飾りであったりする画像の配置はCSSを通して行う。多くの場合はクラスとしてパターン化した配置のひとつを要素に割り当てることで行うわけだが、これを自動化したい。具体的に言えば、画像の縦横サイズやアスペクト比、キャプションの有無に基づいて最適な配置を自動で行い、手作業で要素にクラス名を振らなくて済むようにしたい。 紙媒体の場合は物理的な制限があるので、文章が収まるようにレイアウトを決め、それに合うように画像を作成し配置するという形が多い。ウェブページでも同じように行われてきたが、物理的な制限は違う形のもののため、レイアウトは別の形で自由に行えるのではないだろうか。 また画像そのものにはその最適解が別にあるはずだ。写っているものの最も良い状態を求めて作成し、配置はその画像で伝えたいことが存分に伝わるように、かつ本文のバランスを崩すことなく配置できると良い。そういっ

SVGをサポートする環境がほとんどになってきた。それでもなんとか8であったり、かんとか2.3であったりのことを考慮せざるをえないという状況はありうる。それにはonerror属性を使った対応が有力だが、srcset属性でSVGファイルを指定するだけというハックのことを知った。将来的に使えなくなるわけではないが、やりたいことと実装に食い違いが少なからずあるのでハックと言って良いだろう。 <img src="foo.png" srcset="foo.svg"> 表示したいSVGをsrcset属性で、フォールバックに使いたいPNGをsrc属性で指定するだけだ。これでsrcset属性をサポートしているブラウザーではSVGが、そうでないブラウザーではPNGが表示される。srcset属性のサポートに対して、より多くのブラウザーがSVGをサポートしていることから成立する。もちろん食い違いがあるのでSVGを

時代はとっくにSass 3.4なのでローカル変数メインにしたいということが前提にある。そうすることで変数名にBEM等のしっかりとした命名規則を使わずに済み、自己言及的な変数名と数文字の変数名でおおむね完結することになる。パーシャル間で共有したい場合はしょうがないので!globalを使ってローカル変数をグローバルへエクスポートするようなあきらめを許容して誤魔化す。 まずある程度はグローバル変数として定義しておく必要がある。それらグローバル変数は自己言及的なもの(それこそ$color-black: #000;といったようなもの)で、実際にウェブサイトで使われる要素やクラスとは無関係に定義していく。 // _variables.scss $ratio: 1.7; $ratio-text: 1; $ratio-text-large: 1.5; $line-height-default: $rati

ウィンドウや画面のサイズに合わせて文字の大きさを自動的に変更するテクニックは、俗にレスポンシブ・タイポグラフィーまたはフルイド・タイプと呼ばれている。当初は僕も良いアイディアだと思い多用していたが、重要なのはビューポートの大きさではなくデバイスとの距離だろうと思い直したためもうほとんど使うことはない。当初から嫌いといっていた人はこの辺にしっかりとした意識があったのだろう。 使うことをやめた理由は、単純に技術的制約によってユーザーとデバイスの距離を知るすべがないからに過ぎない。レスポンシブ・タイポグラフィーが目指す、適切な文字の大きさを環境ごとに提示することそのものについては正しい考え方であると思う。ただ今利用されている「ビューポートが768px以下なら文字を小さめにする」というようなアバウトな実装だと問題がある。もちろんvw単位を使ったフォント・サイズ指定でも同じだ。 なぜならばデスクトッ

テキスト入力コントロールにplaceholder属性を使って入力例を表示することができるようになってから、もうかなりの年月がたった。悪用されてもいるが、わかりやすいフォームには不可欠になりつつある程度には浸透したと言ってよいだろう。ただMozilla Developer Networkのグローバル・ナビゲーションに設置されている検索フォームのようにそのスタイリングに失敗しているケースはままある(Chrome 43だと入力済みかどうかまったく判断できない)。そういった失敗を極力減らすためには、Firefoxのようにopacityプロパティーを使ってノーマライズしてやるのが良いだろう。 ではFirefoxの挙動に合わせるようにノーマリゼーションする場合はどのようにCSSを書くことになるのだろうか。 Firefoxではユーザー・エージェントCSSでopacityの値に0.54を指定している(以前

少し前のCSS Transitionを使ったスムーズにスクロールしてトップに戻る機能という記事では、CSS Transitionを使ってスムーズにスクロールさせるためにbody要素のmargin-topプロパティーを負の値を設定した。これはとにかく上方向へのスクロールにしか使うことは出来ない。下方向にスムーズにスクロールさせるためにはまた別のアプローチが必要になるようだ。 何かしらのCSSプロパティーを使い、body要素を上方向にずらすということになる。つまりtransformプロパティーでtranslate()やtranslate3d()を使いY方向のマイナスへ動かすのが向いているようだ。あとはtransitionプロパティーを組み合わせるだけでスムーズにスクロール(しているように見せる)ことができる。 Demo: Scroll Down Smoothly with CSS Transi

前に作ったスクロールした時に位置固定のロゴをトップに戻る機能にすり替えるものを少し手直しして再導入した。今回はスムーズにスクロールさせようかと色々考えていたが、やはりJavaScriptでscrollTo()を制御するのはコストが高い。CSSならどうだと試行錯誤したところ、どうやらbody要素への負のマージンをCSS Transitionで滑らかに変化させれば良いようだ。 Demo: Scroll Smoothly with CSS Transition デモのページにはダミーテキストの各セクションの最後にそれぞれ⇑ Back to Topというリンクがある。それをクリックすると1秒かけてスムーズにスクロールしながらトップに戻る。トリガーとスクロール自体はJavaScriptで行っているが、スクロールのアニメーション自体はCSS Transitionで行っている。具体的には以下のような処理

渡されたSVGファイルを見たらpath要素のアンカーポイントの数字が小数点以下6桁くらいから30桁まで混在していて、無駄な感じがあった。SVGOでできるのでそれでやっても良かったが、まずは単純に小数を指定桁(3から5桁)で四捨五入したいだけなので他に何かされてしまう可能性があるツールはちょっと避けたい。ということでVimの置換でどうにかした。 コマンドとしては長いがやっていることは普通なので、後述の説明が理解できればソラで打てるんじゃないかと思う。 :%s@\d\+\.\d\+@\=round(str2float(submatch(0))*1000)/1000@g 例えば、 0.12345 12.34567 0.99999 56.78999 は、 0.123 12.346 1.0 56.79 と置換される。それぞれ切り捨て、切り上げ、切り上げて余分な0を削除、切り上げて余分な0を削除と置換

多くのウェブ制作者達が色覚多様性について考えることはまずない。せいぜいコントラストを確保したり、リンクの下線を消さないようにしたりすることで、グレースケールでもそれなりに識別できるように注意するくらいだろう。それで十分とも言えそうではあるが、それ以上考えようにも取っ掛かりがないためそれで止まっているとも言える。その取っ掛かりとして色覚多様性を再現するSVGのフィルターを作った。 Repository: Color Blindness Emulation filters.svgに含まれる8つのフィルターは、そのアルゴリズムはともかく、feColorMatrix要素を使ったごく簡単なものだ。 <?xml version="1.0" encoding="UTF-8" standalone="no"?> <svg xmlns="http://www.w3.org/2000/svg" version

一時期は全てのウェブサイトが中央寄せになるのではないかというくらいの勢いだったような気がするが、最近は左寄せが盛り返しているようだ。AwwwardsやHTTPSTERなどのジャンルレスのウェブデザイン・ギャラリーを見るとなんとなくそう思う。正確に言うとレイアウトは中央寄せしつつ、テキストは左寄せしているウェブサイトが増えている。 レイアウトの中央寄せは、最適な一行の文字数に限界があることを考えると採用せざるをえない。CSSでマルチカラム・レイアウトが簡単に提供できる様になれば少し変わる可能性はあるが、縦スクロールとマルチカラム・レイアウトの相性は良くない。実装方法は色々変化していくことだろうが、レイアウトの中央寄せ自体はこのまま継続して行われていきそうだ。 テキストの左寄せが盛り返しつつあるのは、ウェブ・フォントの流行と共にタイポグラフィーへの傾倒が進んだことによる結果だろうか。CSSの実

モバイル・ファーストが浸透して久しくなり、めっきりmin-widthクエリー以外を見かけることはなくなった。そんな中、not (max-width: 768px)という書き方を見かけて、なるほどなと思った。現状のブラウザーにおける実装(と安定した仕様)では768pxを含まずそれより大きいという表現がmin-widthでは書くことができないが、notキーワードとmax-widthを組み合わせることで実現できる。 Demo: Negation of max-width query 特定のデバイスや解像度を強く意識したクエリーの是非はとりあえず脇へ置いておいて、iPhone 5s以下やらiPad Airやら一般的なノートブックやらを意識してクエリーを書くことはままある。多くの場合はそれら特定のデバイスのサイズからを区切りにしてクエリーを書くわけだが、それらのサイズまでで書くとなると少し曖昧な記述

Sassを書く時には変数を多用することと思います。それら変数は自分で定義して自分で使うので、同じプロジェクト内で再定義する必要はあまりありません。しかし他人や自分の作ったSassファイルを流用する場合、その中で使われている変数の値を最適化する必要が出てきます。もしその変数がハード・コーディングされているだけだとしたらどうでしょうか？　その場合変数を直接書き換えることになるでしょう。こういったSassファイルの再利用における問題を解決するためにSassには!defaultというフラグが用意されています。 Less & Sass Advent Calendar 2011もついに18日目ですね。ゴールまであと少しです。 まずはSassリファレンスの!defaultを扱っている部分を読んでみましょう。参考にざっと以下に訳してみました。 変数の値を指定する時、!defaultというフラグを付けておく

Inlining critical CSS for first-time visitsという、クリティカルCSSを初回訪問時のみインラインに展開して、その後はインライン化せず予めキャッシュさせておいたフルセットのCSSを使うというアイディアについての記事を読んだ。実装はともかく、アイディアとして成立していないんじゃないかと思う。 クリティカルCSSをインライン化することのメリットは既に多くのウェブサイトでも取り上げられており、もちろんネタ元のGoogle PageSpeedでも項が割かれている。ここでは特に触れないが、描画領域の大きさにかかわらず初期描画の高速化には大きなメリットがあるとは言えるだろう。上記リンク先の記事ではそれを動的に行うことで、2度目以降の訪問の時にはキャッシュ済みであるフルセットのCSSを使わせるようにし、効率的なキャッシュ運用と保守性を実現する実装について解説されて

1emが必ず16pxになることに対して、chとex単位ではフォントによって変化している。それぞれのフォントのグリフの特定のパーツ、ch単位では0の幅、ex単位ではxの高さ(とされるx-height)、が考慮された上でpx単位に変換され、計算済みスタイルの値となっていることがわかる。Impactのようなx-heightがかなり高く設定されているフォントではex単位で大きく差が出てくるというわけだ。 このことは普通にCSSのプロパティーの値として使う場合はあまり問題になることはない。しかしながらブラウザー以外の何らかのツールで扱おうとすると一定の決めつけが必要となる。そうでないとフォントを調べて係数をひねり出さなければならなくなるからだ。 少なくともメディア・クエリーにおいては初期設定の値を基準として変換されることになるので、Arial (やHelvetica Neue)を基準にした係数を使っ

専用バージョンのウェブサイトとレスポンシブ・ウェブ・デザインによるウェブサイトの優劣が語られることは多い。そういった場合、どちらが優れているのか、またはどちらが劣っているのか、を思想的な面でも技術的な面でも比較される。その過程で両者があたかも排他的な関係であるようによく語られるが、両者が解決するもの、したいものは違う。 単一のHTMLやCSSで完結することや、それに伴うテストの簡略化や不可欠なツールの削減あたりが、レスポンシブ・ウェブ・デザインがもたらす主なものだろう。もしかするとバックエンドとのやりとりもシンプルにできるかもしれない。つまりコードやビジュアル・デザインのレベルではなく、ウェブサイトの構築というレベルにおいてシンプルにしてくれるということだ。 レスポンシブ・ウェブ・デザインは主にこういったコンテンツとウェブページの間における問題を解決するために採用するものだ。 その一方でウ

ESLintできれいに拾えるので、スコープ内でvarの先頭出しをやるようにしようかなという気分になっている。その過程でA criticism of the Single Var Pattern in JavaScript, and a simple alternativeという記事を読んだ。デバッガーでステップ実行しづらいという話はともかく、カンマ忘れでセミコロンの自動補完が起こり、変数のグローバル化をもたらしてしまうというのは印象的だった。 var foo = 'Foooo' bar = 'Barrr', baz = 'Bazzz'; このように一行目のカンマを忘れてしまうと、意図せずbarとbazがグローバル変数になってしまう。この手のエラーもリンターで拾えるとはいえ、見逃してしまった時のことを考えると、こうは書きたくなくなる。 最終行がコメントアウトしづらいというような瑣末な問題があ