ダーク・モードへ適応するなら、フォーム関連要素の色も切り替えるよう、CSSを書くだろう。しかし、それだけでは、例えばテキストエリアで出てくるスクロールバーが明るいままなので、かなり浮いてしまう。meta要素でname=color-schemeを適切に設定すると、そういったスクロールバーの色も含めたあらゆるものの色を暗く(明るく)できる。 書き方は特に難しくない。ダーク・モードへ適応しようと、prefers-color-schemeメディア・クエリーを使って、明るい背景と暗い背景を切り替えるなら、以下のようにHTMLファイルのhead要素以下に書けばいい。viewportと似たようなものだ。 <meta name="color-scheme" content="light dark"> lightとdarkの順序は、逆でも意味は変わらない。これだけでユーザーのOSやブラウザーでのダーク・モー

このウェブサイトのCSSから@mediaルールを極力なくした。今は亡き(殺した)CSS MQPackerへのモチベーションがゼロになったことをきっかけに、段階的に進めている。全廃はまだ難しいので、カスタム・プロパティーに代入していく@mediaルールだけに絞り、それ以外でもなるべく使わない、という方針にした。 普通のCSSであるルールセット側はごくシンプルなコードになる。var()が多いけれども。よくあるプロパティーの上書きが起こらないので、メディア・クエリーがなかった時代のCSSっぽくなる。メディア・クエリーによるプロパティーの上書きを、カスタム・プロパティーによる値の動的変化に置き換えている、と説明できる。 あらかじめ設定したカスタム・プロパティー群をデータと捉え、そのデータを参照する側に@mediaルールのようなロジックに相当するもの書かない、という見方もできる。これを踏まえてロジッ

既にあるウェブサイトの実装を、今後を意識してモダンにしようとすると、どうしても既存のクラシックな何かしらの置き換えが必要になる。多くの人が作り始めているであろうスタイル・ガイドはそういった時に役に立つ。現状での保証された結果を提示してくれるからだ。 クラシックな何かしらの置き換えが必要になった場合、その目的をきちんと知る必要がある。そうでないと正しくモダンに置き換えることができない。すべてをフルスクラッチで書き直すといった場合でも、少なくともクラシックな何かしらによる結果を知る必要があるだろう。 スタイル・ガイドは良くも悪くも結果に過ぎないが、ちゃんとした結果であることは保証されている。それをきちんと作っておけばとあるコンポーネント(とでもいうようなもの)がどのような意図を持ったものかを具体的な実装を知ることなく理解できるはずだ。 ちゃんと作られたスタイル・ガイド、というとかなり大げさだが

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

SVGをサポートする環境がほとんどになってきた。それでもなんとか8であったり、かんとか2.3であったりのことを考慮せざるをえないという状況はありうる。それにはonerror属性を使った対応が有力だが、srcset属性でSVGファイルを指定するだけというハックのことを知った。将来的に使えなくなるわけではないが、やりたいことと実装に食い違いが少なからずあるのでハックと言って良いだろう。 <img src="foo.png" srcset="foo.svg"> 表示したいSVGをsrcset属性で、フォールバックに使いたいPNGをsrc属性で指定するだけだ。これでsrcset属性をサポートしているブラウザーではSVGが、そうでないブラウザーではPNGが表示される。srcset属性のサポートに対して、より多くのブラウザーがSVGをサポートしていることから成立する。もちろん食い違いがあるのでSVGを

表のセルでは数字は右揃えにすることが多い。しかし少数を右揃えにすると、小数点以下の桁数が違う時に読みづらくなる。等幅フォントにしてもそれは解決しない。少数点がうまく縦に並ぶように揃えたいわけだ。CSSではtext-alignプロパティーで文字列が指定できるようにしたいようで、いずれ可能になるかもしれない。とされているが、実はHTML4.01の頃からほぼ同じ機能は仕様で定義されているものの実装はないので、期待は薄い……と思ったものの、うっかり実装されていないかどうか確認した。 Demo: Test Page for Decimal Alignment in Table Cell やはりというか<td align="char" char=".">の実装はなかった。ついでにtext-align: "."もテストしてみたが、こちらもまだ実装はない模様だ。テスト・ページでは省いたが、ベンダー拡張プリ

多くのウェブ制作者達が色覚多様性について考えることはまずない。せいぜいコントラストを確保したり、リンクの下線を消さないようにしたりすることで、グレースケールでもそれなりに識別できるように注意するくらいだろう。それで十分とも言えそうではあるが、それ以上考えようにも取っ掛かりがないためそれで止まっているとも言える。その取っ掛かりとして色覚多様性を再現するSVGのフィルターを作った。 Repository: Color Blindness Emulation filters.svgに含まれる8つのフィルターは、そのアルゴリズムはともかく、feColorMatrix要素を使ったごく簡単なものだ。 <?xml version="1.0" encoding="UTF-8" standalone="no"?> <svg xmlns="http://www.w3.org/2000/svg" version

ウェブ・フォントも完全に行き渡り、今はどう効率的に配信するかについて多くの時間を割くようになった。Google Fontsの低め安定路線を見限り、TypeKitやFonts.comへ鞍替えする人々も増えた。それと同時に自前でホスティングする人々も徐々にその数を増やしており、どれが最適解なのか一応の結論が出るにはもう少しかかるだろう。まず、ウェブ・フォントの読み込みにおいてどのようなアプローチがあり、どのようなメリット、そしてデメリットがあるのだろうか。 TypeKit等に頼るにしろ、自前でホスティングするにしろ、もちろん最終的にはウェブ・フォントをブラウザーに送りつける必要がある。読み込みとはまさにその部分の話だ。話がややこしくなるので、多様な実装を意識した安全な書き方などについては触れない。 普通に@font-face定義を利用 @font-face定義をただ普通に書く場合のメリットは、

CSSグラデーションを使った太くならないリンクの下線は、Mediumの詳細な記事やterkel.jpのその解説とも言える記事を見てそのうちやってみようと思っていた。フォントサイズが大きい時に下線が2pxや場合によっては4pxくらいで引かれるようになるのは見た目に結構な負荷を与えるので、常に1pxで引きたいといった希望を持ってる人は多いはずだ。 このウェブサイトでは以下の要件を満たすような感じで実装した。 常に1pxで下線を引く 文字サイズに依存しない なるべくシンプルな実装 a { background-image: linear-gradient( transparent 0, transparent 50%, rgb(91, 172, 208) 50% ); background-position: 0 1.1em; background-repeat: repeat-x; backg

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

たまに忘れてFirebugで調査して「あーそうだった！　これだよ！　クソが！　俺か！」みたいな。これはFirefoxのフォーム系の置換要素に設定してあるデフォルト・スタイルで、入力ボックスとボタンの高さを揃えるのが面倒くさい原因のひとつ(もちろんこれだけではない)。これはかなり昔からあるけど「置換要素がline-heightプロパティーで高さ変わるわけねーだろクソが」という理由によりWon't Fixなので、死ぬまで付き合うことになりそう。 !importantなため制作者スタイルからはどうあがいても上書きするのは無理なので、他のブラウザー向けにline-height: normalを設定してやるのがまず必要。その上で入力ボックスとボタンのbox-sizingプロパティーが違うことに気をつけ、高さを指定する。 input[type="text"] { height: 1.75em; lin

Lea Verouの編み出したフレキシブルな複数行定義リストは目からウロコだった。このテクニックを知るまではfloatを使うと長い時(コンテンツ幅に収まらない時)に途中で改行とかうまくできないけどまぁしょうがないか……みたいな感じで我慢していた。LF(やCR)を擬似要素経由で挿入してwhite-space: preで改行させてしまうというのは頭良い。ただ複数のdd要素を持つケースにはうまく対応できないのでちょっと変えて使い始めた。 このテクニックはつまりdt要素とそれとセットになったdd要素を一行に並べるというもの。表的なものならばそれは単にマークアップが間違っているのでtable要素でマークアップし直した方が適切だけど、dl要素のが適切なケースも多くあるのでこのテクニックが生かされる場面は多い。 dt, dd { display: inline; } dd + dt:before { c

カラーパレットの簡単なジェネレーターとしてColor Scheme Designer 3を使うことが多かったけど、最近はColorHexaも併用している。パレットの生成ツールとしてはColor Scheme Designer 3のが見やすく使いやすく高機能なので、ちゃんとしたい場合はそっちを使っているけど、Webセーフカラーへの丸めやShadesとかHSLへの変換などが必要になった場合にColorHexaを使うようになった。 ColorHexaでは調べた色のpermalinkが作られるので再利用しやすい。このWebサイトのテーマカラーである#558899を例にすると、ドメインにRGBを付けたURLになる。CSSのコメントとしてColorHexaのpermalinkを埋め込んでおいたりすると後で楽になるし、世の中RGBを見て色がすぐ分かる人は少ないので説明しやすい。 画像から色を抽出するウェ

Flash of Unstyled Textの頭文字をとってFOUTと呼ばれる現象がある。FirefoxでWebフォントの読み込みが完了するまで別のフォントが使われる現象のことで、後にSafariやChrome、Internet Explorerで起こるようになった読み込みの完了まで空白になる現象のことも含めてFOUTと呼ぶことが多い(気がする)。このWebサイトでも起こっていて、それについて聞かれたのでさらっと書いてみる。 この現象の原因はCSSの処理やWebページのレンダリングと並行してWebフォントのHTTPリクエストが行われることにあるので、仕様と言って良い。起こらないようにするにはWebフォントの読み込みが終わるまで他の処理をブロックするとかしないといけないため、改善される可能性はあるけどまず直ることはない。日本のWebサイトではあまり起こらないように感じるのは、Webフォント自

せめてWebKitに実装されてからとか思ってたけど、CSS Image Values and Replaced Content Module Level 3がLast Callになったのでいい機会ということにしてelement()関数についてエントリを書く。element()関数は任意のIDを引数に取ることができ、その要素を画像として参照できるというなかなかの荒業な関数。具体的には画像のサムネイルを簡単に作成できるとかそういうものをイメージするとわかりやすいと思う。 Demo: Filmstrip View いわゆる「フィルムストリップ」のようなものを作るデモだけど、element()はまだFirefox 4以降でしかサポートされていないので、ChromeやSafariなどでは意図した通りに動かない。Firefoxなら下に並んだサムネイルをクリックすると大きな画像が表示される。切り替えやア