全称セレクターは擬似要素にマッチしない
Mediumの印刷スタイルシートの記事を読んでいた。印刷スタイルシートについては常に盛り上がりに欠けるような印象だが、Mediumのデザイナーが書くと盛り上がってくれるんじゃないかとちょっと期待している。ついでに少しこのウェブサイトの印刷スタイルシートに手を入れていたところ、どうやら全称セレクターは擬似要素にマッチしないという、あまり関係のないことを今さら学んだ。 * { color: black !important; } このウェブサイトの印刷スタイルシートではこのようにして、強制的に文字を#000000で印刷させるようにしていた。よくよく確認してみると、実際に印刷するまでもなく、印刷プレビューの状態でも一部色がおかしいことに気付いた。おかしい部分は全て擬似要素で挿入した文字列だった。 最初は全称セレクターが詳細度においてもっとも弱いことに由来する問題かと思ったが、この例では!impo
ターミナル画面のマークアップ
Markdown (やその派生)のpre要素になる記法では、問答無用にその中はcode要素でマークアップされる。多くの場合はコードの断片なのでそれでいいんだけど、そうじゃないことももちろんある。例えばCLIプログラムでの操作手順を記載する時のターミナルの画面のコピー。 プログラムによる出力はsamp要素で、キーボードによる入力はkbd要素になるので、以下のようにマークアップするのがベストに近い。 <pre><samp>$ <kbd>node --help</kbd> Usage: node [options] [ -e script | script.js ] [arguments] node debug script.js [arguments] Options: ... NODE_DISABLE_COLORS Set to 1 to disable colors in the REPL
1/5くらい欠けた円を回す
新しいApple Storeアプリで使われてるローディング・アイコンをCSSで模したもの。たまにこういうものを作ると、自分が新たなCSSテクニックを学ぶことに貪欲でないことを再認識させられる。 Demo: Apple Store App Loading Icon .loading { border: 1px solid #797673; border-radius: 51%; position: relative; width: 2rem; height: 2rem; background-color: #fff; animation-duration: 1s linear infinite spin; } .loading::before { display: block; position: absolute; width: 50%; height: 50%; content: "";
CSSWring v1.1.0
Source Maps対応のCSS圧縮ツールであるCSSWringをようやくメジャー・リリースした。特に使い方は変わってない。内容的には圧縮力はそこそこ向上したけど、まだ「もうすこしがんばりましょう」程度。 ちょくちょくフロントエンド統合ツールに使われるようになってたりして、Source Mapsを吐くCSS圧縮ツールの需要はそこそこあるのかなと感じている。他のCSS圧縮ツールとは圧縮力で全敗みたいな感じなので、どこらへんに差があるのか調べて改善していきたい。 v1系に入ってから、以下のような点で圧縮力の向上に手を入れた。 セレクター内の連続した空白の切り詰め メディア・クエリーのパラメーター内の空白の切り詰め font-weightプロパティーでnormalを400に、boldを700へ変換 marginやborder-styleプロパティーなどでの省略 font-familyプロパティ
Blosxom用Gruntプラグイン
前にちょっと書いたけどBlosxomの動的生成インターフェイスをGruntから叩き、その結果を指定ディレクトリに保存するだけのGruntプラグインを書いて使ってる。汎用性はあんまり考えてないけど、Blosxom側が優秀なのでそれなりにあるような気がする。本体の書き換えが不要で、特殊なプラグインを必要とせず、動的生成向けのプラグインたちが普通に動くといった辺りが、ビルトインの静的生成システムと比べた利点。 Download: grunt-blosxom.js 設定は以下の様な形で書く。普通のGruntプラグインとは違うので、混乱しないようにsrcやdestは使わず、固定か--fileオプションで生成すべきファイルのパスを指定する。 blosxom: { options: { root: '.grunt/weblog/', datadir: '.grunt/weblog/entries/',
$ rm blosxom.cgi
サーバー上からBlosxomのCGIスクリプトを消して、Gruntを使ってローカルで動かしてrsync (かscp)するように変えた。Blosxomは捨ててない。でもトップページの出力などいくつかの機能をGrunt側に持たせてしまったので、そのうち全部Gruntでやっちゃいそう……。 Blosxomに飽きたとかじゃなくて.htaccessから脱却したいな、と。何度かつぶやいたりしたけどCGIは動かせなくていいけど.htaccessだけいじれるレンタルサーバー欲しいみたいなことを考えてて、でもそんなものは探した限りではまったくなくて、需要はもっとなくて、そのうち出てきそうという希望もない。となると.htaccessのようなものに依存しない形に静的なファイル群を整えてやる必要があるのかなと。その一歩としてmod_rewriteに強く依存しているウェブログをどうにかしようという試み。 Blosx
パーマリンクに特別なCSSを追加
Blosxomで記事ごとに専用のCSSを当てる方法を考えていた。last()でrel="stylesheet"を削除してCSSの参照を追加するだけのプラグインを作るのも良いけど、やることのわりにコストが高い。単純にmetaプラグインとinterpolate_fancyプラグインを組み合わせて実現するのが手っ取り早そう。 記事ファイルでは特別なCSSを使うかどうかのフラグのみ書く。 パーマリンクに特別なCSSを追加 meta-special_css: 1 <p>...</p> フレーバーでは以下のようにして、$meta::special_cssを使った分岐を利用する。CSSファイルのパスは記事ファイル名を利用することでユニークさを保証できる。 <?$meta::special_css eq="1"> <link rel="stylesheet" href="/styles$path/$fn.
翻訳はあなたの記事ではない
ウェブ開発を始めとした様々なジャンルにおいて、その有用な文書の多くは日本語以外で書かれている。幸いなことに多くの人がその翻訳を公開してくれている。僕も自分が強く興味をもった範囲で訳したりもしている。良い時代だなと思うが、その翻訳がブログの記事として公開されてしまうと、「んんっ？」と思ってしまう。 もちろんブログが技術文書のようなものを読みやすいデザインじゃないこととか、そのブログのスタイリング上の制限によって元文書から一部情報が欠落する可能性が高いこととか、そういう実際上の問題もある。そういった問題だけでなく、翻訳はあなたの記事ではないし、そうは成りえないということがある。それをブログの記事として公開してしまうと、様々な悪影響があると思う。 よくあるパターンは翻訳の前に訳であることの明示と同時に訳者の意見が書かれているパターン。前置きとして訳者の意見があったりすると先入観を読者に与えてしま
テキスト・ファイル向けURIフラグメント識別子
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.
Blosxomプラグイン: static_permalink
重い腰を上げてpermalinkを静的なHTMLとして吐いておくプラグインを書いて使い始めた。誰かしらがアクセスした時にHTMLが作られてなかったら作成するというシンプルなもの。振り分けはmod_rewriteに丸投げ。今までもRSSだけはそうしていたので、それをpermalinkでも使えるように深い階層でも大丈夫な感じに書き足そうと思ったけど、結局一から書き直した。これでいつでもBlosxomを捨てる用意が整った。 Download: static_permalink プラグインの実行は最後に回した方が良いので、以下のように他のプラグインも含めてリネームしておくと無難。通常はそんなに問題になることはないんだけど、lastを使って置換かけていたりするとそれが反映されなかったりする可能性がある。 00preferred 50foo 50bar 50buz 99static_permalink
right: 100%か負のマージンか
これまでCSSにはレイアウト方法があまりなかった。これからはFlexible Box LayoutやMulti-column Layout、Grid Layoutを始め、positionプロパティーに使える値の拡充などもあり柔軟に行えるようになるだろうが、それはけっして既存のレイアウト方法が不必要になるということではない。選択肢が増えると受け止めるべきだ。例えばright: 100%や負のマージンを使って親要素の外側左にレイアウトする手法はそのまま使い続けることになるだろう。 ほとんど同じレイアウトを実現するright: 100%と負のマージンの使い分けを通して、レイアウト方法の選択をどう行うべきかという基本的な思想を解説することにより、今後増えてくるレイアウトの選択肢にどう相対すべきかがわかるのではないかと思う。そしてそれはCSSプロパティーの意図された使い方を理解するということでもある
プル・クオート
英語で書くとPull Quote、Calloutなどとも呼ばれる抜粋見出しのこと。雑誌のインタビュー記事などでよく見る、インタビュー内容の一部が抜き出されて見出しのように配置されているやつ。blockquote要素でマークアップするのかと思ってたら、aside要素の方が適切らしい。引用ではなく抜粋で、かつコンテンツに同じ内容が既にあるので、なくなっても特に問題がないからか。 この記事はクリエイティブ・コモンズ 表示-継承 3.0 非移植で提供される。 aside要素で括るだけで、あとはp要素のみで良いようだ。figureやblockquote、q要素を更に利用してもよいように思えるけど、冗長すぎるか。出典的なものはfooter要素を使えば良さそうだけど、大抵の場合は明確なので必要なさそう。多人数相手のインタビューみたいなので、誰の発言なのかを示したい時などには使うと良いのかも。以下のマーク
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. つまりユニークなため再利用できないというマイナスの面がある、と。確かに再利用できない。でもこれはマイナス
空白の多いアイコン
直訳だと空虚なアイコン、一般的にはライン・アイコンなどと呼ばれているものは認識するに時間がかかるという問題を抱えているという記事が数日前に話題になった。これに対して人間はもっと認識力に優れているという反論が書かれた。素早く認識できるということと、認識し覚えることができるということはまったく別の話だと思うので、反論はピントがずれてると思う。 僕はライン・アイコンがウェブで使われるのがあまり好きではない。漢字等の複雑なグリフと並べられてしまうと、どこからどこまでが文字でどこからどこまでがアイコンなのかわからなくなるから。アイコン・フォント化されてるとレンダリングの感じも似かよるので更にわからなくなる。モノとしてはすごく好きなんだけど。
いっぱいMinGWがある環境におけるStrawberry Perl向けcpanmのラッパー
MinGWに加えてGit for Windows、Strawberry Perl、DevKit付きのRubyInstallerと、MinGWがいっぱい入ってる。こういう環境だとStrawberry PerlのセットアップでPATH環境変数にld.exeとかがあるフォルダーへのパスを追加される(または追加する必要がある)のがコンフリクトの原因になってとても厄介。どうせもうcpanmしか使わないので、そのラッパー書いてRubyInstallerのDevKitとRubyGemの挙動に似たような感じにごまかすことにしたメモ。 RubyInstallerのDevKitとRubyGemはうまく出来ていて、DevKitをインストールするとRubyGemでインストール系のコマンドを使う時にだけPATHにDevKitのフォルダーを追加してくれるようになっている(んだと思う)。優先してPATHに追加されるので
SVGよりアイコン・フォント！ な理由
両者は共にスケーラブルなもの(にできるもの)なのでその点では互角だけど、様々なプロパティーを持ち多彩な表現が可能なSVGの方がフォーマット的には優位にあると言って良い。が、なかなか利用が広まらないSVGに対して、アイコン・フォントの利用は急速に拡大している。単に流行りとみなす向きもあるけど、やっぱりそれなりに理由があるのではないかと思う。 CSSとの親和性 特に以下の3つのCSSプロパティーは効果的に使える。 font-size color text-shadow PNGで作られたアイコンの色を変更するには編集が必要だけど、アイコン・フォントはCSSファイルで自由に色を調整することができる。独自実装も含めるなら-webkit-maskプロパティーもとても(想像以上に)効果的に使うことができる。他にもちょっとした位置の調整やなんかも慣れ親しんだCSSで普通に可能。更にこれらをHTMLファイル
Data URI化した画像とその再利用性
Data URI化した画像はHTTPリクエストの削減に大いに役に立つので積極的に使って良いと思う。けど、CSSにおいて変数が使えないことなどの理由からその再利用性は低いため、注意して書かないと同じData URI化した画像がいくつもCSSに出てくるなどという無駄につながりかねない。極端な例では3KBくらいのData URI化した同じ画像が8から10以上出てくるCSSファイルとか見たことが何回もある。 単なるアイコンなどは使い回しすることはあまりなく、クラス名に紐付けられるだけなのでこういう問題は起こらないけど、上記のような透過させたグラデーションのような使い回すことを意図したテクスチャを違う背景色と混ぜてアレンジするというような使い方においてData URIを利用すると重複が起こりやすい。そういう時にはOOCSS的なアプローチでData URI化した画像を使うためだけのクラスを作ってセレク
/archives/の削除
こう言うと「過去ログ消したの……」みたいな感じだけど、そうではなくて過去ログへのアクセスのために使っていた/archives/を/blog/に移動させたというだけ。逆に言うとブログのトップページが一覧ページじゃなくなって、月ごとやカテゴリーごとのアーカイブ・ページへのリンクのリストになったという感じ。CoolなURIもたまには変わる。 もちろん/archives/のような過去ログへのアクセスを提供するページは必要不可欠だと思うんだけど、実態がブログ(/blog/)のアーカイブ一覧なのに/archives/にあるのは良くないなぁとずっと思っていた。せめて/blog/archives/にするべきかなと思って、気が向いたので作業を始めた。 途中で気が変わって、最近感じている「記事が全文で並んでるページって読みづらいよね？」みたいな感覚の元、一覧ページをやめて上記のような形にした。同じ内容が色々な
何にレスポンシブ？
レスポンシブ・ウェブ・デザインは当初は多様化するデバイスを見据えて……みたいな話だったような気がするけど、徐々にコンテンツに対してレスポンシブであるべきというような原理主義的な方向に揺り戻しが起きていると思う。それは間違っているとは思わないけど、コンテンツを重視するあまりデバイスというかその向こうにいる人を疎かにしかねないような気がする。 みたいなことを例付きで書こうと思ったけどそれほどのものでもない気がしてきた。デバイスでもブラウザーでもコンテンツでもなく、「人」にレスポンシブであることが大切なんじゃないか。と。 言葉遊びっぽい。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Combine Multiple PNG Images with SVG