Web標準Blogでは、Web標準の利用に興味のあるWebサイト管理者、Webデザイナーの方向けに、Web標準を利用するための手法やノウハウ、参考になるリソース等を、国内外を問わずご紹介します。
なお当Blogでは、Web標準に関する疑問や質問を募集しています。Webコンテンツ実装プロセスにまつわるお悩みでも結構ですので、お気軽に電子メールでstandards@mitsue.co.jp宛にお送りください。
2007年08月31日
HTML 5の先に見えるもの
フロントエンド・エンジニア 矢倉
HTML 5に関して、ご質問をいただきました。
XHTML2.0があまりにも急進的すぎるといった理由からHTML5の開発が始まったと自分的に認識しているのですが、ということは、HTML5が開発されXHTML2.0への架け橋としての機能を果たすことができたら、そこで開発は終わりですか？それとも、今後HTML6、HTML7へと独自に進化していくのでしょうか？
HTML 5とXHTML 2.0はそれぞれ別のワーキンググループが、異なる目的を持ち策定しています。フォーカスの異なるふたつの仕様が「HTML 5からXHTML 2.0へ」と動くかどうかは、疑問に思っています。
また、HTML 5が勧告後も独自に発展していくのかですが、スケジュールとして決まっているわけではありません。現在のHTMLワーキングループはHTML 5の策定という目的のためだけに組織されています。
しかしながら、HTML 5は現在のHTMLに関わる問題を解決するために開発されている仕様です。HTML 5以降、また何らかの問題が発生し対処する必要が認められれば、HTML 6、7へと改版が進むかもしれません。
私たちの関わり方が変化するに伴い、Webも変化していきます。HTMLの将来像も同じように、私たちがどうWebを作りたいと考えるかにより、変わってゆくのではないでしょうか。
恒久リンク | コメント [0件] | 関連情報（トラックバック） [0件]
2007年08月29日
全称セレクタを用いたスタイルの正規化
フロントエンド・エンジニア 木達
スタイルの正規化にまつわるご質問をいただきました。
アスタリスクで全要素のマージンをゼロにするようなリセットの仕方は海外では行われず、使用する要素だけにマージンをゼロを指定していくという仕方が最近の流れだとセミナーで聴きました。
そのほうがブラウザに対する負荷も少ないので・・・ということなのですが、一体どの程度の負荷なんでしょうか？体感的に重いなと感じる程度なんでしょうか？
ブラウザが読み込んだら固まってしまう状態を100としたらどの程度なんでしょうか？
ページ全体をdiv要素で囲んで、その中の全要素（div * { margin: 0; }）と指定したら、その中で使ってる要素だけなので、あまり気にすることではないような気がします。
まず補足しておきますと、個々のブラウザが適用するデフォルトスタイルシートによって生じる差異をあらかじめ解消するため、制作者スタイルシート側で要素のマージンやパディングなどを正規化する際の方法についてのご質問です。
その正規化において、全称セレクタを使う場合と使わない場合とでは、レンダリング上の負荷がどの程度違うかを、あいにく私は知りません。独自に検証することも不可能ではないでしょうが（どのようなテストであれば負荷の差を客観的に計測可能かを慎重に検討する必要はあるにせよ）、まずは説明をされたセミナー講師の方に、事実関係をご確認いただいいたほうがよろしいかと思います。
ただし、最近の流れと言えるかどうかはわかりませんが、CSSに関する多くの著作や講演で知られるEric Meyer氏の以下の一連のBlog記事に端を発し、正規化に全称セレクタを用いない方式への理解が浸透したことは承知しています。
- Eric's Archived Thoughts: Reset Styles
- Eric's Archived Thoughts: Reworked Reset
- Eric's Archived Thoughts: Reset Reasoning
- Eric's Archived Thoughts: Reset Reloaded
- Eric's Archived Thoughts: Formal Weirdness
特に最後にご紹介した「Formal Weirdness」のなかで、彼が全称セレクタを用いない理由として挙げているのは負荷云々ではなく、正規化の影響がフォームコントロールに属する要素にまで及ぶのを避けるため、としています。ただし、誤解のないよう念を押しておきますと、彼は全称セレクタの使用を避けるよう呼びかけているわけではなく、単にそうした考え方を彼は採用しており、それに賛同したり追随する人もいるということです。
恒久リンク | コメント [0件] | 関連情報（トラックバック） [2件]
2007年08月29日
聴覚スタイルシートの作成
フロントエンド・エンジニア 木達
聴覚スタイルシートの作成について、ご質問をいただきました。
現在のブラウザではstressやrichnessなどの聴覚スタイルシートはほとんど対応してないのですが、これらがブラウザに実装され、音声的にもリッチなコンテンツを提供できるようになるのはいつ頃でしょうか？
また、そのとき、それらのプロパティを指定をするのはウェブデザイナーの仕事になるのでしょうか？
聴覚スタイルシートとは、音声読み上げ環境を介してWebコンテンツを利用するユーザーなどに対し、音声表現のスタイル付けを行うもので、音量や読み上げ速度といった特性を指定できます。現在、勧告候補となっているCSS 2.1のほか、CSS3ではCSS3 Speech Moduleとして仕様策定が進められています。
最初のご質問についてですが、残念ながら明確な時期は私にも見当がつきません。どのプロパティをいつ実装するかは個々のブラウザベンダーによってまちまちでしょうし、また特定のブラウザがstress（アクセントの強さを指定）やrichness（声の豊かさを指定）といったプロパティに対応したところで、即時的にそれを利用するかどうかは、個々のサイトにおける運用方針次第、費用対効果の考え方次第であり、一概には言えません。
しかしながら、ご質問にあるstressやrichnessには対応していないものの、先進的なブラウザであるOpera 9はCSS3 Speech Moduleに対応しているそうです。従い、多少限定的なかたちにはなるでしょうが、音声的にリッチなコンテンツを提供することは、既に今現在でも可能と思われます。詳しくは、Opera 9 でサポートされるウェブ仕様 - CSSをご参照ください。
二番目のご質問につきましては、Webデザイナーという肩書き、職種の定義次第であると思います。現状、同じWebデザイナーと呼ばれる人であっても、その業務内容は多種多様ではないでしょうか。仮に対応メディアの別を問わず、スタイルシートの作成をWebデザイナーの仕事として定義するならば、音声表現の専門知識が前提になるにせよ、聴覚スタイルシートの作成もWebデザイナーが担うことになるでしょう。
恒久リンク | コメント [0件] | 関連情報（トラックバック） [1件]
2007年08月24日
HTML 5の設計指針
フロントエンド・エンジニア 矢倉
HTMLワーキンググループは現在HTML 5の設計指針について、そのレビュー及び変更を行っています。設計指針はHTML 5の策定において非常に重要な文書です。
HTMLの改訂にあたり、多くの提案がワーキンググループに寄せられています。しかし、それらの提案をすべて受け入れることは、作成者にとっても実装者にとっても良いことではありません。実装者はすべての提案を実装しなければならず、作成者は各機能を理解し、適切に使うことが求められるからです。
仕様の策定にきちんとした理由をもち、芯の通った仕様書を書くためには、「どのような観点からHTMLを設計するのか」という決まりごとがなければなりません。
「HTML Design Principles」と題されたこの文書は、互換性や有用性という観点からHTML 5の設計指針をまとめています。先日紹介した「Degrade Gracefully」という互換性に対する条項も、指針のひとつに入っています。
公開時期ですが、早ければ9月の半ばあたりとなりそうです。他の仕様書と同じく、公開後できるだけ早く、日本語に訳したものをこちらで紹介したいと考えています。
恒久リンク | コメント [0件] | 関連情報（トラックバック） [0件]
2007年08月24日
iPhone版「善玉、悪玉、卑劣漢（The good, the bad, and the ugly）」
フロントエンド・エンジニア 木達
2007年8月22日
Aaron Gustafson著
（この記事はWeb Standards Project（WaSP）における投稿記事「The good, the bad, and the ugly - iPhone edition」を翻訳したものです。当Blogは翻訳の正確性を保証いたしませんので、必要に応じ原文を参照ください。なお、「The good, the bad, and the ugly」というのは有名な西部劇の映画のタイトルで、日本では「続・夕陽のガンマン」として公開されました。）
iPhoneはWebに多大なる影響を与えています。それを賞賛する人ばかりでなく、悪口を言う人もまた、情熱的なメッセージを寄せています。iPhoneはWeb標準にとってどのような存在でしょうか？モバイルWebに対してはどうでしょう？そして私たちは（いかにして）iPhoneのためのデザインをすべきでしょうか？
iPhoneは約2ヶ月前に発売されて以来、モバイル市場のみならずWebにおいても、少なからず秩序を乱す存在であることが明らかになりました。新たな市場での足がかりを求めて群がるWebデザイナーや開発者らによって問題点が明るみとなり、（多くのケースでは）ちょっとした口論に発展しています。
数日前、Scott Gilbertsonは「iPhoneはInternet Explorer 4の二の舞だ」と述べました。ただiPhoneのためだけに開発され、他と切り離された数多くのWebサイトやアプリケーションを（ちょうどそれをIE4が登場した時期と重ね合わせて）彼は暗示しています。これにJoe Hewittは素早く反応、iPhoneはWebに必要とされる革新をもたらすと述べ、IE4に喩えられるのはそう悪いことではない、と語りました。
私たちは一体どういう状況に置かれているのでしょう？私には確信こそありませんが、いくつか思うところを取りまとめたかったし、皆さんがどう考えているかを知りたいと思いました。
恒久リンク | コメント [0件] | 関連情報（トラックバック） [0件]
2007年08月17日
AmazonがCSSのカスタマイズを許可
フロントエンド・エンジニア 木達
2007年8月16日
Aaron Gustafson著
（この記事はWeb Standards Project（WaSP）における投稿記事「Amazon allowing CSS customization」を翻訳したものです。当Blogは翻訳の正確性を保証いたしませんので、必要に応じ原文を参照ください。）
たいへん興味深い動きですが、AmazonがaStoresでCSSをカスタマイズできるようにしています。
今朝Amazonは、aStore（Amazonのアソシエイトプログラムに参加している人が用いる販売ツールのひとつ）で見た目の完全なカスタマイズをCSSで行えるようにすることを発表しました。目下、インタフェース上オリジナルCSSのボリュームは約8000文字に制限されているものの、その制御可能なレベルは製品紹介から検索結果に至るまで、複数の種類のページに及びます。そのうえ、ユーザーはカスタマイズされた「テーマ」を他の人と共有することもできます。
もちろん、aStoreのマークアップには残念に思う点が少なからずあります。div要素とtable要素の奇妙なミックスからでは、意味上の価値は少ししか生まれません。また、そのマークアップは文法上妥当なものではありませんが、エラーは決して解消が困難なものではありません。DOCTYPE宣言が無いとか、アンパサンドがエンコードされていない、といったことですから（でも、もしあなたがaStoreをカスタマイズしようと思ったなら、DOCTYPE宣言が無いために後方互換モードで表示される点にご注意ください）。
実装状の問題点はさておき、ここで注目すべきなのは、Amazonのようなメジャーな会社がページの見た目のコントロールを部分的にでもユーザーに委ね、かつその目的において一連のカラーやフォントのピッカー（それらは今なお利用できますが）のほかにCSSを使っている、ということです。
あなたはこれをどう思いますか？より多くのページで、このようなカスタマイズができるようになって欲しいですか？それらのページの何が正しく、また何が間違っているでしょう？どうすれば改善できるでしょうか？個人的には、マークアップをカスタマイズできるようになり（microformatsの導入なんてどうでしょう？）、そしてデフォルトのスタイルシートを使わないようにできればと思います。あなたはいかがですか？
恒久リンク | コメント [0件] | 関連情報（トラックバック） [0件]
2007年08月16日
Webにおけるルビのサポート
フロントエンド・エンジニア 矢倉
WHATWG Blogに「(X)HTML 5 will have the only usable implementation of ruby markup」という、HTML 5におけるruby要素のサポートに関する記事が掲載されています（日本語の翻訳もすでに行われています）。
これまでruby要素はXHTMLのモジュールとして定義され、XHTML 1.1で利用可能となっていました。しかし、XHTMLのMIMEタイプをInternet Explorerがサポートしていないこともあり、ルビをWebで使える状況ではありませんでした（皮肉にも、ruby要素はIEの独自実装をベースに企画化された経緯があります）。HTML 5にruby要素を取り込むことにより、text/htmlであるXHTMLやHTMLでもルビの表示が可能となるのです。
しかしながら、ルビをふりがなとして「表示」できるようになるかは別の問題です。要素の表示にはCSSが関わってきます。要素の定義のみでは完全なルビのサポートと言い難いでしょう。
ただ、ルビの表示を制御するためのCSS3 Ruby ModuleというCSSモジュールがあり、すでに勧告候補となっています。うまくゆけばHTML 5が実装されるなかでこのモジュールのサポートも考えられ、ルビの表示がHTML 5の勧告時には行える状況になっているかもしれません。
恒久リンク | コメント [0件] | 関連情報（トラックバック） [0件]
2007年08月10日
品質を高めるためのHTML検証チェック
フロントエンド・エンジニア 矢倉
W3CのConformance ManagerであるKarl Dubost氏が、W3C Q&A Weblogにて「The craft of HTML」という、HTMLの品質管理に関する記事を公開しています。
「HTMLは工芸品のようなもので、精巧な技術が作者に要求される。」という内容の導入部分はとても興味深いです。ただ、その品質についてはHTMLが広く普及していることもあり、文書により異なるとも書かれています。
Webサイトの品質を向上させるためにはHTML文書を検証し、問題を修正することが必要となります。W3CはMarkup Validation Serviceという検証サービスを提供し、作成者がページの文法エラーを即座に発見できるよう、その手助けを行っています。
さて、検証はいつ・どのような目的で行うべきなのでしょうか。
Karl氏は「検証は目的ではなく手段である (HTML validation is not a goal. HTML validation is a means.
)。」と述べ、Webサイトの作成中にも検証チェックをするよう薦めています。Validであることをひとつの目標や到達点にするのではなく、品質の保証を続けていくことが大事という考えは、すこし見落としがちなものであるように思います。
恒久リンク | コメント [0件] | 関連情報（トラックバック） [0件]
2007年08月08日
アクセシブルなFlashにとっての障害
フロントエンド・エンジニア 木達
2007年8月6日
Drew McLellan著
（この記事はWeb Standards Project（WaSP）における投稿記事「Obstacles to Accessible Flash」を翻訳したものです。当Blogは翻訳の正確性を保証いたしませんので、必要に応じ原文を参照ください。）
AdobeのFlashは、Web標準コミュニティからしばしば非難の的になりますが、しかし実際にはそれが最も理にかなった選択であることも多々あります。複数のアプリケーションにとって最高の技術が常にそうであるのと同様、Flash Playerもまた一般的なデスクトップブラウザにとってほとんど普遍的な存在となっています。ではなぜ2007年にもなって、私たちはまだFlashコンテンツをアクセシブルにするうえでの障害を目にするのでしょう？
アクセシビリティとFlashの専門家・Niqui Merretは、Flashにおけるアクセシビリティの問題点リストを取りまとめました。彼女は業務を通じて目にした現状の問題点を詳述しており、リストへのコメントや提案、個々の項目への対処法を募集しています。
リストのなかでも特に興味深いのは、ブラウザベンダーにしか対処しようのない項目です。Niquiは次のように書いています。
FlashとHTML要素のあいだをタブで移動できません：これはFirefoxやSafari、Operaといったプラグインを利用するブラウザで起こります。Internet Explorerでは起こりません。これはブラウザベンダーが解決する必要があります。
MozillaやApple、OperaがMicrosoftの後を追って、この基本的なユーザビリティ問題に取り組んでくれたなら、せめて私たちに技術上のいかなる制約がタブ移動を阻んでいるのか教えてくれたなら、それは素晴らしいことでしょう。私たちは言葉を交わし学ぶほどに、理解を深めてこれらの問題を解決することができます。時は2007年、私たちはこうした基本的な問題に真摯に取り組み始めたといえるでしょう。
恒久リンク | コメント [0件] | 関連情報（トラックバック） [0件]
2007年08月08日
Business Week掲載記事「Jeffrey Zeldman: King of Web Standards」
フロントエンド・エンジニア 木達
2007年8月7日
Andy Clarke著
（この記事はWeb Standards Project（WaSP）における投稿記事「Business Week: Jeffrey Zeldman: King of Web Standards」を翻訳したものです。当Blogは翻訳の正確性を保証いたしませんので、必要に応じ原文を参照ください。）
今週、Business WeekはWaSPの共同設立者であるJeffrey Zeldmanについて特集記事を掲載しました。
Web標準ベースのデザインの先駆者として、彼はブラウザ戦争を終結させ、またWebサイトをすべての人が利用できるようにする手助けをしました。
今週、Business WeekはJeffrey Zeldmanについて特集記事を掲載しました。記事の著者であるJessie Scanlonが「今日では大抵のサイトが標準に準拠している」と書いている点は疑わしく感じていますが、Web標準やベストプラクティスが幅広くビジネスパーソンに周知されるのは、素晴らしいことです。
Jeffrey Zeldmanが初めて彼のサイトを立ち上げた1995年当時、Webがどのような状態であったかを思い起こすことは難しいものです。しかしその頃、WWWがWild West Web（荒涼とした西部のようなWeb）の略語でもあったとは言えるでしょう。つまり、ルールもベストプラクティスも無かったのです。
個人的には、Web標準やアクセシビリティ、ベストプラクティスの普及活動や教育は、今後も良い意味で末永く続けられることだろうと思います。
Jeffrey Zeldman: King of Web Standards（Jeffrey Zeldman：Web標準の王様）
恒久リンク | コメント [0件] | 関連情報（トラックバック） [0件]
