普通のHTMLの書き方
保守しやすく、規模に依存しないHTML文書のために 一般 DOCTYPEで始める 置き換えられるべきまたは旧式のDOCTYPEを使わない XML宣言を使用しない 文字参照はできる限り使わない &と<、>、"、'は名前文字参照を使ってエスケープする 制御文字や不可視文字は数値文字参照を使う コメントではその内容の前後へ空白文字を置く 終了タグを省略しない 空要素の書き方を混ぜない タグや属性値の前後へ空白文字を置かない 大文字・小文字を混ぜない 引用符を混ぜない 属性を2文字以上の空白文字で区切らない 真偽値を取る属性の値は省略する 名前空間は省略する XML属性は使わない data-*とMicrodata、RDFa Lite用の属性と通常の属性を混ぜない デフォルトの暗黙のARIAセマンティックスを尊重する 文書要素 lang属性を追加する lang属性の値はできる限り短くする できる限り
あなたのサービスが落ちた時にユーザーになんと言うべきでしょうか？
Translation of: What should you tell your users when your service is down? by David McKenney つい最近、私達は多くの有名なサービスが完全に停止するという状況に遭遇しました。この出来事は、こういった何か不具合が起きた時にユーザーとどうコミュニケーションをとるかについて学ぶ良い機会なのではないかと思います。あの時InstagramとAirbnb、IFTTT、Vineがユーザーに送った通知は以下のようなものでした: これらから何を学べるのでしょうか？ これらすべてのツイートは、何か不具合が起きた時のコミュニケーション方法として一般的なパターンを採用しています: 技術的な専門用語を避け、ユーザーに簡潔に、そしてフレンドリーに伝えること みなさんの多くが不具合に遭遇していることを確認しました。 問題に気づいた
(S)CSSの書き方メモ
HTML5時代に向いていそうな(S)CSSの書き方を模索しています。SCSSで書くのでモジュール式に色々分割した方が良さそうだな……とか色々試してますが、なかなかこれ！ というものに辿りつけません……。ということで、ここ最近の書き方をメモがてら晒してみる試みです。 実際にこのサイトで使っているSCSSファイルを抜粋しつつ列記していきます。 style.scss style.cssになるSCSSファイルではCSSは書かないようにします。ただし例外としてCSS文法での@importルールはその必要性からここに書きます。Webフォントなんかで使いますね。それ以外はSCSSの@importでモジュール化した各種SCSSファイルを読み込んでいきます。 @import url("http://fonts.googleapis.com/css?family=Pacifico"); @import "va
CSSでモーダル・ウィンドウ
pointer-eventsプロパティでnoneを指定すると最前面に置いた要素を無視して普通にページ操作が可能になります。なので、そういう風にしておいた要素をopacityプロパティで非表示にしておけば、普段は見えないけど特定の操作で最前面に飛び出すモーダル・ウィンドウとかも簡単に出来ます。pointer-eventsプロパティってこういう使い方するためにあるの？ Demo: Pure CSS Modal Window .window { opacity: 0; pointer-events: none; } で、見えない・操作できないウィンドウが作れるので、:target擬似クラスで表示の切替を行えばOKです。 .window:target { opacity: 1; pointer-events: auto; } 簡単！ デモのようにposition: fixed;とかしておくとよりら
Version Control for Designers
このドキュメントは Version Control for Designers の日本語訳であり、元のドキュメントと同じくソースコード管理に予備知識がまったくない人を想定している はじめに リポジトリの構造 ブランチ 作業の流れ ブランチを切る その他の便利なツール ベスト・プラクティス はじめに What have you done for me lately? バージョン管理、ソース管理やリビジョン管理とも呼ばれているものはあらゆる開発に必須である。なぜなら基本的にはメールやインスタント・メッセンジャーと同じようなコミュニケーションをとることができるツールでありながら、人々の会話ではなくソースコードを元にして機能することができるからだ。 バージョン管理 他のプログラマと簡単に意思の疎通を図ることができる 開発チームでコードを共有することができる デプロイしている「製品」バージョンを別個
Git Cheat Sheets JP
設定 基本 ブランチ リモート・リポジトリ git-stash git-svn 参考 修正履歴 設定 Git には様々なオプション設定がある。中には挙動を大きく変えるものもあるので注意が必要である。 設定をすべて表示する $ git config --list システム (/etc/gitconfig) の設定 $ git config --system --list や、ユーザーごと (~/.gitconfig) の設定 $ git config --global --list など表示する対象を絞ることもできる。 ユーザ名とメール・アドレスを設定する $ git config --global user.name "John Doe" $ git config --global user.email "john.doe@example.com" コミットする時に記録されるユーザー名とメ
rev="canonical"
海の向こうで一気に議論が過熱したrev="canonical"ネタ。ざっくりまとめると、TwitterやSMS等の文字数制限のあるメディアで長いURLを投稿するためによく使われてるURL短縮サービスはアレだよね……というところから始まって、じゃぁ個々が自前で短いURLを用意してやって機械的に辿れる仕組み、rev="canonical"を使おうぜ！ という感じ。 URL短縮サービスの提供する短いURLは、on url shortenersで触れられているようにいくつもの問題点がある。一番身近なのはスパムの温床になっていること。インバウンドリンクの追跡が不可能であることなんかも気になる人が多いかもしれない。この話題が再燃した一番大きな原因はDiggBarの登場で、そこらへんの細かいところは短縮URLは必要悪か、単なる悪か。に詳しい。 「短縮URLは必要悪か、単なる悪か。」の最後で触れられている
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
