On Fri, 27 Nov 2009 20:42:16 -0000, Daniel Stalica <d...@s...info>
wrote:

> Ależ oczywiście, masz rację... tylko, że... heh szukamy właśnie sposobu
> na ukrycie kawałka CSS przed walidatorem, może poczytaj ze zrozumieniem
> o co chodzi? Powyższy sposób (ten mój) jest tak samo głupi jak
> postawiony problem, my to wiemy. Daj pomysł jak to obejść, a nie
> wyjaśniaj rzeczy oczywistych...

Ależ ja dokładnie nabijam się z tego, że szukacie sposobu na ukrycie CSS
przed walidatorem.

--
http://pornel.net
this.author = new Geek("porneL");

do góry

porneL pisze:
> On Fri, 27 Nov 2009 20:42:16 -0000, Daniel Stalica <d...@s...info>
> wrote:
>
>> Ależ oczywiście, masz rację... tylko, że... heh szukamy właśnie
>> sposobu na ukrycie kawałka CSS przed walidatorem, może poczytaj ze
>> zrozumieniem o co chodzi? Powyższy sposób (ten mój) jest tak samo
>> głupi jak postawiony problem, my to wiemy. Daj pomysł jak to obejść, a
>> nie wyjaśniaj rzeczy oczywistych...
>
> Ależ ja dokładnie nabijam się z tego, że szukacie sposobu na ukrycie CSS
> przed walidatorem.
>

no niech będzie :)

--
Wkłady kominowe: http://twojkomin.pl

do góry

Daniel Stalica pisze:
> porneL pisze:
>> On Fri, 27 Nov 2009 16:13:48 -0000, Daniel Stalica <d...@s...info>
>>> Np. w PHP sprawdzać USER AGENT, google powie ci więcej...
>>
>> Bezsens. Walidator ma ostrzegać przed błędami. Ukrycie błędu przed
>> walidatorem nie zmienia faktu, że błąd istnieje.
>>
>> To, co walidator pokazuje jest informacją dla autora. Zamiast bawić
>> się w wykrywanie user-agent równie dobrze możesz usiąść i głośno
>> powtarzać "lalalalalala błędów nie ma lalalalala".
>>
>
> Ależ oczywiście, masz rację... tylko, że... heh szukamy właśnie sposobu
> na ukrycie kawałka CSS przed walidatorem, może poczytaj ze zrozumieniem
> o co chodzi? Powyższy sposób (ten mój) jest tak samo głupi jak
> postawiony problem, my to wiemy. Daj pomysł jak to obejść, a nie
> wyjaśniaj rzeczy oczywistych...
>

Ehh jeśli tylko o to chodzi... bierzez IP(iki) validatora :) a pozniej w
kodzie kawałek:

if($ip!=wiadomo_co) { echo "pseudo-zgodny-hack" }

i po problemie :) Kiedyś musiałem tak robić scroll="no" w jakiejś
przeglądarce nie działało CSSami dla body.

+ : nie angażujesz JS do pracy ;)
+ : przesyłasz mniej danych przy każdym otwarciu
- : dodatkowy ifik w kodzie, wpływający na czas jego wykonania

Czyli koszty transferu mniejsze ;) czas wykonania o grosz większy.

Pozdr,p.

do góry

> Ależ ja dokładnie nabijam się z tego, że szukacie sposobu na ukrycie CSS
> przed walidatorem.

Czyli proponujesz nauczyć się żyć z tym, że albo mamy błąd w CSS albo
godzimy się na niewłaściwe zachowanie się strony WWW z punktu widzenia
klienta?

W międzyczasie Paweł zaproponował inny atrybut stylu, który robi to co
chciałem osiągnąć (choć jeszcze nie zweryfikowałem) i jest zgodny z CSS. Tak
więc dalsza dyskusja być może ma charakter jedynie poglądowy.

do góry

On Fri, 27 Nov 2009 21:34:53 -0000, Marek <m...@s...interia.pl>
wrote:

>> Ależ ja dokładnie nabijam się z tego, że szukacie sposobu na ukrycie
>> CSS przed walidatorem.
>
> Czyli proponujesz nauczyć się żyć z tym, że albo mamy błąd w CSS albo
> godzimy się na niewłaściwe zachowanie się strony WWW z punktu widzenia
> klienta?

Ukrycie błędnego kodu *tylko przed walidatorem* nic nie zmienia.
Wszystkie przeglądarki i tak dostaną kod z błędem.

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!


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


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.

--
http://pornel.net
this.author = new Geek("porneL");

do góry

> 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.

do góry

Dnia Fri, 27 Nov 2009 23:36:17 +0100, Marek napisał(a):

>> Ukrycie błędnego kodu *tylko przed walidatorem* nic nie zmienia.
>
> Zmienia to, że klient będzie zadowolony ze spełnionego postulatu
> poprawnej walidacji CSS.

Problemem może być to że nie istnieje coś takiego jak walidator css
którym może posługiwać się laik (w tym przypadku klient). Jeśli klient
nie potrafi czytać wyników walidatora to po prostu nie powinien tego
robić. Walidator _NIE_JEST_ narzędziem dla klientów, tylko dla
webmasterów. Szczególnie walidator CSS.

A w razie czego zawsze możesz klientowi powiedzieć że piszesz w CSS3.2 i
jak ustawi taką opcję w walidatorze to nie będzie czerwonego :)

Poza tym ciesz się że się klient do Cythii nie dorwał, dopiero miałbyś
zabawę!

Przy okazji - następnym razem sprawę walidacji przedyskutuj z klientem
_przed_ podjęciem się wykonania zlecenia, a nie po.

ethanak
--
mailto=window.atob('ZXRoYW5ha0Bwb2xpcC5jb20=');
http://milena.polip.com/ - nie czekam na Ivo!

do góry

> A w razie czego zawsze możesz klientowi powiedzieć że piszesz w CSS3.2 i
> jak ustawi taką opcję w walidatorze to nie będzie czerwonego :)

Póki co temat udało mi się obejść gdyż ktoś zaproponował mi styl "bardziej
współczesny" nież ten, który powodował problem. Tak czy owak sytuacja była
dla mnie trochę frustrująca. Im mniej dyskusji z tym klientem tym lepiej.
Muszę trzymać się nieszczęsnej w/w wytycznej.

> Przy okazji - następnym razem sprawę walidacji przedyskutuj z klientem
> _przed_ podjęciem się wykonania zlecenia, a nie po.

Było przed... to był główny postulat. Było tam znacznie więcej absurdalnych,
które sprostowałem lecz ten jeden pozostał. Założyłem błędnie, że da się to
zrobić. Problem tylko stanowiły ramki wokół Flashy pod FF. Tego nie
przewidziałem.

do góry

W dniu 09-11-28 20:13, Marek pisze:
> Było przed... to był główny postulat. Było tam znacznie więcej
> absurdalnych, które sprostowałem lecz ten jeden pozostał. Założyłem
> błędnie, że da się to zrobić. Problem tylko stanowiły ramki wokół Flashy
> pod FF. Tego nie przewidziałem.

No nie wiem, czy żądanie poprawnego kodu to absurdalne wymaganie. Albo
się umie napisać stronę/aplikację, albo nie. Ot co.

tm

do góry

Dnia Sun, 29 Nov 2009 13:57:08 +0100, Tomasz Muszyński napisał(a):

[...]
> No nie wiem, czy żądanie poprawnego kodu to absurdalne wymaganie. Albo
> się umie napisać stronę/aplikację, albo nie. Ot co.


Poprawny != któryśtam walidator go rozumie.

ethanak
--
mailto=window.atob('ZXRoYW5ha0Bwb2xpcC5jb20=');
http://milena.polip.com/ - nie czekam na Ivo!

do góry