スクロールは制御するな - Weblog - Hail2u.net
WWD Japanのウェブサイトがリニューアルして、スッキリした見やすそうな印象のものに変わった。しかし実際のところ見やすさは見せかけだけで、ナビゲーションをクリックしても見当違いのタブに切り替わったり、ニュース一覧からニュースをクリックしたら、要約ページへ移動するだけで、本文へはもう一度クリックしなければならなかったりする。中でもひどいのがMobile Safariでの閲覧だ。 このウェブサイトではスクロールをほぼ自前で制御しようとしているため、常にこのようにMobile SafariのURLバーとツールバーが上下にそれぞれ表示され続ける。その上、最上端にロゴとグローバル・ナビゲーション、最下端に広告がそれぞれ固定位置であるので、コンテンツの領域がかなり制限されている。iPhone 5SやSEどころか6+や7+でさえも致命的なのではないかと感じられる狭さだ。 とにかく文書を読ませようとい
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}は後ほど好きに指定することになる
CSS Transitionを使ったスムーズにスクロールしてトップに戻る機能
前に作ったスクロールした時に位置固定のロゴをトップに戻る機能にすり替えるものを少し手直しして再導入した。今回はスムーズにスクロールさせようかと色々考えていたが、やはりJavaScriptでscrollTo()を制御するのはコストが高い。CSSならどうだと試行錯誤したところ、どうやらbody要素への負のマージンをCSS Transitionで滑らかに変化させれば良いようだ。 Demo: Scroll Smoothly with CSS Transition デモのページにはダミーテキストの各セクションの最後にそれぞれ⇑ Back to Topというリンクがある。それをクリックすると1秒かけてスムーズにスクロールしながらトップに戻る。トリガーとスクロール自体はJavaScriptで行っているが、スクロールのアニメーション自体はCSS Transitionで行っている。具体的には以下のような処理
ESLintの設定継承システム
ESLintのv0.20.0からプロジェクト・ローカルに.eslintrcがある場合は~/.eslintrcから設定を読まなくなった。つまりESLintのデフォルトの設定をユーザー・レベルで調節する術がほぼなくなったと言って良い。そうなった理由はわからないこともないのだけど、改悪な気がしてならない。 確かにプロジェクト・ローカルの.eslintrcだけしか見ないようにすると、プロジェクト・メンバー間でのコーディング・スタイルが統一しやすくなる。しかしそれはいわゆるフォーマッターの役目で、リンターの役目ではないように思う。リンターの段階でコーディング・スタイルへの準拠を強いられると、普段それと違う書き方をしている人達にものすごいフラストレーションを与えることだろう。 強いられたスタイルのうちいくつかはEditorConfigなどの併用により自動的に対応することはできる。その状態で書かれたコー
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
ウェブ・フォントの読み込み - Weblog - Hail2u.net
ウェブ・フォントも完全に行き渡り、今はどう効率的に配信するかについて多くの時間を割くようになった。Google Fontsの低め安定路線を見限り、TypeKitやFonts.comへ鞍替えする人々も増えた。それと同時に自前でホスティングする人々も徐々にその数を増やしており、どれが最適解なのか一応の結論が出るにはもう少しかかるだろう。まず、ウェブ・フォントの読み込みにおいてどのようなアプローチがあり、どのようなメリット、そしてデメリットがあるのだろうか。 TypeKit等に頼るにしろ、自前でホスティングするにしろ、もちろん最終的にはウェブ・フォントをブラウザーに送りつける必要がある。読み込みとはまさにその部分の話だ。話がややこしくなるので、多様な実装を意識した安全な書き方などについては触れない。 普通に@font-face定義を利用 @font-face定義をただ普通に書く場合のメリットは、
“マークアップ”するということ ～ HTML5勧告に寄せて ～
HTMLを適切な要素を使って書いていくことは実はそれほど難しくはない。しかし過剰に要素を使わずに、かつスタイリングすることも意識して、と適切に“マークアップ”するのはなかなかの修練を必要とする。いったい“マークアップ”するということはどういうことなのだろうか、そしてどのような思考の元に行えば良いのだろうか。 HTML5での変化 著作権表示のマークアップ small要素 footer要素とsmall要素 p要素とdiv要素 footer要素とp要素 スタイリングとの兼ね合い マークアップするということ HTML5での変化 コンテンツに則した素直な形でマークアップできること。 HTML5で変わることや変わったことは多くあるが、それらをおおまかに俯瞰するとこのような言葉に集約できる。そのために様々な要素や属性が追加され、既存の実装をなるべく壊さない形で要素の意味に変更が加えられた。これらの変化は
Sassでの色管理
Sassでは色を変数として定義でき、また様々な関数でそれを操作することが可能になっている。そのため色を論理的に管理することが可能になっているが、これといった手法が確立されているわけではない。このウェブサイトでは少しややこしい形で管理するようにしている。どういう目的でこういう複雑な構造になっているのかを簡単に書いておきたい。 基本色の定義 基本色、つまりテーマカラーであったり、本文の背景色や文字色といった見た目のイメージを決定する色は、色コードを直接指定して定義する必要がある。これはほぼ間違いなくみんな同じように書いているだろう。 $color-dark: rgb(60, 51, 48); $color-light: rgb(252, 249, 240); $color-accent: rgb(17, 136, 187); これらは背景色であったり文字色、そしてリンクの文字色として使っている
CSSのローディング・アイコンのコスト
今までは主にアニメーションGIFで作られていたローディング・アイコンをCSSアニメーションで作るみたいなのが流行っている。面白いとは思うし、ちゃんと作ればスケーラブルなので便利そうでもある。けれどもローディング・アイコンを表示するための空要素が必要になり、かつ後にそれを消さなくてはならない。CSSだけだと面倒くさそうだ。 どういうローディング・アイコンかはこの際問題ではないので、とりあえずmain要素以下に何かしら(仮にサムネイルとする)をロードするまでローディング・アイコンを表示することを考えてみる。普通はJavaScriptでローディング・アイコンの追加→サムネイルのビルド→ローディング・アイコンの削除→サムネイルの追加とやるわけだけど、ローディング・アイコンの追加と削除でDOM操作を伴うのはコストがある気がする。 <main id="result"> <div class="spin
display: noneとレスポンシブ・ウェブ・デザイン
レスポンシブ・ウェブ・デザインとその設計を語る時にdisplay: noneが引き合いに出されることが多いなと感じる。その多用は設計ミスというような具合だ。そういうところは確かになくはないが、多用自体はCSSの貧弱さからくるHTMLの複雑さを意味するだけなのではないかと思う。 レスポンシブ・ウェブ・デザインはコンテンツを様々なデバイスで「収まる」ようにレイアウトを調整することではない。実装としてはそうなることは多いが、実際には多様なデバイスでのコンテンツの一貫性を確保するアプローチであると考えた方が適切なはずだ。その一貫性とはほぼコンテンツへのアクセス性と言って良い。様々な画面でそれを同じように確保するためには、レイアウトの調整だけではなく、構成部品の間引きや移動などが必要となる。 そういった一貫性の確保を同じHTMLを通して行う、とすると実装はほぼCSSに限られることになる。そして今のC
wildfire.vimでVim力を下げる
wildfire.vimという、カーソルがある辺りのテキストオブジェクトをなんとなく選択してくれるVimプラグインを使い始めた。Vim力が下がる代わりに魂の平穏が得られる。ような気がする。 デフォルトではノーマル・モードで<Enter>を押すとカーソルのある辺りのテキストオブジェクトを選択してくれる。HTMLファイルを編集中なら属性値の上で発動させると、クオートの間を選択してくれる。その状態でもう一回<Enter>を押すとその上位にあるテキストオブジェクトをなんとなく選択してくれる。属性値のクオートの間を選択した状態だと、HTMLタグで括られた全体(など)まで拡大される。 逆方向に縮小することも出来るので、適当にタカタカ<Enter>を押して拡大しつつ、広げ過ぎたら<BS>で狭めるみたいな感じで使えて、とてもいい加減に使える。僕は狭める方だけを<S-Enter>に変えて、サクサク感を上乗せ
Webフォントの非同期読み込み - Weblog - Hail2u.net
Webフォントの読み込みは@importだと色々まずいので、主にlink要素を使って並列に読み込むわけだけど、これもまた貴重なHTTPリクエスト数を消費するとか、CSSのパース完了が少し遅れるなどあって、完璧な解というわけじゃない。それを非同期にWebフォント定義の含まれるCSSファイルを読み込むようにして、Webフォントのロードをページのレンダリングと並行して行わせるのはどうか、という試み。 非同期化することによりWebフォント定義の含まれるCSSファイルのリクエストとパースが、ページのレンダリングと並行して行われるようになる。head要素内でlink要素を直接書いた場合は、Webフォント定義の含まれるCSSのリクエストとパース後にページのレンダリングが始まることが多いので、体感速度(ページのレンダリングの開始までの所要時間)は向上する可能性が高い。 動的なlink要素の追加 いわゆるソ
CSSポストプロセッサー時代の到来
SassやLESSといったCSSプリプロセッサーは市民権を得たと言って良いと思う。しかしそれらCSSプリプロセッサーは開発という段階にのみ利をもたらすもので、今のところはそれ以上ではない。CSSを実際にユーザーに届けるまでには、開発だけではなくレビューとリリースという段階もある。レビューとリリースも確実性を持って効率的に行うためには、CSSポストプロセッサーと総称されるようなツール群が必要になるだろう。 この文書はFrontrend Advent Calendar 2013の4日目への記事として寄稿した。明日は@hilokiさんがスタコラサッサと書くようだ。 目次 CSSポストプロセッサーとは CSSプリプロセッサーの出力するCSS CSS Lint 開発用とレビュー用、リリース用のCSS CSSポストプロセッサーのユースケース ベンダー拡張プリフィックスの付加 Media Queries
コンテンツは王様なのか
最近に限らず、ウェブでは何かと「Content is king」というフレーズが多用されてきた。テーブル・レイアウトの駆逐期にもよく見た記憶がある。今までもこれからもコンテンツが王様で、それがために人はウェブサイトに訪れる、と。15年前ならそれは正しかったような気もするけど、様々なウェブサイトに同じようなコンテンツが散在する現在は、人はウェブサイトそのものを目的として訪れるようになっているように思う。 僕がAmazonを使うのは良い商品が安く売っているからではなく、Amazonなら手軽に買い物ができるからだ。多くの人もそうではないかと思う。ユーザー登録やクレジットカード番号の入力を乗り越えて、1円でも安い別のショッピング・サイトで買おうなどと思う人は稀だろう。また、Amazonに売っていなかったら諦めるなどという人も多いだろう。 ショッピング・サイトのコンテンツであるところの取扱商品とその
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. つまりユニークなため再利用できないというマイナスの面がある、と。確かに再利用できない。でもこれはマイナス
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
