Web標準Blogでは、Web標準の利用に興味のあるWebサイト管理者、Webデザイナーの方向けに、Web標準を利用するための手法やノウハウ、参考になるリソース等を、国内外を問わずご紹介します。
なお当Blogでは、Web標準に関する疑問や質問を募集しています。Webコンテンツ実装プロセスにまつわるお悩みでも結構ですので、お気軽に電子メールでstandards@mitsue.co.jp宛にお送りください。
2008年01月23日
HTML 5の草案が公開
フロントエンド・エンジニア 矢倉
HTMLワーキンググループより、HTML 5の最初の草案が公開されました。あわせて、HTML 4（XHTML 1.0）との変更点を簡単にまとめた解説文書も公開されています。
HTML 5は、ユーザーエージェント間の相互運用性を高め、またユーザーにとって便利である機能を追加した、WebサイトやWebアプリケーションを構築するための新しい仕様です。これまでのHTMLやXHTMLとは異なり、要素や属性の定義だけではなく、それらにアクセスするためのDOMインターフェースや、オフラインストレージ機能などが盛り込まれています。
名前はHTMLとなっていますが、HTML 5にはXMLによる構文も定義されています。このためHTML 5は、HTML 4.01やXHTML 1.0の後継仕様ととらえることができるでしょう。あわせて公開されたHTML 5 differences from HTML4という文書では、どのような変更や機能の追加が行われているのかを確認することができます。今回、この文書の日本語訳を用意しました。
HTML 5は2010年9月の勧告を目指していますが、アプリケーションの実装状況により遅れる可能性が高いと考えています。しかしながら、W3Cの勧告は「仕様をすべて実装したアプリケーションが少なくとも2つあること」という条件を満たす必要があるため、仕様が勧告されてもしばらくの間は満足に利用できないといった状況は起こりづらいでしょう。
HTMLワーキンググループは、HTML 5について幅広いコメントを受け付けています。
恒久リンク | コメント [2件] | 関連情報（トラックバック） [1件]
2008年01月22日
IE8の新しい標準モードとモードスイッチ
フロントエンド・エンジニア 矢倉
先月、MicrosoftのIE Teamが発表したIE8がAcid2テストに合格するという話題は、大きな衝撃を与えました。
しかし発表からしばらくして、より標準準拠に近づいたレンダリングをIE8で行うには、DOCTYPEスイッチのようにHTML文書に何らかの「ヒント」を与える必要があるとの情報も流れていました（「IE8 passes Acid2」）。そして先ほど、その詳細とまた経緯が明らかになりました。
A List Apartの「Beyond DOCTYPE: Web Standards, Forward Compatibility, and IE8」という記事によると、新しい「ヒント」は次のようなものになると紹介されています。
- meta要素を記述し、対象としているIEのバージョンを指定する。
<meta http-equiv="X-UA-Compatible" content="IE=8" /> - サーバのHTTPヘッダから、対象とするバージョンを指定する。
X-UA-Compatible: IE=8
「このページはIE8と互換性がある」とHTML文書（またはHTTPヘッダ）側で指定することにより、そのページが「IE8の標準モード」でレンダリングされるようです。
さて、これまでDOCTYPE宣言による判別を行ってきたIEですが、なぜIE8からはこのような方法を取ったのでしょうか。これについて、IEプラットフォームアーキテクトであるChris Wilsonが、IEBlogに掲載した「Compatibility and IE8」という記事にて、互換性を確保するためと説明しています。
IE7ではCSSの属性セレクタやXML宣言への対応など、Web標準準拠においていくつかの向上が図られました。しかしIE8での変更は、その変更をさらに上回るものです。Acid2に関わる技術の実装はもちろん、hasLayoutの廃止など、レンダリングエンジンに根本的な変更を行っている部分もあります。
このため、DOCTYPEによる標準モードの切り替えをIE8でも行ってしまうと、今後Web標準準拠を考え作られたコンテンツが、IE8の標準モードで正確にレンダリングされるページなのか、IE7の標準モードなのか、はたまたIE6なのかということが分からなくなってしまいます。つまりは、標準モードの解釈にさらなる非互換が生じてしまうのです。
まず、当然のことながらIE8用の標準モードにあわせたページをIE7やIE6で見ると、表示が崩れてしまいます。それだけであればIE7やIE6に対し、別個に対処することで解決できます。しかしながら、IE6やIE7の標準モードにあわせたページが、IE8の標準モードで崩れずに表示できるかどうかは分からないのです。
たとえば、アンダースコアハックがあります。IE6の標準モードではアンダースコアハックを利用することができたため、IE6用の対策として広く使われていました。ところがIE7の標準モードではアンダースコアハックが利用できなくなったため、アンダースコアハックに依存した標準モードのページでレイアウトが崩れるなどの不具合が起こってしまったのです。
似たようなことがIE8でも起こるとの懸念があることから、「どの標準モード’をターゲットとしているか」を明示する必要があるのではないかと考えられているのです。IE6やIE7は今後数年も大きなシェアを持ち続けると予想されるため、標準準拠度の高いIE8と、そうではないIE6、IE7を同じDOCTYPEスイッチで区別するのは、互換性の確保という問題から現実的な解決策ではないのです。
少し長くなってしまったため、簡単にポイントをまとめます。
- IE8には、「互換モード」、「標準モード」、「より進んだIE8の標準モード」という、3つのレンダリングモードがある。
- 互換モードはIE6、IE7のものと一緒。標準モードはIE7のものと一緒。
- 互換性を保つため、IE8の標準モードにはmeta要素やHTTPヘッダによる指定が必要。
ブラウザの標準準拠度の違い生み出す互換性の問題は、準拠度の低いブラウザが使われ続ける限り、また、そのようなブラウザを対象としたコンテンツが減っていかない限り残り続けます。このような問題を解決するためにも、Web標準への準拠をいっそう推し進める必要があると考えています。
恒久リンク | コメント [3件] | 関連情報（トラックバック） [7件]
2008年01月18日
アクセスキーの改善とこれから
フロントエンド・エンジニア 矢倉
HTMLではリンクやフォームにaccesskey属性を設定して、キーボードショートカットを割り振ることができます。しかし、仕様上の制限や実装の違いなどの理由から、現在は効果的に利用できるものではありません。
HTML 4以降で定義されたaccesskey属性には、対象がリンクとフォームのみという制限が存在しています。昔のように静的なWebページのみであれば特に問題がありませんが、最近のWebアプリケーションのように多様なコントロールをもつものにとっては、この制限が厄介なものとなります。
これに対し、現在策定中のXHTML Access Moduleでは、新しくaccess要素というものを定義して問題の解決を図ろうとしています。
<access key="m"
title="Main content"
targetrole="main" />access要素のkey属性にアクセスキーを指定し、targetrole属性やtargetid属性で対称となる要素を設定します。アクセスキーの定義が要素として独立したことで、従来は規定されていなかった複数の要素にコントロールを指定する、コントロールにラベルをつけるなどの機能向上が行われています。
しかし、Access Moduleが改善できるのは仕様上の制限だけです。アクセスキーには、まだ他にいくつかの問題が存在しています。
ひとつは、指定したキーがブラウザやOSのショートカットとバッティングしてしまうことです。ページのアクセスキーと、アプリケーションのショートカットのどちらが優先されるのかはアプリケーションにより異なるため、ユーザーを混乱させることとなります。
もうひとつは、アクセスキーについての慣習が存在しないことです。
アクセスキーは製作者の意向が反映されるため、ショートカットキーの統一をはかることが難しいものです。例えば、あるサイトにおいてHキーは「Home」へのアクセスキーとして設定されていますが、別のサイトでは「History」、さらに別のサイトでは「HTML チュートリアル」として設定されていることがあります。このため、ユーザーはページごとにアクセスキーを学習する必要があり、結果として良いユーザー体験を生み出さないのです。
しかし、慣習については少しずつですが生まれてきているようです。例えば携帯電話用のWebサイトでは、次のページへ進むリンクに「6」、前のページに戻るリンクに「4」を指定する例が多く見られます。またWeb版のRSSリーダーでは、「j」が次の記事へ進む、「k」が前の記事に戻るショートカットとしてよく使われています。すべてのページで統一的なアクセスキーのしてはできなくとも、類似サービスや頻繁に用いるキーを統一することによで、ユーザビリティが全体的に向上するのです。
アクセスキーは、仕様、アプリケーション、Webページそれぞれが問題を持っています。向上への取り組みには、まだまだ時間がかかるでしょう。
恒久リンク | コメント [0件] | 関連情報（トラックバック） [0件]
2008年01月11日
target="_blank"は非推奨?
フロントエンド・エンジニア 矢倉
W3Cにおいて、
というご質問をいただきました。target="_blank"は非推奨なのでしょうか？
HTMLの仕様書では、center要素やfont要素などの文書内容を意味づけするものではなく、見栄えを表現する要素や属性が「非推奨 (deprecated)」と定義されています。しかしtarget="_blank"の場合は、この「非推奨」とはなっていません。ただし、HTML 4.0 やXHTML 1.0のStrict文書型では、target属性が定義されていないため利用できません。このためtarget属性を用いる場合は、Transitional文書型を選択する必要があります。
さて、target="_blank"があまり奨められないとされているのには、いくつかの理由が存在します。
ひとつは、リンクが新規ウインドウで開くと明示されていないページの存在です。ほとんどの場合において、新しいウインドウで開くリンクと、現在のウインドウで開くリンクはその表示において区別がなされていません。このため、ユーザーに適切なフィードバックがなされないという問題があります。
また、ユーザーに選択権が与えられないという問題もあります。リンクをどのように開くかという選択はユーザーに委ねるべきという考えがあるため、この観点において、target属性による指定はその選択権をユーザーから奪うことになります。
上記二つの問題は、ユーザーエージェントが対処することで改善できる問題でもあります。今日のタブブラウザには、新規ウインドウをタブで開くというものや、新規ウインドウを無効化するという設定項目を設けているものが増えてきています。
しかしながら、ブラウザごとに設定項目や挙動が異なるため、完全な解決とはいいがたいでしょう。
ユーザビリティに関わる問題もさることながら、ユーザー体験の違いがtarget="_blank"の是非が頻繁に問われる原因でもあります。
たとえば、「リンクをどのように開くかは、どんな場合であれユーザーに選択させるべき。」という意見もあれば、「サイト外へのリンクは新規ウインドウで開きたい。」というものもあります。また「PDFなど、HTML文書以外は新規ウインドウで開きたい。」という、細かな条件下での要求も存在しているようです。このような好みの違いを知ることも難しく、またすべての要求にこたえることはできないでしょう。
target="_blank"は、非推奨ではありません。しかし、想定するユーザーや、target="_blank"のもたらす効果を充分に考えた上で、利用するか否かを決定すべきです。
恒久リンク | コメント [0件] | 関連情報（トラックバック） [2件]
