サイト内検索

質問の回答 #3

この記事は、html5doctor に掲載されている記事「Your Questions Answered #3」を日本語訳したものです。

一部、直訳ではなく意訳した部分がございます。原文と表現が異なることがございますので、ご了承ください。この本日本語訳には、翻訳上の誤りがある可能性があります。したがって、内容について一切保証をするものではありません。正確さを求める場合には、必ず各記事の原文を参照してください。当方は、この文書によって利用者が被るいかなる損害の責任を負いません。もし誤りなどを見つけたら、当サイトのお問い合わせより連絡いただければ幸いです。

質問の回答 #3

(準)定番のHTML5 に関する読者の質問に答えるコーナーがやってきた。前置きは抜きにして、さっそく質問に行ってみよう。

タグを繰り返し使う

Daniel Davis の質問:

先生、

ちょっと確認したいことがあります。

nav 要素は、header や footer のように、ひとつのページに何回でも使えると思っても大丈夫でしょうか。たとえば、ページのトップにあるメニューを囲んだり、下のほうにある「次へ」や「前へ」ボタンを囲んだり。
そう考えると、html, head, body 以外のタグはどれも、何度使っても良いといっても構わないのでしょうか。
先生、よろしくお願いいたします。

膝の調子が悪いのでまた来ますね。

あなたが言うすべての要素をページで何回でも使うことができるというのは、正しい。この header の記事と footer の記事でも、それらはページに何回でも使うことができると言っている。さらに、html, head, body タグすら必要ない。すべてのブラウザーは、それらがあるものと想定してくれる。でも、それらを入れたままにしても問題ない。

— はっきりしたなら幸いだ。RichBruce より。

HTML5 + Javascript クライアント・ウェブ・アプリケーション

Girish の質問:

HTML5+ JavaScript を使って完全なクライアント・アプリケーション(チャット・クライアントや株価ティッカーとか)を、Firefox 3.5 エンジンベースのバンドルとして作れば、それをLinux のデスクトップ・アプリケーションとしてインストールして、firefox 3.5 エンジンを使う独自のウィンドウでそれを実行できるのでしょうか。そのアプリケーションは、ローカル・サーバーとやり取りしなくても、ローカル・ストレージに何でも保存できるのでしょうか。たとえば、URL とかユーザー名とかです。

ピュアな HTML5 + JavaScript ベースのクライアント・アプリケーションをパーッケージできれば、それをインストールしたり、スタートアップ・スクリプトから起動できるのですが。

もしくは、firefox 3.5 エンジンの代わりに、Mozilla Prism を使って、それをウェブ・アプリケーションに変換し、それをバンドルするって、できますか?

技術的にはできるはずだ。確かに、HTML5 offline applications API(マニフェスト経由)を使えば、クライアント・アプリケーションを作って、ウェブ接続しなくても、ローカルでそれを実行できる。

しかし、ブラウザーが問題だ。Prism はスタンドアロンのアプリケーションとしてこれをディプロイするのは良いと思うけれども、Prism が最新の Gecko エンジンを実行しているのか(また、JS エンジンを伴うのかどうか)について、私はわからない。たとえ、そうだとしても、Firefox 3.5 は、今のところ、オフライン・アプリケーションにかなり深刻なバグがある。つまり、まともに動かないんだ!

私は Mozilla のバグについて報告したので、対策が打たれているところだ(実際に、そのバグが修正されテストされているものと信じている)。

代わりに、Fluid(Webkit ベースのアプリケーション)を使う手もある。 – しかし、これは最新の Webkit にアップデートしないと使えない。そうしないと、offline applications API が使えないんだ。(Fluid のサイトをざっと見る限り、進行中のバージョンは最新の Webkit を使うようだ。)

スタートアップ・スクリプトからの起動について – あなたはこれをアーカイブできる。だが、独自のスキーム・ハンドラ(Firevox IIRC)だ:http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#custom-handlers

同様に、スタンドアロンのブラウザーを経由して使うことができる API が、Prism や Fluid 以外にもあるかもしれない。

— がんばってね。Remy より

MIME と DOCTYPE、どっちが優先されるのか

Pedro Estébanez の質問:

こんにちわ、先生。

このサイトは、ウェブ・ディベロッパにとって、とても役に立つますね。みなさんのご尽力に感謝します。

さて、質問があります:

Content-Type HTTP ヘッダに何をセットするかによって、HTML5 なのか XHTML5 なのかをブラウザーに伝えるという点に関して、熱い議論が交わされています。でも、その一方、私は DOCTYPE が本当はどんな役割を果たすのか分かっていません(quirks モードにならないようにすることや、バリデーションを除いて)。

たとえば、DOCTYPE で XHTML としてドキュメントを作り、サーバが text/html としてそれらを返したら、なぜ、ブラウザーでXML モードにならないのですか?

よろしくお願いいたします。

このサイトの Bruce の記事 HTML5, XML and XHTML5 と、Remy の記事 HTML5 Boilerplates を見たかい?

これ(Bruce の記事でリンクされている)も見てほしい。正しい mime タイプの使い方について参考になる。http://www.webstandards.org/learn/articles/askw3c/sep2003/

— ありがとう、Rich より

アウトライン・アルゴリズム

Mike Taylor の質問:

最新の HTML5 仕様のセクション 4.4.11.1 には、アウトライン・アルゴリズムは、ユーザやディベロッパにとって何の役に立つのかがはっきりと書かれていません。この件について、もっと分かりやすく書かれていればいいのにと思います!

このすごいブログに感謝

outliner を使えば、サイトの見出し構造を分かりやすく見せてくれる。アウトラインの見出し構造を見れば、見出しがアウトラインのどの位置に来ることになるのかが分かる。サイトやページのセクションのコードをパースしてみるといい(これで完全に解決するわけではないことは分かっている)。HTML5 Outliner もチェックして、作ったものを確認ほしい。

Bruce が section の記事で、これについて少し触れている。– “ほとんど例外なしに、自然に見出しを入れることができないようなら、section を使うべきではない。HTML 5 outliner tool で自分の作ったものをチェックしてほしい。もし、section に対応するところが "untitled section" になっていたら、たぶん、あなたの作ったものには間違いがある。(しかし、nav や aside 要素にタイトルがなくても問題はない)”

今後の記事でこれについて詳しく扱うつもりだ。でも、とりあえずは、これで参考になれば幸いだ。Rich より。

HTML5 と xmlns

Ad Taylor の質問:

ばかげた質問でなければよいのですが …

html5 DOCTYPE を使ったにもかかわらず、xhtml 構文をつかったら、html タグに xmlns を指定しなければいけないのですか(つまり、xmlns=”http://www.w3.org/1999/xhtml”)?

時間をとらせてすみませんが、よろしくお願いします。

ばかげた質問とは思わなかったよ。でも、答えは簡単だ:No だ!

— ありがとう。Bruce(HTML5 精神科医)より

策定中の仕様を使った開発

Sam Rayner 質問:

私は Super Friends Guide to HTML5 Hiccups を読んだのですが、ちょっと心配になりました。– http://www.zeldman.com/superfriends/guide/

最近、私は個人的なプロジェクトで HTML5 を使って開発しています。実践で学ぶのが一番と思うからです。この新しい仕様を実践に取り入れて、詳しくなりたいと思っています。
しかし、どうやら私は誤解していたようで、よく、footer のような新要素を、仕様のとおりではなく、Super Friends が言っている方法で使ってしまいました。

私は本当に個人の非営利のウェブ作品で HTML5 のベネフィットを楽しみ続けたいと思っています。しかし、将来的にすべてを見直し、仕様の変更を反映しなければならないリスクを背負っていると思うのです。

どうすれば良いと思いますか? HTML5 で進めて、古いプロジェクトも修正するべきですか? - 本当に面倒なことになりそうなんです。

HTML5 で進めて、見えないところの不整合は、そのままほっといても良いのでしょうか(コードはちょっと間違っているかもしれませんが、きれいにスタイルされています)。 – 私の性分にはまったく合わないのですが。

とりあえず、HTML4 に戻して、新要素の代わりに class 名を使ったほうが良いですか?

開発中の仕様を使って開発するのはリスクを伴うことは分かっているのですが、すべてが決まるまで待っていたら、今から何年も HTML4 を使い続けることになってしまいます!

何卒よろしくお願いいたします。

日々、仕様が変更されている点について、あなたが心配することは、よく分かる。追いついていくのは大変だ(HTML6 なんてのもあるが、もうたくさんだ。)。

footer について言えば、もう気づいていると思うが、そのコンテンツモデルは変更されて、header のように使うことができるようになった。

あなたの開発の取る道は、基本的に、今のところ、次の 3 つ、または、その組み合わせになると思う:

  1. HTML5 の新要素を使い続け、仕様が変更されたら、それに従う。
  2. HTML4 を使い、HTML5 を表すような class 名を使う(あなたの提案だ)。
  3. 簡単になった doctype と、将来的に役に立ちそうで、プログレッシブ・エンハンスメントになりそうな要素だけを使う(たとえば、time のようなインライン要素)。

開発プロジェクトで HTML5 を使うことができるようになるまで、しばらく時間がかかるだろうが、私の考えでは、個人的なプロジェクトなら、使わない理由なんてないと思う。ケース・バイ・ケースで判断する必要はあるが、あなたがどこで使ったとしても、ある程度は、古くなってしまうことはないだろう。

— ありがとう。Rich より。

HTML5 と Browser の互換性

多くの人がこの類の質問をしょっちゅう送ってくるので、ここに役に立ちそうなリンクを張っておく。

今回の質問コーナーはこれで終わりだ。近々また投稿するつもりだが、その間も、遠慮なく HTML5 についてドクターに聞いてくれ。