遅延読み込み用のぼやけた画像
Mediumでとある記事を高速にスクロールして読んでいたら、さりげなく画像を遅延読み込みしていることを知った。読み込み発火のタイミングがうまいのかあまり遅延読み込みの存在を感じさせないのもすごいと思ったが、プレースホルダー画像の実装方法が良さそうだった。単純に元の画像を幅30px程度まで小さくしてそれをブラウザーにリサイズさせることでぼやけた画像をプレースホルダーとして表示しているだけだが、十分に機能していそうで目から鱗だった。 画像の遅延読み込みはなかなか曲者で、読み込むタイミングやプレースホルダーとしている画像が悪いと大きくユーザーにストレスを与える。プレースホルダーでよく使われるローディング画像は読み込み中のインジケーターではあるが、同時に何か遅いことをやっていますというネガティブな印象も与えてしまう。ユーザーはローディング画像を見るとスクロールを止めなくてはならないのかと感じること
よろしくESLint
重い腰を上げてESLintを使い始めた。そろそろv1.0.0になるらしい。これは良いなと思ったところを簡単にまとめておく。ついでに引っかかって対処にちょっと悩んだところも。既にすごく好感触なので、このまま素直に乗り換えられると良いな。 package.jsonに設定が書ける 外部設定ファイルとしては.eslinrcの他にもpackage.jsonに混ぜ込むこともできる。フィールド名はeslintConfigで、それ以下は同じ。 { "eslintConfig": { "env": { "node": true } } } 通常のnpmパッケージでは別にした方が良さそうだが、依存解決にnpmを使うだけとかコマンド作るためだけのようなプライベートなケースでは特に気にせず混ぜてしまって良さそう。 no-multi-spaces 複数の連続した空白が検出できる。 var a = 1; これで警告出
CSSできれいな斜め線
CSSで斜めに線を引くようなことをするには多少なりとも工夫が必要だった。つまりCSSで作る吹き出し(もう5年前の記事だ)のようにborderプロパティーを使って頑張るしかなかったわけだ。今はlinear-gradient()があるので直観的に作ることができるようになった。しかしきれいに引くとなるとまだ工夫が必要そうだ。 Demo: CSS Diagonal Line borderプロパティーを使ったもの、linear-gradient()を背景で使ったもの、Data URI化したSVGを背景に使ったもの、以上の計3つのデモを作った。 .lg { background-image: linear-gradient( to right bottom, transparent 50%, #f0f 50% ); background-repeat: no-repeat; background-si
静的ファイルのみのホスティング
ここしばらく使わせやすい静的ファイルのみをホスティングしてくれるサービスを探している。理想としては特定のローカル・ディレクトリーがそのまま公開されるようなサービスだ。FTPフォルダー的なものを実現するクライアントまで用意されているサービスだと言っても良い。 GitHub Pagesは僕の中では理想に近く、自分で使う分にはまったく問題ないが、誰かに使わせようとすると途端に敷居が高くなる。 Gitのインストールとその利用の仕方 GitHubのアカウントの取得と設定 GitHub Pagesの作成と更新 このあたりの仕組みを教えないとならない。これらは一部を自動化するような仕組みを作って提供することも可能だが、そういうものは当初は良くても後々自分か赤の他人の首を絞めることになることはまず間違いないだろう。 世の中には例えばDropboxの一部ディレクトリーをそのまま公開してくれるようなサービスは
Sass - チュートリアル
この文書は古いSassウェブサイトに載っていたチュートリアルの訳で、2013年12月現在もう新しいウェブサイトには存在しません。新しいウェブサイトでのチュートリアルにあたるSassの基本の日本語訳を参照してください。 Translation of: Sass - Tutorial Ruby と Sass のインストール まず、Sass がちゃんと動作するようにします。OS X を使用しているのなら、既に Ruby がインストールされているでしょう。Windows ユーザーならば Ruby のWindows インストーラーで、Linux ユーザーならパッケージ・マネージャーでそれぞれ Ruby をインストールすることが出来ます。 Ruby のインストールが完了したら、以下のようにして Sass のインストールを行います: gem install sass 最初の Sass スタイルシート 非
CSSポストプロセッサー時代の到来について
Frontrend Advent Calendar 2013の4日目の記事として、「CSSポストプロセッサー時代の到来」というタイトルで寄稿した。このウェブログで書こうかと思ったけど、意識はされていないもののそこそこ浸透している概念の話で、トレンドに関わりがあるもののそれに左右はされない話でもあるので、独立した文書にした。長いかと思ったけどそんなに長くもなかった。 CSSポストプロセッサー時代の到来ではさらっと流した、CSSプリプロセッサーのコードと標準的なCSSのコードとのギャップが大きくなりすぎてることについてちょっとだけ。 これは危険な徴候だなーと思ってる。例えばMedia Queriesを効率的に記述するためにミックスインにするみたいなのはよく見るけど、実装の仕方はSassのバージョンと人によりそれぞれで、意図とどういうコードが吐かれるかを把握するのはかなり大変。 .test {
CSSポストプロセッサー時代の到来
SassやLESSといったCSSプリプロセッサーは市民権を得たと言って良いと思う。しかしそれらCSSプリプロセッサーは開発という段階にのみ利をもたらすもので、今のところはそれ以上ではない。CSSを実際にユーザーに届けるまでには、開発だけではなくレビューとリリースという段階もある。レビューとリリースも確実性を持って効率的に行うためには、CSSポストプロセッサーと総称されるようなツール群が必要になるだろう。 この文書はFrontrend Advent Calendar 2013の4日目への記事として寄稿した。明日は@hilokiさんがスタコラサッサと書くようだ。 目次 CSSポストプロセッサーとは CSSプリプロセッサーの出力するCSS CSS Lint 開発用とレビュー用、リリース用のCSS CSSポストプロセッサーのユースケース ベンダー拡張プリフィックスの付加 Media Queries
レスポンシブ・コード
ウェブページにコードを載せる時に、狭い画面ではそのコードのみが書かれているファイルへの単なるリンク、余裕のある広い画面ではそのファイルの内容をインライン展開するというもの。流行りの感じで言い換えると、レスポンシブ・コード的な何か。 Demo: Link on Mobile, Inline on Desktop デモはとりあえずな感じなので、幅が800pxかつ高さが600px以上の場合はインライン展開するようにしてみた。当初は簡単にできそうだと思ったのでobject要素を使ってみたが、結局XHRを使うことにした。通常はクロス・オリジンの問題もないので、普通にGETで読んでテキストとして流しこむのみ。インライン展開されない場合はハイパーリンク経由で開かれることになるので、コードのみが書かれているファイルは必ずtext/plainで返すようにサーバー設定を行う必要があることくらいに注意すれば良い
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. つまりユニークなため再利用できないというマイナスの面がある、と。確かに再利用できない。でもこれはマイナス
フォントの読み込み完了を検知する
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
mod_rewriteのテスト
mod_rewriteは未だにちゃんとわかってない。単純なものならそんなでもないんだけど、ちょっと変わったことやろうとするとすぐ躓く……。この間も躓いたので、簡単にテストできるものでもないかなーと少し真面目に探したら、htaccess testerというのを見つけた。ざっと試した感じではちゃんとチェックできてそう。 使い方はリクエストするURLを適当に決めて入力し、.htaccessからmod_rewriteのルールをコピペしてCheck nowボタンを押すだけ。%{REQUEST_FILENAME}とかはサポートされてないけど、自明なので多分あんまり問題ないと思う。結果はrewriteされたURLとルールの適用状況の簡単な説明(Lだからここで終わったよとか)付きで出力される。 「Apacheとか使わないし～」みたいなセリフを吐ける日が来ることはあるのだろうか。
プライマリSCSSファイル
Sassでは@importをうまく使うと、SCSSファイルを目的別に整理して管理することができます。モジュール化できるということですね。プライマリSCSSファイルとは僕が勝手に付けた呼称ですが、つまり各モジュールを読み込むだけのSCSSファイルのことです。グローバルに使用する変数の設定ファイルなども含めて整理して、プライマリSCSSファイルではそれらを読みこむだけとしておくと管理が少し楽になるんじゃないかと。 このWebサイトのプライマリSCSSファイルは以下のようなものです。 $version: "6.10.21"; /*! * style.css v#{$version} * * LICENSE: http://hail2u.mit-license.org/2011 */ // Web Fonts @import url("http://fonts.googleapis.com/css
Sassで行こう！
Translation of: Getting Started with Sass - A List Apart CSSの持つその簡明さは欠かせない特徴の一つで、それは最も歓迎されている点でした。CSSによるスタイルシートは、セレクターといくつかの適用したいスタイル情報を含むルールを羅列したものに過ぎません。しかし、WebサイトやWebアプリケーションが巨大に、そして複雑になり、様々なデバイスや画面サイズに対応せざるを得なくなった現在、この簡明さという特徴―fontタグやテーブル・レイアウトの淘汰に大いに役にたったもの―が大きな足かせになっています。 簡単な計算機能や変数を追加するなどといったCSSの修正案が過去に提示されましたが、どれもブラウザー・ベンダーには採用されませんでした。仮にこういった新しく素晴らしい拡張されたCSSがあるブラウザーに実装されたとしても、それが実用に耐える程度に
ページめくりの矢印
定期的に発症する画像使いたくなくなる病のため、ページめくりの矢印を画像じゃなくしたいなといろいろ考えているんですけど、なかなか良い物ができません。ユニコードのArrowやDingbatsなどにはいわゆる矢印的なもの(→みたいなもの)はいくつもあるので、そういうのが良いのならそれで良いと思うんですけど、自分のイメージではあんまり矢印々々してないのが良いかなというのがあるので、それらはちょっと使いづらかったです。いろいろ作った中ではborderとtransformプロパティを使ったものがそこそこまともに見えるような気がしました。 Demo: Paging Arrow 最初のスクリーンショットはこのデモを各ブラウザで表示したもので、左からChrome 15・Safari 5.1.1・Firefox 7.0.1・Opera 11.52・Internet Explorer 9.0.3です。各ブラウザ
Reset vs Normalize
CSSの記述法として、ブラウザごとの違いを「Reset」して一から指定するという方法が長らくマジョリティを占めていました。まだまだその方向で書いている人が大半ですが、「Normalize」するという方法を採る人達も増えています。なぜリセットではなくノーマライズなのかというような話をなんとなくダラダラ書いてみたい感じです。 以下、リセットはYUI 2のCSS Resetを、ノーマライズはNormalize.cssをイメージして読んでみてください。 リセットとノーマライズ まずは両者の違いから。リセットはなかったことにするというもので、ほぼ全ての要素に対するスタイル指定を排除しブラウザごとの違いを吸収するものです。対してノーマライズはブラウザのデフォルト・スタイルシートを生かしつつ、各ブラウザ間の挙動を擦り合わせるものです。リセットが負の方向で統一しているとすれば、ノーマライズは正の方向で統一
CSS Lint
CSS Lintをしばらく使っていますが、さすがにLintと名乗るだけあって手厳しいですね。効率的でキレイなCSSを書くために自然とHTMLの見直しをすることになる感じが、過渡期の今にはなかなか良いツールな気がします。W3C CSS 検証サービスのCSS3対応がいまいち(border-radius: 4px / 8px;が正しい演算子ではありませんとか怒られたりとか)なこともありますし、もっとみんな使うと良いと思います！ ストレスたまる気がしますけどね！ このサイトのCSSだと、 セレクタでID使うな widthやheightとpaddingやborderの併用はするな !importantは使うな この辺りで引っかかります。「承知でやってるよ！」とか言いたくなりますけど、そこはぐっと我慢。 気になるのはDisallow qualified headingsという、見出し(h1-h6)要素
jQueryプラグイン: Harmonize Text
親要素の幅に収まるようにフォントサイズを変更するjQueryなJavaScriptコードを、Harmonize Textという名前のjQueryプラグインにしました。FitTextを見て「コード短くて凄い！」とか思ったんですけど、自分の求めているものとはずいぶん違ったので、自分で書いたのをjQueryプラグインにしようというモチベーションが湧きました。 Repository: hail2u/jquery.harmonize-text 内容はリサイズに対応するようにした以外は特に変わっていないので、スクロールバーの有無によってぴったり収まらないバグは直っていません。リサイズは重いし、遅延させた方が良さそうな気がするので、そこら辺のオプションを指定できるようにしようかなと考えています。-1を引数として渡すとでリサイズに対応しない、正の整数ならそのミリ秒だけ遅延させてからリサイズ処理を行うとかで
Google ChromeでＭＳ ＰゴシックをArial+メイリオに置換する
最近のブラウザではWebフォントの利用を可能にする@font-faceをサポートしており、使われているサイトもよく見かけるようになった。@font-faceはWebフォントの利用に限らず、ローカルのフォントの再定義にも使えるので、ユーザースタイルシートで利用すればＭＳ Ｐゴシックをメイリオに置換することが出来る(Chromeでも)。これに留まらず@font-faceデスクリプターのunicode-rangeプロパティを利用すれば、英数字はArialで日本語部分はメイリオで置換するなどというわがままなことが出来る。 unicode-rangeプロパティはグリフのコードを範囲指定することによってsrcプロパティで指定されているフォントのどの部分を利用するかを決定するもの。つまりArialから英数字(PDF: Basic Latinと呼ばれる範囲)を取ってきてＭＳ Ｐゴシックを置換する場合はGo
rotate(360deg)
WindowsのGoogle ChromeでWebフォントを使うと、その縁がギザギザになることが多い(もちろん非ClearTypeのフォントならローカルフォントでも)。今まではそれの解消のためにtext-shadowプロパティで軽く文字色と同じ影をつけてやって誤魔化していたが、-webkit-transformプロパティでrotate(360deg)として一周回すといい感じにフォントにアンチエイリアスっぽいぼかしがかかることを発見した。少し前に書いたCSS3のtransformを使ったフォントの変形の派生。テクニックというよりもハック寄り。 Demo: Beautify MS PMincho on Google Chrome デモではWebフォントではなく、常にギザギザで悲しいＭＳ Ｐ明朝を使ってさしあげた(グリフが細かいためぼかしのかかり方がよく見え、わかりやすいので)。 scaleY(
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Google Chrome 17のDeveloper Toolsでの数字操作