J.Zeldman et al.「HTML5 Super Friends」

zeldman.comにコンテンツが追加されてた。
"Super Friends"という言葉のチョイスが面白いが、ニュアンスが・・？

HTML5 Super Friends

web標準のエバンジェリストの面々が共同署名して出したページ。面子は

• Dan Cederholm
• Tantek Celik
• Wendy Chisholm
• Aaron Gustafson
• Jeremy Keith
• Ethan Marcotte
• Eric Meyer
• Nicole Sullivan
• Jeffrey Zeldman

と豪華。面子に偏りのある（＝Happy Cog関係者が多い）のはこのページができたきっかけを知って腑に落ちた。
その辺はWendy Chisholmのエントリに少し書かれてる。

HTML5 Super Friends

• 8月中旬にHappy Cog Studiosにサインした面々が集まった。
  • Happy Cog：Zeldmanが作った会社
• 集まったときにhtml5について色々議論した。
• 議論した内容をまとめてみた
• まとめたページを出すときに"HTML5 Super Friends"と名乗ることにしてみた
• "HTML5 Super Friends"のコンテンツ
  • HTML5の基本路線を支持しますという宣言
  • 仕様にはいくつか問題があるからそれの指摘と代案を出してみる
    • "Super Friends Guide to HTML5 Hiccups"というページにまとめた
• 集まった面々は既にブログで色々html5について思うこと書いてるけど、包括的で便利なページだと思うよ、と

HTML5 Super Friends Technical Details

HTML5 Super Friends名義でhtml5の技術情報を公開するページ。現在コンテンツとしては、html5の問題点と代案を詳細に列挙した「Guide to HTML5 Hiccups」のみ
"problems"としないで"hiccups"としたニュアンスが把握しきれない。
とりあえず基本路線は賛成してるから具体的なレベルで異論がある、と理解した
canvasとアクセシビリティというweb標準な人ならではの視点もあって面白い。

以下斜め読んだ内容

• html5の基本的なところは賛成だしワクワクしてる。
• 何箇所か変更を加えたり曖昧な箇所をクリアーにすると、html5がもたらすメリットはさらに大きくなる、はず
  • 以下列挙
• validation
  • html5ではxhtml/htmlどっちも選べる。このことを明確にすべき。
    • html5の仕様では、xhtml/htmlに優劣つけるべきではない。
  • html5用のvalidatorに必要な機能
    • syntaxのチェックをvalidation時にできるように。
    • Henri Sivonenがもう1仕事してくれることを期待
    • xhtmlとしてチェックすることをvalidation時に選べるようにする。
      • 属性値は引用つける
      • 空要素のマークアップ
      • 閉じタグ必須
      • xhtml.0で定義された実体参照の使用
      • etc...
    • Henri Sivonenは、validationサービスのhtml5版であるValidator.nu (X)HTML5 Validatorを作った（or作ってる）人
  • validator必要
    • ブラウザでのプレビュー前にvalidationチェックできるかどうかは、生産性に大きく影響与えるから。
      • バグの早期発見ができるようにするというよくある論点。
    • w3cのvalidationサービスでは必要なチェック機能は揃ってる。
      • w3cのvalidationサービスではtext/htmlとしてxhtmlのsyntaxのチェックができる
    • html5のvalidatorでも、text/htmlとしてsyntaxのチェックができることを希望。
• 新しく追加された要素・属性
  • 要素を追加することにはできるだけ控えるほうがよい
    • 例。article要素はいらない。pubdate属性が追加できる以外にsection要素と違いが無い。
    • 提案。article要素は削除、section要素にpubdate属性を追加。
  • 新要素の名称・役割と、マークアップのベストプラクティスの間には連続性があるが、完全ではない。
    • ベストプラクティス＝semanticなclassの命名（header,footer,etc..）のこと。
    • 問題。仕様で定義された新要素の役割と、その要素の実際の使われ方に齟齬が生まれる余地が結構ある。
    • 提案。html5の仕様の中にベストプラクティスをきっちり盛り込む。
  • footer要素
    • 仕様とベストプラクティスが乖離してる典型。
    • 仕様。
      • sectin要素内の末尾に配置されるもの。
      • copyrightや他のメタ情報が配置
    • ベストプラクティス。
      • ページのテンプレートレベルの要素。この点がhtml5におけるメタデータという位置付けと違う。
      • ページ内の要素のテンプレートのよくある例はheader,body,footer。id属性が使われる。
      • footerに配置されるのは、bodyに配置されたコンテンツにとって二次的なものなら何でも入る。
        • メタデータの配置場所という位置付けではないため。
        • ナビゲーション、別のセクション、見出し、も配置されうる。
    • 予想。
      • 仕様に反して（しかしベストプラクティスに従って）、ページの末尾に配置する人続出するはず
    • 問題点。ベストプラクティスでは、class/idでfooterとされた要素にはブロックレベル要素と見出し要素が含まれるのが一番多いパターン。
      • footer要素の仕様と矛盾してる。
      • 最近の傾向。footerもコンテンツとみなすパターンが増えてきている。その場合、コンテンツ部分と重要度の違いという位置づけがされている。
    • 提案。
      • ベストプラクティスと一貫性を維持すること、新要素のheader要素と対の関係を維持する。この２つが達成できるように仕様の定義に追記する。
      • 内容とできる要素への制限を緩める。
      • "...,(A footer) but may contain any information which is secondary to the main content in its nearest ancestor sectioning content. If that is the body than the footer is secondary content to the document as a whole."
  • hgroup要素
    • あとでかく
  • aside要素
    • あとでかく
  • canvas要素
    • 面白い要素。期待度大
    • アクセシビリティで問題
      • アクセシビリティの点ではかなりひどい。1998年のFlashのレベル。
    • 提案。WAI-ARIAを組み込むべき。
      • そういう動きも最近出てるのでlast callまでに実を結ぶことを希望
  • dialog,time,details,figure,progress,meter要素
    • あとでかく
• 位置づけの変わった要素・属性
  • style要素
  • iframe要素
    • サンドボックスをつける。
      • セキュリティ、code integrity、style collisionが理由
  • href属性のないa要素
    • あとでかく
  • cite,div要素
    • あとでかく
• 削除された要素・属性
  • • ほぼ異論なし。
    • table要素関連で意見あり。
    • th要素、thead要素、scope属性が残った点は賛成
    • th要素でabbr属性が削除された理由が知りたい。
    • 行と列が複数あるタイプのtable要素がどういう形でマークアップされるか。
      • 仕様作ってる人にサンプルを提示してほしい