第9回　ValidなHTML、ValidなCSS

W3Cが(X)HTMLやCSSについての勧告を出していることにより、Web制作者は仕様に沿って「正しい」(X)HTMLやCSSを書くことを求められています。

Validな(X)HTMLの基準として挙げられるポイント

まず、

仕様のとおりに書かれている
HTMLバリデータ[1]で減点されない

ことが挙げられます。

DTD（文書型定義）に沿った(X)HTMLを書けば、このようなバリデータの検証でエラーがでないようにすることが可能です。

validだと何が良いのか

XHTMLをXMLアプリケーションとして考えると、パースエラーの出ることのない利用価値のある文書となる（validではないものではパースエラーが出てしまう）
正しい(X)HTML文書に対してでないと、CSSが意図した通りに機能しない
点数が満点になることによる制作者の満足感が高まる

何回かこの連載で取り上げましたが(X)HTMLは文書構造・意味をマークアップする言語ですので、

文書構造が適切に意味付けされていること
DTD・仕様に沿って適切な要素が使われていること
見栄え・振る舞いに関わる記述を(X)HTMLで書かないこと（それはCSSの担当です）

これらに注意しつつ、(X)HTMLの記述は極力シンプルでわかりやすいものが好ましいと言えます。

私たちがお化粧をするときに、ベースのお肌が荒れていると思うようにお化粧がのりません。(X)HTMLとCSSの関係もその関係とよく似ており、構造がしっかりした文書にCSSを載せるというのが前提になっています。

また、独学で学習されている方なら、3の満足感の大きさを経験された方もいらっしゃるのではないかと思います。実際私もそういう時期がありました。見ていただく人にどのように伝わるのかをさしおき、とにかくバリデータでエラーがでないようにすることが目的にすりかわってしまうことすらあったほどです。

とくにAnother HTML-lintでは、文法チェックに加えてアクセシビリティチェックもできるうえ、DTD的には正しくても好ましくない記述をした場合にエラーを出してくれるため、良い(X)HTML文書を書くために重要なツールとなります。

（例）<br />が二つ連続する場合／<div>と</div>の間が空の場合などさまざまです。

バリデータで100点満点をとることに満足してはいけません

正しく(X)HTMLを書くのはWeb制作者に最低限必要だと考えますが、かといってバリデータで満点をとることを目的にしてしまうのは好ましくありません。

具体的なエラーケース：
「<div>と</div>の間が空」というエラーの事例

最近ではリッチなインターフェースを実現するためにJavaScriptライブラリなどを利用する機会も増えてきました。ライブラリにもいろいろな種類があり、たとえばフォームのエラーメッセージの表示方法1つとっても、エラーメッセージ出力場所を<div></div>の中身とするものもあれば、input要素のtitle属性にエラーメッセージをあらかじめ書いておいて出力させるパターンのものもあります。

この場合、<div></div>を利用して出力するライブラリを選ばないというのも1つの方法かもしれませんが、そのような理由でライブラリを切り捨てることによって、表現したいことができないほうが本末転倒なのではないでしょうか。

このようなケースのように、<div></div>を使わなければならない場面もゼロではない[2]ため、バリデータを通過する／しないというだけで頭ごなしにそのサイトの品質を評価できるものではないことを制作者は気を付けなければならないと思います。

<div></div>でも、良くない例もある：
<div style="clear:both"></div>や<div class="clear"></div>

これは、CSSでfloatによる段組みレイアウトを行う際に、floatさせている要素の親要素の背景が途中で切れてしまうことを回避するためによく使われがちなバッドノウハウです。しかし、せっかくCSSだけで解決策があるので（いわゆるclearfix⁠）⁠、こういう目的で(X)HTMLの構造を汚すのは避けたいところです。

CSSはどのように考えるか

CSSにももちろんW3C validation serviceがあります。

http://jigsaw.w3.org/css-validator/

もちろんCSSも正しいとされるものを目指して書くのが望ましいです。ただし、現実の閲覧環境のことをよく考えたうえで記述しなければなりません。

PCで閲覧されることが想定されるほとんどのWebページは、IEやFirefoxなどのブラウザソフトで閲覧をすることがほとんどです。そして、新しいブラウザソフトになるほど、CSSの仕様に準拠した正しい振る舞いをしてくれるものが多いです。一方、2008年4月の現時点でまだまだシェアが高いIE6は致命的な振る舞いの違いを起こしてしまうことが多いのです。いくら正しくCSSを書いていたとしても、どうしても意図どおりに表示できないケースが出てきます。そこで、ブラウザごとにわざわざ違うCSSを書いて読み込ませたり、CSSハック[3]と呼ばれる手法を利用して、特定のブラウザだけに読める記述をしたり、などという工夫がされてきました。

正しいCSSだけで意図通りに表示できるのがもちろん理想です。けれど正しいCSSだけに拘ることによって、意図する表示ができなかったり、レイアウトを崩してしまうことがあったらこれも本末転倒です。

正しいCSSでなければならない理由についてよく考察されている文章がありますのでご紹介します。

Lucky bag::blog: CSS が valid でなければいけない理由って何ですか？のコメント欄より

よりシンプルな解決方法はないだろうか？
validであってCSSの解釈の違いから解決することはできないか考える。

同じ表現になるような代替案は無いだろうか？
スタイルを適用する要素を変えたりして同じような表現はできないか考える。

ビジュアルデザインのほうに無理は無いだろうか？
デザインを少し変えるだけで解決できるなら、同等か、さらに良い表現方法はないか考える。

1,2,3で解決できない場合は適したハックを選んで最小限使う。管理できるようにコメントをつける(そして、僕はここでその記述がvalidかinvalidかは気にしない。この段階ではアンダースコアハック万歳な気分になってる)。

http://www.lucky-bag.com/archives/2007/06/why-css-must-be-valid.html#comments

また、私の経験上、ハックの良し悪しということ以上に、記述したCSSを長く面倒見ることができるか。ということのほうが大切だと思っています。自分で責任持って面倒を見られるのであれば、先行実装で最新のコードを入れようが、invalidなハックをしようが大丈夫だと思いますが、実際の制作現場ではCSSは1人のものではありません。そうするとあとは共同作業をする上で必要なハックに関するルールや、適切なコメントを行う配慮が必要です。

参考1：: http://homepage1.nifty.com/VET06031/web/lint100.html
参考2：: http://www.akatsukinishisu.net/itazuragaki/css/invalid_css_and_webstandard.html
参考3：CSSハック一覧表: valid/invalidとブラウザ別の読み取りの可否が一覧で見ることができる便利な表となっています。
http://spreadsheets.google.com/pub?key=prvB_MFPHuEHOYL7ulKmYOQ&output=html