Bllogerアーカイブ - ドブログ[Do-Blog]

たまには、モノクロで。これは、銀座。。かな？

これは渋谷の道玄坂の上にある家具＆雑貨屋さん。

モノクロフィルムはプリント代が高いので、今後はフィルムスキャンする予定。

スペースのことを考えると、やはり複合機がいいのですが、複合機のフィルムスキャン機能は多少何ありの傾向。

今使ってるHPの複合機は品はいいのですが、時々意味不明のインク切れを起こしていました。で、最近こんな記事を見つけて、ちょっとHP怖くなっちゃいました。

次に買うのは、多分Canon。PowerMacG5と一緒に買おうかな。

向かいの家の屋上へ続く階段。この風景が好きでよく写真に撮るけど、この一枚はトンネル効果がよく出てて、よい感じ。

近所の猫「シューティングスター」。カメラを向けるとよってくるが、常にメンチを切っている。

おまけ。近所の道路に書かれた「トマー」。たぶん、「トマレ」と書かれてるよりよく止まる。

出発です。うれしい咲。飛び出す咲。猪突猛進アホな咲。

道路交通法は守りましょう。

ケツです。ケツ一つ見ても、アホさがにじみ出ます。

二人の影。青春です。この時ボクは、シメサバダンスというのを思いつきました。

新しいPowerMac G5が出るのを春を待つ蛙の様に待ってるボクですが、スムーズなデータ移行を実現するために、ブロードバンドルータを買ってきました。無線LAN機能付き。

今までは、モデムに直に接続してた（危険ですねー）んですが、さっき（2時間前）思いついて買ってきました。

ボクの印象では、無線LANはまだまだ高いものだという印象があったのですが、これが無線LANカードまで付いて、1万円とちょっと。安くなったなぁ。

あと、接続に関しても難しそうだなぁとか思ってたけど、ほとんどワンタッチ（死語ですか）。技術の進歩はすごいなぁ。これでInterLinkをこたつPCにしてもLANケーブルが絡まずに済みます。わーい。

避妊手術の後、エリザベスカラーを付けられ、しょぼーんな咲。

そんな自分の姿を鏡の中に見つけて、懸念と好奇心をさらけ出すアホな咲。

http://www.itmedia.co.jp/news/articles/0502/16/news010.html

そしてまた最悪な完成度でリリースされ、汚物ブラウザとして君臨しそうな悪寒

せめてCSS2ぐらいは実用レベルで対応してくれ

メモ。
セレクタ

CSSの本質を知るには、プロパティを勉強するよりセレクタを勉強した方が、より核心に近づける。

極良スレ
http://cocoa.2ch.net/body/kako/1004/10043/1004374543.html

こっちはKuyoさんのページ。
Kuyo's Homepage ~ バリアのない生活を目指して ~

両方ともWeb製作者必読。

本日の午後、こんな言葉フレーズを思いついたのでした。

ノストラダムス：「私の予言は外れるであろう」

おお！ノストラさん、すげー！

外れることを的中させたよ！

え？でもこの予言自体は当たってるよな？

つまり、この予言は外れてるって事だから、やっぱ当たってる？すげーノストラさん！

アホなボク。

リトル愚かな自分がちょっとだけ好きになりましたとさ。

HTMLの仕様ではimg要素のwidth属性とheight属性は必須属性でもないのに、あらゆるサイトで必ずと言っていいほどひっついています。（img要素に限りませんが、一応、使用頻度が一番高いので。）

ボクはこの二つの属性の存在には、以前から疑問を持っていました。実は要らないのでは？以下箇条書き。構成してないので見難い。。。

• HTML内にピクセル実数値が存在するのはHTMLのコンセプト上疑問である。HTMLには内容のみを記述した方がいろいろな面でメリットがあるということは実証されている。なぜwidth属性とheight属性は黙認なのか？
• 画像のサイズが可変である動的なページなどでは、イメージのサイズをHTMLに書き出すために余計なプログラムが必要になる。よって余計な負荷がサーバにかかることになる。
• 画像が無い、または読み込み中の時、小さなピクセル実数値が指定してあるとalt属性が領域からはみ出して表示されない

  サイズ指定あり

  

  SRC:<img src="./nothing.gif" alt="画像がありません" width="100" height="12" style="background-color:orange">

  画像サイズがフォントサイズより小さくなる可能性があるため、alt属性が見えない。

  書いてて気づいたんだけど、Firefoxならきちんと表示しますね。IE様は相変わらずなので、IEで見てあげて。

  サイズ指定無し

  

  SRC:<img src="./nothing.gif" alt="画像がありません" style="background-color:orange">

  サイズ指定がない場合、alt属性のフォントサイズに合わせて可変になる。

• サイズ指定が無ければ、人為的な実数値入力ミスによる画像の崩れを未然に防ぐことが出来、メンテナンス性が向上する。
• サイズ指定が無ければ、ソースが軽くなる（微妙）
• サイズ指定が無ければ、ブラウザのレンダリング中、画像部分の領域確保が前もって行われないため、ページがかくかくと動いてしまう。が、ユーザーはそんなに気にすることなのか。サイトのデザイナーのエゴではなかろうか。（要調査？）
  どうしても動かしたくない場合は、CSSで指定しちゃえばいいし。
• サイズ指定が無ければ、巨大なサイトで共通で使用されていた画像（ロゴなど）のサイズが変わった場合、多数のHTMLを修正しなくて済む。

わーい。メリットだらけ。実際、製作したWebサイトに導入してみたのだが、メンテナンス性は格段に向上した。

サイズ指定を入れなければレンダリングが遅くなるというが、どの程度のものなのだろう。

いかが？

Appleの情報アーキテクチャを見てると、iTunesをはじめとして、ファセット分類を取り入れつつあることに気が付く。

これはwindows/UNIXユーザーが長く慣れ親しんだ階層型の分類から大きく逸脱したものかと。

昔ならコンピューターのデータの全体像を把握することも可能だったけど、HDDレコーダなどの出現などに象徴されるように「多くのごみの中から自分の必要と思われるデータのみ抽出する」方法から「自分の必要そうなデータを全部取り込んで、その後で取捨選択する」という方法にシフトしつつあると思うんですよ。

iPodはそのいい例で、とにかくガンガン曲を入れちゃって、その後ピックアップするというやり方が可能。

メディアの容量や転送速度を気にしなくてよくなった昨今だから出来る芸当なんだろうな。

今後の情報アーキテクチャはファセット分類をうまく取り入れるorファセット分類を主軸とした設計が必要になってくると思われ。

Webも高速化が進んでるし、ディレクトリの概念に縛られた情報デザインをもう一度見直す必要がありそう。

あほなソースファイルを吐き出さないようにしたくて、Bloggerの設定を弄りました。

[Settings]-[Formatting]-[Convert line breaks]を[YES]から[NO]に変えました。これにより、エントリー時の改行で余計なbr要素を挿入しなくなりました。

よって、これまでのbr要素がすべて抜けてしまったので、記事がひじょーに読みにくくなっています。

徐々に直していくことにします。