最近書かれた記事5件分を表示します。
更新状況をRSS 1.0形式でご覧になれます。
iCaptureではMacintoshのブラウザ"Safari"での表示確認サービスを提供しており、ユーザはSafari上でキャプチャされた画像を見ることができる。2月の半ばから使用不能に陥っていたが、現在は利用できるようになっている。
絶対配置(position: absolute;)している部分が心配だったが、キャプチャされたものを見る限りでは問題ないようだ。
プログラムの例文で、特に意味を持たない変数やファイル名をfooとすることがある。このfooは日本語のhogeに相当するもので、メタ構文変数と呼ばれている。よく見るのはfooやbar、bazだが、この次は何かと思ってリソースを探したところ、驚いたことにRFCが見つかった。
RFC 3092: Etymology of "Foo"では、RFCで特に説明なく使われているfooの語源や補足説明がなされている。いわゆるJoke RFC(April Fool's Day)だが、嘘は書かれていない。fooの語源をRFCにすること自体がJokeなのだそうだ。
- foo /foo/
- First on the standard list of metasyntactic variables used in syntax examples (bar, baz, qux, quux, corge, grault, garply, waldo, fred, plugh, xyzzy, thud). [JARGON]
RFC 3092: Etymology of "Foo" - IETFより引用
bazの次はqux、quuxとなっている。quuxまでは見たことがあったが、corge以降は初めて見るものが多い。また、quuxの次をcorgeとせず、quuuxとする場合もあるそうだ。
今月16日にOpera 8.00のBeta 3が公開された。今回はPreferencesの構造に変更が入り、ポップアップの設定などがより見つけやすい位置に再配置されている。この変更は、これからOperaを使い始めるユーザのために配慮されたものと考えられる。
しかし、HTTP_ACCEPT_CHARSET(文字コードの優先順位)やHTTP_ACCEPT_LANGUAGE(言語の優先順位)が直接変更できなくなっているため、Operaを使い続けている者にとっては使い難い部分がある。ただし、以前のPreferencesを使う手段が用意されているので、次の手順を踏めば問題ない。
;Item, "Old preferences" = Show preferences, 100のセミコロン(先頭)を外して更新するPlatform Windows-Unix-QNX, p alt = Show Preferences, -1の-1を100に置き換えて更新する(Ctrl+F12を使うなら、その一行上を変更する)RDF Site SummaryとReally Simple Syndicationはどちらも略すとRSSになるが、その意味するところは決して同じではない。マスメディアの記事ではこれらを混同しているものがあり、区別が曖昧になっている節がある。
RSS 1.0は、Webサイトの要約や更新情報をメタデータ(図書館における蔵書目録
に近いもの)として記述するためのXMLフォーマットである。
Weblogやそれに近いものでよく使用されており、(RSSリーダを用いた)RSSの利用者は自身でWebサイトを訪れることなく更新の有無が確認できる。あくまでメタデータを配信するためのものであり、見出し、URI、更新日時、要約という最小限の情報しか含まれない。
新たなマーケティング手段として注目されているのが、このRSS 2.0である。RSS 1.0がメタデータを扱うのに対し、RSS 2.0はコンテンツを扱う。RSS 1.0が要約の配信なら、RSS 2.0は記事全文の配信だと考えると分かりやすい。
極端な話になるが、RSS 2.0形式で作成されたRSSのURIさえ分かれば、それ以外のWebページは必要にならない。また、勝手に送られてくる広告メールと違って、ユーザが受信するかどうか決定できる。ユーザの意思決定によって受信されたものは読まれる可能性が高いため、新たなマーケティング手段として注目されているようだ。
それぞれに特徴があるため、一概にどちらが優れているとはいえない。限られた話題のみを提供するのであればRSS 2.0が適しているし、ある程度話題に幅があるのなら、情報の取捨選択(つまり、該当記事を見に行くかどうか)を効率的に行えるようRSS 1.0で公開することが望ましい。ただし、見出しと要約が適切でなければ意味を成さないので留意する必要がある(自戒含む)。
この程、rhongomyniad.org/以下にあるページの一部がGoogleに捕捉された。以前はNotesの最新版であるrhongomyniad.org/notes/latest.htmlのみ捕捉されていたが、今回はNotes :: 2005年2月がHTTPリダイレクトを利用しない正式なURIで捕捉されている。これにより、「2005年2月分にあるキーワードに引っ掛かったのに、リンクを辿ると2005年3月分が表示された」という事態は避けられる。
キャッシュされた文書には例外なく「Googleはこのページまたはページ内のコンテンツとは関連ありません。」という文章を含んだtable要素が挿入されるため、要素を絶対配置しているとレイアウトが崩れてしまう。「Googleが勝手にしていることだから、キャッシュの見栄えは考慮しない」との意見もあるが、なるべく最適な状態で表示させたいと思うのも確かである。
レイアウトの崩れを防ぐだけなら、挿入されるtable要素を消し去ってしまえば一応は解決する。
table[border], table + hr {
display: none;
}
ただし、セレクタの実装関係でMSIEには無効であり、キーワードのハイライトを利用する場合に不便となるので有効な手段とは言い難い。敢えて使うなら、ユーザスタイルシートに組み込むくらいだろうか。
もしPHPが利用可能なら、補正用のスタイルシートをGooglebotに対して出力することで綺麗に解決できる。何種類かあるGooglebotはいずれも"Googlebot/2.1"というUAを返すため、これを利用して振り分ければ良い。
$useragent = getenv("HTTP_USER_AGENT");
if (ereg("Googlebot/2.1", $useragent)) {
echo '<link rel="stylesheet" type="text/css" media="screen,projection" href="foo.css" />';
}
例ではlink要素を直接出力するので、関数を使わないならhead要素内に記述する必要がある。この他、文字列を換えることでYahoo!やMSNのクローラにも対応できるだろう。
id属性は、文書内の特定の要素を参照するために用いる。分かりやすくいえば、ページ内の特定の位置にジャンプ(結果的にジャンプしているだけで、実際には誤り)するものだ。では、id属性はどの要素に振るべきだろうか。
特定の要素を参照するわけだから、考えるまでもなく参照される要素に振るのが妥当である。だが、ここで書きたいのはそのことではない。参照とジャンプの違い、果てはdiv要素の必要性にまで話は及ぶ。
id属性の利用目的は、あくまで要素の参照であって要素へのジャンプではない。要素へのジャンプというのは、ある要素のid属性値を含むリンクを辿った結果、ブラウザの表示として「ジャンプしている」と我々が認識するだけのことである。参照は、「id属性が振られた要素を取り出す」と考えると分かりやすい。
「このページのトップへ」というページの頭へジャンプするためのリンクは、参照とジャンプを間違えている例である。その善し悪しはともかく、id属性の使い方としては誤りである。
次のようにマークアップされたものがあったとする。
<div class="section">
<h2>id属性はどの要素に振るべきか</h2>
<p>id属性は、文書内の特定の要素を参照するために用いる。</p>
</div>
この断片にid属性を振る場合、一般的には次の3通りが考えられる。
div要素にid属性を振るのは妥当な選択である。問題はh2要素にid属性を振る場合だが、これは参照とジャンプを間違えている可能性が高い。id属性をdiv要素に振ろうがh2要素に振ろうが、ブラウザを通して見る分にはそう違わない。ただし、参照を「取り出す」として考えると、両者には決定的な差異が生じる。
h2要素にid属性を振って参照に用いていると、取り出されるものはh2要素、つまり先の例の2行目だけになる。確かに見出しを参照していることにはなるが、それを意図して利用する人は少ないはずだ。多くは、h2要素の次にあるp要素も参照するために使うだろう。従って、h2要素に参照用のid属性を振ることは、通常、選択肢に含まれないことだといえる。故にdivを取り払う選択肢も消える。
divはスタイルを適用するためのコンテナとして用いられるが、本来は参照用のid属性を振るために存在しているのではないだろうか。私はそう考えるからこそ、div要素に一切スタイルを指定していない現在も使い続けている。
最後に、現状ではh2要素にid属性を振っても実害がないことを付け加えておく。私はより良いマークアップの追求を楽しんでいるだけであり、この考え方を主張するつもりは微塵もない。
bug reportが相次いだためか、8.00b2から一週間で新たなPreviewが公開された。このPreviewの安定性は重視されておらず、実験的な意味合いの強いバージョンであることに注意する必要がある。
RDFのlink要素の抜き出しミスは修正されているが、まだその他の細かい点で問題が残っている。8.00b1以降ではこれまで正常に動作していた部分に問題が生じているため、問題の程度によっては7.60p4など過去のPreviewの方が使いやすい場合もあった。しかし、8.00p5で修正されていないのは本当に些細なものなので、常用する分には問題ないと思う。
頻繁に遭遇する問題ではないものの、気になるので報告しておこう。
IMAPの問題がいくつか見つかったため、Preview 5.1として公開し直されている。
2005-03-09 01:50追記
先月28日、オランダのOneStat.comとアメリカのWebSideStoryによってブラウザシェアの調査結果が発表された。WebSideStoryの調査としてはMSIEのシェアが初めて90%を割り、2つ以上の調査でMSIEのシェアが同時に90%を割っているのは初めてだという。
MSIEのシェアが確実に縮小しているという話。実際には傾向(増減)を知るだけで十分であり、ユーザにとってその数値は大した意味を持っていない。自分が使っているブラウザのシェアを見て、増えただの減っただの騒ぐのは何か間違っている。これはINTERNET Watchの記事に対する感想ではなく、シェアの話全体について自分が感じたことだ。
以前は「MSIEなんか使わないでMozillaやOperaを使いましょう」などと言っていた記憶があるが、今ではそう思うこともない。MSIE以外のブラウザを知らない人は別として、その人にとってMSIEが使いやすいから使い続けているのだと考えを改めた。結局はそれだけの話でしかない。かつては自分もそうであったのに、いざMSIE以外のブラウザを使い始めると「何でMSIEなんて使っているのだ?理解できないよ」と考えるようになる。
自分が経験した後、同じようなことをしている他人を見て、そこで初めて気がつくものなのだろうか。昔の自分に「愚かだ」と言ってやりたくなった。