新春特別企画

2014年のWeb標準

この記事を読むのに必要な時間:およそ 3 分

株式会社ミツエーリンクスの渡邉卓です。昨年の2013年のWeb標準と同様,2014年もWebコンテンツのフロントエンド設計および実装に関連した各種標準や,周辺領域の動きに関する短期的な予測を寄稿させていただきます。

2014年のWeb標準については「HTML5勧告予定年」⁠IE6の終焉」⁠CSSプロパティくりかえし問題」をキーワードとして取りあげます。

HTML5勧告予定年

HTML5にとって,2014年はとても重要な年になります。昨年の記事でも触れましたが,HTML5は2014年に「勧告」となる予定であるためです。HTML WGによる2014年の計画では,HTML5を勧告(Recommendation)にする目標が,2014年後半(第4クオーター)に設定されていることがわかります。

HTML5はすでに勧告候補(CR; Candidate Recommendation)であるため,基本的な部分はほぼ安定しています。案件や個人で,HTML5を採用したWebサイト構築・運用に関わったことがある方もいることでしょう。必然的に知見(ノウハウ)も人の数だけ蓄積されています。すべてが手探りで,HTML5仕様側の変更による大規模な変化が日常茶飯事であった過去とは違い,現在のHTML5は「最後のひと押し」を待つだけの状態にまで至っています。

2014年は,HTML5に対する「最後のひと押し」⁠⁠─すなわち勧告化─⁠─がなされ,HTML5を採用したWebサイトがさらに増えていくでしょう。

なお,HTML5の次期マイナーバージョンアップになるHTML5.1は,2015年初頭(第1クオーター)にCR,2016年末(第4クオーター)に勧告となる予定です。⁠2015年のWeb標準」では,HTML5.1についてより詳細に予想できるかもしれません。

IE6の終焉

Internet Explorer 6 (IE6) のサポートが,2014年4月9日に終了します※1)⁠Windows XP SP3のサポートが終了することで,OSの一部としてプリインストール・出荷されたIE6のサポートも同時に終了するためです。

2001年に配布開始されたIE6。約13年という,長いサポート期間が今まさに終わろうとしています。その間に賛否両論があり,栄光と衰退を経験し,必要に駆られて様々なハックを生み出しました。正否両方の意味において,ひとつの時代を象徴する存在であったといえるでしょう。

2014年は,IE6のサポートが終了することで,これまで採用できなかった・採用しづらかった,比較的新しいWeb標準が採用できるようになるでしょう。特にセレクタ仕様のベースライン底上げ※2は,これまでの苦労をある程度低減してくれます。

ただし,JavaScriptおよびDOMに関しては,IE7※3)⁠IE8※4もIE6と大差ありません。この点においては,IE9※5以降─⁠─IE10※6およびIE11※7を含みます─⁠─が基本となるまで状況は変わりません。JavaScriptおよびDOMまわりでの苦労は,いましばらく持ち越しということになりそうです※8)⁠

※1
ただし,Windows Server 2003 R2にプリインストールされたIE6をサポート対象とする場合,現時点での延長サポート終了は 2015年7月14日です。
※2
IE6からIE7へ移行する場合,新たにCSS 2.1の一部セレクタが利用可能となります。
※3
IE7はWindows Vistaにプリインストール・出荷されました。よって,現時点での延長サポート終了は2017年4月11日です。
※4
IE8はWindows 7にプリインストール・出荷されました。よって,現時点での延長サポート終了は2020年1月14日です。
※5
IE9はWindowsへのプリインストールによっては出荷されませんでした。IE9がインストール可能である最も新しいWindowsは,Windows 7です。よって,現時点での延長サポート終了は2020年1月14日です。
※6
IE10はWindows 8にプリインストール・出荷されました。よって,現時点での延長サポート終了は2023年1月10日です。
※7
IE11はWindows 8にプリインストール・出荷されました。よって,現時点での延長サポート終了は2023年1月10日です(※9)⁠
※8
現在は2000年代初頭と比較して,IE6~8が持つJavaScriptおよびDOMの問題をある程度緩和するJavaScriptライブラリjQueryなど)が整備されているため,混沌とした状況は避けることができています。
※9
Windows 8.1にはWindows 8と同一のライフサイクル ポリシーが適用されます。よって,Windows 8の延長サポート終了日とWindows 8.1の延長サポート終了日は同一になります。

CSSプロパティくりかえし問題

現状のCSSでは,同じ意味のCSSプロパティを何度も(少しずつ記述を変えながら)くりかえし記述しなければならない場合があります。

主な原因は2つです。ひとつは,ベンダプレフィクスの副作用によるもの。もうひとつは,プロパティ仕様が変更された際の対応法によるものです。双方の問題を同時に持つ例としては,linear-gradient(),radial-gradient()CSS Flexible Box Layout Moduleを挙げることができます。

ベンダプレフィクスの副作用と回避策

デスクトップ環境向けブラウザのベンダプレフィクスについては,ブラウザベンダーごとの差はありますが,おおむね改善の傾向にあるようです。ベンダプレフィクスをとりまく環境の変化に対応する動き─⁠─特に,負の側面を解決するためのもの─⁠─は,2012年から始まっていました。CSSワーキンググループ内での討議を経たのち,Blink(Google Chrome)Gecko(Mozilla Firefox)ではベンダプレフィクスに関する内部ポリシー変更が行われました。結果,ポリシー変更前から存在するものを除いては,新規に実装されたCSSプロパティにプレフィクスがつかなくなっているようです。実際に各ブラウザの正式版に反映されるまでの時間を考えると,2012~2013年は大きな変革があった期間だといえます。

しかしながら,モバイル環境向けブラウザのベンダプレフィクスについては,なかなか改善が進んでいないようです。更新頻度・OSへの統合度合いが影響していると考えられます。詳細は2011年および2012年の言及をご参照ください※10)⁠

※10
Androidでは,OSとはレンダリングエンジンが分離可能なChrome for Androidを標準ブラウザに据えたり,4.4 KitKatをローエンドデバイスでも実行可能にして2.x系の終焉を図るなど,改善の兆しが見えはじめました。ただこの動きも,各デバイスベンダーが自社製品に搭載するAndroidへChrome for Androidを搭載する場合,ライセンス契約をGoogleと結ぶ必要があると報道されるなど,ひと筋縄ではいかない模様です。

プロパティ仕様の変更が及ぼす影響と回避策

CSS関連仕様に限ったことではありませんが,W3CのWD(Working Draft)においては,その編集段階で仕様が大幅に変わってしまうことがあります。特に深刻なのは,新仕様と旧仕様の間に後方互換性がないほど,文法が変わってしまう場合です。 CSS関連仕様に限ったことではありませんが,W3CのWDにおいては,その編集段階で仕様が大幅に変わってしまうことがあります。特に深刻なのは,旧仕様と新仕様の間に後方互換性がないほど,文法が変わってしまう場合です。

このような場合には,旧仕様に準じた文法で記述したプロパティと,新仕様に準じた文法で記述したプロパティを,両方とも順番に気をつけて記述する必要があります。要件にもよりますが,旧仕様しかサポートしないブラウザ・新旧両仕様ともサポートするブラウザ・新仕様しかサポートしないブラウザのすべてに対応する必要が,現実に存在しています※11)⁠

プロパティ仕様が変更されること自体は,歓迎すべきでしょう。変更されるということは,旧仕様にバグがあり,仕様として確定させる(勧告にする)には問題があったという事実を意味しているからです。ここで重要なのは,仕様を変更しないことではなく,⁠プロパティ仕様の変更が及ぼす影響を最小限に抑えるには,どうすればよいか」を考えることです。

現時点で,W3Cはこの難問に取り組んでいる途中のようです。その結果生まれた解決案のひとつが,⁠仕様勧告のプロセスを改善する」ことです。

議論中である仕様勧告のプロセスを改善する変更案の冒頭では,現行のプロセスから大きく変更した点を列挙しています。CSS関連仕様策定で,⁠プロパティ仕様の変更が及ぼす影響を最小限に抑えるには,どうすればよいか」を考えた際,重要となる項目は「実装要件を現在の規定より厳密化し,広範なレビューを実施する」「LC(Last Call)とCRを統合し,新たにCR※12とする」の2つでしょう。これらの項目によって,⁠バグを内包したままの仕様が広く流布してしまう」⁠仕様変更が及ぼす影響が非常に大きくなる」問題を,今よりも軽減することができます。2014年中に結論がでるか否かは不明ですが,今後の動向に注目していきたい解決案です。

※11
設計手法としてRWDを採用し,モバイル環境向けブラウザにも対応が必要な場合などが該当します。
※12
2013年10月24日版ドラフトでは「LC/CR」と呼ばれています。ISSUE-53反映された結果,Editor's Draftでは「CR」に名称変更されました。

各種ツールによる回避策と問題点

前述した回避策がとられつつあるとはいえ,現時点では同じ意味のCSSプロパティを何度もくりかえし記述しなければならないケースが多々あります。

そこで使われているのが,くりかえしの手間を省く各種ツール群です。思いつくだけ列挙してみても,CompassSassLESS HATLESS)⁠nibStylus)⁠Autoprefixerなど,枚挙に暇がありません。これらのツールは確かに便利であり,1回の記述で複数のベンダプレフィクスの有無・Web標準仕様の変更に対応できます。

しかし,昨今,仕様側やブラウザ側ではなく,ツール側(の出力結果)に問題があるケースもでてきています。たとえば,最新のWeb標準仕様に準じたプロパティを出力できず,結果的に古い仕様のプロパティだけが出力されてしまうことがあるのです※13)⁠Webサイト開発者(ツールのユーザ)側としては,出力結果(CSSファイル)やプロパティの変換・くりかえしを実施している部分の実装を確認することで,前述したような問題があるか否かを確認することも必要になってきています。

2014年は,引き続き同じ意味のCSSプロパティを何度もくりかえし記述しなければならない問題に直面することがあるでしょう。また,その解決策として各種ツールを用いるときも,最新の仕様に対応しているか否かを確認する必要が出てくるかもしれません。

※13
たとえば,Compass 0.12.2 における linear-gradient() が該当します。最新仕様では,グラデーションラインの終点を表現するために to top や to bottom といった表現を用います。しかし,Compass 0.12.2 における linear-gradient() では構文エラーとなり,古い仕様を用いた結果しか出力されません。結果,最新仕様に追従するためには自身でもう一度定義を記載(CSSプロパティ複数回列挙)する必要が生じます。

著者プロフィール

渡邉卓(わたなべすぐる)

株式会社ミツエーリンクス フロントエンド・エンジニア。Webサイト設計・実装,JavaScript プログラミングに従事。

コメント

コメントの記入