8/3付けで、XMLHttpRequest仕様が勧告候補として公開されました。
オブジェクトの実装状況は申し分ないでしょうから、テストスイートの作成と検証が終われば、とくに問題なく勧告に向かうのではないでしょうか。
8/19に、Web Performance WGの設立がアナウンスされました。
設立が検討されている旨は先々月の記事で紹介しましたが、このたび晴れてWGとして活動がスタートしました。
Charterによると、策定する仕様は次の3つです。
Navigation TimingとResource TimingはもともとWeb Timingというひとつの仕様で定義されていましたが、仕様と実装ともにNavigationTimingインターフェースの進みが早かったことから仕様の分割に至ったようです。
実装も始まっており、MicrosoftがIE9で、Chromeは6から機能が利用できるようです。Firefoxについては、該当のバグを読む限り、Firefox 4のfeature freezeに間に合うかどうかという状態のようです。
]]>7月13日付で、Mobile Web Best Practices WGより、Mobile Web Application Best Practicesの最終草案が公開されました。
MWBP WGはMobile Web Best Practicesを発表していますが、この文書は「モバイル端末でのWebブラウジング」を想定したものでした。
Mobile Web Application Best Practicesは「モバイル端末とWebアプリケーション開発」をそのスコープとしており、HTML5のAppCacheやWeb Storageの利用、HTTPリクエスト数を減らすことなどに言及しています。
7月27日付で、WebApps WGよりCORS (Cross-Origin Resource Sharing)の草案が公開されました。
7月27日付けで、CSS WGよりCSS Snapshot 2007の最終草案が公開されました。
HTMLのstyle属性などからCSSを利用する際の要件を定めるCSS Styling Attributes Level 1が1月に公開されたこともあり、それをスナップショットに組み込んだことが変更になります。
日本語訳を更新していますので、そちらもご覧ください。
7月27日付けで、CSS WGより新しいメディアクエリーの勧告候補が公開されました。
勧告候補の更新ということで、仕様に大きな変更は行われていません。今回の勧告候補の公開に合わせて、テストスイートのβ版も公開されています。
こちらも新しい仕様にあわせ、日本語訳を更新しています。
7月27日付で、WebFonts WGよりWOFF仕様の草案が公開されました。
昨年より編集者ドラフトとして存在しており、またW3C Member Submissionとして提出されてはいましたが、草案としての公開は初めてになります。
]]>Microdataの簡単な概要と書き方、そしてMicrodataに対応するGoogleのRich Snippetsに関して紹介しています。スライドも公開していますので、そちらもご覧ください。
なお、すべての書き方を網羅しているわけではなく、またDOM APIについても「仕様で定義されている」程度の言及しかしていません。
イベントのなかで、曖昧に答えてしまった質問がありましたので、改めて調べました。
質問は、「スライド中の例でitemscopeには属性値が書かれていないが、XMLで書くとしたら値はどうなるか。itemscope="itemscope"とすればよいのか。」といったものでした。
仕様のなかで、itemscopeは“boolean attribute”にカテゴライズされています。仕様書の定義を簡単にまとめると、次のようになります。
boolean="") もしくは属性名と同じ (boolean="boolean")。後者の場合、属性値は大文字小文字を区別しないが、値の前後に空白文字は認められない。"true" や "false" といった属性値は boolean 属性に認められない。偽を表す場合は、属性を記述してはならない。ですので、XHTML5でMicrodataを利用したい場合は、itemscope="" もしくは itemscope="itemscope" と記述することになります。
しかし、Geolocation WGやWeb Fonts WGなど、活動範囲を狭めたグループも存在します。現在設立が検討されているWeb Performance WGとWeb Notification WGは、スコープを絞って仕様を短期間の間で策定することを目指しているようです。
Web Performance WGは、Webアプリケーションの開発において重要なパフォーマンス計測のための仕様を作るWGです。Web Timingという編集者ドラフトの仕様がWebApps WGで提案されていますが、こちらを参考に仕様の策定が検討されています。
Web TimingはIE9でも試験的に実装されているようです。
構想段階ではありますが、映像や音声についてもパフォーマンスが問題になることから、グループとして何か活動することも視野に入れているようです。
Web Notification WGは、バルーンやGrowlなど、デスクトップに情報を通知するためのAPIを策定するグループです。Google Chromeの拡張として内部的に実装されたAPIがすでにWeb Notificationsとして編集者ドラフト段階にありますが、単純な通知APIに絞ることなどを含め、プラットフォーム非依存なAPIを策定していくことが検討されています。
どちらの活動についても、すでに専用のメーリングリストが設けられています。提案されている仕様はWebApps WGで議論が行われていましたが、それを独立したWGで集中して作業させたいという意図があるのでしょう。
ベンダーの動きも活発になっていますし、今後はこういった機能を絞った小さなグループでの策定が増えていくのかもしれません。
追記 (2010-08-20)：Web Performance WGは8月19日付けで立ち上げが発表されました。
Co-chairを務めるMicrosoftのJason Weberが、WGの立ち上げに関しエントリをIEBlogに公開しています。
]]>最近ではCSS3を使用したデザインパターンが数多く紹介されています。ボタン要素など簡単なものであれば、画像を用意する事なく表現が出来ると思います。
しかしソースレベルでは(-webkit-)(-moz-)などの接頭辞をつけないとブラウザがうまく処理を行えない現状としては、接頭辞がついたものを業務レベルで実装するべきではないのでしょうか？
※一般的に接頭辞を使用している要素などは納品データ内にあるべきでないのでしょうか？
使うべきでない、あるべきでないとは思いませんが、利用には細心の注意をはらう必要があるでしょう。
まず、CSS仕様には、ベンダー接頭辞の利用は避けるべき（Authors should avoid vendor-specific extensions
）と書かれています。仕様が安定して接頭辞を外す段階になったら、使い始めることができるという認識です。
しかし、仕様が安定してから実装に反映されるまで、さらに製品としてリリースされるまでには時間がかかります。たとえば、WebKitは接頭辞なしのborder-radiusを昨年7月に実装しましたが、そのコードが製品に反映されたのは今年1月のChrome 4が最初で、Safariにおいては6月のSafari 5までかかってしまいました。
とはいえ、border-radiusは昨年夏の段階で仕様も安定していました。接頭辞つきで実装されているものの安定しているプロパティもありますから、接頭辞つきプロパティを一概に「避けるべき」というのは実利的には思えません。
その機能が安定していると判断できれば、ベンダー接頭辞つきのプロパティを書くことに大きな問題はないと思っています。
ただし、この時大事なのが、接頭辞のない正式なプロパティも含めることです。「いまは機能しないから」と言った理由からか、接頭辞なしのプロパティを省いたWebページやサンプルに出くわすことがありますが、これにはいくつか問題があります。
まず、特定のエンジンでしか機能しないという問題があります。先日リリースされたOpera 10.60やIE9 Platform PreviewはCSS3 Backgrounds & Bordersの多くのプロパティに対応していますが、それらは接頭辞のない正式なプロパティとして実装されています。
ところが、ページのソースコードに-webkit-border-radiusや-moz-border-radiusだけしか書かれていないサンプルが意外に多いのです。これでは同等の機能を備えているにも関わらず、OperaとIE9ではその恩恵にあずかれません。
もうひとつの問題は、正式なプロパティを実装したあと、接頭辞つきプロパティのサポートが行われなくなることです。
プロパティが標準化されていれば、将来的に接頭辞は省かれた状態で実装されます。このとき、ベンダーによっては接頭辞付きのプロパティを引き続きサポートするか、それとも打ち切るかという選択ができます。
たとえば、WebKitは先程のborder-radiusをはじめ、多くのプロパティで -webkit-のつくプロパティも引き続きサポートしています。Microsoftも後方互換を非常に重視していますから、-ms-のついたプロパティを今後もサポートする可能性は非常に高いと思われます。
いっぽう、Mozillaは接頭辞つきのプロパティについて、早くからサポートを打ち切ることを考えているようです。background-originの接頭辞を外すバグの中で、開発者のDavid Baronが「製作者が接頭辞つきのプロパティを利用するのであれば、次のように接頭辞なしのプロパティも書いているはずだという立場をとっている。Web上にあるGecko固有の内容は最小化したい。」と語っています。
すべての接頭辞つきプロパティに対し同様の対応を行えるかは難しいところでしょう。たとえば、border-radiusのサブプロパティに、ひとつの角を丸めるプロパティ (-moz-border-top-right-radius など) がありますが、標準化の過程でプロパティ名や構文が変更されてしまいました。Geckoは古い構文のプロパティ (-moz-border-radius-topright) のみを以前から実装しているので、接頭辞を外すにせよ -moz-opacity のようにある程度の期間を設けてる対応を行うかもしれません。
接頭辞つきプロパティがサポートされ続けたとしても、接頭辞への依存は避けるべきです。接頭辞つきのプロパティを利用するのであれば、対応する正式なプロパティもあわせて記述すべきというのが基本的な見解です。
では、プロパティの安定度合いははどうやって判断すればよいのでしょうか。
ひとつ参考になるのが、仕様書のステータスです。接頭辞は仕様が勧告候補（仕様が固まり、実装を呼びかける段階）になった際に省くとされていますから、近々で勧告候補になっている仕様であれば、機能が安定しているとおおむね考えてよいでしょう。
また、CSS WGでもベンダー接頭辞を省くタイミングについてベンダーと連携し、プロパティごとの安定度を仕様書に盛り込むことなどを検討しているようです。そうなると、安定度合いを知るとても良いソースになります。
使うことを考えるには、仕様だけでなく実装状況についても知る必要があります。以下は各ベンダーの出している情報になります。
すこし厄介なのが、仕様が初期の段階で安定していないにもかかわらず、試験実装のあるプロパティです。ベンダー固有の拡張を標準化する際に良く起こりますが、CSS Image Valuesで定義される予定の画像グラデーションやCSS Animationsなどが当てはまるでしょうか。
このような仕様については、値だけでなくプロパティ名に変更が起こる可能性があります。ですから、接頭辞なしのプロパティを書くかどうかは難しいところです。しかし、実装も多くありませんから、接頭辞なしがどうこうというよりは、その機能に依存しないコンテンツ作りを心がることをまず考えましょう。
長くなりましたが、まとめると
3番目については、情報を集めるのがまだまだ難しいというのが現状だと思います。これについては、情報をまとめる場所が必要だと考えています。
]]>CSS WGより、CSS3 Backgrounds & Bordersの最終草案が6月12日付で公開されました。
透過した画像を持つborder-imageとの兼ね合いについて検討する必要があったことから外されていたbox-shadowがふたたび追加されました（透過画像についての言及は省かれ、単純にボックスに影を落とす機能に限定されました）。
他にもいくつかの変更が行われ、仕様が最終草案に差し戻されました。次の公開時には、再び勧告候補になっているものと思われます。
SVG WGより、6月22日付でSVG 1.1 Second Editionの最終草案が公開されました。
先週の投稿ですでにお伝えしましたが、HTML5と関連仕様が6月24日付で更新されました。
W3C Blogに、CSS WGのco-chairであるDaniel GlazmanがCSS 2.1の現状について記事を投稿しています。
現場について、要点がいくつか書かれています。大まかに訳すと次のようになります。
8月にはF2Fミーティングがあるようなので、そこで大きな課題が解決されれば、CSS 2.1とセレクタ仕様の勧告がより具体的に見えてくるでしょう。
]]>これまで公開されていた草案については、HTML5仕様の更新に基づくアップデートが主な変更点になります。HTML5 differences from HTML4のchangelogから、気になったものを抜き出してみました。
title要素の指定が任意とされたwbr要素が追加されたmeta要素のname属性の値にkeywordsが追加されたHTML+RDFaは、先日公開されたRDFa Core 1.1に準じたものとなりました。HTML 4.01にRDFaの属性を組み込んだDTDも検証目的として用意されています。
新しく公開されたHTML5: Techniques for providing useful text alternativesでは、さまざまな条件のもと適切な代替テキストを与えるための指針や要件を記載しています。将来的にはHTML5の代替テキストに関するセクションを置き換える目的で作業が進められています。
もうひとつのPolyglot Markup: HTML-Compatible XHTML Documentsは、先日「HTML/XHTML Compatibility Authoring Guidelines」で触れた互換性ガイドラインになります。名称が変更されましたが、文書の目的は変わっていません。
HTML5や関連仕様が実際に使われることが増えてきました。ですから、制作者・開発者向けのドキュメントへのニーズが高まってくるでしょう。現在はリファレンスとして使う文書が多いですが、今後はalt-techniquesのように考え方を伝える文書が重要になってくるのではないでしょうか。WGの成果物としても、リファレンス型でない文書の方がより望ましいのではないかと感じています。
いつもの変更点の更新と、Polyglotマークアップの訳を公開しました。
]]>:visited疑似クラスに関する挙動の変更が適用されたことがわかりました。
以前このBlogで取り上げたときには、「同じ対策がWebKitでも行われている」段階でしたが、その後コードがチェックインされ、Safari 5で反映されたようです。
同じWebKitを利用するChromeですが、先日安定版となったChrome 5ではこの変更は反映されていません。しかし、開発版であるChrome 6では反映されていることから、挙動が変更されることは確実とみてよいでしょう。
というわけで、今回はいま一度、どのような影響があるのかを確認してみましょう。
:visitedでも指定が適用されるプロパティは、color, background-color, border-*-color, outline-color, column-rule-color といった色関連のプロパティに限定されます。borderなど色指定を含むショートハンドプロパティの場合は、色のみが適用されるようになります。
その他のプロパティは適用されませんので、text-decorationやborder-style, background-imageなどを:visitedに利用している場合、今後はそのスタイルが適用されなくなります（:linkと同じスタイルになります）。
また、rgba(), hsla(), opacityについては、不透明度の指定が:linkの不透明度になります。
ですから、次のように異なる不透明度が状態によって指定されているとします。
:link { color: rgba(0, 0, 255, .8) }
:visited { color: rgba(255, 0, 255, .3) }
これは次のコードを指定したものと同じ効果になるでしょう。
:link { color: rgba(0, 0, 255, .8) }
:visited { color: rgba(255, 0, 255, .8) }
:visitedにtransparentもしくは不透明度が0 (例: rgba(r, g, b, 0)) をもつ値が指定された場合、RGBの指定も無視されて:linkと同じ色になるようです（とはいえ、こういった指定をするケースはほとんどないと思います）。
不透明度をリンクに指定するケースが多いとはあまり思えませんが、お気をつけください。
さて、もともとの問題となっている、DOM側の取得にも制限がかかります。すべてのリンクが未訪問として扱われるため、Selectors APIのquerySelector, querySelectorAllやgetComputedStyleから:visitedなリンクを取得しようとしても、それができなくなります。
このDOMの挙動については、Internet Explorer 8のIE8標準モードでも同様の処理がすでに行われています（プロパティの制限はありません）。
未訪問・既訪問でtext-decorationを変更するものや、background-imageで異なる画像を表示させるWebサイトは一定数存在します。レイアウトが著しく崩れるといったものはそこまでないと予想しますが、未訪問と既訪問の区別を色以外で行っていたばあい、訪問者はその区別をつけられなくなってしまいます。カンプのデザイン段階から、未訪問と既訪問のスタイルについて確認することが一層重要になってきそうです。
まずは、DougがPatrickにIE9でのSVG対応について、その理由を尋ねています。
Patrick曰く、MicrosoftはWebの現在とこれからのトレンドについて情報を集めており、製品のプランニングに活かすそうです。IE9のプランニングにおいて、これからのトレンドはグラフィックスと判断し、グラフィックス機能の強化を行うことになったそうです。“GPU-powered HTML5”など、ハードウェアアクセラレーションによる機能強化について盛んに述べていることからも分かりますね。
グラフィックス規格であるSVGも、そういったグラフィックス機能強化のひとつとして検討されたのでしょう。MicrosoftはSVG 1.0の策定には参加しており、その前にVMLをW3C Submissionとして提出することも行っていましたが、これは期待したほど広がりを見せなかったと語っています。しかし、近年HTML5でSVGがtext/htmlなHTML文書にも埋め込めるようになったことで開発者からの注目や期待が高まったことなどをふまえ、「SVGが最適な選択肢であり、今がそのときだ」と述べています。
なお、VMLも互換性のためにサポートは続けるとのことですが、VML to SVG Migration Guideという移行ガイドも用意されています。
すでにMIX10のセッションなどで紹介されていますが、IE9はSVG 1.1の機能すべてをサポートするわけではありません。IE9では、SVG 1.1仕様の23モジュールのうち、フィルタ, アニメーション (SMIL), フォント (SVG Fonts)を除く20モジュールがサポート予定とされています。
理由として、SVG 1.1は大きな仕様であることや、ブラウザー間で相互運用性の取れている機能を実装するという方針を挙げています。Dougのフォローアップ記事でも、最初からSVG 1.1をフルサポートするブラウザーはこれまでになく、さらにはどのブラウザーも未だフルサポートに至っていないと書かれています。限定したサポートを最初のバージョンで行うことは、それほどおかしなことではないでしょう。
さて、Patrickは個人的に、SVG FontsはWOFFなどWeb Fonts WGで進んでいる動きなどを踏まえ、引き続き調査は続けるが、今の段階で広がるとは思わないと考えているようです。また、フィルタやアニメーションについては、IE固有のフィルタ機能や、SMILをHTMLに組み込んだHTML+TIMEなどが過去にうまくいかなかったことを紹介しつつ、CSS Transitions, AnimationsなどCSSの表現力が強化され、また少しずつ広まりを見せている現状から、今後の流れがどうなるか静観したいという思いがあるようです。
SVG WGはSVG 1.1 Second Editionの作業を進めていますが、仕様として古く、また実装や開発において、面倒を解消したり、また単純化したい機能がいくつかあるようです。ほかにも、SVGとCSS, Canvasで重なる視覚効果やアニメーション、APIの重複についても共通化されるといいという意見を述べています。
Doug, Patrickふたりとも、こういった問題を検討中のSVG 2.0では改善したいと考えているようです。グラフィックスの「HTML5」としてSVGが進んでいくのかどうかは定かではありませんが、多くのベンダーが関わり策定にあたる今後が楽しみになってきました。
]]>br要素などは、<br />という記述、<br>という記述のどちらも書くことができるようになっています。また、これら2つの表記が混在することも可能です。
とはいえ、これからHTMLの基本を教えるときに「どちらでもいい」といった教え方をすると、教えられる側は少し悩んでしまうかもしれません。また、製作者にとっても、保守性や複数人での作業に影響があると言われていますから、なるべくならばコードの書き方に一貫性を持たせたいと考える人は多いのではないでしょうか。
こういった理由などがあり、HTML5でもXHTMLのような書き方を好む人は多いです。また、XHTML互換の書き方で書くと、HTML5パーサやXMLパーサのどちらでも処理できる利点があります。
XMLとして利用出来ることは「XHTMLの利点」として言われ続けながらもあまり活かされない印象がありましたが、EPUBなどXHTMLを利用するフォーマットが注目されはじめてきていることから、XHTMLとしても処理できるHTML文書の需要は少し高まってくるのかもしれません。
さて、HTML WGでもこのXHTML互換のHTML5記法について、前々よりValidatorにそういった構文チェック機能を設けるような仕組みを設けるべき、XHTML互換の構文であることを示す属性を定義してはといった声が上がっていました。Validatorの対応や構文の定義には至っていませんが、製作者向けのガイドラインを整備しようという話が進められ、Editor's Draftではありますが文書が公開されています。
内容はXHTML Media Typesの互換性ガイドライン (日本語訳) に近いでしょうか。新しいHTML5と周辺仕様の草案が来月中に更新される予定ですが、このガイドラインも草案として公開する流れで進められています。
]]>HTML5やCSS3は発展途上ですからオーサリングツールの対応もまだ充分ではありません。今後のアップデートにも期待したいです。
オーサリングツールのほかにも、マークアップが適切かどうかを判断するための術がほしいところです。HTML5では適合性チェックツールとしてValidator.nuが開発されており、W3CのMarkup Validator (開発版)にも実験的に組み込まれています。
しかしながら、HTML5仕様自体が策定中ですから、当然Validator.nuも開発途中です。また、開発リソースの問題もあり、実装されていない機能もまだまだ多く残っています。つまり、Validator.nuに通っただけで適合しているとは言えないのです。
たとえば、文書のエンコーディング指定ですが、HTML5ではふたつの書き方があります。
meta要素のcharset属性による指定 (<meta charset="UTF-8">)http-equiv属性による指定 (<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">)どちらを使ってもよいのですが、なにせシンプルですからHTML5のものがよく使われています。互換性について気になるかもしれませんが、実はこのcharset属性、古いブラウザーの実装を元に仕様ができた経緯があり、古いブラウザーでも問題なくサポートされています。
ところが、そういったことを知らず、互換性を気にしているのか、このどちらをも指定する文書があるようです。先日CSS Nite LP9連動コーディングコンテストの審査をしていたときにもいくつか見かけたのですが、ふたつ書くことは認められていないと仕様書に書かれています。
There can only be one character encoding declaration in the document.
（訳: 文字エンコーディング宣言は文書中にひとつのみ存在することができる。）
しかし、これはValidator.nuでまだ実装されていない (該当バグ) ため、チェックされずに通ってしまいます。
実験的ではあれ「Valid」と表記するのも少し困りものですが、Validator.nuだけのチェックでは安心出来ない例がいくつかあるので、お気をつけください。
]]>Henriはまた、HTML5のValidator “Validator.nu” も開発しています（Firefoxのコードは、このValidator.nuとベースが同じです）。一昨日のことですが、HTML5に埋め込んだSVGとMathMLの検証もValidator.nuで行えるようになったそうです。
このニュースを参照するかたちで、OperaのAnne van Kesterenが、HTML5のパーサのあゆみについて自身のBlogで取り上げています。
記事によると、初期のHTML5仕様 (このときはWeb Applications 1.0と呼ばれていました) では既存のHTML仕様を拡張するもので、構文解析アルゴリズムは定義されていなかったそうです。しかし、作業を進めていくうちに基盤の定義が必要になったことから、アルゴリズムの定義が始まったとのことです。
Mozillaのようにパーサを置き換えるという大掛かりな変更は、他のブラウザーでは行われていないように思います。しかし、HTML5の構文解析アルゴリズムに準拠する作業は進められており、Internet Explorer 9でもツリー構築処理などが変更されるようです。
さて、少しパーサからは離れますが、先日Firefoxの開発版に:-moz-any()という擬似クラスが実装されました。
このセレクタは括弧内にカンマで単純セレクタを並べ「このどれかにマッチする」という条件を表すことができるものです。上記のDavid Baronの記事では、ul, ol, menu, dir といったリストが深くネストした状態のユーザーエージェントスタイルシートを、:-moz-any() で書き直した例が紹介されています。また、昨日にはHTML5のセクション要素と見出しのスタイルづけに、この:-moz-any()を利用するパッチが投入されました。
CSS仕様としてはまだ存在していませんが、メーリングリストでは議論が行われたこともあり、CSS4セレクタとして同様の機能が定義されるかもしれません。
HTML5の実装は要素や属性の導入だけではなく、基盤となる処理の変更やスタイルシートの対応も含まれます。目に見えやすい機能やAPIが取り上げられがちですが、こうした足場を固める作業も、地道に進められています。
]]>Device APIs and Policy WGより4/6付で、File API: Writerの草案が公開されました。
ファイルアクセス関連のAPIは、WebApps WGからFile APIが公開されていますが、ファイルの書き込みについては仕様がありませんでした。WriterではBlobBuilderやFileWriterといったインターフェースが定義されており、アプリケーションからファイルを書き込む仕組みが提供されることになります。
XHTML2 WGより4/15付で、XHTML M12n 1.1 Second Editionの改訂勧告案が公開されました。
XHTML 1.1 Second Editionの改訂勧告案も、早期に公開される予定とのことです。
RDFa WGより4/22付で、RDFa 1.1の草案が2つ公開されました。
RDFa Coreは「RDFa 1.0」と呼ばれたRDFa in XHTML仕様をもとに、RDFaの概念や処理を単一仕様として独立させたものです。他にもいくつかの変更が反映されています。XTHML+RDFa 1.1はXHTML 1.1にRDFa 1.1を取り込んだものになります。
HTML5での利用については、これまで通りHTML WGよりHTML+RDFaとして公開されます。RDFa 1.1に対応した新しい草案も公開にむけ準備が進められているようです。
]]>このアルファ版には、先日より各所で取り上げられている、CSSの:visited擬似クラスに関する大きな修正が現在Firefoxで行われています。詳しくは、次のページをお読みください。
(二つ目の記事について、翻訳をMozilla Developers Streetに寄稿させていただきました。)
:visited擬似クラスは訪問済リンクにスタイルを与えられるもので、CSS1から定義されています。これだけであれば特に危険はありませんが、getComputedStyle()などと組み合わせることで、訪問済のサイトが取得できてしまうことが知られていました。
今回行われた修正は、Mozillaの開発者David BaronによるPreventing attacks on a user's history through CSS :visited selectorsを反映したものです。問題をすべて解決できるわけではありませんが、履歴を取得する方法のうちとくに簡単なものを防ぐという意図が語られています。
さて、制作者として特に気になるのが、:visitedに指定できるプロパティが color, background-color, border-*-color, outline-color, column-rule-color といった色指定に限定されることでしょうか。どういうことかというと、:visitedに指定されたbackground-image などが効かなくなります（:link と同じものが適用されるようになります）。
同じ対策がWebKitでも行われていることから、将来的にSafariやChromeでも同様の変更が反映されるようになりそうです。
色以外のプロパティには:linkの指定が反映されることがほとんどでしょうから、レイアウトの崩れが頻発するというのは考えにくいです。しかし、background-imageなどは多くのサイトで利用されていますし、こうしたプロパティの利用を前提としたデザインについては、今後をふまえた対策が必要になりそうです。
3月5日付で、HTML WGよりHTML5関連仕様の草案が公開されました。「HTML5と関連仕様、言語リファレンスが公開」で取りあげていますが、Canvasの2D Context APIやマイクロデータの分離にくわえて、製作者向けリファレンスも公開されています。
W3C Blogにて、HTML WGのco-chairをつとめるMicrosoftのPaul Cottonへのインタビューが掲載されています。
MicrosoftとW3Cの関わりから始まり、HTML WGの現状や問題解決プロセスについて触れたインタビューになっています。
Web Fonts WGが設立されました。あたらしいWOFFというフォントフォーマットの策定などを行うグループになります。詳細は「Web Fonts WGの設立、WOFFの標準化へ」をお読みください。
]]>