2006年 07月 21日

CSS Nite Vol. 10

神崎さんの話目当てで行って来た。

  • CSS の話があんまない。
  • XHTML って名前だけで ill-formed とか勘弁して!
  • RDFSPARQL やろうよ
  • GRDDL くるかもよ
  • XSLT! XSLT!
  • ウェブのインフォーマルな良さと、フォーマルな応用性を繋ぐのが重要なんだよ

結構マニアックな方向の話だった。会場の人で「well-formed」なんて聞いたことがないという人が多くてびびる。今回の話をきっかけにちゃんとそういうことも考えてくれたらいいなぁとてきとうに思った。

SPARQL の話とデモは、なんとなくイメージが掴めて面白そうな感じ。


かなり人が多くて、立ち見だった。抽選の応募がケイタイからだったのだけれど、ケイタイが圏外だった。MacBook が欲しくなった。関係ない。

2006年 01月 14日

リソースの定義

URI の R の定義。

RFC 3986 に書いてあるみたい。

要約が Web Kanzaki にある。URIとファイルディレクトリ -- ごく簡単なHTMLの説明, URIの意味するところ, Resource (RFC 2396 を基にしている。RFC 2396 は obsolete)

RFC 2396 では微妙に細かいことが書いてあったんだけど、RFC 3986 では意味するところが「なんでもいい」になった感じ。長いこと書いてあるけど大半が例。URI がついてるもんは全部リソース、インターネットを通じてアクセスできる必要はない、抽象的なものでもいい。

Resource
This specification does not limit the scope of what might be a resource; rather, the term "resource" is used in a general sense for whatever might be identified by a URI. Familiar examples include an electronic document, an image, a source of information with a consistent purpose (e.g., "today's weather report for Los Angeles"), a service (e.g., an HTTP-to-SMS gateway), and a collection of other resources. A resource is not necessarily accessible via the Internet; e.g., human beings, corporations, and bound books in a library can also be resources. Likewise, abstract concepts can be resources, such as the operators and operands of a mathematical equation, the types of a relationship (e.g., "parent" or "employee"), or numeric values (e.g., zero, one, and infinity).

注意:勝手にマークアップしました。

思ったよりてきとーだった。

2005年 11月 21日

俺的 XHTML 構造

だいたい決まった構造の HTML を書くようになってきたので、俺の場合を紹介してみる。body 以下を書く。

  1. body
    1. (div#all)
      1. h1#top
        1. a
      2. div.section#navigation
        1. h2
        2. (p#skip-to-main-content)
          1. a
        3. map
          1. ul
            1. li#navigation-home
              1. a
            2. 以下似たようなのが続く
      3. div.section#content
        1. div.section
          1. h2
          2. 内容
        2. 以下似たような(ry
      4. div.section#footer
        1. address

おおむね上のような感じ。っていうか ol, li で書くとすげぇ大変なんですが!!

これはもちろん現実的にこうなっただけであって、いろんな妥協に溢れている。

body 直下の div#all なんてもちろんいらない要素だけど、実際問題 CSS 書くときに、これがあるだけで、クロスブラウザ用の無駄にややこしいハックを減らせるので、安全になる。幅も広がる。

div#navigation map なんて、パっと見変な風に見えないかもしれないけど、ぶっちゃけた話、こじつけられた div 要素みたいなもの。意味的には問題ないので、使ってみると結構便利。ただし display: block を書かないとハマるときがある。こいつには一枚多く背景に画像突っ込めるわけだ。あと実は p#skip-to-main-content も、アクセシビリティの配慮とか、そういうの関係なく、あると便利な要素の一つ。サイトによっては書かなかったり (そもそもナヴィゲーションがないとか) するけど。

できるだけ意味をこじつけて、div じゃない要素を使おうとしているだけ。いろいろ置換してけば div 厨になるんです。なんでもいいけど、悪いのは微妙な仕様の CSS と、その CSS に対応してない IE なんですよ!! 俺は悪くない! 放せ!

CSS 本来の力・XHTML のあるべき姿

上のセクションに続き (とはいえ書いたのはこっちが先だ。つまり、まだ今「上のセクション」はない) 割と理想的な XHTML の姿と、CSS 2.0 の本来の姿。 True Power of CSS

body 直下に h1 を置き、サイト名やら、文書タイトルを書き直すのはバカらしい。既に title 要素を書いているのだから、それを利用すべき。これで hn の数字が全体的に一個減る。

本当はフッタ情報 (書いた人やら、連絡先やら) も body 内に書くものじゃない気がする (どっちかといえばメタデータなはず) けど、とりあえず仕方ないので address 要素置いてる。CSS からリンクは作れないし、フッタっぽく表示させるのは困難。

2005年 10月 17日

MetadataManipulator

icho にデフォルトで搭載される予定らしい MetadataManipulator について。

とりあえず基本的に icho に依存しないので自分のサイトで実験することにする。Javascript 入れていれば左上になんか出てるはず。たぶん。

どこまで決めうちしていいか考え中なので、いまのところ MetadataManipulator 自体はソース生成しかやってない。ピョコピョコさせたり、CSS 的に欲しい要素を補完するのも外側。

link 要素の出現順に何も考えずにソース生成すると CSS が適用しずらいのでいくつか MetadataManipulator の外側で修正してある。内側に入れるか悩む。入れるんだろうけどどうやって入れるか悩む。

  1. あんまり役に立たない。next, prev はいいけど……
  2. in-page heading が役に立ちそうだけどうまいことナビゲーション生成するのがめんどい。汎用性云々。ながったらしいし。h2 だけ抽出とかにすればいいのか。
  3. 実装が定まらない。クラスっぽくするかモジュールっぽくするか。
  4. マルチリンガルじゃない。"in-page heading" っていう文字列を埋め込んでる。"ja-jp,ja;q=0.8,en-us;q=0.5,en;q=0.3" とかいう文字列を優先順位高い順に配列に突っ込む関数は書いたけど、どの時点で実行するか迷う。
  5. あんまりときめかない。

# IECSS の問題があるけど本質じゃないのでとりあえず放置

var mmul = document.getElementById("MetadataManipulator-Local-RelatedLinks-Dd").childNodes[0];
var fill = function (linkName) {
var ret = getElementsByClassName("MetadataManipulator-" + linkName, "li", mmul);
if (ret.length < 1) {
ret = document.createElement("li");
ret.className = "MetadataManipulator-" + linkName;
ret.appendChild(document.createTextNode(linkName));
} else {
ret = ret[0].parentNode.removeChild(ret[0]);
}
return ret;
}
// 順番を保証・これ以外の rel は copyright の次以降に。
var standard_link_rel = ["start", "prev", "next", "contents", "index", "glossary", "help", "copyright"];
var links = {};
standard_link_rel.each (function (i) {
links[i] = fill(i);
});
standard_link_rel.eachWithIndex (function (i, index) {
mmul.insertBefore(links[i], mmul.childNodes[0+index]);
});
with (mmul.parentNode) {
style.left = "-201px";
if (document.all && document.attachEvent) mmul.parentNode.addEventListener    = document_addEventListener;
addEventListener("mouseover", function (e) {
style.left = "0px";
}, true);
addEventListener("mouseout", function (e) {
style.left = "-201px";
}, true);
}

ながったらしい CSS との組み合わせです。see base.css

2005年 01月 15日

chokan & FOAF

実験的に Rena を使ってみたかったので、よろしそうなプログラムを考える。

IRC BOT に何か FOAF アレこれできるような機能をつけてみたかった (意味があるかは考えない) ので、とりあえず URI に反応して、それが FOAF だったら foaf:nick と foaf:name をとってくるようにしてみた。

URI (http:) が PRIV されたら HEAD でアクセスして、ステータスコードと Content-Type を確認。`text/xml', `application/xml', `application/rdf+xml', `text/ntriples' であれば Rena にロードさせる。

ロードしたら rdf:about="" なリソースを探し、それが foaf:PersonalProfileDocument であれば foaf:primaryTopic のさすリソースの foaf:nick と foaf:name をてけとーに取得して IRC に NOTICE

Rena は結構遅いので、RDF パース中は chokan が他の処理しないかもしれない。

作るにあたって Using Rena to Process RDF in Ruby が役に立った。

よく考えると open-uri に Accept ヘッダを加えるのは無理 (もしくはめんどう) なので、最初から GET して、response.body を StringIO にして Rena に投げることにする。こうしないとネゴシエーション効いてる場合ダメになる。

メイン部分のコード。

# uri は読み込んだ RDF の URI の URI クラスのインスタンス
# res は HTTP#get の値
model = Rena::MemModel.new
model.load(StringIO.new(res.body),{
:content_type => Regexp.last_match[0],
:base => uri.to_s
})
resource = model[uri.to_s] # 相対 URI は絶対 URI に変換されている。
if resource &&
resource.get_property(RDF + "type").uri == URI.parse(FOAF + "PersonalProfileDocument")
mes = "foaf:PersonalProfileDocument"
foaf = resource.get_property(FOAF + "primaryTopic")
nick = foaf.get_property_values(FOAF + "nick")
name = foaf.get_property_values(FOAF + "name")
# string_array は rdf:Alt とかも全部ひっくるめて単一の文字列の配列にする
mes += " [nick:#{string_array(nick).join(", ")}]" unless nick.empty?
mes += " [name:#{string_array(name).join(", ")}]" unless name.empty?
subject << notice(channel, mes.to_jis)
else
puts "Not FOAF"
end
2004年 11月 29日

画像をてきとーに一覧表示する。

/view-img/2003/ みたいな。

RDF は画像ファイル自身に埋め込んだのを取り出していちいち動的に合成してる。現状では同じディレクトリに samp-meta.rdf があるからそっち直接読んでもいいんだけど……実験ってことで……

合成するとき REXML 使ってるから怪しい XML (名前空間接頭辞が他のファイルと違うとか) があるとたぶんパースエラーになる。稀なケースだし Ruby のライブラリでガッチリキッチリ実装した使いやすいやつを知らないので仕方ない。

ローカル側では RDF を埋め込む (ファイル名に -meta.rdf をつけたやつを突っ込む) ときに画像サイズが一定以上だったらサムネイルを作って、その情報 (foaf:thumbnail) も追加して埋め込む。

サーバー側は同じディレクトリの画像をスキャンして RDF を取り出し、@rdf:about を書き換えて合成。合成したヤツを XSLT エンジンに渡す。あとはまぁ普通に XSLT テンプレの仕事で……

ちなみにファイル名のリストは別に XML 作って渡してる。丁度いい語彙があれば RDFRDF として突っ込んだほうがスマートだけど考えるのが面倒だった。

だいぶソースが汚い。

2004年 11月 22日

RDF on Ruby

なにやら w3.org ドメインにあるじゃないですか! っていってもどれほど使えるかわかりませんけど……

2004年 11月 18日

画像メタデータの管理法

画像に埋め込んであるだけだといちいち編集するのが面倒なので、簡単な管理方法を考えた。っていっても firefox.png に対して firefox-meta.rdf というファイルを作っておいてスクリプトで一括合成させるだけのものだけど……

本当は firefox.rdf にしようと思ったけど、そのままアップロードしたとき MultiViews のネゴシエーションで RDF のほうが優先されて困るので -meta というサフィックスをつけた。playing.xml を変換するスタイルシートに playing-style.xsl と同じような雰囲気。

むしろ画像データ (firefox.png) をリクエストしてメタデータ (firefox.rdf) が返ってくるは少し変な気もする。いやでも firefox.png はメタデータを含んでいるし、image/png を受け入れないなら RDF を返してもいいか。実際 W3C もそういう方法 (photoRDF) を考えているみたいだし……

2004年 11月 11日

PNG への RDF メタデータ埋め込み

とりあえず iTXt への書き込み/読み込み方法はできたので実際にどうやって埋め込むかを考える。考えるっていっても、メタデータを埋め込んでいる PNG ファイルというと RDF のアイコンが既にあるのでそいつをそのまま真似ればいいかなと。

この埋め込み方法は二つのチャンクを使う。一つはメディアタイプを明確にする Metadata Type チャンク。もう一つは実際にデータを埋め込む Metadata チャンク。RDF アイコンではこれらは tEXt チャンクに入っているけど、日本語を (というか国際化のために) 使うのでどちらも iTXt に入れる。Metadata Type (ASCII しか使われないっぽい) も iTXt にするのは tEXt, zTXt チャンクが iTXt 登場のおかげで既に古くさい感じが漂うから。

ってか実際何を埋め込んで何をしたら面白いかをちゃんと考えてない。まだあくまでこういう方法もできるという保険みたいなもん。何かいいことできないかな。