2007年8月アーカイブ
2007年8月26日
なぜCSSフレームワークを利用しないのか
Why I don't use CSS Frameworks - Warpspireの記事について。CSSフレームワークを利用してもそんなに開発効率は良くならないし、避けがたいブラウザのバグはフレームワークを使っても避けられない。その上、自分のコードと書き方になれてしまっているし、CSSフレームワーク由来のバグを抱えるかもしれないし、コーディングの勉強にならない。だからCSSフレームを利用していない。乱暴に要約するとそんな内容。
もう二つの反対意見。一つ目は、フレームワークは多くの使っていないスタイルを読み込ませることで動作が重くなるのではというのと、HTMLのマークアップはプロジェクトによって固有のclass・id構造になる。それがセマンティックの強みでフレームワークはその強みを削ってしまうというもの。二つ目はCSSフレームワークは「それを不変なものとして維持させて、HTMLを変更させ」ようとしている、それはHTMLとCSSのそもそもの考え方に適さない、というもの。
9/18追記。
2007年8月25日
新ハーバード流交渉術
ハーバード流交渉術の続編的な性格も持っているため「新ハーバード交渉術」という日本語タイトルにしたそうです。原題は「Beyond Reason : Using Emotions As You Negotiate（理性を超えて：交渉に感情を用いる）」。
本書の内容は「交渉相手との感情的な関係を「ポジティブ」にする」ことで交渉を成功させるといったもの。3部構成で、1部でポジティブ（ネガティブ）な感情を生み出す源となる5つの「革新的な欲求」を提示して、2部で5つの革新的な欲求について、実践例を交えて詳細に説明しています。最後の3部ではより実践的なアドバイスとして、「強いネガティブな感情に対処しよう」「準備の重要性」「アイデアを実世界で使う」という3点について書かれています。5つの革新的な欲求について簡単な要約を下記に記します。
- 価値理解：自分の考えが認められているか
- つながり：仲間として扱われているか
- 自律性：自分にも意思決定の余地があるか
- ステータス：ステータスにふさわしい扱いを受けているか
- 役割：求めれている役割を満たしているか
交渉の現場において、冷静になるのは難しいですし、威圧されている状況化で自分の考えを述べることも難しい。良好な関係じゃない交渉であればもちろん厳しいですが、良好な関係であってもその関係を崩してしまう懸念があるから、やはり厳しい。本書にはそういった感情に対する対処法や、関係を崩さないための実践的な提案がなされています。
ただ、本書に掲載されている状況とまったく同じ状況というのはそんなにないですし、提案通りに対処しても、人によっては落ち着きを取り戻せないかもしれない。5つの革新的な欲求を「相手の立場を知るためのフレームワーク」としてとらえ、事前に何を準備しておくか、どうやって心の落ち着かせるかとか、経験を積み重ねて自分にあった方法をアレンジしていくのが肝要なのかなと思います。
本の内容を通貫するコアな概念があるとわかりやすいですね。わかりやすい本の条件と言えるかもしれないです。
2007年8月24日
Wikipedia : 編集履歴から政府機関や企業が自己に不利益な項目を削除した形跡
- Technobahn ニュース : 任天堂やソニーもWikipediaを検閲？ Wikiscannerによる調査で判明
- 秋元@サイボウズラボ・プログラマー・ブログ: Wikiscanner - Wikipedia+なかのひと検索
- メモログ：情報の行間を読む（3/4）発信者を知る
Wikipediaの編集履歴をたどれるツール、Wikiscannerを利用して調査した結果、政府機関や企業が自己に不利益な項目を削除した形跡がみつかったそうです。たとえば任天堂がゲームキューブの初期不良問題の記述を削除したとか。詳細な情報についてはTechnobahnの記事を参照ください。
記述内容が事実であるかどうかは別として、やはり企業が自社の関連する項目を編集するのは誤解を招きそうですね。不都合な事実だから削除した、情報操作だと思われても仕方がない。個人的には、自分の関わっている製品が、事実であれども強烈な批判にさらされていたら、ついカーッとなって削除したくなる気持ちもわからなくもないですけど。
情報の受信者としての立場から考察すると、情報とは「発信者の意図が込められている」ということを念頭に置くことが大事だなと再認識した次第です。Wikipediaにおいては「不特定多数の発信者が、自分の考えに基づいて情報を記載している」ということを忘れないようにする。他の情報源をあたってみたり、別の視点から考察してみるということが肝要かと思います。最終的には、信じるべき情報かいなかは自分で判断せざるをえないわけですけど。
追記（9/2）
追加で見つけた情報をいくつか追記します。
2007年8月23日
FireFox排除運動
slashdot.orgの原文が発見できなかったのですが、アメリカでFirefoxの排除運動というものがあるそうです。話の主旨は、広告料で成り立っているサイトなのに広告を非表示（ad block）されるのは困る！非表示にするようなFirefoxは排除しよう！というもの。
具体的な排除運動の方法としては、User Agentを判別してFirefoxだったらhttp://whyfirefoxisblocked.com/ に誘導するというもの。User Agent Switcherを利用すればUser Agentは書き換え可能なので、ユーザーが誘導されることを拒否することは可能。
HDレコーダーのCMスキップ機能と同じですね。ユーザーとしては不要だけど、制作者としては困ると。ユーザーに見ることを強制するような広告は、ビジネスの形としては厳しくなりつつあるという印象を受けました。他の何かと時間の使い方を競合させないような広告の出し方が良いように思う。CMは見なくても手持ち無沙汰な電車の中吊りとか無駄に読んだりする。
2007年8月22日
Firefox : link prefetching（リンクの先読み機能）
いろいろ調べものをしていたときに見つけました。他のブラウザまでは調べていないのですが、Firefoxではlinkタグのうちrelが「next」もしくは「prefetch」となっているhrefのURLを、ブラウザのアイドル時間中に先に読み込んでおきます。こうすることによって、次のページに遷移したときにスムーズにページが表示されます。たとえばHTMLでプレゼンを作成した場合に、次のページの画像などもprefetch対象にしておくと読み込みがスムーズになって良いかもしれない。
ただし、hrefにクエリストリングが含まれるような場合や（http://memolog.org/index.html?foo=0 みたいな）、hrefがhttp以外の場合はprefetchは行わないようになっている。逆に言えば、prefetchしてほしくないときはhrefに適当なクエリストリング的なパスを入れておけば良いみたい。
prefetchによるHTTP リクエストには「X-moz: prefetch」というヘッダが付与されているのでどのリクエストがprefetchによるものかは判別できる。これをうまく利用してprefetchをしないようにすることもできるかのかなと思います。
2007年8月21日
アンビエント・ファインダビリティ
ambient（周囲を取り巻く・完全に包囲している）とfindability（位置特定可能な・特定の対象物の発見のしやすさ）を二つあわせて、アンビエント・ファインダビリティ。直訳すると「周囲を取り巻く特定の対象物の発見のしやすさ」というような感じですが、私なりに解釈するとしたら「自分の取り囲む広大な情報の波から特定の情報を発見する」ようなことを表しているのかと思います。アンビエント・ファインダビリティの世界では、個人は「広大な情報から適切な素早く情報を入手する」ことが肝要で、本書では情報とは何か、情報の見つけやすさとは何かを伝え、最後に台頭しつつある情報を選りすぐる社会的な仕組み（タクソノミーとかフォークソノミーとか）などを次々と紹介しています。
ただ、情報について各論的に紹介するのみにとどめていて、実際にこれからの「アンビエント・ファインダビリティ」な世界でどのように行動すべきか、といった提言はなされていない。その点が、すこし拍子抜けというか、結末がうやむやな映画を見たような感覚を覚えました。「真の情報はどこにあるか」みたいな質問に対して回答を出すようなものなので、一意的な結論を出すのは難しいのかもなーと、思ったりもしますが。
情報とは、発信者がいて受信者がいるわけですが、インターネットにおける個人は発信者にも受信者にもなる。発信者としては「いかにして情報の波から自分の情報を際立たせるか（発見しやすくさせるか）」というのが重要な課題になる（見つけられない情報はないに等しいから）。受信者としては、玉石混合な情報からどのようにして「玉」の情報を見つけ出すか、いかがわしい情報を切り捨てることができるかが肝要となる。この二点を念頭に入れて本書を読むと、読みどころ満載で非常に楽しめました。
ということで、しばらくのブログネタとして、この半年くらいの読書の感想文を書き連ねていこうかなと考えています。順番は、机の左にあるものから順々に（規則性ゼロ）。
2007年8月19日
Blueprint : CSSのフレームワーク
Blueprintとは、いわゆるひとつのCSS のフレームワークです。ライブラリはbutton.css、grid.css、reset.css、typography.cssの4つのCSSで構成されていて、圧縮版のcompressed.css、ライブラリをインクルードするためのscreen.css、印刷用のprint.cssなどが同封されています。それぞれのCSSはその名の通りで、button.cssはボタン用のCSS、grid.cssはグリッドデザイン用のCSS、reset.cssはいわゆるブラウザのデフォルト設定をリセットするためのCSS、typography.cssはタイポグラフィティ用のCSSです。
わりとシンプルな構成のCSSで、Typographyのサンプルのように奇麗に段組みに仕上げることができる。背景の罫線がきれいにはまっているのに小さく感動を覚えます。Firebugを使ってサンプルサイトを日本語に置き換えてみましたが、日本語でも奇麗に表示できます。
ただ、一つのグリッドのデフォルトの横幅は70px（うちマージンが20px）で、全体を960pxと固定的に指定されてます。横幅を変更したいときはCSSを手作業で調整する必要となるため、すこし手間がかかる。
YSLOW 勉強 : まとめ
- 1 : HTTPのリクエストを最小限にしよう
- 2 : CDNを利用しよう
- 3 : Expires Header を追加しよう
- 4 : Gzip 化しよう
- 5 : CSSはページの上に配置しよう
- 6 : スクリプトはページの下に配置しよう
- 7 : CSS expressions の使用は控えよう
- 8 : CSSとscriptは外部ファイルにしよう
- 9 : DNS lookups を減らそう
- 10 : Javascriptを最小化しよう
- 11 : リダイレクトを控えよう
- 12 : 重複するscriptを削除しよう
- 13 : ETags を設置しよう
YSLOWの勉強のまとめ。最後に自分の所感をまとめておきます。
YSLOWにおける13の評価基準を一つずつ見てきてわかったことは、YSLOWとは、HTTPの応答を減らせる余地があるかないかを評価するためのツールだということ。それは1の解説にあった「「ユーザーの待ち時間の大半は画像やCSS、javascript、Flashなどのページの構成要素のダウンロードに費やされている」という原則を根本としている。
評価基準はHTTPの応答を減らせるアイデアを13個連ねたといった体裁で、それぞれの難易度がまちまちです。7 : CSS expressions の使用は控えようのように比較的簡単なものから、2 : CDNを利用しようのように対応が開発的にも・コスト的にも難しいものまであるし、10 : Javascriptを最小化しようのように、対応は難しくなくても、メンテナンスが猥雑になる懸念があるものもある。すべてを「A」にするよう努力するよりは、全体の利益とコストを鑑みて、ケースバイケースで最適な対応を考えるのが肝要なのかと思います。
13の評価基準をオペレーション作業とHTMLコーディング作業のふたつに分けるとしたら、2、3、4、9、11、13がオペレーション作業で、1、5、6、7、8、10、12はHTMLコーディング作業に分けられるかと思います。
HTMLコーディングを業務の一部にしていたものとしては、やはり後者の方がより興味がそそられました。どれもわりと普通のことが書かれている感がありますが、たとえば「大規模な集客を想定しているポータルサイトだから、画像の点数を減らしてサイトが重くならないようにしよう」とか、そういったソリューションを持ったHTMLコーディングなどを頭に妄想させていると、わくわくしますね。たぶん誰も気がつかないと思いますが、サーバーの負荷を少し減らして、そして最終的には地球に優しいHTMLになっている、はず（かなあ）。
最後に、この勉強を書き連ねている最中に見つけた、日本語でより詳細に記しているサイトを紹介しておこうと思います（勉強始める前に探しておけばよかった）。
2007年8月18日
Checkbot : ウェブページのリンクを自動チェックしてくれるツール
Checkbot はウェブページのリンクを自動でチェックしてくれるツールです。ウェブページ上のリンク切れとかを探すのときに役立ちます。
Macへのインストールは簡単で、ファイルをダウンロードして解凍したのちに、ターミナル開いてperl Makefile.PL、make、make installをするだけです。いくつか依存モジュールが存在しますが、Mekefile.PLを実行したときに教えてくれます。
実際の動きとしては、HTTP で返ってきたレスポンスを集計している感じです。401とか301とか404などなど。checkbotではそれに加えて、下記のような項目を教えてくれます。
- 901 Host name expected but not found：host nameが見つからなかった
（In this case the URL supports a host name, but non was found in the URL. This usually indicates a mistake in the URL. An exception is that this check is not applied to news: URLs.） - 902 Unqualified host name found：ホスト名がドメイン部分を含んでいない
（In this case the host name does not contain the domain part. This usually means that the pages work fine when viewed within the original domain, but not when viewed from outside it.） - 903 Double slash in URL path：URLのパスの中にダブルスラッシュが含まれている
- 904 Unknown scheme in URL：URLが、checkbotがわからないスキーマで始まっている。
(The URL starts with a scheme that Checkbot does not know about. This is often caused by mistyping the scheme of the URL, but the scheme can also be a legal one. In that case please let me know so that it can be added to Checkbot.)
リンク先のページは存在しているけど意図しているリンク先と違うとか、そういうものは確認できません。
2007年8月17日
YSLOW 勉強 : 13: Configure ETags
rules for high performance web sitesの十三個目（最後）。ETags（Entity Tags）を設定しよう。ブラウザが持ったキャッシュが古いかどうかを判断するための情報として、構成要素（component：画像とかスクリプトとか）のバージョンをETagで特定させることで、last-modified（修正日）よりも柔軟（で確度の高い）情報を提供することができる。
ETagにおける問題は、サーバーを特定させるような属性で（ETagが）構成されていると、複数台のサーバーで運用している場合に、キャッシュしたサーバーと、再度アクセスしたときのサーバーのEtagが異なるために、304（not modified）ではなく200のレスポンスを返してしまうということ。
複数台で運用しているウェブサービスで、ETagがサーバーを特定させるような書式になっている場合は（デフォルトの書式ではサーバーを特定させるような状態になっている）、ETagを利用すると返って動作が遅くなってしまう。ETagの恩恵に授かれない場合には、ETagを削除してしまった方がいい。
2007年8月16日
YSLOW 勉強 : 12: Remove Duplicate Scripts
rules for high performance web sitesの十二個目。重複したスクリプトを削除しよう。IEの場合は、HTTPリクエストがキャッシュされていない場合は、リクエストを二回行ってしまう（キャッシュしている場合でもリロードするとHTTPリクエストを送る）。それに加えて、スクリプトの判定は二倍行われてしまうため、余計に時間がかかる。この現象はFirefoxでも発生する。
開発チームの人数やスクリプトの数が多くなると、二重に入れてしまうようなケースがあるとのこと。なるほど。
2007年8月15日
YSLOW 勉強 : 11: Avoid Redirects
rules for high performance web sitesの十一個目。リダイレクトを避けよう。HTMLドキュメントにたどりつくまでは何の要素のダウンロードも始まらないので、リダイレクトしている間はすべてが遅れる。
もっとも無駄なリダイレクトの一つは、URLの末尾「/（スラッシュ）」が抜けているときに起るリダイレクトで、/のついたURLにリダイレクトします（http://memolog.org => http://memolog.org/）。この問題はAlias や mod_rewrite、DirectorySlashを利用することで、対処することができます。
次の例として旧サイトから新サイトへの移行の話に触れていますが、要するに、HTTPでレスポンスのやりとりをするのはできるだけ避けて、代わりにApacheのAliasやmod_rewriteを使った方が良いということのようです。
あとは末尾のスラッシュは忘れずにつけるということでしょうか。
2007年8月14日
Font Tester : 使いたいフォントをウェブ上で比較検討
Windows IE でmemolog.orgを閲覧したときに、font-size:12pxに指定している箇所よりfont-size:11pxに指定している箇所の方が大きく表示されていたので、不思議に思っていろいろテストしてたときに思い出したページ。
Font Testerは選択したフォントが、ブラウザ上でどんな感じで表示されるのかをプレビューしてくれるウェブサービスです。画面が3つにわかれているので、フォントを比較検討したいときは便利。
ただ、残念ながら日本語フォントがプルダウンメニューから選択できない。とりあえずFirebugでプルダウンメニューの値をすり替えて表示させたりした（IEでは確認できませんが）。日本語フォントもプルダウンメニューに追加してってfeedbackだすのが良いかもなあ。
結局、原因はfont-familyが「Trebuchet MS」であったためだったようで、font-familyをsans-serifに変更しました。理由までは深く追求せず。
2007年8月13日
YSLOW 勉強 : 10: Minify JavaScript
rules for high performance web sitesの十個目。Javascriptを最小化しよう。スクリプト内の不要なスペースとか改行やタブとかを削除することで、ダウンロードするファイルのサイズが減るのでレスポンスタイムを短くすることができる。代表的なツールにはJSMINがある。
スクリプトを難読化（Obfuscation：不要な文字を削るのとともに、functionや変数の名前を変えて短くする）させることは、最小化よりもファイルサイズを削ることにつながるけれど、バグを誘発する恐れがあるためここではお勧めしていません。
最小化の方がメンテナンスコストも低いと記述されていますが、スペースや改行、タブなどを削った時点でメンテナンスコストは結構高い（メンテナンスしにくい）状態であるように思いますが、どうなんでしょう。
YSLOW 勉強 : 9: Reduce DNS Lookups
rules for high performance web sitesの九つ目。DNS lookups を減らそう。あるhost名とIPアドレスを関連づけるためにDNS（Domain Name System）lookupを行うけれど、これには20〜120ミリ秒の時間がかかる。lookupが完了するまではそのhostからダウンロードすることはできない。
ウェブページに存在するhostについてOSにもブラウザにもDNSのキャッシュがない場合に、DNS lookupが行われる。Webページ上で利用しているhost名が少ない方がDNS lookupがおこなれる回数が少なくなる。
ただ、hostを単一に減らすことは、ページ上での並行したダウンロードを減らすことにもつながる。DNS lookupの数を減らしてレスポンスタイムを下げる一方で、並行したダウンロードが減ったことによってレスポンスタイムが増えてしまうかもしれない。ガイドラインでは、hostはすくなくとも2つ、多くても4つとしている。
2007年8月12日
YSLOW 勉強 : 8: Make JavaScript and CSS External
rules for high performance web sitesの八つ目。JavascriptとCSSを外部ファイルにしよう。インラインで記述していると（外部ファイルを設置するより）HTTPのリクエストを減らせるけれど、毎回読み込むのでhtmlファイルのサイズは増えてしまう。外部ファイルにしておくと、ブラウザがキャッシュするのでhtmlファイルサイズも減らせるし、次回からのHTTPレスポンスも減る。ただ、Yahoo!のホームのようにセッションごとのページビューの少ない場合は、インラインで記述してしまった方がレスポンスが良好の場合もある。
ポータルサイトのトップみたいに、大量にアクセスがあって、トップページだけ見て別のサイトに移動してしまうユーザーが多い場合、すべてのユーザーにキャッシュを持たせるよりは、インラインにしてHTTPリクエストを減らた方が良い場合もある。というのが、パフォーマンスチューニングの醍醐味なのかなと、個人的な感慨にひたったしだいです。
2007年8月10日
YSLOW 勉強 : 7: Avoid CSS Expressions
rules for high performance web sitesの七つ目。CSS Expressions の使用を避けよう。CSS Expressionsとは、background-color: expression( (new Date()).getHours()%2 ? "#B8D4FF" : "#F08A00" ); （2で割れたら#B8D4FF、割れなかったらF08A00）というように、CSSの指定をダイナミックに行えるIEの独自拡張のこと。 便利な機能だけど、expressionsの判定がマウスを動かしたりするだけで行われてしまうため、何千回も判定を繰り返す可能性がある（パフォーマンスにも影響がある）。
わたしはこの機能そのもののことを知らなかったからそう感じるのかもしれませんが、この独自拡張を使っている人っているのかなあ・・
YSLOW 勉強 : 6: Move Scripts to the Bottom
rules for high performance web sitesの六つ目。スクリプトはできるだけ（HTMLの）下に移動させよう。これも5と同じくレンダリングに関わる話で、CSSは読み込みきらないとレンダリングが始まらなかったのですが、スクリプト（javascript）の場合は読み込み始めると、そこから下に記述されている内容のレンダリングがストップしてしまうので、できるだけ下に置く方がいい。
たとえばアクセス解析スクリプトはHTMLの下の方に移動しても大丈夫そうですね。ただ、そうすると今度はページを完全に読み終えるまでアクセスを計上してくれなくなりそうですけど。
2007年8月 9日
YSLOW 勉強 : 5: Put CSS at the Top
rules for high performance web sitesの五つ目。スタイルシートはheadタグの中で指定しよう、という話。なんか普通の使い方のような気がするのですが・・話の主旨はスタイルシートが最初の方に読み込まれておけば、ページのレンダリングが暫時的にすすんでいくから、ページを早く見ることができるということ。完全に読み切るまで真っ白な画面で待たされるより、少しずつでも表示されていく方がユーザーエクスペリエンスも高くなる。
2007年8月 8日
実際に表示されているブロック要素のサイズを表示する
単純にwidthを指定しているところであればブロック要素の横幅はすぐにわかるのですが、borderやpadding、marginが入るとわかりにくくなる。たとえば <div style="width:100px;"><div style="padding:10px;" ></div></div> のように、入れ子で指定されている横幅がいくつになるのか、いちいち計算するのはめんどうくさい（右の例のように単純なときはいいですけど）。
WEB Developerの「Display Block Size」（informationのメニューの中の項目）では、実際に表示されているブロック要素の縦幅と横幅を表示してくれます。欠点はブロック要素がたくさん入れ子になっていると、下の画像のように重なりまくってしまい何がなんだかわからない状態になってしまうところ。
その欠点を補うために、Firefox アドオンの「View Source Chart」を利用。View Source Chart は構造化した状態でHTMLソースを表示してくれます。「Display Block Size」を適用した状態で、View souce chartを表示すると、それぞれのブロック要素のサイズが構造化されたHTMLソース上にうまいこと表示してくれます。これでブロック要素のサイズが重なって見えないということは回避することができる。
YSLOW 勉強 : 4: Gzip Components
rules for high performance web sitesの四つ目。gzipで構成要素を圧縮して、HTTPのresponseサイズを減少させようという話。gzipについては、Wikipediaのgzipのページを参照。
YSLOWのページでは、HTMLドキュメントだけではなく、CSSやscript、JSONやXMLなどあらゆるテキストのresponseについてgzipにする価値があると述べられています。
2007年8月 7日
YSLOW 勉強 : 3: Add an Expires Header
rules for high performance web sitesの三つ目。Expires headerを使って構成要素をキャッシュ可能な状態にしよう、という話。キャッシュを持つことによって、キャッシュを読み込んだあとの不必要なHTTP requestを減らすことができる。WebサーバーがApacheであるなら、ExpiresDefaultの設定を使ってキャッシュする時間を設定することができる。
キャッシュを長く効かせるとファイルを更新してもキャッシュを参照してしまう、という問題が出てきます。なのでファイル名を変更するなどしてキャッシュを参照しないように工夫するとよい。
2007年8月 6日
WYSIWYG : IEのDOMではobjectタグの中にあるembedタグを認識しない？
あいまいなタイトル。実のところ、詳しくはよくわかっていないのですが、どうもIEのDOMではobjectタグの中にあるembedタグは削ってしまうようなのである。謎なのです。
webアプリケーションでよくあるWYSIWYGエディタ（リッチテキスト）では、すごくざっくりいうと、Javascriptで入力フォームであるiframe中のHTMLをツールボタンのクリックなどのイベントにあわせて、書き換えて動かしている。言い換えると、ブラウザが持っている情報を引き出して、変更して押し込んで、というやりとりをしている。そのため、ブラウザ側で期待されるデータを出力してくれないと、エディタから情報が消えてしまったりする可能性がある。
たとえば<object classid=&guot;" ><embed></embed></object> というobjectタグの中にembedタグが入っている状態のタグをコピーしてWYSIWYGエディタで貼付けると、Firefoxでは貼付けたままのものが出力されるけれど、IEではembedタグが抜けた状態で出力される。
objectタグとembedタグを別々に使っている分には、特に問題ないように見受けられる。どうもobjectタグの中にembedタグが入るということをIEがDOM構造として認めていない（無視している）のではないだろうかと推察している。IE developer toolでDOMを見たところでも、objectタグに埋めたembedはどこにも表示されない。しかし確たる情報もなく、悶々としている。
2007年8月 5日
YSLOW 勉強 : 2: Use a Content Delivery Network
rules for high performance web sitesの二つ目。 ユーザーの待ち時間の大半は画像やCSSなどの構成要素をダウンロードするのに費やされているという視点から、待ち時間を減らす為にCDN（Content Delivery Network ）を利用しようという話。Content Delivery Network (CDN) とは、ユーザーに効率的にコンテンツを配信するために分散化させたネットワークのことをさします（e-wordもあわせてごらんください）。
CDNは自社で構築する方法もあれば、Akamaiなどのサービス（CDS：Content Delivery Service）を利用する方法もある。けれども、いずれにせよ時間も費用もかかる対策ではあるので、なかなかハードルの高い基準であると思います。
YSLOW 勉強 : 1: Minimize HTTP Requests
内向きに話題になっていたYSLOWをインストールして試してみるという話。YSLOWはrules for high performance web sites（ウェブサイトを高速にするルール）に記載されている法則に則って、ウェブページの表示を遅くしている原因が何かを教えてくれるFirebugzの拡張プラグインです。
rules for high performance web sites のルールは全部で13個。その一つずつを、小刻みに勉強していこうという試みです。
一つ目は「1.Minimize HTTP Requests」。ユーザーの待ち時間の大半は画像やCSS、javascript、Flashなどのページの構成要素のダウンロードに費やされているから、これらの数を減らして HTTP request の数を減らしていこうということ。ページのリッチさを保ちつつ、HTTP requestを減らすアイデアが記されています。
- イメージマップを利用して画像の点数を少なくする：ナビゲーションバーなど、統合できる画像を統合して、HTTP request を減らす
- 「CSS Sprites」という手法を使う：いくつかの画像を一つの画像にまとめて、background-positionでずらしながら利用する。
- インライン（imgタグ）で挿入している画像をCSSで表示するようにする：インライン上の画像は実際のページに組み込まれるため、HTML ドキュメントのサイズを増やしてしまう。だから（キャッシュされる）CSS上で呼び出す方が良い。
- ファイルを統合する：JavascriptやCSSなどのファイルをひとつにまとめて HTTP request の数を少なくする。
ちなみに、memolog.orgのトップページの判定はD判定・・、Feed Flareの外部Javascriptがエントリーごとに入っているために、評価が下がっているようです。スタッツ用に埋め込んでいるけど（たぶん）トップページには必要なさそうなので、外してみよう。
2007年8月 4日
Safari 3 (webkit) がサポートしている CSS 3 プロパティ
webkit の拡張タグ上で、すでにいくつかのCSS 3プロパティがsafari 3上で利用することができます。利用可能なのは、box-shadow、border-image、border-radius、border-radiusなど。いずれも「-webkit-」というprefixを入れることで利用することができる。
複数のセレクタを指定したときにIE6バグ
たとえば、<p class="foo bar" > と複数classをつけている場合に、p.foo.bar {font-size:100px;}というかたちで指定すると、IE5と6では、p.bar {font-size:100px;}と指定しているのと同じ状態になってしまう、という話。IE7ではこの現象は発生しない。
この現象は、たとえば「奇数行で最後の行にはこの背景色にして、偶数行で最後の行になる場合はこの背景色にする」というようなことをしたい場合に少し困る。p.odd.last {color:#000;}とp.even.last {color:#fff;} というような指定をしても、どちらもp.lastと解釈されてしまい、CSSファイルの後ろで指定した方が反映されてしまう。
たとえばodd_lastとか、even_lastとか、そういうユニークなクラスを指定するとか、そういった回避方法はなくはないのですが、スマートな方法じゃないし、なによりめんどうくさい。
2007年8月 3日
拡張CSSで角丸コーナーを作る
- Safari 3 CSS Support » CSS, JavaScript and XHTML Explained
- Rounded borders, create them with CSS! - CSS3 . info
各ブラウザが独自で用意している拡張CSS（CSS extensions）を利用して、角丸コーナーを作ろうという話。CSS3 にborder-radiusというボーダーの角を丸くするためのプロパティが提案されており、ゆくゆくはborder-radiusにスタイルが引き継がれていくのかなと推測しています。
CSSの指定の仕方は簡単で、下記のようにwebkitやmozのプレフィックスをつけて指定するだけ。webkitはwebkitとsafari向け、mozはmozilla系のブラウザ向けの指定。IEでは適用されません。
-moz-border-radius: 5px; -webkit-border-radius: 5px;
実際に右にある「最近のブログ記事」のリストに指定してみました。若干、カクカクした感じになりますけど、個人的には許容範囲。
そのほかにもブラウザが独自に用意している拡張CSSはたくさんあって、そのへんは下記のリンクなどが参考になります。これでしばらくは楽しめそうです。
2007年8月 1日
似顔絵
今日は以前に無駄に描いて結局お蔵入りしていた似顔絵を、場つなぎ的に出してみようと思います。描き方は簡単で、写真をタブレット使ってトレースしただけ。似顔絵の方が「歯抜け」感があって似ているような気がします。
MTで奇数行、偶数行ごとに背景色をつける方法
ブロックタグ内で使える変数を利用して、奇数行（odd）と偶数行（even）にわけてclassを指定することができます。偶数行と奇数行にわけて配色したいというときに非常に便利。これだけでデザインの幅がかなり広がる。右側の「最近のブログ記事」の一覧で実践してみました。作成したテンプレートは下記のようなかたち（不要な箇所は割愛しています）。
<MTEntries lastn="10"> <li class="widget-list-item <MTIf name="__odd__">odd</MTElse>even</MTIf>"> <a href="<$MTEntryPermalink$>" ><$MTEntryTitle$></a></li> </MTEntries>
そして適用したCSSは下記のような感じ。
.widget-archives .widget-header {border:none; padding-bottom:0; margin-bottom:0;}
.widget-archives ul {border:1px solid #ddd;}
.widget-archives li {margin:0;padding:0; overflow:hidden;}
.widget-archives li {display:inline;}
.widget-archives li a {display:block; padding:5px;}
.widget-archives li.odd a {background-color:#f0f0f0;}
.widget-archives li.even a {background-color:#e6e6e6;}
.widget-archives li.even a:hover {background-color:#FFA6E9;}
.widget-archives li.odd a:hover {background-color:#FFBFEF;}
これで完了。MTEntriesの他に、MTCommentsでも利用可能。コメントの場合で、たとえばエントリーの投稿者のコメントには特別のCSSを入れたいという場合には、<MTIfCommenterIsEntryAuthor>author</MTIfCommenterIsEntryAuthor> というような形で、authorというclassを追加すると良いかもしれない。