Web標準Blogでは、Web標準の利用に興味のあるWebサイト管理者、Webデザイナーの方向けに、Web標準を利用するための手法やノウハウ、参考になるリソース等を、国内外を問わずご紹介します。
なお当Blogでは、Web標準に関する疑問や質問を募集しています。Webコンテンツ実装プロセスにまつわるお悩みでも結構ですので、お気軽に電子メールでstandards@mitsue.co.jp宛にお送りください。
2010年6月29日
HTML5の更新:代替テキスト、Polyglotマークアップ草案が追加
フロントエンド・エンジニア 矢倉
24日付けで、HTML5関連草案が更新されました。また、新たにふたつの草案が公開されました。
- HTML5
- HTML Canvas 2D Context
- HTML Microdata
- HTML+RDFa 1.1
- HTML5 differences from HTML4
- HTML: The Markup Language
- HTML5: Techniques for providing useful text alternatives
- Polyglot Markup: HTML-Compatible XHTML Documents
これまで公開されていた草案については、HTML5仕様の更新に基づくアップデートが主な変更点になります。HTML5 differences from HTML4のchangelogから、気になったものを抜き出してみました。
- 電子メールなど別の方法でタイトルが存在するケースにおいて、
title要素の指定が任意とされた wbr要素が追加されたmeta要素のname属性の値にkeywordsが追加された
HTML+RDFaは、先日公開されたRDFa Core 1.1に準じたものとなりました。HTML 4.01にRDFaの属性を組み込んだDTDも検証目的として用意されています。
代替テキストのテクニックと“Polyglot HTML”
新しく公開されたHTML5: Techniques for providing useful text alternativesでは、さまざまな条件のもと適切な代替テキストを与えるための指針や要件を記載しています。将来的にはHTML5の代替テキストに関するセクションを置き換える目的で作業が進められています。
もうひとつのPolyglot Markup: HTML-Compatible XHTML Documentsは、先日「HTML/XHTML Compatibility Authoring Guidelines」で触れた互換性ガイドラインになります。名称が変更されましたが、文書の目的は変わっていません。
HTML5や関連仕様が実際に使われることが増えてきました。ですから、制作者・開発者向けのドキュメントへのニーズが高まってくるでしょう。現在はリファレンスとして使う文書が多いですが、今後はalt-techniquesのように考え方を伝える文書が重要になってくるのではないでしょうか。WGの成果物としても、リファレンス型でない文書の方がより望ましいのではないかと感じています。
日本語訳
いつもの変更点の更新と、Polyglotマークアップの訳を公開しました。
恒久リンク | コメント [0件] | 関連情報(トラックバック) [0件]
2010年6月14日
:visitedの挙動変更がSafari 5に反映
フロントエンド・エンジニア 矢倉
先週火曜にリリースされたSafari 5ですが、以前お伝えした: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からの取得も不可能に
さて、もともとの問題となっている、DOM側の取得にも制限がかかります。すべてのリンクが未訪問として扱われるため、Selectors APIのquerySelector, querySelectorAllやgetComputedStyleから:visitedなリンクを取得しようとしても、それができなくなります。
このDOMの挙動については、Internet Explorer 8のIE8標準モードでも同様の処理がすでに行われています(プロパティの制限はありません)。
未訪問・既訪問でtext-decorationを変更するものや、background-imageで異なる画像を表示させるWebサイトは一定数存在します。レイアウトが著しく崩れるといったものはそこまでないと予想しますが、未訪問と既訪問の区別を色以外で行っていたばあい、訪問者はその区別をつけられなくなってしまいます。カンプのデザイン段階から、未訪問と既訪問のスタイルについて確認することが一層重要になってきそうです。
恒久リンク | コメント [0件] | 関連情報(トラックバック) [0件]
2010年6月 8日
IE Teamのプログラムマネージャが語るIE9とSVG
フロントエンド・エンジニア 矢倉
SVG WGのBlogにて、Team ContactのDoug Schepersと、IE TeamでSenior Program Managerに就くPatrick Denglerの対談が公開されていました。MicrosoftがSVGについて考えていることや、SVG仕様で改善したいところ、検討中のSVG 2.0など面白いトピックが多いので、すこし紹介します。
SVG対応の理由
まずは、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という移行ガイドも用意されています。
IE9でサポートしない機能
すでに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の改善点やSVG 2.0への期待
SVG WGはSVG 1.1 Second Editionの作業を進めていますが、仕様として古く、また実装や開発において、面倒を解消したり、また単純化したい機能がいくつかあるようです。ほかにも、SVGとCSS, Canvasで重なる視覚効果やアニメーション、APIの重複についても共通化されるといいという意見を述べています。
Doug, Patrickふたりとも、こういった問題を検討中のSVG 2.0では改善したいと考えているようです。グラフィックスの「HTML5」としてSVGが進んでいくのかどうかは定かではありませんが、多くのベンダーが関わり策定にあたる今後が楽しみになってきました。
