はてなブックマーク

HTMLページの構造の階梯（かいてい） 非常に懐かしい文書をdeztec.jpが保存しておいてくれた。構造と内容を分離し、ウェブページを動的に生成してサーブするのが制作者にしか利益がないのに対し、CSSによってセマンティクスと表現方法を分離するのは広く閲覧者に利益がある。そこが何しろ重要な点だということが分からないから、実際には、相対的なものにすぎないなどと書けるのだろう。 しかし構造と内容の分離こそ、制作者の自慰行為に「過ぎない」。しかもここで例示されている「構造」は文書構造ではなく、パーツである。文書には内容と構造があるが、実はこれは不可分なのだ。昔XSLTを利用してフラットな「自家製XMLインスタンス」と構造を分離した気になっていたことがあったが、分離などではなく、暗黙的に存在していた文書構造をXHTML1.0という形式を用いて明示しただけの話だということに、やってみて気づいた。そし

Hatena::agenda - 本物のリキッドレイアウトの具体化。 リキッドレイアウトは動的なスタイルシートによって実現する。CSS2は閲覧環境に応じてある程度柔軟な変化を提供するが、まだ充分ではない。今現在でもJavascriptの助けを借りれば、本物のリキッドレイアウトに近づけることはできる。 リキッドレイアウトを助ける主なstuffは、今のところ次の四つ。 1. CSS2のfloatプロパティ本来の使い方 2. CSS2のfloatプロパティでのページレイアウト 3. CSS2のtableでのページレイアウト 3. CSS3のマルチカラムの先行実装 1. CSS2のfloatプロパティ本来の使い方 floatプロパティは「サイドバー」を表現するために作られたのでは、ない。テキストが回りこむ浮動オブジェクトを描くのがfloatプロパティの本来の姿である。しかし例えばあるテーブルにfl

CSS3のマルチカラム（草案）の先行実装を利用すると、Googleの検索結果がモニタ上で一望できる。それに伴ってGoogleナビゲーションその他の位置も最適化してみた。 マルチカラムで表示したGoogle検索結果（約65kb, 16色png画像） 「次へ」という最も利用する頻度の高いナビゲーションは常に右上に表示しフォントサイズも巨大にしてクリックしやすくする。 ついでにアクセスキーも設定してキーボードで操作しやすくしておく。 検索結果のステータス（「100件中 1 - 10件 何秒」とかいうあれ）は縦幅を取って邪魔なので、ブラウザのステータスバーに移動させる。 ログイン情報が縦幅を奪う理由は何もないので、最下部へ移動していただく。 滅多に褒めてくれないうちの嫁さんも「いいね」って言ってた。greasemonkeyスクリプトとユーザースタイルシートで実現している。 マルチカラムGoogle

Hatena::agenda - 本物のリキッドレイアウトの続き。 リキッドなマルチカラムの実例 Hatena::agendaは実験場ではないけれども、CSS3 Columns - MDCで紹介されているmozilla独自拡張プロパティを使用してリキッドマルチカラムにしてみた。デメリットもかなりあってまだ改善の余地があり余っているものの、場合によっては低解像度から高解像度まで、シングルウィンドウから並行閲覧まで手広くカバーできる。 このプロパティを実装していないブラウザ向けに、一応スクリーンショットを用意してみた。 幅が小さいと1カラム（約50kb） ある程度広げると2カラム（約90kb） 充分広げると3カラム（約110kb） 念を押しておくが、-moz-で始まる独自拡張プロパティは、正しく使えば問題ない。これはCSS validatorを通らない。しかしCSS実装は、不明なプロパティは無

どうやら世の中の「リキッドレイアウト否定派」はリキッドレイアウトの真の姿をまるで知らないらしい。想像力が足りないのだろう。リキッドレイアウトというのは、ウィンドウ幅を小さくしても横スクロールバーがでないとか、本来そんなちんけなものではない。 リキッドレイアウトを否定するというのは、ウェブデザインを放棄することと同義だ。固定レイアウトというのは、例えば1024*768px向けデザインとでも言うべき代物で、ウェブデザインと呼ぶに相応しくない。 本物のリキッドレイアウトは隙間に流れ込む水のような振る舞いをする。Hatena::agenda - ブログのサイドバーは要らないではサイドバーを否定したが、実は一つ例外がある。本物のリキッドレイアウトを採用しているなら、サイドバーも有用となり得るのだ。 もちろんサイドバーとは何かを知っていなければならない。簡単にいえば、サイドバーのようなインターフェイス

ウェブサイトを構築する上で、私が最初に読んでおくべきと考えている、オンライン・ハイパーテキストのためのスタイルガイドを久しぶりに熟読し、及びこの文書にリンクしている文書を読み漁った。その中で変わらないURIこそがクール - 徒書は参考になった。 「変わらない」ということがクールなURIであることの必要十分条件。ファイルの拡張子が示されていても、変わらなければクールなのだ。拡張子がなければクールかといえば全くそうとは限らない。例えば止むを得ない事情で、コンテントネゴシエーション等が使えないサーバに移転することになったら? 運営する主体によってクールなURIの形式は変わってくるかもしれない。 個人で運営する以上は、その個人に関する情報がURI、特にhost名に含まれてしまう。結局のところ消失しないPURLを取得しておき、ハイパーリンクはなるべくPURLを用いてInternet Archiveな

http://d.hatena.ne.jp/user/configview から設定で消せるようで。 .hatena-star-comment-container, .hatena-star-star-container { display: none; } はてなスター邪魔だからCSSで消した（つもり）。あ。あと、はてブとやらのコメントは言論、言及として認めていないので悪しからず。基本的に全部「こだわりません」付き（謎）として解釈する。当然だけど。 野暮ながら書くと（100文字等に）規制されているものは言論ではない。すなわち、そんなメディアを通じて何か言った気になるのはアホ。それはさておき。 ブログパーツ - Google 検索 一昔前も、自分の「ほーむぺーじ」にちょこちょこ動くマスコットだの占いだの置く人が多かったけれど、ウェブに何かを公開するという力の使い方を知らなかったんだろうね。

ウェブで糞議論をする気は最早毛頭ないんで。 ざっとみて一番多かったのが、文章が横に広がりすぎてウザイとか、横幅100%ウザイとかいうぼやきだった。わらい。Hatena::agenda - ブログのサイドバーは要らないでは、文章を横に広げろとか、横幅を100％にせよ、とは言っていない。むしろ適切なmax-widthプロパティを場合によっては推奨してもいいくらい。所謂「最大化厨」対策。うちでは、「閲覧者は馬鹿、的な発想」でCSSを書いている気がして嫌だったから今までやらなかっただけ。だが昨今法外に横幅を奪うデザインのサイトが多いので、そういうサイトをよく利用する人にとってはウィンドウ幅を変えずに済んで便利だろうと思い直してCSSを改善してみた。失うものも殆どないからね。 次。そのブログの過去の記事等を辿りづらいという主張。あんなちっこいカレンダーとかサイドバーに押し込められたリストを使うより、

記事本文（いわゆるpermanent link / permalink）に関して、「サイドバー」は100%要らない。要ると思っているのは100%勘違いである。エゴで固執するなら「さいどばー」に相当するリソースへのハイパーリンクを提供すればいい。Web2.0なんだろ? だったらそのリンク先を得意のAjaxとやらで上手に扱えばいいじゃないの。もっともその程度にAjaxなんて全然必要ないけれども、かっこよさげだろう? わらい。 煩悩是道場 - ブログのサイドバーって本当に必要？ 煩悩是道場の中の人は情報の消費者の視点で記事を書かれているが、サイドバーは「ブロガー」として見ても要らないものである。せっかくのPCのマルチタスク機能の利用を妨害してまで横幅を消費する価値が、「さいどばー」にあるのかどうかを考えればわかる。ある記事を参照しながら何かを書くときウィンドウを左右に二つ並べないのは、多くの人に

ユーザースタイルシートで、例えばbody{ font-family : "メイリオ" } という意味の指定をした場合、本文のフォントはメイリオになるようにCSSを書こう。これは何も特別な処置を要求するものではない。ウェブデザインの基本を守っていれば既に達成しているはずだ。すなわち「本文に異なるフォントを混在させない」という鉄則である。この場合、font-familyの指定はしないか、あるいはbodyセレクタに一回のみ記述すると良い。意味もなくpに指定して優先度を上げたりしないように注意して欲しい。というのも、ユーザースタイルシートとは何もCSSとは限らない。ブラウザのフォント設定だってユーザースタイルシートを変更する行為だし、そのような利用者はCSSよりも遥かに多いと思う。そしてブラウザのフォント設定がどの程度の優先度を持つかは、そのブラウザによるとしかいえない。CSSを書けるなら、bod