スクロールは制御するな - Weblog - Hail2u.net
WWD Japanのウェブサイトがリニューアルして、スッキリした見やすそうな印象のものに変わった。しかし実際のところ見やすさは見せかけだけで、ナビゲーションをクリックしても見当違いのタブに切り替わったり、ニュース一覧からニュースをクリックしたら、要約ページへ移動するだけで、本文へはもう一度クリックしなければならなかったりする。中でもひどいのがMobile Safariでの閲覧だ。 このウェブサイトではスクロールをほぼ自前で制御しようとしているため、常にこのようにMobile SafariのURLバーとツールバーが上下にそれぞれ表示され続ける。その上、最上端にロゴとグローバル・ナビゲーション、最下端に広告がそれぞれ固定位置であるので、コンテンツの領域がかなり制限されている。iPhone 5SやSEどころか6+や7+でさえも致命的なのではないかと感じられる狭さだ。 とにかく文書を読ませようとい
WebKitでのSVGを背景画像にすると起こるバグ
SVGはそのリサイズ(スケーリング)においてブラウザ間で差異やバグがあります。有名なのはviewBoxがないことによるIE9やWebKitでのバグでしょうか。それでもimg要素等でSVGを使う場合はSVG側でwidthとheightそしてviewBox属性を指定し、CSSなどでリサイズすれば大体問題ありません。なので背景画像で使う場合もbackground-sizeプロパティーを使えば……と思いきや、なかなかの落とし穴がありました。 Demo: SVG Arrow WebKit以外では自動リサイズが期待されるviewBoxのみ指定したSVGを背景画像にすると問題なくキレイにリサイズされます。対してWebKitではリサイズされたりされなかったりです。しかもChromeとSafariでは挙動が少し違ったりもし、追求する気が失せるほど挙動不審です。どうも良きに計らってはくれそうにないので、明示的
CSS Transformによるセンタリングのベスト・プラクティス
上下左右のセンタリングには様々な手法が編み出されてきた。最近はCSS Transformを使う方法がメジャーになりつつある。コンテナーとセンタリングしたい要素のサイズが共に不明でもうまくいくところなど、そこそこ万能感があるのがポイントだろうか。このCSS Transformによるセンタリングは左下に動かしてから右上に戻すパターンと、その逆の右上に動かしてから左下に動かすパターンがある。どちらでも理論的には上手くいくが、ベスト・プラクティスとなりうるのは後者だけだろう。 Demo: Centering Unknown with CSS Transform (top/left) このデモは実際に不具合が起こりうるパターンになっている。センタリングする要素をtopとleftプロパティーで動かした後、transform: translate(-50%, -50%)で元に戻しているわけだが、Inte
下方向にもCSS Transitionでスムーズにスクロール
少し前のCSS Transitionを使ったスムーズにスクロールしてトップに戻る機能という記事では、CSS Transitionを使ってスムーズにスクロールさせるためにbody要素のmargin-topプロパティーを負の値を設定した。これはとにかく上方向へのスクロールにしか使うことは出来ない。下方向にスムーズにスクロールさせるためにはまた別のアプローチが必要になるようだ。 何かしらのCSSプロパティーを使い、body要素を上方向にずらすということになる。つまりtransformプロパティーでtranslate()やtranslate3d()を使いY方向のマイナスへ動かすのが向いているようだ。あとはtransitionプロパティーを組み合わせるだけでスムーズにスクロール(しているように見せる)ことができる。 Demo: Scroll Down Smoothly with CSS Transi
CSS Transitionを使ったスムーズにスクロールしてトップに戻る機能
前に作ったスクロールした時に位置固定のロゴをトップに戻る機能にすり替えるものを少し手直しして再導入した。今回はスムーズにスクロールさせようかと色々考えていたが、やはりJavaScriptでscrollTo()を制御するのはコストが高い。CSSならどうだと試行錯誤したところ、どうやらbody要素への負のマージンをCSS Transitionで滑らかに変化させれば良いようだ。 Demo: Scroll Smoothly with CSS Transition デモのページにはダミーテキストの各セクションの最後にそれぞれ⇑ Back to Topというリンクがある。それをクリックすると1秒かけてスムーズにスクロールしながらトップに戻る。トリガーとスクロール自体はJavaScriptで行っているが、スクロールのアニメーション自体はCSS Transitionで行っている。具体的には以下のような処理
Chrome 42におけるフォント設定とlang属性
Chrome 42でこのウェブサイトの日本語部分が変わってしまった(かもしれない)。内部的な標準フォント設定が変わったことにもよるが、それだけではない。設定で指定したSans SerifフォントがCSSのsans-serif汎用ファミリーに反映されなくもなった。lang属性がある要素のみで再現する。 Demo: lang="ja", font-family, and Chrome 42 例えばWindowsでは仮にChromeの設定(chrome://settings/fonts)からSans SerifフォントをＭＳ Ｐゴシックや游ゴシックなどに変更していた場合、lang="ja"を指定している最初のセクションのみChrome内部で設定されている日本語標準フォントであるメイリオになってしまう。OS Xでも同じ挙動になる。条件はlang属性というだけで、Googleの検索結果ページなどでも
我慢の期間
MovableTypeとWordPressとJekyllとHugoや、Gruntとgulp、SassとLESSとStylus、果てはjQueryなどの話はスケールやパターンを変えて繰り返される。その話はあたかも特定の何かに依存することが良くないとか新しいこっちのがすごいぞというように結論づけられることが多くて、僕にはちょっと頷けないこともあったりする。大切なのは何を解決しようとしていたかを忘れないことだと思う。複雑化しそうな場合にそこから先へ踏み込まずに我慢する期間がいるとかかも。 GNU makeでいいじゃん的な結論はそれは確かにビルドという点ではそうなんだけど、Gruntが解決しようとしていたのはそこじゃない。npmという生態系の中で完結させやすいタスク実行環境を手軽に用意することができることで、それ以上でもそれ以下でもない。実行速度以外にも腐臭を放つAPIやプラグイン間で一貫性のない
max-widthを否定するクエリー
モバイル・ファーストが浸透して久しくなり、めっきりmin-widthクエリー以外を見かけることはなくなった。そんな中、not (max-width: 768px)という書き方を見かけて、なるほどなと思った。現状のブラウザーにおける実装(と安定した仕様)では768pxを含まずそれより大きいという表現がmin-widthでは書くことができないが、notキーワードとmax-widthを組み合わせることで実現できる。 Demo: Negation of max-width query 特定のデバイスや解像度を強く意識したクエリーの是非はとりあえず脇へ置いておいて、iPhone 5s以下やらiPad Airやら一般的なノートブックやらを意識してクエリーを書くことはままある。多くの場合はそれら特定のデバイスのサイズからを区切りにしてクエリーを書くわけだが、それらのサイズまでで書くとなると少し曖昧な記述
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
OOCSSの欠点とEvery Declaration Just Onceのもたらすもの
昨日も少し書いたEvery Declaration Just Onceアプローチ(以下EDJOと略す)について、皆が目を瞑っているOOCSSの欠点、CSSが持つ特徴、HTMLとの兼ね合いという点からもう少し書いてみたい。これについては未だ誰ともちゃんと議論していない。機会があったらこの記事をベースにでも誰かと話してみたい。 上記Googleの文書は、主にパフォーマンスの観点で書かれている。どうしても長くなりがちな定義を分散して書くよりも、能動的に短くすることができるセレクターを分散して書いた方が、プロダクションにおいてリリースされるCSSファイルのサイズを小さくすることが可能だろうというものだ。同時にこの文書の筆者は自身のブログで、より自然にCSSを書くための手法(原文: 「The Natural Way of Writing CSS」)としてこのEDJOという手法について述べている。 僕
ウェブ・フォントの読み込み - 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で変わることや変わったことは多くあるが、それらをおおまかに俯瞰するとこのような言葉に集約できる。そのために様々な要素や属性が追加され、既存の実装をなるべく壊さない形で要素の意味に変更が加えられた。これらの変化は
CSSライブラリーはそのままでどうぞ
Normalize.cssを始めとして、Twitter BootstrapやPureに至るまでCSSのライブラリーは数多くある。それらはそれなりに気をつけて作られているが、他のライブラリーと混ぜることはもとより、ページ制作者のCSSと混ぜることは想定されていない。単純にlink要素を使って先に読ませるか連結するだけで使わないと、開発者はもちろんそれらが使われているページのユーザーにも意図しない不具合が起きる可能性がある。 そのためNomralize.cssなどではわざわざ以下のように推奨されている。 It is recommended that you include the normalize.css file as untouched library code. 概ねライブラリーと呼ばれるものには手を付けるべきではないが、フロントエンド界隈では軽視されている傾向があるように思う。特にC
ウェブ・タイポグラフィーのベスト・プラクティス
Translation of: The All-Inclusive Guide to Web Typography Best Practices インターネットを見渡してみると、如何にタイポグラフィーがウェブ・デザインにおいて絶対的な支配力を持っているかに気付くことでしょう。とにかくウェブ・デザインの95%はタイポグラフィーだというわけです。このようなことを考える時は、様々なことを考慮しなくてはいけません。インターネットとはコンテンツであり、コンテンツとは文字そして文章です。すなわちタイポグラフィーを意味するわけです。 懸命なウェブ・デザイナーなら誰しもこのことは知っており、注意深くまた慎重に時間を費やし、作成中のウェブサイトでタイポグラフィーがきちんとなるようにしていることでしょう。その中では読者に機能的で魅力的であるようなタイポグラフィーを提供するため、ウェブサイトの情報アーキテクチャ
HTML5 Shivの削除
このウェブサイトは、rem単位を使っていたりと、Internet Explorerだと事実上バージョン9以降でしかうまく閲覧できないようになっている。となるともうHTML5 Shivを使う意味もあまりないので削除した。これでようやく不格好な条件付きコメントを見ないで済む。 条件付き○○というものはうまく機能するが、それの利用には継続したメンテナンスが必要になる。条件付きで何かを特別視するので、プラットフォームに変化が加わるごとに、意図した通りに機能してくれるかどうかや追加で特別視する必要があるかどうかを確認しなければならない。そうしないと古く時代遅れのプラットフォームに依存し続けることになる。 現実世界の多くの仕組みではメンテナンスなしでも大体うまくいく。それはプラットフォームに変化が加わることがあまりないからだ。人々も大体そう感じているので、何もしなければそのまま動くはずだと考えている。
Style Guide - About - Hail2u.net
Sketch, markup, code, style, test, and then deploy. Weblog Documents Projects About Hail2u.netで使われているマークアップやスタイルの解説兼プレビューのページです。マークアップはHTMLのソースを、スタイルについては全ての変更履歴を含むGitリポジトリかこのページで参照されている非圧縮のCSSファイルを参照してください。このページに限ってはマークアップにおかしいところが多々ありますが、その多くはプレビューを作る上でのやむを得ない事情によるものです。 バージョニング フォーマットはSemantic Versioningを使っています。ただしAPIの変更などというものはあまりないので、以下のような条件でバージョン番号の増加を行っています: メジャー・バージョンは、レイアウトの大幅な置き換えやテーマカラー
余白を割合で分割
余白を特定の比率で分割したいなとちょっと考えていた。つまりmargin-leftとmargin-rightプロパティーの計算済みの値が3:2とかの比率で自動調節されるように、ということ。そのようなことをTwitterでちょっと書いたら、@o_tiがcalc()を使う方法を考えてくれた。 Demo: Split margins 1 to 3 最初のデモの幅は320px、二つ目のデモの幅は480pxになっている。margin-leftプロパティーでcalc()を使い、100%から要素の幅を引いた残りを4で割っている。margin-rightプロパティーはautoで自動調節すれば良い。 .test { margin-right: auto; margin-left: calc((100% -320px) / 4); width: 320px; } Inspect margin-left: cal
display: noneとレスポンシブ・ウェブ・デザイン
レスポンシブ・ウェブ・デザインとその設計を語る時にdisplay: noneが引き合いに出されることが多いなと感じる。その多用は設計ミスというような具合だ。そういうところは確かになくはないが、多用自体はCSSの貧弱さからくるHTMLの複雑さを意味するだけなのではないかと思う。 レスポンシブ・ウェブ・デザインはコンテンツを様々なデバイスで「収まる」ようにレイアウトを調整することではない。実装としてはそうなることは多いが、実際には多様なデバイスでのコンテンツの一貫性を確保するアプローチであると考えた方が適切なはずだ。その一貫性とはほぼコンテンツへのアクセス性と言って良い。様々な画面でそれを同じように確保するためには、レイアウトの調整だけではなく、構成部品の間引きや移動などが必要となる。 そういった一貫性の確保を同じHTMLを通して行う、とすると実装はほぼCSSに限られることになる。そして今のC
アクティブなナビゲーション項目とmark要素
アクティブなナビゲーション項目、つまり現在のページへのナビゲーション項目はclass属性を使ってactiveなどと付けられることが多い。特に間違ってはいないんだけど、いまいちピンとこない。というかしっくりこない。大体は流されてそうしているけど、このウェブサイトではmark要素を使ってる。 HTML5仕様ではmark要素は以下のようになってる。 The mark element represents a run of text in one document marked or highlighted for reference purposes, due to its relevance in another context. mark要素が含まれる要素のコンテキストとは別のコンテキストでの関係性をハイライト等で表したい時に使うと解釈してる(同じコンテキストならemやstrong、そしてb
right: 100%か負のマージンか
これまでCSSにはレイアウト方法があまりなかった。これからはFlexible Box LayoutやMulti-column Layout、Grid Layoutを始め、positionプロパティーに使える値の拡充などもあり柔軟に行えるようになるだろうが、それはけっして既存のレイアウト方法が不必要になるということではない。選択肢が増えると受け止めるべきだ。例えばright: 100%や負のマージンを使って親要素の外側左にレイアウトする手法はそのまま使い続けることになるだろう。 ほとんど同じレイアウトを実現するright: 100%と負のマージンの使い分けを通して、レイアウト方法の選択をどう行うべきかという基本的な思想を解説することにより、今後増えてくるレイアウトの選択肢にどう相対すべきかがわかるのではないかと思う。そしてそれはCSSプロパティーの意図された使い方を理解するということでもある
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
