セッション5「混ぜるな危険？　複合文書から見たXHTML+CSSとスキーマ活用」

event report webstandards cssnite

XHTML を複合文書として利用する際の注意点とCSSを正しく適用するコツを解説
スキーマに照らしてXHTMLの可能性を広げるスキーマ活用

Ruby Annotation

  • 仕様書に日本人が日本語で名前が載ったのが石川氏が最初
  • Rubyの国際標準にMicrosoftが提案
  • テーブルのようにすることで実装
  • rp要素を削除する要求があったが拒否
  • ルビは（）表記するものではないと日本が主張

XHTML Media Types

  • 仕様における「should not」は「空気読めｗ」
  • XHTML で配信するなら application/xhtml+xml にしろ。text/html で配信したいなら html でやれ

An XHTML+MathML+SVG Profile

  • DTD を全部組み合わせた
  • 「これを本当にしたいのか」と行間を読むｗ


  • XHTML 2.0 のゴールは可能な限り XML の機能が使えること
  • モバイル上でも SVG の対応が進んでいる（NetFront）
    • SVG の対応はモバイルの方が早かった（らしい）

XML 複合文書とは

複数の XML ボキャブラリが混在した文書

  • 「参照」型複合文書
    • 外部のリソースをURIで参照
  • 「埋めくみ」型複合文書

名前空間の役割

要素名及び属性名として使用される名前の集まり

  • 異なる xml ボキャブラリ間の要素名や属性名の衝突を防ぐ
  • ある xml ボキャブラリに属する要素や属性をグループ化して識別可能にする

xml 複合文書においては名前空間はきわめて重要
ただしどのレベルまで細かく混在できるかはボキャブラリによって異なる

複合文書へのスタイルシートの適用

CSS Module:Namespacesを活用して各ボキャブラ利用スタイルシートに名前空間を指定

スキーマによる検証

スキーマの役割

後者は仕様策定者の仕事

主な xml スキーマ言語

各スキーマ言語の対応度

どれも一長一短あり、完璧なスキーマ言語は無い
１つのスキーマ言語を全てやろうとせず、それぞれの良いところを組み合わせて使う

モジュール化されたXHTML DTDのカスタマイズ

ポイント
  • 拡張は考えない
  • 編集時にいらない機能を削る
方法
  • DTD中の以下のような記述を探す
    • <!ENTITY % xhtml-モジュール名.module "INCLUDE">
  • IGNOREでその機能を削除することができる

独自のvalidatorを作成できそう。（メモ：oXygen,onvdl）

セッション7「Internet Explorerの開発・フィードバックプロセスと、業界標準への取り組みについて」

event report webstandards cssnite

このセッションの目的

IEとの付き合い方を知る
  • 開発サイクル
  • ベータプログラミング
  • IEのモヤモヤはこのタイミングで
IEをもっと信頼できるブラウザにするために
  • 信頼できるブラウザで一番重要なのは？
  • どんなフィードバック方法が有る？

日本語版ベータプログラムの異議

実施の有無
  • 市場規模に沿って、日本語版が無い場合がある
  • 日本語版のプログラムが有る場合は常に英語版と連動
  • 実施希望と評価フィードバックが有れば実現のための働きかけも可能
日本語版が優先される理由
  • 市場が評価されている
  • 2バイト圏唯一のベータプログラム
  • ローカルアプリケーションがある
日本語版の体制について
  • 日本に Windows Div が存在することで、US開発チームへ積極的にアプローチできる

現在のフィードバックフレームワーク

製品開発チーム主催
  • Technical Beta Program（クローズド）
    • 開発チームにダイレクトにレポート
TechNet/MSDN主催
  • TechNet Plus/MSDN会員向けCTPプログラム（オープン）
    • 主に情報収集が目的
マーケティング主催
  • Customer Preview Program（オープン）
    • 主に情報発信とReadiness（準備）を高めることが目的

Technical Beta Program とは

目的
  • 製品品質の向上のため、フィードバックを収集し、反映させた後製品出荷するのが目的
開発部隊が主体となって実施
  • 日本の開発チームによる日本語での対応
    • 原則としてベストエフォートな対応
メリット
  • 最新の情報を入手できる
  • 計画的に参加し、評価期間を確保することが可能

製品開発サイクルと評価のポイント

英語版のベータでも他言語に対応
  • 英語でも機能は共通
  • 日本語環境での動作・テスト可能
各リリースの段階でbug barが設定される
  • 遅れるほど重要問題しか守成されない
  • 修正されなかった問題は技術情報/リリースノート/回避策を提供、そのご修正モジュールとして公開

次のIEの評価は・・・

現在プラン中
  • 今までのフィードバックの確認
  • ベータの前にXHTML/CSSなどWeb標準に対する日本からのフィードバックEscalation Pathの確保
  • ベータセミナー（新機能のレビュー）
  • Technical Beta Programで！

今後の取り組みについて

日本の市場に合った製品は、日本の市場に合った効果的なフィードバックフレームワークから
マイクロソフトからの提案と質問

まとめ

  • 日本にはWindows開発統括部がある
  • フィードバックは開発主催のTechnical Beta Programで
  • IEに対する要望は早期フィードバックプログラムを通じてbetaまでに
  • BugはTechBetaを通じてRCまでに
  • もっとデベロッパ/デザイナのと意見交換できる場を設ける

memo

  • IE7はVistaではユーザ権限が低く、アプリケーションの操作をするのにadmin権限にしなければならない

セッション8「パネル・ディスカッション：ブラウザはどこに向かうのか？」

event report webstandards cssnite

注意：聞いて書いてるので、内容の信憑性は保証しません。

Web標準とは？

firefox
  • 各ブラウザベンダが実装すること
  • 仕様自体がオープンなこと
    • W3Cの仕様が準拠
ie
  • 準拠したい気持ちは有るが、互換性も優先したい
  • Web標準が基本になっているのは確か
  • 勧告仕様であっても必ず準拠する必要が有るとは思えないが、要望が有ればやる
opera
  • web標準と言う言葉は、いくつかは原型かされていて定義されている
  • 既存技術を正確に準拠するのは必要
  • 企業技術を準拠することもある

最新版でのサポート状況

firefox
  • Firefox
    • geckoエンジンのリデザインにより、CSSのサポート向上
    • URIの折り返しもサポート
    • ボーダーのバグも修正
    • IMEモードを搭載（ieの独自拡張）
ie
  • IE7からW3C準拠と明言
  • 今後のバージョンにて対応していく予定
opera
  • バグはある。だがCSS,SVG,JavaScript,DOMはすばらしい
  • 仕様書以外にある技術をレンダリングするのが最大の問題で難しい
  • 製品化した時に、問題が発生した時にW3Cにあげて、それを標準化する動きを持つ

今後のサポート計画

firefox
  • 準拠度を高めていく
  • 新しい仕様に対応するのか、既存のバグを修正するのか
  • パフォーマンスに影響なければ新しい仕様は来るものは拒まず
ie
  • 修正や仕様変更はUpdateと言う形で行っている
  • 日本向けにフィードバックプログラムを構築する予定
opera
  • すでにHTML5の先攻実装はあるのか？
    • 時々のトレンドがあるので、簡単には勧告されない
    • テストビルドの時点でHTML5をする予定

microformatsについてどう考えているか

firefox
  • firefox3でサポートする予定(プライオリティ2)
  • コミニュティ内ではする方向であるが、優先順位はかなり高い方ではない
  • UI側の問題や、実際に製品としてサポートするか未定
ie
  • 現段階で言えることはない
  • しかし、全く無視しているわけではない
opera
  • 今のところ言えない
    • IEのようにオープンにできないｗ
  • userJS,userCSS,wighitでできるのではないか
  • 人間が第一で機械処理が第二、それが押し進むと危険では？
  • 人間の考え方と機械処理の考え方が違うので、デザイン面で問題があるのでは？
  • 子供が使えるような言語を使えば機械処理が可能だが、大人が使う言語で利用すると機械処理が難しい

ベンダー間の協力関係

firefox
  • オープンソースであるため、開発を止めることができない
  • ベンダー同士の協力に関してはWHATS内でかなり協力している
  • 共通のテストケースを作るのはAcid2の二の舞ではないか
    • 明確なテストレベルを決めるのはどうか
ie
  • 次期IEでブラウザベンダと協力していくかどうかは未定
  • 要望があれば。。
opera
  • HTML4に間違いが合ったので解決しなければならない
  • 後方互換も重要だが、これからの実装が重要
  • ブラウザベンダー同士で全てを共有し合うことはあり得ない
  • とは言え、スタンダードは必要で、テストやバグを共有していく
  • 今後のHTML6なり7なりを作っていくべき

ユーザとの対話/共同

firefox
  • mozillaは全てオープン。秘密が無い
  • firefox2の23%がボランティアから
  • 今後も可能な限りオープンで行く
ie
  • MSはデベロッパとのコミュニケーションによって大きくなっていった
  • webクリエイタ・デザイナとのコミュニケーションを行っていなかった
  • 今後webに対して要望に応じるようする
opera
  • 新機能追加時に使われ方を調査

基本的機能の進化

firefox
  • オフライン機能を開発中
  • キャンバス周りはがんばる
  • JavaScriptの強化
  • CSS3も対応する方向で進んでいる
  • audio,videoのオープンコーデック策定を考えている
ie
  • UIの強化を予定
    • インテリジェントな機能を追加していきたい
opera
  • pc,mobile,ds,wii,athor...
    • それぞれを同期するシステムを構築

The Open Web

firefox
  • 90年代のブラウザ戦争を二度と起こさないのが目的
ie
  • 標準技術を作っていきたい
  • 独自のコミュニティがある
  • 互換性を踏まえながら新しい挑戦を行う
opera
  • openな技術を...？？？
  • たくさんのプラットフォームで動いている
  • 一つのWebのために働いている
  • その品質のためにある