少し前にCSSWringにCSSハックを維持するオプションを付けた。デフォルトはオフで、必要ならばpreserveHackstrueにするという形で、CLIツールでも--preserve-hacksオプションで有効にするという形にした。これに対してデフォルトで有効であるべきじゃないかというイシューが立てられた。大体のことはそこで答えて、オフのままであるべきだと考えていると主張しておいたけど、もうちょっと書きたい。

CSSの圧縮ツールの場合、対処すべきバグというのは大きく二つに分けられる。ひとつはブラウザーの実装バグで、これはCSSを書く上でどうしようもないことなため、ある程度は考慮する必要がある。もうひとつがCSSコード自体のバグだ。こちらは、どれが単なるCSSのコードのバグでどれがCSSハックによる作為的なバグなのかを切り分けることがとても難しい。そういったコードを含むCSSが正確にパースされるかどうかもわからないので、ツールはもちろんパーサー側でも取り扱いには困難が伴う。

CSSハックは多くの場合はブラウザーの実装バグを悪用したものではあるが、ちゃんとした実装ならばCSSのバグとみなされるものがほとんどだ。そしてそういったバグを利用してでも特別扱いが必要なブラウザーがあることも確かでもある。しかしそれは実装の上でも明確に区別して扱われるべき、具体的にはshame.cssのようなアプローチにより、本流のコードとは別に管理されるべきだと思う。

またCSSの圧縮とCSSハックは相容れないとも感じる。仮に改行や複数の空白文字を使ったCSSハックなどが編み出された時、主にそういったものを削除するためのもであるCSSの圧縮ツールでどう扱えばいいのか、と考えるとそうなってしまう。これは極端な例だが、つまり「無駄」なものを削除するためのものが、「無駄」を利(悪)用したテクニックについて考慮するというのはよくわからないというような話だ。どこまでサポートすべきかという判断も難しい。

ツールは処理する対象のバグに寛容であるべきではない。なので、そういったバグをデフォルトで見逃すようなツールは作るべきではない。