Hatena::Groupweb

vantguarde

|

5.13

microdata雑感

| 02:38

(うわわわ、セクションのやつよりずっとブックマークがついている。なぜ。)

それはそうとですよ。

I've renamed property="" to itemprop="".

[whatwg

はやいよ!

というわけでpropertyitempropに改名しました。前のエントリも書き換えました。ふー。

というわけでまだまだ落ち着いた感じのしないmicrodataですが、前の奴についたコメントとかを読んでみたので、雑感などを。

microformatsとの関連

microとあるせいかつながりがあるように思ってる人がいらっしゃるようですが、ほとんど無いと言ってよいでしょう。かたや語彙(プロファイル)の集合で、かたやフレームワーク。かたやhuman readable優先、かたやそういう目的じゃない。いろいろ違います。

仕組みの設計やHixieの発言を見るに、RDFaにかなり近い仕組みです。microformatsって一概にまとめるのも結構危ないですね。一貫した仕組みがないのに、そう見えてしまうし。

RDF

RDFとの違いをちょっと書きましたが、もうちょっと。

現在のproposalでは、RDFとしても出力可能なんですが、カスタム語彙を書く時に問題がでてきます。ただ単itemprop=titleとか書いちゃうと、それがhttp://www.w3.org/1999/xhtml/custom#titleというURIにマップされてしまうので、概念の衝突が起こってしまう可能性があるんですね。

共有を目的としない文書であればcom.example.***みたいに書く必要がないわけなんですが、RDFに変換した時にあまりよくないわけです。

あとは、全てのアイテムの主語が文書のURIになってしまうのもRDF的には残念なのかなと。subjectがIDREFじゃなくてURIも取れるように変更されれば、それを利用して回避する事はできそうですが。

めんどう?

「面倒」とか「手書きは」的な意見を目にしたのですが、ちょっとよくわからないんですよね。

  • com.example.***」みたいなのがめんどくさいのか
  • それともこういう行為自体が面倒なのか

前者であれば、手書きであっても例えば--titleとでもまずタイプして、あとでcom.example.に置換しておくとか、そういう工夫をすればclass書くのと大差がないように思います。あと、一番手間がかかるのは、語彙を設計したり、正しくマークアップしたりする事だと思うので、そこまで問題にならないかなあと。

で、後者であれば本末転倒というかなんというか。文章中から機械可読なデータをある程度楽にするためには、spanなりでマークアップする必要があるわけで。それはRDFaだってmicroformatsだって同じです。そういう面倒をかけないといけないし、かけてもいい人のために用意されてるものでもあるわけで。

それともあれですかね、インライン要素が本文中にいっぱいあるのは「美しくない」てきな感覚なんでしょうかね。うーん。まあいいや。

DOM APIが用意されている強み

しかし、DOMのAPIが用意されているのはいいですね。RDFaはたぶん定義してないでしょうし、microformatsはDOM以前にプロファイル毎に実装を作らないといけないですし。

インターフェースを全然見ていないので解らないんですが、スクリプトからアイテムやプロパティのコレクションをいじる事が出来ると楽しそうかなって思いました。itempropとか書かずとも、データテーブルの情報だったりをアイテムとしてマッピングできたりなんかすると、面倒ってことにはならなさそうですし。

5.11

HTML5のmicrodata

| 02:04

おおおっ。きましたよーー

microdata in HTML5の最初のドラフトが上がってきました。ちょっと前にユースケースが集められてたので、追加する気なんだとちょっとびっくりしたのですが、すごいですねー

さて、ざっとですが読んだので紹介を。試しにここの簡単な概要を書くと、こんな感じになるようです。

<section item="com.example.weblog">
  <h2>このサイトについて</h2>
  <p><span itemprop="com.example.title">vantguarde</span>っていうweblogです。
  <p><span itemprop="com.example.author">id:vantguarde</span>がやってます。
</section>

itemは新しい「アイテム」を、itempropはハッシュでいうnameを表します。valueは要素のtextContentになるんでしょうか。

itemがネストされると、構造化されたデータを値に取る事が可能です。最新のエントリーについての情報を追加してみます。

<section item="com.example.weblog">
  <h2>このサイトについて</h2>
  <p><span itemprop="com.example.title">vantguarde</span>っていうweblogです。
  <p><span itemprop="com.example.author">id:vantguarde</span>がやってます。
  <p itemprop="com.example.latest" item>最新の記事は
    <a itemprop="com.example.permalink" href="/html5_microdata">
<span itemprop="com.example.title">HTML5のmicrodata</span></a>です。<br>
    <time itemprop="com.example.pubdate" datetime=2009-05-11>2009/05/11</time>に公開されました。
</section>

その他、idの付いた要素を参照し、アイテムの主語とするsubjectなんて属性も定義されています。RDFaからの影響がよく解る属性ですね。

itempropの語彙ですが、基本は例に挙げたようなJavaっぽいNamespaceを使うようです。ただドメイン持ってない人のためなのか、URLも使えるようです。URLといいつつHTML5の「URL」にはURIも含まれるはずなので、tag URIとかも使えるのかなとは思います(解決されるのかどうかはさておき)。

さて、microdataはmicroformatsよりも“human readable”に狂ってはおらず、機械に都合の良いデータも簡単に埋め込む事が出来るようです*1

使うのはproperty付きのmeta要素です。microdataの追加にあわせ「itempropがあるものはflow content」という定義が追加されました。これでbody内に書く事が可能です。

<section item>
  <h2 itemprop="com.example.label">コロッセオ</h2>
  <meta itemprop="com.example.lat" content="41.890278">
  <meta itemprop="com.example.long" content="12.492222">
  <p itemprop="com.exmaple.desc">ローマにある円形闘技場跡です。</p>
</section>

データの利用ですが、DOM APIが提供され、またJSONやRDFへの変換アルゴリズムも用意されてます。

面白いですね。RDFとの違いをざっと考えてみましたが、リテラルやURIを持つリソース(ObjectProperty)、データ型などの概念がないこと、同じプロパティを複数持てない事でしょうか。まあでも、語彙を工夫すればそこまで問題ない気がしています。

propertyなど属性名のコンフリクトは気になるところですが、RDFaの処理モデルを考えると問題ないのかなと。書く側に紛らわしいっていう問題は残りますが。

実装の段階でどうなるのかも含めていろいろ楽しみです。

*1:目的が機械のためのデータを表現することなので、出来ないと困るわけですが

5.2

headerがhgroupとheaderに分離

| 00:21

おおっと。これは。

Per feedback on the matter, I've renamed <header> to <hgroup> and introduced a new <header>.

Re: Naming of <header>

Rename <header> to <hgroup> and restrict it just to supporting subheadings.

Introduce a new <header> element.

(X)HTML5 Tracking

というわけで、headerhgroupに名前を変え、そして新たにheaderという名前の要素が加わりました。

なんのこっちゃっていう話なんですが、旧headerが持っていた「見出し要素のグループ化」と「なんか導入部分によくある要素群のコンテナ」っていう役割を分けて、それぞれ別の要素にしたって話です。

headerにはかねがね「見出し要素をグループ化する要素なのに、名前のせいかただのコンテナとしてしか使われてない」みたいな意見がありました。見出しのグループ化というのが主な要素の目的なのに、名前のせいでただの便利divにしかなってなかったと。そのくせ内側にsectioning contentを入れられないので、headerの中にnavが入ってるとnon-conformingになるという、軽いいじめな状況だったわけです。

さて、hgroupは目的が一つになったので、見出し要素のみを内容に持つ要素になりました。名前が気持ち悪いですがシンプルです。

一方、新しいheaderはsectioning contentでは無くなり、footerと同じただのflow contentになりました。これでnavとかを中に入れられるようになってます。必要性があまり無い気もしますが、便利に使えばいいと思います。

現在の使われ方に近い書き方が出来るようになったので、よい変更ではないでしょうか。

4.20

HTML5のセクション(その4)

| 01:14

もうちょっと。ひとまずこれで終わりかなあ。

sectioning contentとアウトライン

見出しのランクから開始されるセクションは暗黙的なものですが、sectioning contentは常に明示的なセクションを開始します。sectioning contentが存在する場合は、直下にある最初の見出しが、そのセクションの見出しになります。

その見出しのランクより高いものがsectioning content内に新たに出現した場合は、そこでセクションが閉じられ、新しいセクションがその兄弟として生成されます。

<h1>foo</h1>
<section>
  <h2>bar</h2>
  <h1>baz</h1>
</section>

この場合、baz(h1)はfooの兄弟ではなく、bar(h2)の兄弟になります。ランクが低いものはサブセクションになるけど、高いものは上に上がってくれないわけですね。なんか気味悪いという人もいるかもしれませんが、きちんとsectioning contentで囲ってあげれば済む話ということで。

さて、セクションと見出しからアウトラインを生成するアルゴリズムHTML5には存在しています。いろいろ面倒なので訳しませんが。

<h1>vantguarde</h1>
<section>
  <h2>09.xx.xx</h2>
  <article>
    <h3>HTML5のセクション</h3>
    <section>
      <h4>フラットでなんとか</h4>
      <h3>リニアがどうこう</h3>
    </section>
    <h4>見出しのグループ化</h4>
    <h5>headerの中にh1だけ?</h5>
    <h3>divをそのままsectionにするなんて</h3>
  </article>
  <h4>HTML5が2010年に出るってのはデマ</h4>
</section>

雑なHTMLですねー。それがこんな感じになります。たぶん(詳しく読んでない)。

  1. vantguarde
    1. 09.xx.xx
      1. HTML5のセクション
        1. フラットでなんとか
        2. リニアがどうこう
        3. 見出しのグループ化
          1. headerの中にh1だけ?
      2. divをそのままsectionにするなんて
      3. HTML5が2010年に出るってのはデマ

正しく実装されてるかはわかりませんが、HTML5 Outlinerなるものがあるので、確かめる事ができます。ただし、画像の代替テキストを読んでくれたりしないので、そこはちょっと不便かも。

今後どうなるか

こんなアルゴリズムが用意されてますが、どうなるんでしょうね。

まずは、どういう風に実装されるのかが気になるところです。Wordとかが持ってるようなアウトライン表示機能を内蔵してくれるんでしょうか。ただ、W3Cの仕様書みたいなものは変なアウトラインになってしまうし、HTML5限定で機能するというのも全く意味がない。

実装という観点から考えると、どれくらい意味があるものなのかちょっとよく分からないんですよね。制作者のための要件にもならないですし。アルゴリズムが使えなければ、あまり新しい要素を使う意味もないかなあと思うわけで(正しく使えない事が多いだろうから)。

とりあえず、使う時にはきちんと見出しとセクション、そしてセクションどうしの関係を見るようにしましょう。HTML5って処理系はゆるい感じに見えますが、意味的にはStrictよりもっと厳しいですよ。

4.18

HTML5のセクション(その3)

| 15:01

続きを書くの、わすれてました。というわけで、今回はセクションの構成と、sectioning contentについて。

フラットでなんとか

ここの構造って、たぶんこうなってると思います。

<h1>vantguarde</h1>

<h2>09.04.18</h2>
<h3>くたばるのは僕の方だよね</h3>
<h4>まあでも考えなよ</h4>
<h4>例考えるの飽きた</h4>

<h2>09.04.17</h2>
...

HTML5のHeadings and sectionsというセクションには、だいたい次のような感じセクションを構成する流れが書かれています。

  1. 見出し要素に出会ったら、セクションを開始する
  2. 次の見出し要素に出会ったら、そのランク(hn)を調べる
  3. ランクが同じ、または高ければ、そこで現在のセクションを終了し、新しいセクションを開始する
  4. ランクが低かったら、新しいサブセクションを現在のセクションの中に開始する

だから、こんな感じになりますね。

  1. vantguarde
    1. 09.04.18
      1. くたばるのは僕の方だよね
        1. まあでも考えなよ
        2. 例考えるの飽きた
    2. 09.04.17

特に難しくはないかなと。

見出しのグループ化

さて、じゃあこういうのはどうなるんでしょう。

<h1>HTML 5</h1> 
<h2>A vocabulary and associated APIs for HTML and XHTML</h2> 
<h2>W3C Working Draft 12 February 2009</h2> 
<dl>
  <dt>This version:</dt>
...

W3Cの仕様書なんですが、h2が前にあるh1とともに、一つの見出しブロックを構成しています。サブタイトルみたいなものと考えればいいでしょう。

しかし、今言ったアルゴリズムでは“HTML 5”の下に“A vocabulary...”と“W3C Working Draft...”という、二つのサブセクションができてしまいます。これは意図されたものではないでしょう。

そこで登場するのが、見出しブロックを構成するheaderです。headerh1-h6とともに、heading contentとしてカテゴライズされています。

<header>
  <h1>HTML 5</h1> 
  <h2>A vocabulary and associated APIs for HTML and XHTML</h2> 
  <h2>W3C Working Draft 12 February 2009</h2> 
  <dl>
    <dt>This version:</dt>
  ...
</header>

こういう風に囲んであげると、ひとまとめの見出しとして扱われます。

グループ化という側面もあり、たとえばheaderの中にh1ひとつしかないってのは良くないです。non-conformingではないですが。

sectioning content

sectioning contentはセクションを開始する要素を表します。section, nav, article, asideが該当します。

ここの場合、たとえばこんな感じになるかなあと。

<h1>vantguarde</h1>
<section>
  <h2>09.xx.xx</h2>
  <article>
    <h3>HTML5のセクション</h3>
    <footer>
      <p><a>html5</a>, <a>markup</a> | 12:26</p>
    </footer>
    <section>
      <h4>フラットでなんとか</h4>
    </section>
    <section>
      <h4>見出しのグループ化</h4>
    </section>
    <section>
      <h4>sectioning content</h4>
    </section>
  </article>
  <article>
    <h3>HTML5が2010年に出るってのはデマ</h3>
    <footer>
      <p><a>html5</a> | 23:35</p>
    </footer>
    <p>出るわけないです。本気で思ってるんですか?目を覚ましてください。</p>
  </article>
</section>

こんな感じです。ちょっとfooterを入れてしまってるのでごちゃごちゃしてますが、まあこちらも理解できるかなあと。

なんでもsectionにする人はくたばればいいと思う

気をつけてほしいのが、divsectionでそのまま置き換えたもの。

<article>
  <h1>タイトル</h1>
  <section class="content">
    <p>blah...
  </section>
  <footer class="related">
    <ul>...
  </footer>
</article>

たぶんスタイルシートのために用意してるんでしょうが、そういうものはまずdivでやりましょう。section.contentがあると、その中に見出しのない無名のサブセクションができてしまいます。もちろんそれがサブセクションである場合ならば構いませんが。

ほかにもsection#containerとか、とても怪しい感じのマークアップを見る事があります。もしそういう風に書いていたら、悔い改めてdivにしましょう*1

レイアウト関係はあとで書くようにして、とりあえず見出しとセクションを意識する事からはじめましょう。

*1:必ずしもsectionが間違ってるわけではないですが、よく考えてください

aratako0aratako02009/09/01 17:00> グループ化という側面もあり、たとえばheaderの中にh1ひとつしかないってのは良くないです。non-conformingではないですが。

hgroupがまさしくこんな感じで書かれていますけど、そうすると、複数の見出しがあるときにこそ使うべきだってなりますよね(だってグループ化だから)。

するとサイト制作という実務上は利用シーンがかなり限定されるような気もするんですがどうなんですかね(愚痴っても仕方がないんですけど)。

|
Contact: @vant / lepetitcroissant@gmail.com.