Nakajiman Software Blog: 2008-01

2008-01-31

IEは特定条件下でoffsetTopの値がおかしくなる

JavaScriptのoffset計算について調査していたところIEのoffsetTop値がおかしいことに気づきました（Firefox、Opera、Safariは問題無し）。試しにjQueryプラグインのDimensionsでも試してみたところ、こちらも正確なoffsetTop値を算出できないようです。

内容を説明するとbody要素（青色の枠）の中に三つのdiv要素（緑、黄、赤色の枠）をネストさせたHTMLを用意します。

これらの要素には次のスタイルを適用しています。

body {
　　background: #EEEEEE;
　　overflow: hidden;
　　border: 20px blue solid;
　　margin: 10px;
　　padding: 5px;
}
#d1 {
　　border: 20px green solid;
　　margin: 18px;
　　padding: 5px;
}
#d2 {
　　border: 20px yellow solid;
　　margin: 10px;
　　padding: 5px;
}
#d3 {
　　border: 20px red solid;
　　margin: 10px;
　　padding: 5px;
}

この時、赤枠のdiv要素(d3)のoffsetTop値を求めたところ、88となるところが73となってしまいました。原因を調べたところ緑枠のmargin-top-width値がoffsetTopに加算されていない事がわかりました。さらに調べたところmargin-top-width値が1～15までは加算されず、16以上は加算されることが分かりました。

またこの事象はbody要素と緑枠のdiv要素の間にp要素を入れても発生するのですが、table要素（下記イメージ）を入れると今度は正しい値を返します。事象が発生する要素とそうでない要素のパターンはまだ整理できていない状態です。

IEの内部ではoffsetTop値の算出にどんなことをしているのか気になる今日この頃です。

2008-01-22

住所の単語から住所の候補をサジェスト表示する #2

以前に公開したデモにキー操作機能を加えたものを作成しました。
キーボードから住所の単語を入力後、マウスに手を伸ばすことなく住所候補を選ぶことができるので使いやすくなったかと思います。

住所の単語から住所の候補をサジェスト表示する #2

まだ中小の解決すべき課題があるため、引き続きデモとしての公開になります。
もう少しお待ちください。

2008-01-20

xml:lang と hreflang でリソースのロケールを判別できるようにする

The Atom Syndication Format (RFC4287) を読むと、Atom Feed 自体のロケールと、外部リソースのロケールが指定できることがわかります。

Atom Feed 自体のロケールは、次のように xml:lang を使って指定します。xml:lang は Atom Feed の中のどの atom 要素にでも指定できるとあります。ですが、私は atom:feed に指定して、Atom Feed 全体としてのロケールを表現することに留めます。

<feed
  xmlns="http://www.w3.org/2005/Atom"
  xml:lang="ja"
>

外部リソースのロケールは、次のように hreflang を使って指定します。

<link 
  type="text/html"
  href="http://example.com/archives/1.html"
  hreflang="ja"
/>

xml:lang と hreflang の値は Tags for the Identification of Languages (RFC3066) に準じるとあります。ですので、日本語なら "ja" になります。

Mozilla Japan ローカライズセンターを読みながら、日本語のロケールの考え方や、ロケール名の変遷や背景などを理解しました。なので、ローカライズに対する理解はまだまだ浅いといえます。標準仕様と個人的見解がごちゃ混ぜになってしまったかもしれません。

コンピュータ翻訳&ローカライズ完全ガイド (イカロスMOOK)

TRADOS6 Freelance―翻訳支援ソフトの世界標準+「翻訳メモリ」活用法

by G-Tools

2008-01-19

atom:link@rel="enclosure" と atom:content はどう違うのだろうか

The Atom Syndication Format (RFC4287) を読んでみると、外部のリソースを表現として atom:link と atom:content が使えることになっていますが、その両者の使い分けや使いどころがわかりません。

以下は、私の勝手な推測、考え方、気づきなどを書き流したものです。

次のような atom:link@rel="enclosure" を使ったポッドキャスティングの例がよく引き合いになりますが、

<link rel="enclosure" type="audio/mpeg" length="1337"
  href="http://example.org/audio/ph34r_my_podcast.mp3"/>

意味として捉えると、次のように atom:content を使ったほうが適切にも思えます。

<content type="audio/mpeg" 
  src="http://example.org/audio/ph34r_my_podcast.mp3"/>

atom:link は length という atom:content にない属性を持っています。この length によって外部リソースがサイズが把握できるので、外部リソースを選択的にダウンロードするような用途でうまく機能しそうな気がします。

であれば、atom:content が外部リソースを表現できる必要性がない気がしますし、逆に atom:content も length 属性を持ってしまえばよい気がします。

ポッドキャスティングではなくエントリ内の画像と捉えると、コンテンツ内のリソースと捉えることができるので、atom:link じゃなく atom:content が適切であるという解釈もできます。ですが、atom:content が length 属性を持たない理由にはなりません。

atom:link@rel="enclosure" は、次のように RSS 2.0 Specification の enclosure 要素に対応します。この RSS 2.0 の仕様に影響を受けているのかもしれません。

<enclosure url="http://www.scripting.com/mp3s/weatherReportSuite.mp3"
  length="12216320" type="audio/mpeg" />

もしかすると、歴史的な背景とか、他の標準仕様との関係とかを知らないと、うまく理解できないのかもしれません。

まだモヤモヤしますが、今のところの結論としては、エントリ自体が外部リソースであるか、外部リソースがエントリ内の部分を表現するときは atom:content を使い、指定したときだけダウンロードするなど、外部リソースを選択的に操作するときは atom:link を使うという整理になりました。

どないなもんでしょう。

Head Firstオブジェクト指向分析設計 ―頭とからだで覚えるオブジェクト指向の基本
Brett McLaughlin Gary Pollice 長瀬嘉秀

オブジェクトデザイン (Object Oriented SELECTION) (Object Oriented SELECTION)

by G-Tools

atom:updated 日付と時刻の書式、そしてバリエーションの実際

The Atom Syndication Format (RFC4287) によると、atom:updated や atom:published の日付と時刻の書式は Date and Time on the Internet: Timestamps (RFC3339) に準じるとあります。

RFC3339 を見てみると、とても幅広い表現ができることがわかります。そこで、私が使っているサービスの Atom Feed を覗いてみたところ、次のパターンのいずれかのパターンに収まるようでした。

<updated>2008-01-13T13:45:25.946+09:00</updated>
<updated>2008-01-17T23:07:42+00:00</updated>
<updated>2008-01-18T21:35:07Z</updated>

ですので、(ライブラリなどの振る舞いにもよりますが) 自ら Atom Feed を生成して配信することがあれば、このバリエーションのいずれかになるよう調整すればよさそうです。

一般的な用途だと時刻は秒まであれば十分なのと、見た目が日本時間だと確認がしやすいので、私の中で atom:updated の日付と時刻の書式は、次のように表現することにします。

<updated>2008-01-13T13:45:25+09:00</updated>

これならわかる Web標準サイトの作り方入門の入門
うえがき麻矢山田祥寛

Webユーザビリティ・デザイン Web制作者が身につけておくべき新・100の法則。

Web標準XHTML+CSSデザインクリエイターが身につけておくべき新・100の法則。

by G-Tools

2008-01-17

atom:Content@type="xhtml" でセマンティックウェブ度を上げる

atom:Content Element の HTML 表現として type="html" と type="xhtml" がありますが、コンテンツの構造や内容をプログラムで解釈しやすいように xhtml を使うように心がけることにする。

atom:Content Element での XHTML 表現は、次のようになります。この他の表現もありますので、詳しくは The Atom Syndication Format (RFC 4287) を見てください。

<content type="xhtml">
<div xmlns="http://www.w3.org/1999/xhtml">
<b>for Google Maps InfoWindow</b>
</div>
</content>

この XHTML 表現を GGeoXml を使って Atom+GeoRSS を Google マップに表示してみるで使った Atom Feed に適用してみたところ、次のように Google Maps API で期待どおり動作しました。

ちなみに HTML 表現を使うと、次のようになります。この他の表現もありますので、詳しくはRFC 4287 を見てください。

<content type="html"><![CDATA[
<div>
<b>for Google Maps InfoWindow</b>
</div>
]]></content>

RFC 4287 では CDATA セクションを使ってよいかの言及はありませんが、Google Maps API で期待どおり動作しました。ですが、RFC 4287 にしたがって CDATA セクションを使わずにテキストノードを使ったほうがよいでしょう。可読性が落ちてしまうのが難点なんですが・・・。

とすると、プログラムにも人にも優しい XHTML 表現を使うのがベターかなという結論です。

セマンティック・ウェブのためのRDF/OWL入門
神崎正英

by G-Tools

2008-01-13

2008年のレインコートはトレンチコードで決まり

アイリスオーヤマが販売しているトレンチコート風のレインコートです。サイズはコーギー専用です。PET CITY のワゴンセールで 1,480 円でした。

↓こんな感じです。うちのは体系が小ぶりなので、後ろ足の袖があまり気味です。

↓上からから。

犬川柳コーギー魂! (タツミムック)
コーギースタイル編集部

by G-Tools

Trac で Active Tickets by Owner というレポートを作ってみた

Trac の View Tickets でアクティブなチケットを所有者ごとに分類して表示する Active Tickets by Owner というレポートを作ってみました。

そのレポートの SQL Query は、次のとおりです。owner カラムの別名を __group__ として、所有者ごとに分類するように指示しているのがポイントです。

SELECT p.value AS __color__,
  owner AS __group__,
  id AS ticket,
  summary,
  component,
  t.type AS type,
  time AS created,
  changetime AS modified,
  description AS _description,
  reporter AS _reporter
FROM ticket t
LEFT JOIN enum p ON p.name = t.priority AND p.type = 'priority'
WHERE status IN ('new', 'assigned', 'reopened')
ORDER BY owner, p.value, t.type, time

この SQL Query は TracReports を参考にして組み立てました。

このドキュメントをひととおり読んでみたところ、様々なオプションがあり、レポートの出力方法をカスタマイズして、希望するレポートを作成できることがわかりました。

わたしが注目したカスタマイズ項目は、次のとおりです。

QUERY_STRING を使って URL のパラメータと値を SQL の可変値として対応づけできる。QUERY_STRING に応じたダイナミックなレポートが作成できるということです。

前述の SQL Query のように指定したカラムで分類できます。また、優先度による色づけもできます。必要ならスタイル(CSS)も指定できます。

レポートの行や列のレイアウトも指定できます。指定したカラムでの折り返しや、指定したカラムを1行にするなどです。

CSV や RSS/XML にエクスポートするカラムと、HTML に表示するカラムを選別できます。あるカラムは HTML に表示しないけど、CSV や RSS/XML には含めるなどです。

Subversion実践入門—達人プログラマに学ぶバージョン管理
Mike Mason でびあんぐる

by G-Tools

2008-01-10

なんて商売っ気のないメールなんでしょうか。実に惜しいです。

ScanSnap S300 で両面パスワード付きスキャン

先月の上旬に購入していた富士通 ScanSnap S300 ですが、年明けて時間ができたので、ようやくセットアップして試しスキャンすることができました。これがなかなかです。わたしが求めていたことがちゃんと実現できました。

このとき ScanSnap のサイトからユーザ登録したのですが、1週間後の今ごろになって登録完了のお知らせがメールで届きました。そのメールの内容は、次のとおりです。

なんて商売っ気のないメールなんでしょうか。せっかく登録ユーザにメールを送る機会が持てたのですから、自社やパートナーの関連商品とか消耗品の宣伝とかしてもいいんじゃないかなぁ。実に惜しいです。


○○ ○○ 様

こちらは、「両面カラースキャナ ScanSnap」のユーザサポートセンターです。

お客様からのユーザ登録を受付けました。ありがとうございました。

[製品名]両面カラースキャナ ScanSnap

[ユーザ登録番号] ##########

以上でございます。

================================= a Fujitsu company ===
株式会社ＰＦＵ イメージング サービス＆サポートセンター
ホームページ　http://scansnap.fujitsu.com/jp/
  ･･･省略･･･
======================================================

担当者のみなさんに次の本を紹介したい気分です。

パーミションマーケティング―ブランドからパーミションへ
セスゴーディン Seth Godin 阪本啓一

by G-Tools

富士通 ScanSnap S300 はかなり気に入っていますので、どんどん売って、どんどん利用者を増やして、よりよく進化して欲しい、そういう製品です。応援しています。

2008-01-08

atom:id はどのような値を割り振ればよいのだろうか

feed/id や feed/entry/id はどうなっているのだろうかと、いくつかの Atom Feed の中やサンプルを見てみると、次のようなものが多いようです。

urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a
http://example.org/blog/a-day-at-the-beach.xhtml
tag:blogger.com,1999:blog-1509463847369212828.post-8271786567008127478
tag:flickr.com,2005:/grouppool/322338@N20/photo/56104498

The Atom Syndication Format によると、atom:id の値は IRI にしなさいとあります。また、その値は、グローバルでユニークにしなさいともあります。が、その IRI を使ってどのような atom:id を割り振ればよいかといった指針は示されていません。

で、そこが知りたいのよーと探してみると、How to make a good ID in Atom にそのヒントがありました。

次のように、atom:id は feed/link や feed/entry/link の URL と同じでいいと思っていましたが、atom:id は普遍性が要求されるため、URL が変わったとしても atom:id は変えてはいけないようです。

ので、このような状況になると atom:id の意味づけや運用に支障が出てきそうです。ちなみに atom:id が示したリソースが実存する必要性はないようです。

http://example.org/blog/a-day-at-the-beach.xhtml

次のように UUID を使うという方法もあるようです。ただ、こうすると、URL と UUID の対応表を保持しないといけませんね。

urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a

次のように The 'tag' URI Scheme を使うという方法もあるようです。調べた範囲ではもっとも使われている方法でした。

blogger.com は、ブログとエントリの単位でユニーク値を付与し、その値を組み合わせて Tag URI としています。UUID と同じく URL との対応表が必要ですが、blogger.com (と年) をスコープにしている点が異なります。

filckr.com は URL をそのままマッピングしています。これだと前述のとおり URL が変わったときに不都合がありそうです。

tag:blogger.com,1999:blog-1509463847369212828.post-8271786567008127478
tag:flickr.com,2005:/grouppool/322338@N20/photo/56104498

う～む。私も自前の Atom Feed を設計しているのですが、atom:id をどう割り振ろうかとよっと悩んでしまいました。

サイトの構成を変えない前提とすれば、atom:id と URL は同じでよい気がしています。filckr.com が Tag URI にしている根拠はどこにあるのだろうか。まだ私の理解の曖昧さがあるのだろうか。

サイトの構成を変えることを前提とすれば、blogger.com と同じように、サイト内でユニーク値を付与して、その値と URL の対応表を保持すればよい気がしています。

将来のことを考え過ぎると、前に進めなくなりそうなので、前者の atom:id と URL を同じにする案でいこうかなぁと・・・でもなんかシックリこないので、もう少し保留にします。

Web開発者のためのRSS & Atomフィード
ベンハンマースリー Ben Hammersley 菅野良二

JavaScript & DHTMLクックブック―Webエキスパート必携テクニック集

by G-Tools

登録: 投稿 (Atom)