Aby strony internetowe były dostępne dla wszystkich, wymyślono standardy programowania. Organizacja W3C zajmuje się standaryzacją sieci, promuje strony dostępne dla użytkowników, wskazuje kierunki rozwoju, dostarcza narzędzia i oprogramowanie ułatwiające poprawne tworzenie aplikacji internetowych. Jednak wielu web developer’ów nie przestrzega tych zasad, z uwagi na fakt, że wymagają one znacznie więcej niż podstawowych wiadomości, a tworzenie zgodnie ze standardami zajmuje więcej czasu. Niemal wszystkie z dostępnych narzędzi ułatwiających kodowanie stron, nie tworzy kodu zgodnego ze standardami – dlatego jeżeli nie piszesz kodu ręcznie, stworzenie strony zgodnej ze standardami jest praktycznie niemożliwe.
Dlaczego tak wiele stron jest niezgodnych ze standardami?
Opera przeprowadziła badania z których wynika, że 95% stron jest niezgodnych ze standardami W3C. Niestety nie sprawdzili, ile z tych stron jest zgodnych z obowiązującymi standardami. Bo zgodnie wiele standardów jest jeszcze „akceptowanych” (kompatybilność wstecz), ale nie powinno się ich już stosować.
Strony są tworzone niezgodnie ze standardami, ponieważ mnóstwo aplikacji (takie jak Dreamweaver, Contribute, Frontpage), jak i systemów CMS tworzy kod, który można by ocenić jako „śmietnik”. A taki śmieciowy kod sprawia tylko kłopoty. Sprawia problemy w różnych przeglądarkach, sprawia problemy czytnikom stron których używają osoby niedowidzące, wreszcie utrudnia webdeveloperom skuteczną rozbudowę strony. Bo jedna zmiana powoduje wiele nieprzewidzianych efektów. To tak jakby wstawić nowe okno i martwić się, czy dom się nie zapadnie. Strony niezgodne ze standardami są właśnie takie.
Niesamowite jest to, że wiele systemów CMS, jak i stron jest prezentowanych jako zgodne ze standardami, jednak żaden – ŻADEN – z testowanych przeze mnie systemów nie generuje kodu zgodnego ze standardami! Często na takich stronach znajduje się odnośnik który umożliwia sprawdzenie kodu xhtml. Jednak kliknięcie w taki link generuje listę błędów znajdujących się na stronie. Czemu ma taki link służyć – oprócz wprowadzania w błąd – nie jestem w stanie dociec. Tym bardziej że nawet bez linku każdy może sprawdzić zgodność strony ze standardami wykorzystując ten link: http://validator.w3.org/
Robisz zgodnie ze standardami, albo licz się z konsekwencjami prawnymi
W Australii niezgodne z prawem jest tworzenie stron, których nie mogą obsługiwać osoby niepełnosprawne. Podczas olimpiady w Sydney, w 2000 roku, osoby niewidome i niedowidzące pozwały z tego powodu Sydney Olympics Organizing Committee, ponieważ osoby takie nie były w stanie kupić sobie biletów na olimpiadę. I sprawę wygrali więcej informacji tutaj: http://www.contenu.nu/socog.html. Na polskie realia wydaje się to może śmieszne, ale za 10 lat pewnie już tak śmieszne nie będzie – nawet u nas. Tym bardziej że UE już pracuje nad wprowadzeniem podobnych standardów.
Zalety kompatybilności
Poza kwestiami prawnymi, które jeszcze nas nie dotyczą, trzeba mieć na uwadze pozostałe argumenty
- pewność, że strona jest dostępna dla różnych użytkowników, różnych systemów i przeglądarek, a dzięki temu klient nie straci potencjalnego odbiorcy swoich produktów / usług kiedy strona u jednego się wyświetli prawidłowo, a u innego nie.
- strony zgodne ze standardami zajmują wyższe pozycje w wyszukiwarkach jak Google.
- nowe przeglądarki, czy nawet nowe wersje przeglądarek z niemal 100% prawdopodobieństwem będą poprawnie wyświetlały taką stronę.
- strona wygląda tak samo w różnych przeglądarkach. Bez zachowania standardów strona może wyglądać inaczej pomiędzy różnymi przeglądarkami. Od tej reguły zawsze będą istnieć wyjątki, jednak zachowanie zgodności ze standardami gwarantuje najwyższy procent kompatybilności między przeglądarkami.
Również sądzę, że powinno się przestrzegać standardów W3C, ale mam małe zastrzeżenie: wynik walidatora nie jest w pełni prawdziwym wynikiem. Podstawowym problemem, którego walidator nie wykrywa, to typ danych, jaki jest wysyłany w nagłówku. Z drugiej strony może to i dobrze, bo Internet Explorer niezbyt sobie z tym radzi.
Kolejną rzeczą jest to, że bardzo duży procent stron stoi na różnego rodzaju CMSach. W takim przypadku wygenerowanie prawidłowego kodu graniczy z niemożliwością, gdyż… treść musiałaby nie być edytowalna wizualnie, więc stroną musiałby zarządzać człowiek znający się na standardach i potrafiący z nich skorzystać.
Standardy to standardy, ale myślę, że najważniejsze jest to, aby kod renderował się praktycznie tak samo w każdej przeglądarce(nawet tekstowej, bo na takich bazują czytniki dla niewidomych). Podsumowując: ważne jest, aby koder znał standardy W3C, ale wg mnie nie musi się ich ściśle trzymać, ważne, aby strona była dostępna.
Ja jednak będę się trzymał tej wersji, że standardy zostały stworzone po to, aby ich przestrzegać. Ponadto, łatwiej jest zakodować stronę zgodną ze standardami, niż niezgodną – oczywiście zakładając, że się owe standardy zna. Poprawne pisanie kodu zmniejsza też do minimum różnice w wyświetlaniu strony w różnych przeglądarkach. Sam przekonałem się o tym nieraz, szczególnie w starszych wersjach IE był to problem.
Teraz koduję zgodnie ze standardami i jeżeli strona inaczej wyświetla się np. w IE to wiem że coś przeoczyłem, a poprawienie takiego błędu zajmuje mi chwilę. Brak zachowania standardów – szczególnie przy dużych serwisach – bardzo utrudnia, lub nawet uniemożliwia znalezienie błędu.
Przepraszam, ale się nie zgodzę, że poprawnie napisana strona w IE będzie się wyświetlała poprawnie. Ta przeglądarka ma swoje „standardy” i W3C nie ma z nią nic wspólnego. Może przy prostych layoutach nie ma problemu, ale w bardziej zaawansowanych, wręcz staje się to wielogodzinną pracą, aby stworzyć dodatkowy CSS dla IE.
Masz oczywiście rację. Tyle, że nigdzie nie napisałem, że strona zgodna ze standardami wyświetla się dobrze w IE. Napisałem, że strona zgodna ze standardami maksymalnie minimalizuje (heh, maksymalnie minimalizuje…) różnice między przeglądarkami.
I teraz, jeżeli strona jest zgodna ze standardami, to poprawienie jej tak, aby nawet w IE wyświetlała się dobrze, to kwestia dosłownie chwili (zakładam, że zna się typowe błędy IE). Natomiast, jeżeli strona jest niezgodna ze standardami, to może się ona wyświetlać nieprawidłowo z różnych powodów, innych niż znane błędy IE.
Najdziwniejszy błąd, z jakim miałem do czynienia to że IE6 nie respektowało styli dla klas, które w nazwie miały myślnik „-”. Nie wiem dlaczego taki błąd występował, bo nigdzie nie mogłem znaleźć dla niego rozwiązania. Aż zauważyłem, że dla sprawdzanej podstrony mój kod posiada błędy, które wynikały z niepoprawnego wklepania kodu (tak, sam z palca wpisałem takie głupoty). Po poprawieniu – jak ręką odjął – klasy były rozumiane przez IE6 poprawnie. Co najciekawsze, w innych warunkach nie potrafiłem powtórzyć tego błędu, ale na tej jednej podstronie mogłem go powtarzać do woli. Taka zagadka. Najgorsze, że gdyby kod posiadał cały czas błędy, to w życiu bym nie doszedł do tego jak naprawić ten specyficzny problem w IE. Stąd będę się upierać, że lepiej pisać od razu kod zgodny ze standardami, a podczas pisania mieć na uwadze typowe błędy IE. Do tej pory mnie ta metoda nie zawiodła, stąd wszystkim polecam.
Na jakimś innym blogu czytałem, że trzymanie się standardów daje wykonawcy dodatkowe argumenty, gdy klient ma zastrzeżenia, co do profesjonalizmu wykonania strony.
Właściwie nigdy nie traktowałem kwestii standardów jako argumentu przetargowego. Raczej trzymam się standardów, bo uważam że tak powinno się tworzyć strony. Druga sprawa, że tak jest mi jest nawet wygodniej, a dodatkowo mam świadomość dobrze wykonanej pracy pod którą mogę się podpisać.
No ale o czy my mowimy Panowie!
Wystarczy spojrzec na te strone:
- 5 bledow html
- 11 bledow css.
LOL
Zgadza się, to jest kwestia o której wspomniałem w tym artykule. Błędny kod to już wina samego WordPress’a. Ten niewalidowalny kod html pochodzi bezpośrednio z jego core i nie może być zmieniony bez ingerencji w kod php – a nie ma sensu tego robić, bo przy kolejnej aktualizacji zmiany znowu zostaną nadpisane.
Jedną rzecz trzeba powiedzieć – kod WordPressa jest niewalidowalny, ALE akurat tutaj jest to zaleta. Dlaczego? Ponieważ te błędy pochodzą wyłącznie z tego, że WordPress używa w formularzach atrybutu „aria-required”, który nie istnieje w specyfikacji w3c. Natomiast ten atrybut służy do tego, aby strona była bardziej dostępna jeżeli chodzi o WAI. To taki paradoks, gdzie standardy nieco kłócą się z dostępnością strony.
Co do błędów css – tutaj masz rację, po prostu zainstalowałem skórkę i nie zwracałem uwagi czy css jest dobry czy też nie. Ważniejszy dla mnie był wygląd samej skórki.