普通のHTMLの書き方
保守しやすく、規模に依存しないHTML文書のために 一般 DOCTYPEで始める 置き換えられるべきまたは旧式のDOCTYPEを使わない XML宣言を使用しない 文字参照はできる限り使わない &と<、>、"、'は名前文字参照を使ってエスケープする 制御文字や不可視文字は数値文字参照を使う コメントではその内容の前後へ空白文字を置く 終了タグを省略しない 空要素の書き方を混ぜない タグや属性値の前後へ空白文字を置かない 大文字・小文字を混ぜない 引用符を混ぜない 属性を2文字以上の空白文字で区切らない 真偽値を取る属性の値は省略する 名前空間は省略する XML属性は使わない data-*とMicrodata、RDFa Lite用の属性と通常の属性を混ぜない デフォルトの暗黙のARIAセマンティックスを尊重する 文書要素 lang属性を追加する lang属性の値はできる限り短くする できる限り
遅延読み込み用のぼやけた画像
Mediumでとある記事を高速にスクロールして読んでいたら、さりげなく画像を遅延読み込みしていることを知った。読み込み発火のタイミングがうまいのかあまり遅延読み込みの存在を感じさせないのもすごいと思ったが、プレースホルダー画像の実装方法が良さそうだった。単純に元の画像を幅30px程度まで小さくしてそれをブラウザーにリサイズさせることでぼやけた画像をプレースホルダーとして表示しているだけだが、十分に機能していそうで目から鱗だった。 画像の遅延読み込みはなかなか曲者で、読み込むタイミングやプレースホルダーとしている画像が悪いと大きくユーザーにストレスを与える。プレースホルダーでよく使われるローディング画像は読み込み中のインジケーターではあるが、同時に何か遅いことをやっていますというネガティブな印象も与えてしまう。ユーザーはローディング画像を見るとスクロールを止めなくてはならないのかと感じること
WebhookからPubSubHubbubへの翻訳
少し前に公開されたIFTTTのMakerチャンネルを使って、GitHubリポジトリーのWebhookをPubSubHubbubの公開POSTリクエストに翻訳するようにした。GETを使った公開リクエストがあまり行儀が良くなさそうなことが前から気になっていたので、Makerチャンネルを使えば良いかなと試したところうまくいった。 Makerチャンネルの有効化 まずはMakerチャンネルのページへ行き、Connectボタンを押す。するとユーザーごとに専用のエンドポイントURLが作成されるので、How to Trigger Eventsというリンクをクリックして、それを確認しておく。 https://maker.ifttt.com/trigger/{event}/with/key/{secret_key} エンドポイントURLはこのような形になっている。{event}は後ほど好きに指定することになる
display: noneとレスポンシブ・ウェブ・デザイン
レスポンシブ・ウェブ・デザインとその設計を語る時にdisplay: noneが引き合いに出されることが多いなと感じる。その多用は設計ミスというような具合だ。そういうところは確かになくはないが、多用自体はCSSの貧弱さからくるHTMLの複雑さを意味するだけなのではないかと思う。 レスポンシブ・ウェブ・デザインはコンテンツを様々なデバイスで「収まる」ようにレイアウトを調整することではない。実装としてはそうなることは多いが、実際には多様なデバイスでのコンテンツの一貫性を確保するアプローチであると考えた方が適切なはずだ。その一貫性とはほぼコンテンツへのアクセス性と言って良い。様々な画面でそれを同じように確保するためには、レイアウトの調整だけではなく、構成部品の間引きや移動などが必要となる。 そういった一貫性の確保を同じHTMLを通して行う、とすると実装はほぼCSSに限られることになる。そして今のC
ウェブデザインにおけるセマンティック・バージョニング
アプリケーションの世界ではセマンティック・バージョニングが広く受け入れられた……かどうかはわからないが、採用例はすごく増えている印象だ。ウェブデザインではどうかというと、ウェブ・アプリケーションのバージョニングに追随しているだけであったり、そもそもバージョニングされていなかったりするような気がする。ウェブデザイン、主にCSS(とCSSプリプロセッサー)においてセマンティック・バージョニングを導入するとすると、どのようなタイミングでメジャー、マイナーそしてパッチ番号を増やせば良いのだろうか。 セマンティック・バージョニングの中心となる概念は後方互換性だ。後方互換性が: 失われる: メジャー 失われない新機能の追加: マイナー 失われない修正: パッチ 数語でまとめるとこのようになるだろう。ウェブデザインにもこれを当てはめるとすると、ウェブデザインにおける後方互換性とは何なのかということをまず
Style Guideから始めるウェブデザイン
Matt Steeleという人のウェブサイトのリデザインについての記事を読んだ。海外では中々の人気を誇るExpression EngineからDB不要のフラットファイルなCMSであるStatamicに乗り換えたというのもイマドキだなーと思ったけど、まずStyle Guideを書いてそれを元に作っていったというのが、自分の作り方と重なる部分が多くて印象的だった。 実際にはSketchやInkscape等のベクター画像編集ソフトウェアでデザイン・カンプと想定されるコンテンツをマークアップしただけのスタイル・ガイドを作成をまず作成し、適宜クラスやどうしても必要なdiv要素を追加しつつCSSを書くという作業フローなんだと思う。もちろんSketchの前に紙でのプロトタイピングとかがあっても良い。デザイン・カンプをHTMLで再現するというこれまでにもあった作業フローとは似て非なるものである、というあた
right: 100%か負のマージンか
これまでCSSにはレイアウト方法があまりなかった。これからはFlexible Box LayoutやMulti-column Layout、Grid Layoutを始め、positionプロパティーに使える値の拡充などもあり柔軟に行えるようになるだろうが、それはけっして既存のレイアウト方法が不必要になるということではない。選択肢が増えると受け止めるべきだ。例えばright: 100%や負のマージンを使って親要素の外側左にレイアウトする手法はそのまま使い続けることになるだろう。 ほとんど同じレイアウトを実現するright: 100%と負のマージンの使い分けを通して、レイアウト方法の選択をどう行うべきかという基本的な思想を解説することにより、今後増えてくるレイアウトの選択肢にどう相対すべきかがわかるのではないかと思う。そしてそれはCSSプロパティーの意図された使い方を理解するということでもある
CSSポストプロセッサー時代の到来
SassやLESSといったCSSプリプロセッサーは市民権を得たと言って良いと思う。しかしそれらCSSプリプロセッサーは開発という段階にのみ利をもたらすもので、今のところはそれ以上ではない。CSSを実際にユーザーに届けるまでには、開発だけではなくレビューとリリースという段階もある。レビューとリリースも確実性を持って効率的に行うためには、CSSポストプロセッサーと総称されるようなツール群が必要になるだろう。 この文書はFrontrend Advent Calendar 2013の4日目への記事として寄稿した。明日は@hilokiさんがスタコラサッサと書くようだ。 目次 CSSポストプロセッサーとは CSSプリプロセッサーの出力するCSS CSS Lint 開発用とレビュー用、リリース用のCSS CSSポストプロセッサーのユースケース ベンダー拡張プリフィックスの付加 Media Queries
インターレースPNG
PNGファイルを書き出す時にインターレースPNGにすると、ファイルサイズ増えるけど、表示の体感は速くなる。また、ウェブページにおいては最初に画像の大きさ分だけ確保されるので、リフロー(レイアウト)を抑止できる。レスポンシブ・イメージとまでは言えないけど、多少はみんなに公平に優しい気がするので、ファイルサイズをケチらずに、すべてインターレースPNGにしてしまうのが良い気がする。デメリットも特に知らない。 新たなPNGファイルならば書き出し時にインターレースPNGにすれば良いけど、既存のものを手作業で修正しようとなると面倒くさい。optipngにインターレースPNGに変換するオプションがあるので、それを使って処理すると良い。 $ optipng -i 1 -strip all *.png ついでに消し忘れているかもしれないメタデータの削除も行うと、ファイルサイズが節約できて幸せ。メタデータの削
GitHubのエラー・ページ
GitHubのStyleguideにエラー・ページのセクションがあるのを知った。それによると外部ファイルに依存しないように書いているらしい。CSSはstyle要素で、JavaScriptはscript要素で、画像ファイルはBase64エンコードしてData URIで、それぞれHTMLに直接埋め込むというスタイル。 実際に404のテンプレートでもちゃんとそうなっていた。フロントエンド脳なので、HTTPリクエストを減らして、エラー・ページのコストを下げたいのかなと単純に考えてしまったけど、Not Foundの連鎖を避けることとか外部ファイルがCDN経由の場合の確実性を上げることとかの方が強い理由のようだ。エラー・ページを単独で機能するようにしておき、エラー時に余計な負荷を与えないようにすることにより、より速やかに復帰できるように、ということになりそう。 HTTPエラー・ページの意味も重要だけど
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. つまりユニークなため再利用できないというマイナスの面がある、と。確かに再利用できない。でもこれはマイナス
CSSのルールセットの可搬性
シンプルなセレクターが多くの利点を持つことはよくわかるんだけど、可搬性が上がるというのはどうもしっくりこない。ルールセット単位での可搬性というのはかなり無理があるんじゃないか。数種のプロパティーの組み合わせを再利用するのは良いけど、それにセレクターは含めると可搬性落ちると思う。 Twitter Bootstrapのような完全にそれに依存してそれだけで完結するような仕組みならばシンプルなセレクターのルールセットの可搬性はかなり高いと思う。ただその可搬性はデザインの断片の可搬性ではなくデザイン全体の可搬性ということになる。レイアウトのリズムや細かいディテールも含めた完全な移植で、○○の△△を流用したいとしてもそれを含むルールセットを持ってくれば済むという事にはならない。そのルールセットに余計なプロパティーが含まれていて要編集だったり、他のルールセットに依存していて単体ではうまく機能しないことが
次はこれ読んで
MovableTypeにあったからか前や次のエントリー(とそれに加えてウェブログのトップ)に移動するリンクをpermalinkに設置するウェブログは多い。こと日本に限ると90%以上のウェブログにあるように感じる。このクラシカルなパターンに対して、最近はRead This Nextなどとして最も関連性が高いエントリーをひとつだけ推薦したり(Dustin CurtisとかSvbtleネットワークのウェブサイトはそう)、単に時系列的に1つ古いエントリーへのリンクのみというパターンが増えている。 次にこれを読むと良いんじゃないかなー 特にSvbtleで採用されている最も関連性の高いエントリーをRead This Nextとして推薦するというのは、トピックがバラエティに富んでいて時系列における前後にあたるエントリーと関連性が薄いことが多いウェブログには向いていそう。つまり企業やプロダクトではなく個人
::beforeによる(画像)置換の終焉
なんだか最近のGoogleのペンギン先生は::beforeや::after擬似要素で仕込まれるモノもバッチリ解釈するとかいう噂(本当か嘘かは知らない)を聞いた。スクリーンリーダーも読んじゃうらしい。ここのロゴは::before擬似要素でHを一文字挿入して実現していたので、もし解釈されるとなるとウェブサイトのタイトルが「Hhail2u.net」になってしまう。 特に::beforeや::after擬似要素に限った話ではなく、古き良きtext-indentプロパティーによるものやattr()関数とかでも問題が起こるという話だと思うので、画像置換とその類のテクニックはもう本格的にアレな時代なのかもしれない。別の方法を……といってもCSSが解釈されて隠したり改変したりするのもチェックしてるという話なので、CSSでどうにかしようというのは無理がある。::before擬似要素でcontentプロパティ
2012年のMedia Queries
2011年にはMobile Firstという手法が浸透した。当初は多分に技術的な事情によるもので、先に低解像度向けのスタイルを書くことによって、高解像度向けのスタイルで使われる大きな画像を読み込まれないようにするというテクニックでしかなかった。しかし、結果としてコンテンツ重視でCSSを書きやすくなることがわかり、急速に浸透することになった。Media QueriesはそんなMobile Firstの中核をなす技術だが、その使われ方は限定的なもの(ほぼmin-widthとprintだけ)だ。2012年にはそこらへんも変わってくるんじゃないかと思う。 @media screen and (min-width: 481px) { /* do something */ } こういった強く「スマートフォン」を意識した書き方をするのではなく、コンテンツに応じて切り替えポイントを探る必要があるだろう。例
SVGよりアイコン・フォント！ な理由
両者は共にスケーラブルなもの(にできるもの)なのでその点では互角だけど、様々なプロパティーを持ち多彩な表現が可能なSVGの方がフォーマット的には優位にあると言って良い。が、なかなか利用が広まらないSVGに対して、アイコン・フォントの利用は急速に拡大している。単に流行りとみなす向きもあるけど、やっぱりそれなりに理由があるのではないかと思う。 CSSとの親和性 特に以下の3つのCSSプロパティーは効果的に使える。 font-size color text-shadow PNGで作られたアイコンの色を変更するには編集が必要だけど、アイコン・フォントはCSSファイルで自由に色を調整することができる。独自実装も含めるなら-webkit-maskプロパティーもとても(想像以上に)効果的に使うことができる。他にもちょっとした位置の調整やなんかも慣れ親しんだCSSで普通に可能。更にこれらをHTMLファイル
BODUM CANTEEN 0.4L
愛用していたthermo mug 3287のステンレス部分が細かい傷だらけになってしまい、漂白してもすぐ茶渋等が付いてしまうようになったので、BODUMのダブルウォールのマグ、CANTEENの0.4リットル版を買った。 取っ手もガラス製。ダブルウォールなので見た感じよりは軽い。飲み口の部分は広く、ちょっと厚め。底が少し細くなっているので安定は良くはないが、悪くもない。0.4リットルなのでかなり深く、長めのスプーン必須。公式のサイトの画像は異様にキレイに写っているけど、アレをイメージしてると裏切られる。ちゃんと洗って磨けば安っぽくは見えなくなる程度にはキレイ。底にはシリコンの穴塞ぎがあるので、洗う時は気をつけた方がよさそう。 0.4リットルくらいでダブルウォールのマグとなるとあまり選択肢なかった。ダブルウォールのマグは最近増えてきたような気がするけど、ほとんど0.3リットル以下。Amazon
Lea Verouのフレシキブルな複数行定義リスト
Lea Verouの編み出したフレキシブルな複数行定義リストは目からウロコだった。このテクニックを知るまではfloatを使うと長い時(コンテンツ幅に収まらない時)に途中で改行とかうまくできないけどまぁしょうがないか……みたいな感じで我慢していた。LF(やCR)を擬似要素経由で挿入してwhite-space: preで改行させてしまうというのは頭良い。ただ複数のdd要素を持つケースにはうまく対応できないのでちょっと変えて使い始めた。 このテクニックはつまりdt要素とそれとセットになったdd要素を一行に並べるというもの。表的なものならばそれは単にマークアップが間違っているのでtable要素でマークアップし直した方が適切だけど、dl要素のが適切なケースも多くあるのでこのテクニックが生かされる場面は多い。 dt, dd { display: inline; } dd + dt:before { c
Soma FontFriend
Google Web Fontsのテストはまじめにやる時はちゃんとテストページを作って確認してるけど面倒くさい。Google Web FontsのPreview Textは日本語使えないので、日本語部分との相性やベースラインのずれなどが確認できなくて問題外。でもできるだけ手抜きしたいので、そういう時はSoma FontFriendというブックマークレットをこのWebサイトを開いてから起動している。これは結構昔からあるブックマークレットで元々は単にfont-familyを書き換えるだけだった(と思う)んだけど、今のバージョンだとGoogle Web Fontsからフォントを引っ張ってきて確認できる。愛用してる。 Full preview of Soma FontFriend 起動するとこのような画面が左下(画面位置は矢印をクリックすると移動できる)に出てくるので、中央右の一番上にあるGoog
Rainbow
Rainbowはコードのシンタックス・ハイライトをやってくれるJavaScriptライブラリ。拡張の仕組みが凄く書きやすそうで良さそう。名前は悪い。しかもリダイレクト先のURLはrainbowsだし……。まぁとにかく乗り換えようかなとちょっと思った理由をちょっと書いておく。「ちょっと」なのでまだあんまり乗り換える気ない。 書きやすいといっても所詮は正規表現なので、定義フォーマットがGoogle Code Prettifyの黒魔術的なアレよりもちょっとシンプルだとかそういう意味にすぎない。なのでこの点だけでは既存の様々なシンタックス・ハイライトしてくれるライブラリから乗り換えるという程のパワーがあるわけではないと思う。他にもpre要素の子ではないそこらのcode要素のハイライトにも対応している所とかすごいと思うんだけど、おまけ機能的な感じでこれも乗り換えの動機にはならなそう。 僕が乗り換えよ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
