上下左右のセンタリングには様々な手法が編み出されてきた。最近はCSS Transformを使う方法がメジャーになりつつある。コンテナーとセンタリングしたい要素のサイズが共に不明でもうまくいくところなど、そこそこ万能感があるのがポイントだろうか。このCSS Transformによるセンタリングは左下に動かしてから右上に戻すパターンと、その逆の右上に動かしてから左下に動かすパターンがある。どちらでも理論的には上手くいくが、ベスト・プラクティスとなりうるのは後者だけだろう。 Demo: Centering Unknown with CSS Transform (top/left) このデモは実際に不具合が起こりうるパターンになっている。センタリングする要素をtopとleftプロパティーで動かした後、transform: translate(-50%, -50%)で元に戻しているわけだが、Inte

前に作ったスクロールした時に位置固定のロゴをトップに戻る機能にすり替えるものを少し手直しして再導入した。今回はスムーズにスクロールさせようかと色々考えていたが、やはりJavaScriptでscrollTo()を制御するのはコストが高い。CSSならどうだと試行錯誤したところ、どうやらbody要素への負のマージンをCSS Transitionで滑らかに変化させれば良いようだ。 Demo: Scroll Smoothly with CSS Transition デモのページにはダミーテキストの各セクションの最後にそれぞれ⇑ Back to Topというリンクがある。それをクリックすると1秒かけてスムーズにスクロールしながらトップに戻る。トリガーとスクロール自体はJavaScriptで行っているが、スクロールのアニメーション自体はCSS Transitionで行っている。具体的には以下のような処理

このウェブサイトではしばらく前にpreやcode要素のフォント・ファミリー指定を消した。あまり確認していなかったが、無指定なので良い感じになってくれるだろうと軽く考えていた。が、どうもMobile Safari 8で等幅フォントになっていなかったようだ。なかなかうまく再現できなかったが、どうやらlang属性で変わるようだ。また君か。 Demo: pre font on Mobile Safari 8 デモのページをMobile Safari 8で見るとlang属性でjaを指定したセクションのpre要素が等幅フォントになっていないことがわかる。このページにはスタイルは当てておらず、まったく同じ内容を持つがlang属性のないセクションではpre要素のフォントはちゃんと等幅フォントになっている。 lang=zhで報告されているBug 96348と同じで、内部のフォント設定によるフォールバックがs

CSS Font LoadingとFont Face Observer、Web Font Loader ウェブ標準であるCSS Font Loadingが気軽に使えるようになるにはまだまだ時間がかかりそうだ。そのポリフィルであるFont Loaderは動作が不安定かつ開発が止まっており信用できない。代替技術としてはポリフィルと同じ開発者が積極的にコミットしているFont Face Observerと、広く使われているWeb Font Loaderがある。同じフォントの読み込みを検知する場合、この三者ではどのようにコードが変わってくるのだろうか。 以下のコード例では、自前でホスティングしているOpen Sansの読み込みが完了・失敗したらbody要素にクラスを振るという単純なケースを書き分ける。 CSS Font Loading仕様はPromiseによる実装で、読み込み待ちはPromiseで

昔はOSネイティブを尊重したスクロールバーにしろ派だった。今は描画領域がらみで色々考えたくないので、オーバーレイで独自描画されちゃえばいいのに派になってる。WindowsだとInternet Explorer 11以降(10以降かも)の自動非表示スクロールバー的なのが妥当な落とし所なのかな。かっこいいと思ってはいないんだけど。 ウェブ制作者としては、もちろんこの辺りの扱いが仕様通りに実装されてればどっちでも良いわけだけど、ちゃんとされそうな気配がまるでない。また仕様自体でもMedia Queriesのwidthやheightではスクロールバーを含むで、CSS Values and Units Module Level 3のvw系では含まない(スクロールバーの有無に影響を受ける)だったりして、大変覚えづらい。 それぞれがそうなっている理由や実装がマチマチな理由もなんとなく推測できる。でも、こ

CSSWringに同じルールセット内で重複する定義(プロパティーとその値のセット)をルールセットから削除する機能をつけてる。最初、重複するプロパティーを問答無用で削除しようかと考えたんだけど、同じプロパティーを同じルールセット内でわざと使うことは結構あるのでダメそうだった。なので完全一致で削除するようにしようとしてる。 PostCSSでCSSをパースすると、各定義は以下のような構造になる(一部省略)。 { type: 'decl', before: '\n ', prop: 'color', between: ': ', value: 'white' } typeに定義であることが明記されていて、propでプロパティー名、valueで値が拾える。またbeforeにプロパティー名の前にある文字列、betweenにプロパティーと値の間の文字列が入ってる。 一致のチェックはpropとvalueを

base要素のhref要素で別のドメインのページを指し、リソースの基準となるURLを変更すると、History APIを使った履歴操作が行えなくなる。Same Origin Policyに引っかかって、セキュリティ・エラーが吐かれるようだ。 <!-- http://www.example.com/foo/bar --> <base href="http://other.example.com/"> <script> history.replaceState(null, '', '/replace'); </script> http://www.example.com/上のページでURLの書き換えを行おうと以上のようにすると、ブラウザーはbase要素のhref属性の値を考慮してhttp://other.exmaple.com/replaceに書き換えようとする。しかしSame Origin

git-release.jsでファイルと行の指定をまとめて設定する良い方法を考えてた。結局はコロンでつなぐという古き良き感じにしたけど、ウェブではこういうのにも使えそうなのをRFC5147 - URI Fragment Identifiers for the text/plain Media Typeで仕様を決めているらしい。何行目かだけじゃなくて何文字目から何文字目までみたいなのが出来るようだ。 以下はExamplesの簡単なメモ。 http://example.com/text.txt#char=100 text.txtの100文字目。 http://example.com/text.txt#line=10,20 text.txtの11から20行目。line=10が10行目と11行目の境界ということ。 https://example.com/text.txt#line=,1 text.

Webフォントの読み込みは@importだと色々まずいので、主にlink要素を使って並列に読み込むわけだけど、これもまた貴重なHTTPリクエスト数を消費するとか、CSSのパース完了が少し遅れるなどあって、完璧な解というわけじゃない。それを非同期にWebフォント定義の含まれるCSSファイルを読み込むようにして、Webフォントのロードをページのレンダリングと並行して行わせるのはどうか、という試み。 非同期化することによりWebフォント定義の含まれるCSSファイルのリクエストとパースが、ページのレンダリングと並行して行われるようになる。head要素内でlink要素を直接書いた場合は、Webフォント定義の含まれるCSSのリクエストとパース後にページのレンダリングが始まることが多いので、体感速度(ページのレンダリングの開始までの所要時間)は向上する可能性が高い。 動的なlink要素の追加 いわゆるソ

随分前に勢いで訳したものの、すぐに我に返って記事にはしなかったCSSLintのルールの超訳を、言及貰って気が向いたので更新した。新しく追加されたルールの訳を追加しただけ。でもドキュメントとして残すのも、訳し方的にアレな感じがあるので、あんまり良くないけどGistのままで。 CSSLintのルールが大体において厳しすぎるのは、CSSに厳密なエラー処理のようなものがないことと文法的にゆるいことが理由なのかなーと改めて思った。つまりCSSLintのような厳しくイライラさせるもので警鐘を鳴らし続けることによって、ゴミとか鼻クソがくっついたような汚CSSを世の中にばらまいていることを強烈に意識させようということなのかなと。すみません。 デフォルトの設定のまま特定の警告をスルーするだけだと、オオカミ少年的になってしまうので、無視すると決めたルールを無視するようにちゃんと設定して使う必要がある。v0.9

Vim 7.4の標準ランタイムに含まれているCSS構文ファイルにはかなり大幅な変更が加わっている。CSS Animations等の新しいCSS仕様に対応していたり、非推奨になった要素をErrorで表示するようになったり、ベンダー拡張プリフィックス部分を別に強調したりなどなど。 開発はGitHubのリポジトリでやっているようなので、手元で修正してたものをプル・リクエストさせてもらった。こっちの方では既に大幅な変更が加わっている。ドラスティックな変更点だとCSSの値の強調色が変わってたりとか。他はCSS3モジュールへのさらなる対応などが主なもの。同梱バージョンではバグの修正はあまりされていないので、text-indentやinline-tableでおかしくなるのが気になってた人は入れ替えると良い。 vim-css-syntaxでの修正内容は取り込んでもらえ、こちらは用済みっぽいので内容を空にし

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',

normalize.cssのコミットを購読してる。主にnormalize.scssを追随させるためだけど、勉強になることも多い(多かった)し。この前のコミットでREADMEが更新され、そのまま使うことを推奨すると変更された。特に邪悪な変更というわけではないんだけど、そのまま使いたくないなーみたいなのがちょっとある。 normalize.cssは素晴らしいものだし、そのまま使って何も問題ないものなことは確か。でも、そのまま使うと無駄が多い。例えば以下の様なケース。 body { margin: 0; } body { margin: 1em; line-height: 1.6; font-family: "Helvetica Neue", "Calibri", sans-serif; color: #ddd; background-color: #333; } normalize.cssのb

ブラウザーはviewportによって折り返しを自動で行なってくれるわけだけど、場合によっては適切ではない位置で行われてしまうのをコントロールしたいという話。見出しをセンタリングしているようなケースで幅によっては一文字だけ次の行になってかっこ悪い！　みたいなのを解消したいということであったり、逆にびろ～んと間延びしないようによさそうな位置で改行を入れたいということであったり。一年くらい前にResponsive Line Breaksと呼ばれるようになった。 具体的なものはResponsive Line Breaksにあるデモやこのウェブログの日付表示の部分とかがそれ。ここではviewportの幅が広い時に良い位置で改行が入るようになっている。 article footer br { display: none; } @media (min-width: 60em) { article foo

utm_xxxを利用したユーザー追跡はまぁ便利ではあるのだけど、どうしてもURLの正規化に悪影響がある。設置したツイートボタンやブックマークボタンはこちら側で正規のURLを仕込んでどうにかすればいいのだけど、ブラウザーの拡張やブックマークレットにはどうしようもない。かといってリダイレクトでは訪問者にも管理者にもコストが高いので、replaceState()を使ってURLだけ書きかえるという話。 正規化する関数を発火させるタイミングの制御には色々アプローチがあると思うけど、素で書くといろいろ面倒そうなのでGoogle Analyticsのコードに混ぜることにした。 var _gaq = _gaq || []; _gaq.push(['_setAccount', 'UA-XXXXXX-X']); _gaq.push(['_trackPageview']); _gaq.push(function