クリティカルCSSの動的なインライン化
Inlining critical CSS for first-time visitsという、クリティカルCSSを初回訪問時のみインラインに展開して、その後はインライン化せず予めキャッシュさせておいたフルセットのCSSを使うというアイディアについての記事を読んだ。実装はともかく、アイディアとして成立していないんじゃないかと思う。 クリティカルCSSをインライン化することのメリットは既に多くのウェブサイトでも取り上げられており、もちろんネタ元のGoogle PageSpeedでも項が割かれている。ここでは特に触れないが、描画領域の大きさにかかわらず初期描画の高速化には大きなメリットがあるとは言えるだろう。上記リンク先の記事ではそれを動的に行うことで、2度目以降の訪問の時にはキャッシュ済みであるフルセットのCSSを使わせるようにし、効率的なキャッシュ運用と保守性を実現する実装について解説されて
クリティカル・パスのCSSなるシロモノ
クリティカル・パスのCSSをインライン化して、描画の開始を早めるテクニックが広まり始めている。数字上は確かに効果的だが、ソーシャル・ボタンの非同期化によるスクロールのつっかかりと似たような問題を孕んでいるのではないかという思いが強い。 世の中にはスクロールをまったくしない人とすぐにする人がいる。しない人はまったくしないので、クリティカル・パスのCSSのインライン化は意味があるような無いようなところだ。効果的になるはずのスクロールする人は、ページが表示され次第とりあえずスクロールするという行動を取ることが多いように思う。その時、非同期で読み込まれたCSSが間に合っていないとかなりひどいことになるだろう。 こういったページ閲覧中のちょっとしたパフォーマンスの低下を避けるためにも、CSSは一気に読ませた方が良いと考えている。非同期化されたJavaScriptによりコンテンツの追加や削除が頻繁に行
普通の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を生やしてウェブページが出来ていた
CSSの単位について
CSSでは単位が色々使えるようになった(なっている)。そのため、ちょくちょく「○○には✕✕単位を使うべき」という記事をよく見るようにもなった。僕は単位は管理の都合で決定し、統一した方が無難だと考えている。 それぞれの単位には疑うことなく向き・不向きがある。しかし向き・不向きを考慮して使い分けをすると、同じサイズを違う単位で表現することになる。とある要素で0.8emと2rem、20pxが同じサイズになる、と考えながらCSSコードを読んでいくのは苦痛だろう。 利用する単位の決定はプロジェクトの種類によって都合の良し悪しがある。ウェブサイトの構成パーツに画像や動画が多い場合、ピクセル・ベースでプロトタイプを考えた方が効率的だ。現状では低コストにアスペクト比を維持したまま適当にリサイズしてもらうことが難しいからだ。となるとpx単位へ統一していった方が紛れがないだろう。逆に文章のコンテンツありきであ
MSYS2によるsasscのビルド
sasscにはMSIインストーラーの野良ビルドがあるが、CLIツールをインストーラーで入れるのは抵抗がある。他にはSublime Text 2向けのsasscの単体実行ファイルが配布されていたりもするが、こちらはコンパイル・エラーが起きた時にエラー・メッセージをちゃんと吐かない。探せば他にも配っている人はいるかもしれないが、静的リンクの実行ファイルが作られるようにMakefileが修正されたらしいので、自前でMSYS2を使ってビルドすることにした。 MSYS2のインストールから、gccとGitのインストール、リポジトリーのクローンと順に行い、makeするだけでうまくビルドできた。手順を説明する必要すらなさそうだ。sassc v3.4.1では静的リンクだと6MBくらいの実行ファイルが出来上がる。 MSYS2は既存の環境にほとんど触れないので、何も壊さない。ホーム・ディレクトリーもWindow
Gandi.netへ移住 - Weblog - Hail2u.net
バリュードメインを使う理由がほとんどなくなってきた上、存在したCSRF脆弱性への対応についてその修正アナウンスが出ないということがあったので、レジストラーをGandi.netへ変更した。ドメインごとにメールボックスが5つ提供されること以外には特筆してメリットはなさそうだが、デメリットもないように感じたためここに決めた。ネーム・サーバーはCloudflareのそれを使っているため、ダウンタイムなしで移住できたように思う。 ドメインにかかる費用は安くもないが高いほどでもない。.comと.netで移管にかかる費用が違うことなど、この辺りの金額についてはPrice Listで事前に確認することができる。 移管作業では少しとまどった。Gandi.netでは事前にアカウントをとりづらい仕組みになっており、アカウントを持っていない状態でTransferページからいきなり移管を申請し始めることになる。あと
ページごとのCSS - Weblog - Hail2u.net
HTTPS＋HTTP/2時代なのでCSSを連結しなくても大丈夫だよ、といった風の記事をよく見るようになった。僕はそういった推測や検証は概ね間違っていると考えている(そのうち検証したい)のだが、一方で小さいウェブサイトではそれなりにうまくいくとも考えている。まずは色々やってみようと、このウェブサイトでCSSを論理的な単位で作るように(分割するわけではない)した。 論理的な単位といっても、ウィジェットごとにCSSを作るのはいかにも小さすぎると感じた。様々なツールもそのような利用の仕方を想定されていないため、それぞれのウィジェットで同じコードを何度も書く必要が出てきたりもするだろう。そういうものをうまくまとめても結局はそのまとめたものを参照するコードが必要になる。 感覚としてはページ(の種類)ごとくらいに分けるのがわかりやすそうだ。例えばウェブログの記事ではこの3種が読み込まれることになる。 c
2015年に見限ったCSS - Weblog - Hail2u.net
去年はCSSグラデーションを見限ったような気がする。CSSグラデーションは便利ではあるものの、実装の差がいまいち想像しづらく思ってもみない結果になることがよくある。SVGでやった方が結果からもテクスチャであるという面からも安定という印象だったため、去年からほとんど使わなくなった。今年はtext-shadowとletter-spacingプロパティー、そして::selection擬似要素を見限った。 text-shadowプロパティー 文字に影を付けるプロパティーだが、あまり有効に使える場面がない。エンボスやべベルの代わりにするには貧弱すぎることや透過しかできず合成モードを持たないことあたりが足を引っ張っている。もちろんいわゆるなんちゃってフラットデザインというレベルだと文字に影を付ける必要がほとんどないことも影響がある。 実際に今年作った・見たウェブサイトで使った・使われていたというのは記
HTTPSにした時に気を付けたこと - Weblog - Hail2u.net
何回かやる必要が出てきそうなので、どういう形でやったのかをアバウトに記録しておく。本当は何もせずできればいいのだけど、世の仕様はそんなにうまくできてはいない。 内部リンク 事前に徹底的に書き換えておくのが良い。内部リンクにはドメインも不要なので/で始まる絶対パスで全部書くように統一するのが楽だろう。 ただしrel=canonicalは色々なウェブサービスから(時々考えなしにプロトコル・スキームから始まっていると仮定されて)使われるため、http:から始める方が安全かもしれない。そもそもFacebook向けのOGPでog:urlを書いている場合もあり、この類もプロトコル・スキームから始める必要があり、どうせ書き換える必要は出てくる。諦めて機械的に書き換えができる仕組みを作っておくのも良い。 このウェブサイトの場合は、OGP他を消した上で全て絶対パスにしておくという手法を取ったが、おすすめしな
Dropboxの(S)CSSスタイル・ガイドの所感 - Weblog - Hail2u.net
Dropbox社内のスタイル・ガイドを読んでいた。スタイル・ガイドとなっているがCSSのコーディング規約の方のスタイル・ガイドだ。最近のシンプル回帰の傾向と違い、かなり厳しいようだ。完全に守ってるとしたらかなりすごい。 特に特徴的だったのはCSSプロパティーの記述順だろう。近頃は「もう面倒なのでアルファベット順で……」という規約が多い。対してDropboxのそれはいくつかに大きくジャンル分けして記述するようになっているようだ。そのジャンルの中では順不同なのも面白い。そのカテゴリ分けもレイアウト、インラインの見た目、ブロックの見た目、その他と妥当に分かれている。 コンポーネント分けのパターンも考慮すると、多くはその分けられたカテゴリのどれかひとつだけを使うようにクラス分けされるはずなので、実質意味がないようにも見えるところに興味を持った。複数のカテゴリのプロパティーが混ざったらそのクラスはお
サブディレクトリ－をgh-pagesへ向ける運用
gh-pagesブランチの管理にはいくつか手法はあると思うのだけど、決定版はなさそうに思える。まともにやるとするとsubtreeを使うのが良さそうだが、パワフルすぎて役不足な印象だ。僕は公開するファイル群を吐くサブディレクトリーをmasterからは無視しつつ、gh-pagesブランチではそのサブディレクトリーをルートにするみたいな運用に落ち着きつつある。 example.com/ ├ dist/ │ └ index.html ├ src/ │ └ index.mustache ├ .gitignore ├ index.js └ package.json Node.jsでindex.jsを使ってsrc/index.mustacheを処理し、dist/index.htmlを吐くという形だ。ルートでは.gitignoreでdist/を無視し、普通にoriginを追加しておく。dist/で改めてg
ブックマークのおっかけ
ソーシャル・ブックマークはまだそれなりに機能するが、いまだに追いかけるのが難しい。その中ではてなブックマークのお気に入り機能は出色の出来栄えと言えそうだが、やはりブラウザーであのページを見るのは辛い。かといってRSSリーダーで読むのもなかなか難しいと感じる。HBFavは良いものだが、やはりデスクトップでどうにかしたい。 ストック型では色々試した末にはてなブックマークのお気に入りRSSからIFTTTのEmail Digestに貯めて毎日深夜に送っておくという形でしばらく落ち着いた。RSSリーダーでお気に入りフィード読むのは本当に苦行だったが、相当マシな気もする。特に気が向かなかったら読まずにとっておくこと(未読でプレッシャーかかったりしない)も、捨てることもできる。僕は送る時間を夜中の3時にして余裕のある朝にチェックできるようにしているが、みながウェブページを見てブックマークし終わる午後3時
srcset属性を使ったSVGフォールバック・ハック
SVGをサポートする環境がほとんどになってきた。それでもなんとか8であったり、かんとか2.3であったりのことを考慮せざるをえないという状況はありうる。それにはonerror属性を使った対応が有力だが、srcset属性でSVGファイルを指定するだけというハックのことを知った。将来的に使えなくなるわけではないが、やりたいことと実装に食い違いが少なからずあるのでハックと言って良いだろう。 <img src="foo.png" srcset="foo.svg"> 表示したいSVGをsrcset属性で、フォールバックに使いたいPNGをsrc属性で指定するだけだ。これでsrcset属性をサポートしているブラウザーではSVGが、そうでないブラウザーではPNGが表示される。srcset属性のサポートに対して、より多くのブラウザーがSVGをサポートしていることから成立する。もちろん食い違いがあるのでSVGを
dns-prefetchとpreconnect、そしてprefetchやprerenderとpreloadの併記 - Hail2u
dns-prefetchとpreconnect、そしてprefetchやprerenderとpreloadの併記 2014年10月より標準化作業が公開されたResource Hints仕様により、既存のrel=dns-prefetchとrel=prefetch、そしてrel=prerenderは置き換えられる可能性がある。この置き換えが起こる可能性は決して高くはなさそうなので、実装されているもののままでも構わないと思うが、link要素のrel属性は複数の値を取ることができるので、同時指定しても良い。 rel=dns-prefetchはrel=preconnectと完全に対応しているので、そのまま追加してやるだけになる。 <link href="//example.com" rel="preconnect dns-prefetch"> rel=prefetchとrel=prerenderはR
Git for Windows v2.x.xのインストール
Git v2系のWindows版がGit for Windowsの方で少し前から公開され始めていたことを今さら知ったので、更新した。2015/05/05現在はv2.4.0がリリースされている。インストールから動かすまでけっこう手間取ったので、メモがてら記事に残しておく。Git v2の使い勝手とかについては特に書かない。 ~/.bashrcの読み込み このGit for Windowsでは、デフォルトで無理やり~/.bashrcを読みに行くことがなくなった。~/.bash_profileは読みに行くので、~/.bash_profileから~/.bashrcを読みに行くように、つまり普通にBashを設定してやれば良い。 if [ -f ~/.bashrc ]; then . ~/.bashrc; fi これだけ書いた~/.bash_profileを作成するのが良い。あまり関係ないイシューではそ
JavaScriptをビルドするJavaScript
たまには素でJavaScriptファイルをビルドすることも考えないと頭がダメになりそう。他にgulpとかでかすぎるし、npm run-scriptだけでいけるいけるみたいな話を先行者以外からも聞くようになったので、そっちに比重を移すことも視野に入れたいとか。僕はビルド・ツールをnpm run-scriptで薄くラップする手法というのが現実的だと考えてて、それを確認したいというのもあった。 依存はnpmやBowerで解決している前提で、自前で書いたものを最小化し、依存と連結するようなものを想定しておく。つまり、 node_modules/foo/dist/foo.min.js src/js/bar.js src/js/baz.js をbuild/js/main.min.jsへとビルドするくらいにしておく。 #!/usr/bin/env node 'use strict'; var async
文字参照と属性セレクター
文字参照を含む可能性がある属性の値を使ってセレクターを自動生成するような仕組みで少しハマった。文字参照をそのまま属性セレクターの値として指定してしまったので、うまく動かなかった。style要素に記述するようなケースでも、属性セレクターの値には文字参照は使えない。戻して書き、必要ならバックスラッシュでエスケープする。 Demo: Character Reference and Attribute Selector デモのp要素にはtitle属性の値に二重引用符が文字参照で入っている。普通に文字参照を使って属性セレクターを書いた場合、要素が選択できない。また属性セレクターでの二重引用符は特別な意味を持つので、引用符なしのつもりで書いても同じように選択できない。文字参照を戻した上で以下のどれかで指定する必要がある。 一重引用符で括る 二重引用符で括り、エスケープする 二重引用符をエスケープする
rel=subresourceを併用したCSSの遅延読み込み
クリティカルなんとかの関係やウェブ・フォントにおいて、CSSの遅延読み込みを行う気運は高まっている。様々なアイディアがあって、普通にCSSの内容を読み込んでhead要素に追加するものや、link要素を動的に追加するもの、予めlink要素をrel=stylesheetなしで書いておいて後で追加するものなどがその主なものだ。最後の手法ではrel=subresourceを追加して書いておくと、一部ブラウザーでダウンロードが速く始まるんじゃないかというアイディアを持った。 サポートが広いのでprefetchかなと思ったけど、書いたそのページ内で使うリソースの先読みに使うものではないような印象で、すぐさま使う場合はsubresourceの方が適切なようだ。Chromeがそういうイメージで実装してるという話で、ウェブ標準では特に細かく規定はないようではある。 <html> <head> <style>
Sassの変数の仕組みとOOCSS
A List Apartに掲載されたA Vision for Our Sassという記事を読んでいた。ここに書かれていることが正しいとすると、やはりOOCSSあってのSassなのかなという思いを強くした。でも、今のSassの変数の仕組みとCSSのフラットな構造を考えると、Sassを使ったOOCSSの実現は既に詰みかけている局面だと考えることが多い。 例えばFunction over Presentationの例を見てみよう。 $primary-color: #b32293; //magenta $secondary-color: #2f6b49; //green これは確かに機能すると思う。しかし大体においてカラーパレットは最低でもあと5色くらいは必要になることが多いだろう。もちろん$primary-colorのバリエーションであったりするわけだが、それらの名前付けはどうするのだろうか。例
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
