普通のHTMLの書き方
保守しやすく、規模に依存しないHTML文書のために 一般 DOCTYPEで始める 置き換えられるべきまたは旧式のDOCTYPEを使わない XML宣言を使用しない 文字参照はできる限り使わない &と<、>、"、'は名前文字参照を使ってエスケープする 制御文字や不可視文字は数値文字参照を使う コメントではその内容の前後へ空白文字を置く 終了タグを省略しない 空要素の書き方を混ぜない タグや属性値の前後へ空白文字を置かない 大文字・小文字を混ぜない 引用符を混ぜない 属性を2文字以上の空白文字で区切らない 真偽値を取る属性の値は省略する 名前空間は省略する XML属性は使わない data-*とMicrodata、RDFa Lite用の属性と通常の属性を混ぜない デフォルトの暗黙のARIAセマンティックスを尊重する 文書要素 lang属性を追加する lang属性の値はできる限り短くする できる限り
HTMLは開発者たちのために
昔からよく「HTMLの正しさ」というような表現を見る。少し前はHTMLの構造的な完全さや文法的な正確さなどにウェブページの表示やCSS、そしてJavaScriptが依存していたので、そういった点を強く意識する必要があった。Firefoxが親切に教えてくださっていたXMLパースエラーのことを思い出すとわかりやすい。僕も良くそれに類する表現を使っていた。 今はブラウザーとウェブ標準技術が共に進化したので、そういった形式的な正しさはさほど重要ではない。かろうじてハイパーリンクだけがまともな壊れたHTMLでもなんとか修復して解釈してくれる。命名規則ベースのCSSならばHTMLがどうあれうまくスタイルが当たってくれるだろう。足りない機能はDOMツリーの状況をほとんど無視できるShadow DOMでどうにでもできるというわけだ。 HTMLにCSSとJavaScriptを生やしてウェブページが出来ていた
ブックマークのおっかけ
ソーシャル・ブックマークはまだそれなりに機能するが、いまだに追いかけるのが難しい。その中ではてなブックマークのお気に入り機能は出色の出来栄えと言えそうだが、やはりブラウザーであのページを見るのは辛い。かといってRSSリーダーで読むのもなかなか難しいと感じる。HBFavは良いものだが、やはりデスクトップでどうにかしたい。 ストック型では色々試した末にはてなブックマークのお気に入りRSSからIFTTTのEmail Digestに貯めて毎日深夜に送っておくという形でしばらく落ち着いた。RSSリーダーでお気に入りフィード読むのは本当に苦行だったが、相当マシな気もする。特に気が向かなかったら読まずにとっておくこと(未読でプレッシャーかかったりしない)も、捨てることもできる。僕は送る時間を夜中の3時にして余裕のある朝にチェックできるようにしているが、みながウェブページを見てブックマークし終わる午後3時
Sassでの色管理
Sassでは色を変数として定義でき、また様々な関数でそれを操作することが可能になっている。そのため色を論理的に管理することが可能になっているが、これといった手法が確立されているわけではない。このウェブサイトでは少しややこしい形で管理するようにしている。どういう目的でこういう複雑な構造になっているのかを簡単に書いておきたい。 基本色の定義 基本色、つまりテーマカラーであったり、本文の背景色や文字色といった見た目のイメージを決定する色は、色コードを直接指定して定義する必要がある。これはほぼ間違いなくみんな同じように書いているだろう。 $color-dark: rgb(60, 51, 48); $color-light: rgb(252, 249, 240); $color-accent: rgb(17, 136, 187); これらは背景色であったり文字色、そしてリンクの文字色として使っている
Node.jsパッケージ: next-update
next-updateパッケージは、Node.jsパッケージが依存しているパッケージを一時的に最新バージョンに更新し、設定済みのテストを走らせるツール。これによりd(evD)ependenciesを上げても大丈夫かどうかをほぼ確実に確認できる。グローバルにインストールしてコマンドラインから利用する。 Node.jsパッケージのリポジトリで実行するだけであとは勝手にやってくれる。実行すると以下の様にひとつずつ最新バージョンをインストール→テスト→元のバージョンに戻すを繰り返してくれる。 next-update - Tests if module's dependencies can be updated to latest version version: 0.4.5 author: {"name":"Gleb Bahmutov","email":"gleb.bahmutov@gmail.c
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
安全でアクセシブルなアイコン・フォント
Translation of: Bulletproof Accessible Icon Fonts by Filament Group アイコン・フォントを利用する場合、あらゆるユーザーに適切にアイコンを提供しようとすると、かなり気をつける必要があります。そのフォントが読み込まれなかった時にどうなりますか？@font-faceがまだサポートされていないブラウザーでは？ どうすれば安全に(bulletproofに)アイコン・フォントを利用できるかをこれから解説したいと思います。 効率的で機能的なウェブサイトを制作するという、この終わることのない探求において、ベクター形式のアイコンを提供する手段として、簡便であるフォントを利用することが何度も提案されてきました。対して私達は通常ベクター形式のアイコンとしてSVGをIan Featherがブログ書いたような理由から選んで(また、薦めて)おり、既に
Webフォントのホスティング
Webフォントのホスティングのみを提供するようなサービス、つまりWebフォント専用のカスタムCDNを探していた。しかし、Webフォントがメジャーになったとはいえ、そこまでニッチなサービスはあんまりないようだ。代表的なものだとTypeFront。が、かなり制限厳しい。試してすらいないけど、$15/月は払わないとまともに機能しそうもないような仕様だった。 Webフォント専用にこだわらずに、GitHub PagesやDropboxを利用するという手もありそうだけど、Internet Explorer 9以降やFirefox 3.5以降におけるCORSによる制限に対応できない。また、パフォーマンスに難点があったり、Content-Typeでトラブりそうとかも。 Google Drive Google Driveだとどうかなーとテストしてみたら、Access-Control-Origin: *となっ
Gruntべったり
Gruntをよく使うようになったけど、プロジェクトの中心にどっかと存在していると不自由なことが多い気がするなーと感じている。Gruntべったり、つまりプロジェクトをGruntに強く依存させるとポータブルである保証のあるタスクだけを使う(書く)ことを強いられる。Gruntはその雑な自由度が良い所で、そこに何かしらの制限が加わってしまうのはその良さを低減させてしまうと思う。 Node.js自体にクロスプラットフォームだけどさほど書かれるスクリプトのポータビリティを意識した作りになってないような印象を持っている。そのためその上で動くGruntでポータビリティとかなんの冗談だとか思ってしまう。 Gruntの開発チームが公式にメンテナンスしているgrunt-contrib-*は確かに安定して優秀で、大体のことはポータブルなそれらで事足りたりする。だけど簡単なタスクを書いて使いたい時はもちろんあるし、
ファビコン・カンニング・ペーパー
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 -
フォントの読み込み完了を検知する
TypeKitとかがやってるWebフォントの読み込みが終わったらhtml要素にクラス名を振るアレの話。TypeKitがオープンソースでリリースしているWebFont Loaderを使う方法が安全で安定。Googleがホスティングしているのもあるので手軽でもある。でも読み込み完了の検知以外にも機能があってパワフルすぎる気がするので、Adobe Blankを使って自前で書いてみることにした。 Adobe Blankのサイズ削減 Adobe Blankはそのまま使うと30KB以上ある。読み込み完了検知だけなら幅0のグリフが1つあればそれで良いので、まずはサブセット化してサイズを抑えることから。aだけのWOFFなAdobe Blankを作ればちょうど1KBくらいになる。 Download: adobe-blank.woff @font-face定義の追加 外部リクエストにすると意味が薄れるのでDa
grunt-task-helperが良さそう
grunt-task-helperというGruntプラグインを使っている。ざっと言うとsrcとdestを比較してフィルターをかけた結果を他のタスクで使えるようになったりするもの。例えばビルトインの比較機能であるnewFileを使うと、更新されたファイルがあった場合にだけ走るタスクと似たようなものが簡単に作れる。 grunt-contrib-concatを使っているとして、そのタスク設定が以下のようになっているとする。 concat: { options: { seperator: ';' }, prettify: { src: [ 'scripts/prettify/prettify.js', 'scripts/prettify/lang-config.js', 'scripts/prettify/lang-css.js', 'scripts/prettify/lang-scss.js',
Google Chromeのスーパーリロードのメニュー
Crl+F5やCtrl+Shift+Rでのスーパーリロードは有名だけど、開発者ツールを開いているページだと更新ボタンの長押しでメニューが出てくるのは知らなかった。キャッシュ破棄からのスーパーリロードはすでに便利さを体験した。 ハード再読み込みとか普通に通じないと思うので、スーパーリロードにラベル変えて欲しい。
SCSSファイルの組織立て
ファイル間の移動が面倒とか補完が効きやすいからとかいうひどい理由からあまりSCSSファイルを細かく分けてなかった。積極的にplaceholder selector利用するようになったりで見通しが悪くなることが多かったのもあって、もうちょっと組織立ててやった方がいいなとこのウェブサイトのSCSSで色々試してる。変数定義のカテゴリ分けとクラス名の追加・整理、そしてSCSSファイルのパーツ単位での分割まではやった。 色を変更する時は色の変数を格納しているSCSSファイルを編集すれば良い、というような形にするためにバンバン変数を作ってやることにした。そうすることによって設定する基本カラースキームの色は直接CSSプロパティーの値で使わないようになり、論理的な値指定を行えるようにもなる。 クラスの追加・整理は読めないとかよく言われる属性セレクタ使うのやめたのが大きな変更。他にも子要素セレクタとかCSS
適切に改行を行う
ブラウザーはviewportによって折り返しを自動で行なってくれるわけだけど、場合によっては適切ではない位置で行われてしまうのをコントロールしたいという話。見出しをセンタリングしているようなケースで幅によっては一文字だけ次の行になってかっこ悪い！ みたいなのを解消したいということであったり、逆にびろ～んと間延びしないようによさそうな位置で改行を入れたいということであったり。一年くらい前にResponsive Line Breaksと呼ばれるようになった。 具体的なものはResponsive Line Breaksにあるデモやこのウェブログの日付表示の部分とかがそれ。ここではviewportの幅が広い時に良い位置で改行が入るようになっている。 article footer br { display: none; } @media (min-width: 60em) { article foo
utm_xxxを削除してURLの分散をちょっとだけ防ぐ
utm_xxxを利用したユーザー追跡はまぁ便利ではあるのだけど、どうしてもURLの正規化に悪影響がある。設置したツイートボタンやブックマークボタンはこちら側で正規のURLを仕込んでどうにかすればいいのだけど、ブラウザーの拡張やブックマークレットにはどうしようもない。かといってリダイレクトでは訪問者にも管理者にもコストが高いので、replaceState()を使ってURLだけ書きかえるという話。 正規化する関数を発火させるタイミングの制御には色々アプローチがあると思うけど、素で書くといろいろ面倒そうなのでGoogle Analyticsのコードに混ぜることにした。 var _gaq = _gaq || []; _gaq.push(['_setAccount', 'UA-XXXXXX-X']); _gaq.push(['_trackPageview']); _gaq.push(function
Drawic
フッターのアイコンをSVGにした。GitHubにリポジトリも作っておいた。ぴくせる・ぱーふぇくとってなんでしたっけ……。 暗い背景向けの白いアイコンのみだけど、まぁそこは普通のSVGなのでエディターで開いてfillプロパティーの値を変えれば好きな色に変更できる。二種類ある矢印系には全方位を用意しなかったけど、transform属性でrotate()関数を利用して方向を調節できるのでそれで(若干中心をずらしてあるのでtranslate()も併用した方が良い)。 shape-rendering: crispEdges with crispEdges (Left) vs. w/o crispEdges (Right) Deliciousのアイコンはrect要素を組み合わせたものなので、そのままでは拡大・縮小すると端がぼやけることがある。そういう時はみんなが独自実装したCSSのimage-rend
SCSSファイルの整理
SCSSファイルの整理をしてた。Sass 3.2を使い始めて以降、%セレクターをとりあえず使ってみる感じが多かったけど、ようやくどういうものに使うべきでどういうものに使うべきではないのかがわかってきたような気がする。というわけで現在のこのWebサイトのスタイルの構成のメモ。 関数 変数 Webフォント プレースホルダー・セレクター IDやクラス指定のないHTML要素 normalize.css ページを構成する要素のデコレーション ページを構成する要素のレイアウト その他ウィジェット 印刷向け 関数はどこで使われるかわからずプライオリティが高いので最初にインポート。それから変数を定義して、それを使ってスタイルを書いていく。Webフォントは変数のところでインポートして定義するようにした。Sass 3.2ではCSSの@importディレクティブを自動的に先頭に移動してコンパイルしてくれる機能が
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)があ
Sassの存在意義
SassはCSSの貧弱さを補うような便利機能について取り上げられることが多い。そのためその機能の奥に隠れているものについて触れられることはあまりない。例えば変数や四則演算、関数によって値に論理的な意味を持たせることができることとか。そういうCSSに足りない概念の導入できることとかももちろん周知させたいけど、それ以上にHTMLとCSSによるWebサイトの作成に新たなアプローチが加わることを周知させられればいいなぁと最近思う。Sassの存在意義というのはその辺りに見いだせるんじゃないかと考えているので。もう「CSSグラデーションのミックスイン！」とかスニペットでやれるようなことを推すのはやめたい(やめてほしい)。 現状ではWebサイトは以下の2つのアプローチでしか作成(更新)できない。 HTMLで文書をマークアップして、それに合わせてCSSにセレクターを書く CSSでデザインを定義して、それに
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
