普通のHTMLの書き方
保守しやすく、規模に依存しないHTML文書のために 一般 DOCTYPEで始める 置き換えられるべきまたは旧式のDOCTYPEを使わない XML宣言を使用しない 文字参照はできる限り使わない &と<、>、"、'は名前文字参照を使ってエスケープする 制御文字や不可視文字は数値文字参照を使う コメントではその内容の前後へ空白文字を置く 終了タグを省略しない 空要素の書き方を混ぜない タグや属性値の前後へ空白文字を置かない 大文字・小文字を混ぜない 引用符を混ぜない 属性を2文字以上の空白文字で区切らない 真偽値を取る属性の値は省略する 名前空間は省略する XML属性は使わない data-*とMicrodata、RDFa Lite用の属性と通常の属性を混ぜない デフォルトの暗黙のARIAセマンティックスを尊重する 文書要素 lang属性を追加する lang属性の値はできる限り短くする できる限り
遅延読み込み用のぼやけた画像
Mediumでとある記事を高速にスクロールして読んでいたら、さりげなく画像を遅延読み込みしていることを知った。読み込み発火のタイミングがうまいのかあまり遅延読み込みの存在を感じさせないのもすごいと思ったが、プレースホルダー画像の実装方法が良さそうだった。単純に元の画像を幅30px程度まで小さくしてそれをブラウザーにリサイズさせることでぼやけた画像をプレースホルダーとして表示しているだけだが、十分に機能していそうで目から鱗だった。 画像の遅延読み込みはなかなか曲者で、読み込むタイミングやプレースホルダーとしている画像が悪いと大きくユーザーにストレスを与える。プレースホルダーでよく使われるローディング画像は読み込み中のインジケーターではあるが、同時に何か遅いことをやっていますというネガティブな印象も与えてしまう。ユーザーはローディング画像を見るとスクロールを止めなくてはならないのかと感じること
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
画像の縦横サイズの追加
自前の画像を参照する時に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定義をただ普通に書く場合のメリットは、
“マークアップ”するということ ～ HTML5勧告に寄せて ～
HTMLを適切な要素を使って書いていくことは実はそれほど難しくはない。しかし過剰に要素を使わずに、かつスタイリングすることも意識して、と適切に“マークアップ”するのはなかなかの修練を必要とする。いったい“マークアップ”するということはどういうことなのだろうか、そしてどのような思考の元に行えば良いのだろうか。 HTML5での変化 著作権表示のマークアップ small要素 footer要素とsmall要素 p要素とdiv要素 footer要素とp要素 スタイリングとの兼ね合い マークアップするということ HTML5での変化 コンテンツに則した素直な形でマークアップできること。 HTML5で変わることや変わったことは多くあるが、それらをおおまかに俯瞰するとこのような言葉に集約できる。そのために様々な要素や属性が追加され、既存の実装をなるべく壊さない形で要素の意味に変更が加えられた。これらの変化は
横並びのリストのセンタリング
リストを横並びにしてセンタリングというのはよく使う。ただよく使う(われる)わりには「これ！」というようなテクニックがないような気がする。inline-blockで並べた場合は項目の間に隙間ができ、floatで並べた場合はセンタリングがトリッキーすぎる。気分で色々使い分けてたけど最近はdisplay: inline-tableをよく使うようになって、これで良いかなーという感じ。 <nav class="paging"> <ul> <li><a href="foo">Prev</a></li> <li><a href="bar">Next</a></li> </ul> </nav> というようなマークアップの一般的なページング・ナビゲーションだと、 .paging { text-align: center; } .paging ul { display: inline-table; } .pa
Sassで行こう！
Translation of: Getting Started with Sass - A List Apart CSSの持つその簡明さは欠かせない特徴の一つで、それは最も歓迎されている点でした。CSSによるスタイルシートは、セレクターといくつかの適用したいスタイル情報を含むルールを羅列したものに過ぎません。しかし、WebサイトやWebアプリケーションが巨大に、そして複雑になり、様々なデバイスや画面サイズに対応せざるを得なくなった現在、この簡明さという特徴―fontタグやテーブル・レイアウトの淘汰に大いに役にたったもの―が大きな足かせになっています。 簡単な計算機能や変数を追加するなどといったCSSの修正案が過去に提示されましたが、どれもブラウザー・ベンダーには採用されませんでした。仮にこういった新しく素晴らしい拡張されたCSSがあるブラウザーに実装されたとしても、それが実用に耐える程度に
Sass、そしてSassy CSS (SCSS)
CSSを拡張したメタ言語であるSass、そしてその別文法として定義されたSCSSについて、960.gsなどのCSSフレームワークと絡めて、Sass (主にSCSS)の良さを解説する。 CSSフレームワーク Sass Sassy CSS aka SCSS SCSSでCSSフレームワーク 2カラムレイアウトの作成 clearfixやReset CSSの組み込み カラム幅の変更 カラムの入れ替え SCSSで完結することの意義 まとめ 最後に CSSフレームワーク 960.gsやBlueprint、BlueTripなどCSSフレームワークと呼ばれるものは色々ある。フレームワークと名乗るだけのことはあって、それらの生産性はとても高い。テンプレートで適切にクラス名やIDを埋め込むだけなので、複雑怪奇なCSSコーディングを意識することなく誰でも簡潔にきれいなカラム・レイアウトを作成できる。 HTML 4
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
