普通のHTMLの書き方
保守しやすく、規模に依存しないHTML文書のために 一般 DOCTYPEで始める 置き換えられるべきまたは旧式のDOCTYPEを使わない XML宣言を使用しない 文字参照はできる限り使わない &と<、>、"、'は名前文字参照を使ってエスケープする 制御文字や不可視文字は数値文字参照を使う コメントではその内容の前後へ空白文字を置く 終了タグを省略しない 空要素の書き方を混ぜない タグや属性値の前後へ空白文字を置かない 大文字・小文字を混ぜない 引用符を混ぜない 属性を2文字以上の空白文字で区切らない 真偽値を取る属性の値は省略する 名前空間は省略する XML属性は使わない data-*とMicrodata、RDFa Lite用の属性と通常の属性を混ぜない デフォルトの暗黙のARIAセマンティックスを尊重する 文書要素 lang属性を追加する lang属性の値はできる限り短くする できる限り
Gitのdiffコマンドにある--exit-codeオプション - Hail2u
npmコマンドでよく書くパターンにGitで固定のファイルをステージしてコミットするというようなものがある。なんらかの処理を行うメインコマンドのpostコマンドでよくやる。まれにその固定のファイルが更新されないこともあり、その時コミットしてしまうとcommitサブコマンドが正常に(終了コード0で)終了しない。これを避けるためにはステージされることで更新があったかどうかをチェックする必要があることになる。それはdiffサブコマンドの--exit-codeオプションを使うとうまく書くことができる。 例えば更新されているかもしれないfooというファイルをステージして、更新があった場合にのみコミットしたい、とすると以下のようにコマンドをつなげれば良い。 $ git add foo && git diff --cached --exit-code --quiet || git commit --mes
我慢の期間
MovableTypeとWordPressとJekyllとHugoや、Gruntとgulp、SassとLESSとStylus、果てはjQueryなどの話はスケールやパターンを変えて繰り返される。その話はあたかも特定の何かに依存することが良くないとか新しいこっちのがすごいぞというように結論づけられることが多くて、僕にはちょっと頷けないこともあったりする。大切なのは何を解決しようとしていたかを忘れないことだと思う。複雑化しそうな場合にそこから先へ踏み込まずに我慢する期間がいるとかかも。 GNU makeでいいじゃん的な結論はそれは確かにビルドという点ではそうなんだけど、Gruntが解決しようとしていたのはそこじゃない。npmという生態系の中で完結させやすいタスク実行環境を手軽に用意することができることで、それ以上でもそれ以下でもない。実行速度以外にも腐臭を放つAPIやプラグイン間で一貫性のない
Semantic Versioningにおける破壊的な変更
io.jsがv1.3.0になり、ビルトインのURLモジュールでresolve('/foo/bar', '.')が/foo/とスラッシュ付きで返されるようになった。今までは/fooとスラッシュなしで返っていたので、これは破壊的な変更であり、Semantic Versioningに従うならばメジャー・バージョンを上げるべきではないのかという議論がなされていたようだ。 仮にこういった実装ミスの修正が破壊的な変更だとすると、ほとんどすべてのバグ・フィックスは破壊的な変更になってしまう。バグ・フィックスは必ずどこかで何か(モンキーパッチとか)を破壊するし、破壊しないことを保証することは不可能だ。Semverにおいては変更の仕分けはユーザーの利用ではなく、仕様という観点での話になる。つまり仕様に変更があったかどうかが焦点になる。 このURLモジュールのケースでは、仕様が外部(ドキュメントのブラウザーの
rel=subresourceを併用したCSSの遅延読み込み
クリティカルなんとかの関係やウェブ・フォントにおいて、CSSの遅延読み込みを行う気運は高まっている。様々なアイディアがあって、普通にCSSの内容を読み込んでhead要素に追加するものや、link要素を動的に追加するもの、予めlink要素をrel=stylesheetなしで書いておいて後で追加するものなどがその主なものだ。最後の手法ではrel=subresourceを追加して書いておくと、一部ブラウザーでダウンロードが速く始まるんじゃないかというアイディアを持った。 サポートが広いのでprefetchかなと思ったけど、書いたそのページ内で使うリソースの先読みに使うものではないような印象で、すぐさま使う場合はsubresourceの方が適切なようだ。Chromeがそういうイメージで実装してるという話で、ウェブ標準では特に細かく規定はないようではある。 <html> <head> <style>
Every Declaration Just Onceの例
同じ定義は書かないCSSの簡単な例とその書き方に対する覚え書きを残しておく。同じ定義を書かないようにしていくと、CSSプリプロセッサーはおろか、セレクターのネストもなくて良いのかと感じてくる。もしかするとCSSの着地点はここなのかと洗脳されつつある。もはや第三者の目で見ることができなくなったので、他の人の意見も聞いてみたい。 .foo { border: 1px solid red; margin: 0 auto; width: 40rem; } .bar { border: 1px solid green; margin: 0 auto; width: 40rem; } .baz { border: 1px solid blue; margin: 0 auto; width: 40rem; } このような共通する定義を持つセレクターは以下のように書かれる。 .foo, .bar, .ba
ブラウザー・キャッシュの今
元々「静的なファイルは限界までキャッシュしろ！」というような金言はそれほど重要視していなかった。The changing role of the browser cacheという記事では、開きっぱなしにされるタブと継続的デプロイをキーワードに、ブラウザー・キャッシュの役割が変化していることを解説している。 ブラウザー・キャッシュが再訪問に対して威力を発揮するのに対し、開きっぱなしにされるタブでは再訪問されることはなく、継続的デプロイされるアプリケーションではその効果は限定的なものにしかなりえない、という意見だ。納得の出来る意見ではある。 僕が元々こういった長期間のキャッシュに疑問を持っていたのも少し似ている。特に継続的デプロイの元では限定的な効果になることは自明だと考えていた。またいわゆる普通のウェブページにおいては再訪問という行為そのものが随分前から死滅したとも考えている。具体的にはソー
スクロール・ハイジャッキングなど
変なスクロールとか呼ばれちゃったり、邪悪とかゴミとか散々な感じ。どちらかというと実装上の問題ではなくて、見る方と作る方(発注元で実装者ではない)とでウェブサイトの目的への意識がずれていることが原因なんじゃないかと考えている。 見る方は何かしらの情報を得られるとかそういう目的でスクロール・ハイジャッキングがなされるウェブサイトをそれを知らずに開き、スクロールしようとしたら「なんだこれクソが」となる。実際ユーザーが制御できないウェブページというのは邪悪であるわけで、その感想で間違ってはいないんだけど、その前提としてウェブサイトは有用な情報を効率良く届けるただそれだけのものという意識がある。 一方、作る方はこういったカスタム・スクロールを使ったウェブサイトを作ると決めた場合、それはもっと芸術的なウェブサイトを意識しているはずだ。情報の提示そのものではなく、よりプレゼンテーション寄りで、いわば(イ
rawgithub.comへのホットリンク
ある記事でrawgithub.comを使ってJavaScriptウィジェットを配布しているのを見た。もちろんrawgithub.comが「テストなどにのみ使って！」と書いているのもあるけど、使うべきじゃない理由は他にもある。 パフォーマンス Amazon S3っぽいので、速度的に大きな問題が起こることはあまりなさそう。どちらかというと、サービス提供者のコスト・パフォーマンス。開発補助の便利ツールとして感謝して使うくらいにしとかないと大変そう。MIMEタイプの変更が行われる前までのGitHubのrawサブドメインへのアクセスが全部rawgithub.comに飛んだとすると、月額いくらになるのか見当もつかない。 ドメインの将来 ドメインの更新忘れなどで悪意のある第三者にドメインが奪われた時に、悪意のあるファイルを配信されるようになるかもしれない。rawgithub.comの用途は主にCSSファ
CSSポストプロセッサー時代の到来
SassやLESSといったCSSプリプロセッサーは市民権を得たと言って良いと思う。しかしそれらCSSプリプロセッサーは開発という段階にのみ利をもたらすもので、今のところはそれ以上ではない。CSSを実際にユーザーに届けるまでには、開発だけではなくレビューとリリースという段階もある。レビューとリリースも確実性を持って効率的に行うためには、CSSポストプロセッサーと総称されるようなツール群が必要になるだろう。 この文書はFrontrend Advent Calendar 2013の4日目への記事として寄稿した。明日は@hilokiさんがスタコラサッサと書くようだ。 目次 CSSポストプロセッサーとは CSSプリプロセッサーの出力するCSS CSS Lint 開発用とレビュー用、リリース用のCSS CSSポストプロセッサーのユースケース ベンダー拡張プリフィックスの付加 Media Queries
アイコン・フォントとユーザースタイルシート
ユーザースタイルシートでフォントを独自に設定(固定)している場合に、アイコン・フォントがうまく表示されないであろうことについて順に説明している記事を読んだ。ユニコードの私用領域へのマッピングだけでなく、代替となる文字列を提供する……だけでは、まだ足りないのではないかという話。前に書いた気もする。 ユーザースタイルシートによるフォントの固定だけでなく、ブラウザーの設定で文書のフォントを利用しない場合や、私用領域へのマッピングではなくリガチャを使っていたとしても同じ話。きちんと意識しておき割り切るか、場合によってはSVGで背景として表示する方法に変える必要がある。アイコンの表示が欠けた場合、ウェブサイトが機能しなくなる恐れのあるナビゲーションなどでは避けた方が無難かなと僕は思う。完全に補助的な飾りにすぎないケースにおいては空白や豆腐でも可としたい。 最後に挙げられているgetComputedS
Sassの存在意義
SassはCSSの貧弱さを補うような便利機能について取り上げられることが多い。そのためその機能の奥に隠れているものについて触れられることはあまりない。例えば変数や四則演算、関数によって値に論理的な意味を持たせることができることとか。そういうCSSに足りない概念の導入できることとかももちろん周知させたいけど、それ以上にHTMLとCSSによるWebサイトの作成に新たなアプローチが加わることを周知させられればいいなぁと最近思う。Sassの存在意義というのはその辺りに見いだせるんじゃないかと考えているので。もう「CSSグラデーションのミックスイン！」とかスニペットでやれるようなことを推すのはやめたい(やめてほしい)。 現状ではWebサイトは以下の2つのアプローチでしか作成(更新)できない。 HTMLで文書をマークアップして、それに合わせてCSSにセレクターを書く CSSでデザインを定義して、それに
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
