3つのウェブサイト
知人と「3つだけウェブサイトを購読できるアプリがあったら何を登録する？」という話になった。3つとなると選んだウェブサイトで自分の性格や興味が如実にあらわれそうだ。つまり3つのウェブサイトで自分を表現するという形になるのかもしれない。そう考えたのでその場では保留にした。 ひとりで1時間ほど考えた結果、以下の3つのウェブサイトになった。 QuirksMode Little Big Details Lovely Package それぞれ今の自分の興味と知識、そして楽しさにすごく近いところがテーマになっているウェブサイトだ。ウェブ標準、ユーザビリティー、そしてビジュアル・デザインというキーワードを割り当てることもできる。それぞれ更新が楽しみなことはもちろん、ほとんどの記事を数回は読み返している。 例えばフロントエンドの人たちはLittle Big Detailsの全記事を一度ながめてみると良い。英
スタイル・ガイド・ジェネレーターについて
僕は以前からJavadocを踏襲した形のスタイル・ガイド・ジェネレーターには構造的な欠点と思想的な欠点を持っていると考えている。実際にはスタイル・ガイドを中心としたウェブ制作体制をよく利用すること、そしてその中での作業を自動化してくれるであろうジェネレーターには期待していること、はあらかじめ断っておきたい。 構造的な欠点は、コメントとして埋め込まれることになるであろうHTML断片が重複しやすいこと、だ。コンポーネントという単位ではまず重複することはないが、コンポーネント間で共有するクラスでは必ず重複することになる。もちろんコメントに埋め込むコードは短いもので、場合によっては軽量マークアップ言語を利用できるため、コストとしては微々たるものだ。しかし単純な繰り返し作業を省力化するための自動化ツール(ジェネレーター)が、そういったまた別の単純な繰り返しを強いるというのはどこかがおかしいと感じる。
モダンとクラシックをとりもつスタイル・ガイド
既にあるウェブサイトの実装を、今後を意識してモダンにしようとすると、どうしても既存のクラシックな何かしらの置き換えが必要になる。多くの人が作り始めているであろうスタイル・ガイドはそういった時に役に立つ。現状での保証された結果を提示してくれるからだ。 クラシックな何かしらの置き換えが必要になった場合、その目的をきちんと知る必要がある。そうでないと正しくモダンに置き換えることができない。すべてをフルスクラッチで書き直すといった場合でも、少なくともクラシックな何かしらによる結果を知る必要があるだろう。 スタイル・ガイドは良くも悪くも結果に過ぎないが、ちゃんとした結果であることは保証されている。それをきちんと作っておけばとあるコンポーネント(とでもいうようなもの)がどのような意図を持ったものかを具体的な実装を知ることなく理解できるはずだ。 ちゃんと作られたスタイル・ガイド、というとかなり大げさだが
画像配置の自動化とその本当の目標
ウェブページにおいて図であったり飾りであったりする画像の配置はCSSを通して行う。多くの場合はクラスとしてパターン化した配置のひとつを要素に割り当てることで行うわけだが、これを自動化したい。具体的に言えば、画像の縦横サイズやアスペクト比、キャプションの有無に基づいて最適な配置を自動で行い、手作業で要素にクラス名を振らなくて済むようにしたい。 紙媒体の場合は物理的な制限があるので、文章が収まるようにレイアウトを決め、それに合うように画像を作成し配置するという形が多い。ウェブページでも同じように行われてきたが、物理的な制限は違う形のもののため、レイアウトは別の形で自由に行えるのではないだろうか。 また画像そのものにはその最適解が別にあるはずだ。写っているものの最も良い状態を求めて作成し、配置はその画像で伝えたいことが存分に伝わるように、かつ本文のバランスを崩すことなく配置できると良い。そういっ
遅延読み込み用のぼやけた画像
Mediumでとある記事を高速にスクロールして読んでいたら、さりげなく画像を遅延読み込みしていることを知った。読み込み発火のタイミングがうまいのかあまり遅延読み込みの存在を感じさせないのもすごいと思ったが、プレースホルダー画像の実装方法が良さそうだった。単純に元の画像を幅30px程度まで小さくしてそれをブラウザーにリサイズさせることでぼやけた画像をプレースホルダーとして表示しているだけだが、十分に機能していそうで目から鱗だった。 画像の遅延読み込みはなかなか曲者で、読み込むタイミングやプレースホルダーとしている画像が悪いと大きくユーザーにストレスを与える。プレースホルダーでよく使われるローディング画像は読み込み中のインジケーターではあるが、同時に何か遅いことをやっていますというネガティブな印象も与えてしまう。ユーザーはローディング画像を見るとスクロールを止めなくてはならないのかと感じること
Formspree
Infield Top Aligned Labelの実験がてら、Formspreeでコンタクト・フォームを作成して設置していた。Formspreeは登録不要で使えるメール・フォームの設置をサポートするウェブサービスだ。提供するのはほぼエンドポイントのURLのみで、それに自分のメール・アドレスを追加したURLへPOSTするフォームを作るだけで設置が完了する。 設置完了後に1回だけ自分で設置したフォームを使いメールを送信すると、設置したURLとメール・アドレスの紐付けを確認するメールが来る。その手順に従い確認すると、あとはそのフォームで送られた内容が指定したメール・アドレスへ転送されてくるようになる。 Infiled Top Aligned Labelの実装では多少複雑な形になっているが、それほどややこしくもしなかった。複数列にしたのでFlexboxを使う方が良さそうだったが、結局floatと
我慢の期間
MovableTypeとWordPressとJekyllとHugoや、Gruntとgulp、SassとLESSとStylus、果てはjQueryなどの話はスケールやパターンを変えて繰り返される。その話はあたかも特定の何かに依存することが良くないとか新しいこっちのがすごいぞというように結論づけられることが多くて、僕にはちょっと頷けないこともあったりする。大切なのは何を解決しようとしていたかを忘れないことだと思う。複雑化しそうな場合にそこから先へ踏み込まずに我慢する期間がいるとかかも。 GNU makeでいいじゃん的な結論はそれは確かにビルドという点ではそうなんだけど、Gruntが解決しようとしていたのはそこじゃない。npmという生態系の中で完結させやすいタスク実行環境を手軽に用意することができることで、それ以上でもそれ以下でもない。実行速度以外にも腐臭を放つAPIやプラグイン間で一貫性のない
“マークアップ”するということ ～ HTML5勧告に寄せて ～
HTMLを適切な要素を使って書いていくことは実はそれほど難しくはない。しかし過剰に要素を使わずに、かつスタイリングすることも意識して、と適切に“マークアップ”するのはなかなかの修練を必要とする。いったい“マークアップ”するということはどういうことなのだろうか、そしてどのような思考の元に行えば良いのだろうか。 HTML5での変化 著作権表示のマークアップ small要素 footer要素とsmall要素 p要素とdiv要素 footer要素とp要素 スタイリングとの兼ね合い マークアップするということ HTML5での変化 コンテンツに則した素直な形でマークアップできること。 HTML5で変わることや変わったことは多くあるが、それらをおおまかに俯瞰するとこのような言葉に集約できる。そのために様々な要素や属性が追加され、既存の実装をなるべく壊さない形で要素の意味に変更が加えられた。これらの変化は
透過PNGをSVGを利用して軽くするテクニック
透過PNGは現状では唯一に近いフルカラーの透過画像を作成する手段だが、ファイル・サイズが大きくなりがちだ。対してJPGはファイル・サイズという点で大きく優るが、透過することは出来ない。このあちらを立てればこちらが立たずの問題をSVGのマスク機能を使って透過だけを受け持つPNGとJPGを組み合わせることで両立させるテクニックを知った。 透過させた画像をまず普通に作る。それから透過してないJPG画像と、透過を反転させてマスクに使うPNG画像を生成する。それらをHTMLでSVGのmask要素をインラインに書くことで組み合わせる。ベースとなるJPG画像が一般的にファイル・サイズに優れ、マスクに使うPNGは空白が多いこと、SVGの記述はごく短いもの、というわけで最終的に低ファイル・サイズが実現できる。 SVGのセキュリティ上の制限により、HTMLにインラインで記述するケースでしか使えないのでCSSの
PostCSSとCSS MQPacker
PostCSSというCSSのパースと変更を行うNode.jsパッケージを知った。Autoprefixerで使われている。名前からわかるように、主にCSSをポストプロセスするためのパッケージだけど、単にパーサーとして使っても良さそう。 習作ということでメディアクエリをまとめるライブラリ、CSS MQPackerを作った。パース結果のオブジェクトを把握するまでがちょっと時間かかったけど、その後は特に難しいことはなく、快適にCSSポストプロセッサーを書けそうな予感がする。 PostCSSのparse()を呼んだ返り値やprocess()で呼ばれる自前の関数に渡されるオブジェクトは、その子の配列rulesの各要素にルールセット(かメディアクエリなど)が格納され、それらは以下のような構造になっている。 { type: 'rule', decls: [ { type: 'decl', parent:
書きやすい・読みやすい・優しい
およそコーディングにおいては書きやすさが重視される傾向が強い。例を挙げるまでもないだろう。しかし、その書きやすさは主観的なものであることが多く、他人の読みやすさへは寄与しない。読みやすさにも主観的な面はあるが、それでも落とし所というものはある。ただ、そういった読みやすさは人間へのもので、機械とそれを通して利用することになるユーザーに優しいとは言えないことが多い。これらすべてを満たす夢の書き方みたいなものは、特にフロントエンド開発においては、なかなか存在しない。 開発においては以下の様な形でワークフローを構築したい。それぞれの段階で対象になる人が違うことが重要だ。 自分が書きやすい形でのコーディング 他人が読みやすい形でのレビュー ユーザーに優しい形でのデプロイメント CSSの開発においてこれらに対応するものを具体的に挙げると以下の様になるだろう。 Sass・CSSCombなど ウェブ標準仕
Sassでの色管理
Sassでは色を変数として定義でき、また様々な関数でそれを操作することが可能になっている。そのため色を論理的に管理することが可能になっているが、これといった手法が確立されているわけではない。このウェブサイトでは少しややこしい形で管理するようにしている。どういう目的でこういう複雑な構造になっているのかを簡単に書いておきたい。 基本色の定義 基本色、つまりテーマカラーであったり、本文の背景色や文字色といった見た目のイメージを決定する色は、色コードを直接指定して定義する必要がある。これはほぼ間違いなくみんな同じように書いているだろう。 $color-dark: rgb(60, 51, 48); $color-light: rgb(252, 249, 240); $color-accent: rgb(17, 136, 187); これらは背景色であったり文字色、そしてリンクの文字色として使っている
calc()とvw単位を使った飛び出すpre要素
飛び出すpre要素っていうのは昔書いた描画領域一杯にpre要素の幅を拡大するテクニックと目指す見た目は同じもの。以前考えたものはちょっとの間使ったもののバグが多くすぐやめた。このテクニックは大きい要素を左右に付け、はみ出した部分を隠すというものだった。それをvw単位を使ってビューポートの幅を取り、それとcalc()を組み合わせることでどうにかしようという試み。 Demo: Expand pre Element #2 pre要素の左右が#f0fの矩形で埋められている。Chrome 35、Firefox 30、そしてInternet Explorer 11で確認できる。Mobile Safari 7ではうまく動かない(多分vw単位の問題のような気がする)。わかりやすいように左右に追加する擬似要素の背景の色を変えておいたけど、同じ色にすればあたかもpre要素が飛び出すように見えるはず。 .tes
Bitbucketでの執筆
WEB+DB Press Vol.81の特集はBitbucketでプライベート・リポジトリを使って書いた。最初はメールで詰めて、書く段階になってBitbucketへ作業場を移すという形だった。Gitを使った執筆のメリットはそこかしこで色々と触れられているので、実際に体験してのネガティブな感想を少しだけ書く。 最初からBitbucketが良かった メールだと後で読み返すのが非常に面倒くさいので、トピックごとに整理しながら最初からプライベート・リポジトリでやれれば良かった。特に書き始めから最初のレビューまでちょっと間が開いたので、記事がメールでのやりとりと矛盾しているかどうかを確認するのが大変だったため、参照しやすい形で残っていれば……と強く感じた。 また、トピック・ベースでの作業なら粒度も下げやすかったと思うので、コミットを追うのも楽だったはずだ。 レビュー BitbucketのDIFFビュ
WEB+DB Press Vol.81 イマドキHTML/CSS開発
6月24日発売のWEB+DB Press Vol.81にて「イマドキHTML/CSS開発」というタイトルで特集を執筆した。特集では機器や周辺技術の変化と進化がもたらす多様性に、今までのような現状の機器への逐次対応という視点ではなく、未来のそれらを見据えた形で相対するにあたっての考え方や実装方法を解説している。具体的には検証可能な「コンポーネント」という単位をどう作り、それをどう扱うか、だ。 「マルチデバイス」というイマドキの事情 独立性を重視した設計 コンパクトな開発サイクル デバイスの特徴を活かしたUI 環境に左右されない画像 特集はこのような形で構成されている。現状の説明から始まり、コンポーネントの設計から、その実装をまず解説し、それらの自動化・最適化・効率化について、コンポーネントごとに実装から検証までを行う小さなサイクルを中心に据えたワークフローへの変革を絡めて触れていくという形に
安全でアクセシブルなアイコン・フォント
Translation of: Bulletproof Accessible Icon Fonts by Filament Group アイコン・フォントを利用する場合、あらゆるユーザーに適切にアイコンを提供しようとすると、かなり気をつける必要があります。そのフォントが読み込まれなかった時にどうなりますか？@font-faceがまだサポートされていないブラウザーでは？ どうすれば安全に(bulletproofに)アイコン・フォントを利用できるかをこれから解説したいと思います。 効率的で機能的なウェブサイトを制作するという、この終わることのない探求において、ベクター形式のアイコンを提供する手段として、簡便であるフォントを利用することが何度も提案されてきました。対して私達は通常ベクター形式のアイコンとしてSVGをIan Featherがブログ書いたような理由から選んで(また、薦めて)おり、既に
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
v6.15
ブラウザーのサイズによって文字の大きさを少し変えるようにしたので、それに合わせてemを使ってレイアウトするようにした。縦のリズムもちゃんと計算してやろうかと思ってるけど面倒になってきた。やって思ったのはやっぱりcalc()が必要ということ。違う単位を混ぜられるのはとても手軽だ。Sassでも無理だし、将来的にもできるようにならないし。faviconもちょっとだけ変えた。 カラム定義 カラムは本文を9カラムで48em程度にしたかったので以下のようにした。 $column: 3.5em; $gap: 1em; これで9カラムで47.5emになる。Style Guideだとそこらでダブルクリックするとカラムがオーバーレイ表示されるようになってる(_grid-overlay.scss使った)。12カラムが収まる場合はマルチカラム……にしたかったけど、とりあえずはタイトルや日付けをちょっとずらすだけに
アクティブなナビゲーション項目とmark要素
アクティブなナビゲーション項目、つまり現在のページへのナビゲーション項目はclass属性を使ってactiveなどと付けられることが多い。特に間違ってはいないんだけど、いまいちピンとこない。というかしっくりこない。大体は流されてそうしているけど、このウェブサイトではmark要素を使ってる。 HTML5仕様ではmark要素は以下のようになってる。 The mark element represents a run of text in one document marked or highlighted for reference purposes, due to its relevance in another context. mark要素が含まれる要素のコンテキストとは別のコンテキストでの関係性をハイライト等で表したい時に使うと解釈してる(同じコンテキストならemやstrong、そしてb
リンクの下線の再発明
少し前までは「リンクの下線を消すな、いやでも消したい」みたいなことしか話題にならなかったのに時代は変わったなどということをMediumのためのリンクの下線の再発明といった趣向の記事を読んで思った。僕も以前これと似たような方法(後述)でリンクの下線の再実装を行ったことがあるので、楽しく読んだ。この辺りの制御を行うCSSプロパティー達の実装が後回しにされてる現状は悲しい。 僕はborderで線を引いた擬似要素を絶対配置するというような手法で行っていた。 .entry-content a { position: relative; color: inherit; text-decoration: none; } .entry-content a::after { border-bottom: 1px solid #f0f; display: block; position: absolute;
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
