画像の縦横サイズの追加
自前の画像を参照する時にwidthとheight属性を追加すると激しい腹痛におそわれる病を長く患っていたけど、どうやら完治したようなのでバッチ処理で追加してた。ついでにimg要素の各属性の記述順序なども書きかえたりして、楽しく時間を浪費した。大いなる無駄だが、他人には迷惑をかけないし、途中から段々トランスしてきた。 サイズを明示した画像がはみ出すことへの対策にはCSSでmax-widthプロパティーを使う。それだけだと縦横比が狂ってリサイズされるので、以下のようにheightプロパティーも併用するのが良い。 img { height: auto; max-width: 100%; } @supports (object-fit: scale-down) { img { height: auto; max-width: none; object-fit: scale-down; } } こう
ウェブ・フォントの読み込み - Weblog - Hail2u.net
ウェブ・フォントも完全に行き渡り、今はどう効率的に配信するかについて多くの時間を割くようになった。Google Fontsの低め安定路線を見限り、TypeKitやFonts.comへ鞍替えする人々も増えた。それと同時に自前でホスティングする人々も徐々にその数を増やしており、どれが最適解なのか一応の結論が出るにはもう少しかかるだろう。まず、ウェブ・フォントの読み込みにおいてどのようなアプローチがあり、どのようなメリット、そしてデメリットがあるのだろうか。 TypeKit等に頼るにしろ、自前でホスティングするにしろ、もちろん最終的にはウェブ・フォントをブラウザーに送りつける必要がある。読み込みとはまさにその部分の話だ。話がややこしくなるので、多様な実装を意識した安全な書き方などについては触れない。 普通に@font-face定義を利用 @font-face定義をただ普通に書く場合のメリットは、
複数のPNGからICOへ変換
favicon.icoの作成を自動化しようとして、いくつかCLIの変換ツールを物色していた。最終的にImageMagickのconvertに行き着いたので、あまり得られるところはなかった……。 png2ico $ png2ico favicon.ico logo-16.png logo-32.png logo-48.png logo-256.png 特に何も考えずに使える良いツールだった。しかし256x256以上、つまり256x256のアイコンは含めることができない制限がある。16x16以外に32x32だけでなく、256x256を含めてやりたい現状だとちょっと使いづらい気がする。 ToICO $ toico -o favicon.ico logo-16.png logo-32.png logo-48.png logo-256.png これもあまり考えずに使えた。しかし生成されるICOファイ
安全でアクセシブルなアイコン・フォント
Translation of: Bulletproof Accessible Icon Fonts by Filament Group アイコン・フォントを利用する場合、あらゆるユーザーに適切にアイコンを提供しようとすると、かなり気をつける必要があります。そのフォントが読み込まれなかった時にどうなりますか？@font-faceがまだサポートされていないブラウザーでは？ どうすれば安全に(bulletproofに)アイコン・フォントを利用できるかをこれから解説したいと思います。 効率的で機能的なウェブサイトを制作するという、この終わることのない探求において、ベクター形式のアイコンを提供する手段として、簡便であるフォントを利用することが何度も提案されてきました。対して私達は通常ベクター形式のアイコンとしてSVGをIan Featherがブログ書いたような理由から選んで(また、薦めて)おり、既に
right: 100%か負のマージンか
これまでCSSにはレイアウト方法があまりなかった。これからはFlexible Box LayoutやMulti-column Layout、Grid Layoutを始め、positionプロパティーに使える値の拡充などもあり柔軟に行えるようになるだろうが、それはけっして既存のレイアウト方法が不必要になるということではない。選択肢が増えると受け止めるべきだ。例えばright: 100%や負のマージンを使って親要素の外側左にレイアウトする手法はそのまま使い続けることになるだろう。 ほとんど同じレイアウトを実現するright: 100%と負のマージンの使い分けを通して、レイアウト方法の選択をどう行うべきかという基本的な思想を解説することにより、今後増えてくるレイアウトの選択肢にどう相対すべきかがわかるのではないかと思う。そしてそれはCSSプロパティーの意図された使い方を理解するということでもある
opacityとz-index
opacityプロパティーで1より下が指定された要素はその重なり順が変化するという仕様があるようだ。擬似要素を複数組み合わせて紙をずらして重ねたようにロゴをちょっと改悪した時に初めて知った。いつものChromeのバグかと思った……。 仕様ではpositionプロパティーがstatic以外の要素でopacityプロパティーを1より下にするとz-indexプロパティーが0であるとみなされるようになっている。そのためその要素でz-indexプロパティーを-1にして背面に移動するようにしたり、100等で意識的に手前に持ってきたりするようにしている場合、その重なり順が壊れてしまう。 と、こう書くと結構単純な感じなんだけど、実際には0とみなされた上で新たな重なり順が作られるので、いくつかの要素をまとめて半透明にして重ねまくってたりすると、どういう重なり順になるかとてもイメージしにくい。ので余程の理由が
枠線付きの吹き出し
ミニブログの隆盛以降ウェブ上でよく見かける吹き出しをCSSで作るお話。単色のものはかなり前に書いた。今回はそれに枠線をつけてみよう！ みよう！ みよう！ Demo: Bordered Speech Bubble 枠線は単なるsolidなborderで少し角を丸めただけ。 尻尾を付ける :before擬似要素を使う。デモの3番目のサンプルのように、まず枠線と同じ色で三角形を作る。三角形は以前のエントリで書いた手法と同じで、左右のborderをtransparentにすることによって作る。 .speech-bubble:before { border-top-width: 16px; border-right-width: 16px; border-bottom-width: 0; border-left-width: 16px; border-color: #369 transparent;
不明なCSSセレクター
ブラウザーがCSSをパースする際、不明なセレクターに遭遇するとどうなると思いますか？ 実はそのセレクターを含むルール全体が無視されます。何を当たり前のことを言っているんだと思われるかもしれませんが、そのルールが複数のセレクターを持っていて、そのうちひとつだけが不明なものだとしてもルール全体が無視されるということはあまり知られていないような気がします。知られていないというよりも意識する必要があまりなかったという方が近いですかね。 つまり以下のようなCSSコードは無意味です。 :-moz-any(article, aside, nav, section) h1, :-webkit-any(article, aside, nav, section) h1, :matches(article, aside, nav, section) h1 { color: red; } CSS4の:matche
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
