CSSは機械語なみの低級言語 « hidetox.com blog に追記。
CSSには「スコープ」という概念がない。すべてがフラット。グローバル・スコープ。だからCSSファイルをいくら分割@importしたところで、そんなの関係ねぇ。思わぬところで干渉してしまう。原因究明が困難。スパゲティ・コード、というよりも、CSS自体がパスタボウル。
XHTMLとCSSは分離せずに一体化させたほうが「モジュールとしての再利用性」が高まるのでは？ プログラミング言語では「オブジェクト指向」でデータと処理をバンドルしたように。
例えばTextMateでHTMLを編集するときは左端の行番号表示のところにブロック単位の表示フィルタ・コントロールが出る。defとendで括られたメソッドなどの単位で、一時的に非表示にできたりする。HTMLエディタにこういう機能を作るのは簡単なんだから、XHTMLのbody中、例えばある意味のある情報単位のボックス(div)のとなり（ソース上で隣接した場所）にCSSを埋め込んだらいい。<style>タグというよりもxml:nsによる解決策のイメージ。そしてエディタではタブなどで XHTML/CSS/Both のビューを切り替えられるようになっていればいい。
このアイデアはどうだろう？
あ、これってJavaScript使えば現状でも実現可能ですわ。ブラウザは未知のタグやネームスペースの要素を無視してくれるから。普通にソース中に埋め込んでしまえばいい。それをJavaScriptで処理したうえでStylesheetsにつっこめばいい。 スクリプトならエラーが出たときの行数が出るので、こういう処理をするとエラー行番号が分からなくなって困る（Rubyでevalブロック中のエラーのように）わけだが、そもそもCSSのエラー行番号なんてあまり役に立っていないと思うので、とくに問題は増えていない気がする。どう？
あ、ちなみに、これってXMLだから安心してやれることかもしれない。まあ実務上はべつに仕様がどうとか関係ないけど、XMLの仕様として拡張可能であることは、安心して勝手な拡張をしていい、ということになる。そういう草の根的な動き（※注：企業がやるのも含めて、非標準化団体による推進という意味で）によって新たな拡張が標準（デファクト）になるケースだってある。RSSのAuto-Discoveryだってそういうもんじゃなかったか？ 要素ではなく属性による解決（よりライトウェイトなので影響度が少ないはず、という点でスマートだと思う）であるmicroformatsもそういう存在。そういう意味では、以前このブログで「XHTMLがXMLだろうがSGMLだろうがブロークンだろうが関係ない」と書いてしまったけど、まあ実務上は実際に関係ないけど、UA(user agent)実装者などにとっては大きいな。うん。
