「サイトの横幅」再論：950px時代のウェブデザイン［絵文録ことのは］2009/01/14
以前、サイトの横幅を640ピクセルにする理由――統計と現状に基づく結論［絵文録ことのは］2006/11/25で、「実際にサイトを閲覧している人のブラウザーの横幅と、ブラウザーによる印刷上の制約から、特に画像は左端から640ピクセルくらいに収まるようにした方がよさそうだ」という結論に落ち着いた。これには、一行字数が多すぎると読みづらい、という、紙媒体の扱いも多いわたしの経験的な見方もある。 もちろん、これにはリキッドデザイン主義者の方から「ページ幅を指定するようなデザインであること自体が悪」という反応があったり、「印刷用CSSを使おう」といった反応があったりしたのだが、「印刷時のことを考えれば640pxという制約がある」という結論は特に揺るがなかった。 その後、今まで約2年経った。閲覧者の環境も変わり、当時主流だったIE6にはなかった「用紙サイズに合わせて印刷」機能を備えたIE7ユーザーも増
例：「固定幅と可変幅のどちらがより適切なウェブデザインか」という議論をしている場合
例：「固定幅と可変幅のどちらがより適切なウェブデザインか」という議論をしている場合 あなたが「可変幅は固定幅よりも優れている」っ言ったのに対して否定論者が… 事実に対して仮定を持ち出す 「可変幅は横スクロールが発生しないが、もし横スクロールが発生する可変幅なデザインがあったらどうだろうか？」ごくまれな反例をとりあげる 「だが、ユーザーCSSを使い全て固定幅で閲覧している人もいる」自分に有利な将来像を予想する 「何年か後、横スクロールバーが存在するという保証は誰にもできない」主観で決め付ける 「閲覧者自身が可変幅であることを望むわけがない」資料を示さず持論が支持されていると思わせる 「世界では、可変幅は横に広がって見難いという見方が一般的だ」一見、関係がありそうで関係のない話を始める 「ところで、Jintrickがアニメキャラのファンサイトを運営していたのを知っているか？」陰謀であると力説す
Google検索結果をリキッドマルチカラムで一望し、次の検索結果を先行読み込みして高速に表示し、かつ履歴で戻れるGreasemonkeyスクリプト (agenda)
Google検索結果をリキッドマルチカラムで一望し、次の検索結果を先行読み込みして高速に表示し、かつ履歴で戻れるGreasemonkeyスクリプト 注：Googleの仕様変更に伴い、このスクリプトは形骸化している。修正版はMulticol Google Search (agenda)で公開している。 Googleをマルチカラム環境に最適化する (agenda)は、10分かそこらで書いた適当なスクリプトだったのでいつか書き直そうと考えていたが、暇を見つけて終わらせたので公開しておく。今回Stylishやユーザースタイルシートは使わず、Greasemonkeyのみで動作するようにした。googlesearchutility.user.js。 スクリーンショット 留意点など 訳あってwww.google.comでしか履歴は動作しない。www.google.co.jpでも基本的に動作はするが、そこ
本物のリキッドレイアウト - 補足：Hatena::agenda
Hatena::agenda - 本物のリキッドレイアウトの続き。 リキッドなマルチカラムの実例 Hatena::agendaは実験場ではないけれども、CSS3 Columns - MDCで紹介されているmozilla独自拡張プロパティを使用してリキッドマルチカラムにしてみた。デメリットもかなりあってまだ改善の余地があり余っているものの、場合によっては低解像度から高解像度まで、シングルウィンドウから並行閲覧まで手広くカバーできる。 このプロパティを実装していないブラウザ向けに、一応スクリーンショットを用意してみた。 幅が小さいと1カラム（約50kb） ある程度広げると2カラム（約90kb） 充分広げると3カラム（約110kb） 念を押しておくが、-moz-で始まる独自拡張プロパティは、正しく使えば問題ない。これはCSS validatorを通らない。しかしCSS実装は、不明なプロパティは無
本物のリキッドレイアウト - Hatena::agenda
どうやら世の中の「リキッドレイアウト否定派」はリキッドレイアウトの真の姿をまるで知らないらしい。想像力が足りないのだろう。リキッドレイアウトというのは、ウィンドウ幅を小さくしても横スクロールバーがでないとか、本来そんなちんけなものではない。 リキッドレイアウトを否定するというのは、ウェブデザインを放棄することと同義だ。固定レイアウトというのは、例えば1024*768px向けデザインとでも言うべき代物で、ウェブデザインと呼ぶに相応しくない。 本物のリキッドレイアウトは隙間に流れ込む水のような振る舞いをする。Hatena::agenda - ブログのサイドバーは要らないではサイドバーを否定したが、実は一つ例外がある。本物のリキッドレイアウトを採用しているなら、サイドバーも有用となり得るのだ。 もちろんサイドバーとは何かを知っていなければならない。簡単にいえば、サイドバーのようなインターフェイス
リキッドレイアウトの弱点を克服 - Hatena::agenda
リキッドレイアウト採用にあたって問題点を再検討してみた。ブラウザで解決できる問題だとは思うので、リキッドレイアウトに起因するデメリットではないが、少なくとも現在ある問題としてこれは明らかにまずい。 ブラウザのサイドバーを利用するなどしてメイン領域の幅を変更すると、文字の表示位置が大きくずれ、読んでいた場所が分からなくなる。 今のところ回避方法としては、内容が長大な場合には複数のページに分割するなどして縦方向のスクロールを多く要求しないようにすることくらいしかないが、よく考えてみればそれはウェブデザイン的に結構基本的なことだったりする。 ここで陥ってはならないのが、逆も真（謎）と思い込んでしまって「ある程度縦長にならざるを得ない場合には幅固定の選択肢もあり」と判断してしまうミス。複数のページに分割とは、何も物理的に分割しなければならないわけではない。こういう止むを得ない状況を打破するためのC
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ichiro.to