って質問されたら、これだ！っていう答えが思いつかない。valid ではない CSS ってのは、単純な記述ミスとかではなくて、例えば Safari の複数背景画像や Opera の opacity なんかの先行実装、もしくは -moz 系などの独自実装を使うことで invalid となっているケース。
(X)HTML で invalid だと、パーサが処理出来ないとか内容が表示されないとかクリティカルな issue が発生するかもしれないけれど、CSS では意図して invalid なコードを書くケースってのがあると思う。それが良いか悪いかは別にしてね。
んで、タイトルの問い。仕様に沿った記述をすべきっていう真っ当な回答があるんだろうけど、なんかこう膝を打つような回答って何だろ。あなたが書く CSS は valid ですか？ valid であろうと心がけていますか？ そうあるべき理由って何ですか？
Comments
始めまして。
現場の方の声では無く、膝を打つような回答でも無いのですが（すみません･･･）、私は自分の表現力を高める為に意識しています。個人的に制作しているものに関してではありますが、 hack の使いどころを見極める為に valid を心掛けています。
私的には、 valid でなければならない理由は無く、 valid ではない記述に関しての説明が出来れば良いかなと考えております。
css定義そのものと、cssを解釈するブラウザの実装が（互換性と表現力において）パーフェクトであれば、css記述もvalidなものが書けるでしょうが、前提の2つの要素がパーフェクトにならない限りは、当然css記述の方もパーフェクトにvalidというわけにはいかんでしょうね。
現場の声ですが・・・
はじめてコメントさせて頂きます。
難しい問いですね、少し考えてみて思ったことは、イレギュラーな実装がないと、企画の範囲の知識しか持たない人でも、そのコードを読んだり、メンテナンス出来るというのが利点かと思います。
CSS Hackはコード的にValidな事も多いですが、検索して調べたりする時に少し手間がありますし「何故それがHackとして機能するのか」を理解せずに使ってしまう人も多いと思いますのでValidなCSS Hackも場合によってはInvalidな気持ちで扱った方が良いのかな？と思いました。
お目汚し失礼しました。
仕様に沿った記述をすべきっていう真っ当な回答？
実際のブラウザで「真っ当に」表示されなくても、その答えが真っ当？
valid とかチェックで１００点とかただの営業トークだよね。
ドロップシャドウなんて良い例で、規格から消えたり復活したり。
利用する側は、ソースを観たいんじゃないよ。
魅力的なコンテンツを持ってない人間が、validとか１００点とかを言い訳にしたいだけなんだよ。
やはり現場の意見ですが。
構造を記述するHTMLについては仕様に対してかなり厳格である必要もあるでしょうが、「表現」を実現するCSSにおいて仕様に厳格であることはさほど重要ではないと考えます。
CSSに求められていることは第一に顧客やデザイナが求めるデザインを実現することであって、CSSの仕様に従うことが（開発者にとって）直接的なメリット／デメリットとはなりません。HTMLに比べると差し替えるコストも低いですし、開発／運用時に解りやすい「綺麗なコード」を書くことのほうが重要ではないでしょうか。
ただ、開発効率的に、仕様を「理解」することは重要だと思います。
こんばんは。
僕はCSSに関してはvalidかどうかはあまり拘っていません。
複雑なビジュアルを再現するときには、遠回りした方法でvalidにするか、invalidになっても3行で済ますか考えることがありますが、遠回りした方法でvalidにできたとしても、スタイルの汎用性を落としたり、可読性が失われるようであれば迷わずinvalidで近道します。
よりシンプルな解決方法や代替手段があるのに、invalidにして近道する(した気になる)ことが問題で、うちの生徒にも、どこからかハックテクニックを覚えてきて、問題があるとすぐにアンダースコアハックで解決しようとするってのを見てきました。
★1.よりシンプルな解決方法はないだろうか？
validであってCSSの解釈の違いから解決することはできないか考える。
★2.同じ表現になるような代替案は無いだろうか？
スタイルを適用する要素を変えたりして同じような表現はできないか考える。
★3.ビジュアルデザインのほうに無理は無いだろうか？
デザインを少し変えるだけで解決できるなら、同等か、さらに良い表現方法はないか考える。
★4. 1,2,3で解決できない場合は適したハックを選んで最小限使う。管理できるようにコメントをつける。(そして、僕はここでその記述がvalidかinvalidかは気にしない。この段階ではアンダースコアハック万歳な気分になってる)
といった感じでしょうか。
関連文章:
http://www.akatsukinishisu.net/itazuragaki/css/invalid_css_and_webstandard.html
>>haifun さん
意識するってのは重要ですね。仕様通りに書いても解決できないものを、リスクを分かった上で invalid な記述で解決するケースはあると思います。
>>smilkobuta さん
確かにブラウザの実装が完璧であれば invalid な CSS を書く可能性は低いかもしれませんね。でも先行実装なんてのがあると、それを使いたくなる人も居たりするのです :D
>>hisagi さん
そうですね、At your own risk であれば関係ないですけど、自分以外の手に委ねられる可能性がある場合には気を付けなければいけないでしょうね。
>>yamada さん
普通に真っ先に思いつきそうなまじめな答えだと思いますが？
つまり、優等生的な答えってことで「真っ当」という言葉を使っています。
>>Sig. さん
どこに重要度を置くかってことですよね。対クラであれば求められているものを実現することなのかもしれませんが、内部的に重要なのはそのウェブサイトを maintainable なものにするということかも知れません。いずれにしろ、仕様を理解することは重要ってのは、全く持ってその通りですね。
>>wu さん
分かってやっているのか、安易に逃げているのか、目に見える結果は同じかもしれないけれど後者は潜在的な問題を抱えているよね。時間が経ってから見直しても何故自分がそんな記述をしたのか理解できないかもしれないし。
まあ、お金が発生している状況では、費用対効果で簡単な解決に逃げてしまわざるを得ないっていうプラグマティックな問題があるのかもしれない。分からないけど。
うーたんのその考えをちゃんと理解した生徒がどんどん世に出てくれば本当に心強いね。
>>all
皆さんに、こうやってコメントやブクマコメントで意見を言って頂けて本当に感謝です。
僕の中で朧気ながら見えた答えってのは、自分がその CSS の面倒を一生見るんであれば invalid でも全然構わない。でも、自分以外の誰かが関わる可能性が少しでもあるんであれば、仕様に沿った valid な CSS を書いておく責任が発生するんじゃないのかなあってことでしょうか。
ちなみに、トップページで CSS Validation Service にリンクしている理由は、別に valid を主張しているのではなくて、もしかしたら僕の拙い CSS を参考に見てみたいと思う人がいるかも知れなくて、そんな人のためにツールを使わなくてもコードを見られるようにしておいた方が良いかなっていう考えからです。