> Ukrycie błędnego kodu *tylko przed walidatorem* nic nie zmienia.

Zmienia to, że klient będzie zadowolony ze spełnionego postulatu poprawnej
walidacji CSS. A do tego FF będzie też zadowolony bo wykona dyspozycję w tym
"niepoprawnym" CSS i nie będzie rysował ramek wokół Flasha.

> Wszystkie przeglądarki i tak dostaną kod z błędem.

To małoistotne jest. Ważne, że zareagują poprawnie.

> To tak jakbyś napisał post na usenet z błędami ortograficznymi, ale przed
> wysłaniem przepuścił go przez komputerowy sprawdzacz pisowni i przy każdym
> wskazanym błędzie wybierał opcję "dodaj do słownika". Wtedy sprawdzacz
> pisowni powie ci, że post jest bezbłędny! Super!

Troszkę inaczej bym to ujął. Jest źle, że słowo Klient Word 2007 pisze z
dużej litery a podkreśla je gdy jest pisane z małej. Jednakże dokument piszę
na komputerze cudzym i nie chcę aby Word podkreślał mi to słowo, które wiem,
że dobrze piszę. No i szukam obejścia.

> Oszukując walidator oszukujesz tylko swoje narzędzie. Kod zadziała w
> przeglądarkach (lub nie) niezależnie od tego, do czego zmusisz walidatora.

Kod zadziała na FF i zniesie niekorzystny efekt - sprawdzałem. Dla IE kod
nie ma znaczenia.

> W przypadku CSS wystarczy zrozumieć reguły interpretacji błędów opisane w
> specyfikacji:
>
> http://www.w3.org/TR/CSS21/syndata.html#parsing-erro
rs
> Z których wynika, że nieznane właściwości są po prostu ignorowane.

Klient widzi ERROR na czerwono po przepuszczeniu przez walidatora. Wszystko
co usłyszałem to "ma go nie być". Nie trafia argumentacja, że zostanie
zignorowany.