9.10.2009 / Komentarze

Standardy czy kompatybilność?

  • Facebook Polub
  • LinkedIn Opublikuj
  • Twitter Udostępnij
Bartek Cymer
Dodał: Bartek Cymer
Managing Director / peppermint
 

Zgodność ze specyfikacją W3C od dawna jest argumentem pro agencji interaktywnych. Za dobry nawyk uznajemy stosowanie tych najbardziej rygorystycznych - XHTML 1.0 Strict. Jednak w dalszym ciągu można spotkać się z niemiłą reakcją gdy promowany przez nas serwis nie przechodzi pozytywnie walidacji. Czy aby na pewno i za wszelką cenę musimy brnąć w kierunku stuprocentowej zgodności ze standardami?

Uważam, że ślepe podążanie za specyfikacją mija się z celem. Specjalista od lat kodujący serwisy siłą rzeczy jest zaznajomiony ze standardami, a jeśli strona nie jest z nimi stuprocentowo zgodna nie świadczy to wcale o braku jego profesjonalizmu. W tej chwili na pierwszy plan wysunęła się kwestia użyteczności serwisów i ich kompatybilności z różnymi przeglądarkami i platformami - ja także uznaję to jako sprawę priorytetową. Myślę, że specyfikacje powinny być traktowane raczej jako rekomendacje niż reguły.

Oczywiście podejrzewam, że gdyby np. WCAG nie było li tylko rekomendacją, lecz istniałby odpowiedni walidator, to znacznie więcej mielibyśmy stron z ułatwieniami dla osób niedowidzących. Byłyby to strony 1:1 zgodne z tymi założeniami. Jednak coraz częściej producenci stron wykazują wiele swojej inwencji tworząc bardzo przyjazne użytkownikom rozwiązania.

Zdrowe podejście do sprawy standardów wydaje się mieć Google. Oficjalnie obalili mit, jakoby poprawna walidacja serwisu ułatwiała jego pozycjonowanie. Czy oznacza to, że mamy robić niepoprawne składniowo serwisy? Wprost przeciwnie - Google promuje serwisy z wzorową architekturą informacji i poprawnym zapisem semantycznym. Ważne jest, żeby serwis był odbierany przez bota dokładnie tak samo jak przez użytkownika.

Trudnym elementem są też wszelkiego rodzaju WYSWIGi - zwłaszcza te wykorzystywane zgodnie z przeznaczeniem, czyli obsługiwane przez osoby nie posiadające żadnej znajomości HTMLa. Za prostotę wstawiania treści i bogate możliwości edycyjne płacimy niepoprawnym kodem źródłowym. Oczywiście można taki kod automatycznie czyścić, autor pozostanie jednak nie do końca przewidywalny - zwłaszcza gdy treść wklejana jest z Worda, osadzany jest film video, widget itp. W tym przypadku podążanie za standardami również jest ślepym zaułkiem.

Naszym zadaniem jest poprawne wyświetlenie treści z edytora, po bezproblemowym jej wprowadzeniu i ograniczenie zapędów początkujących użytkowników do nadmiernego stylowania  (czerwony, zielony, kursywa, pomarańczowy, pogrubiony).

Podsumowując, o ile zgodność ze standardami jest jak najbardziej pożądana, trzeba wypracować rozsądny kompromis. Serwis poprawnie wyświetlający się, kompatybilny z wiodącymi przeglądarkami, w którym kosztem standardów osiągnęliśmy zamierzony cel w niczym nie ustępuje temu przechodzącemu walidację.

  • Facebook Polub
  • LinkedIn Opublikuj
  • Twitter Udostępnij
Tag arrow
Chmura tagów

Tagi: standardy, w3c, xhtml


Komentarze (4)
 1 / 1 
meg
1. meg 11.10.2009 / 21:43
Mam pewną watpliwości, co do przesłania artykułu i intencji autora. Na wstępnie postawione jest pytanie:" Czy aby na pewno i za
wszelką cenę musimy brnąć w kierunku stuprocentowej zgodności ze standardami?" (w domyśle W3C).
Czekałam na odpowiedź w stylu:
a) NIE, bo jeśli projektant projektuje na przykład www z ofertą wyczynowych (tylko) rowerów górskich, w grupie docelowej osób niedowidzących może będzie jeden promil. Wtedy pieniądze przeznaczone na dostosowanie strony do standardów nie zwrócą się. Oczywiście pomijając zimną finansową kalkulację można tą niedrogą pracę wykonać dla prestiżu.
b) TAK, bo zawsze, bez względu na produkt i jego przeznaczenie należy uwzględniać standardy W3C. Po pierwsze dlatego, że społeczeństwo się starzeje, a starsze osoby stanowią dużą grupę konsumentów. Po drugie dlatego, że uznajemy, że nawet jeśli tylko jeden użytkownik strony www jest niedowidzący lub nie słyszy, należy ułatwić mu korzystanie z zawartości strony www. Bo tak!

Tyle, że na końcu jest puenta: " Serwis poprawnie wyświetlający się, kompatybilny z wiodącymi przeglądarkami, w którym kosztem standardów osiągnęliśmy zamierzony cel w niczym nie ustępuje temu przechodzącemu walidację" Hmmmm... Mam wrażenie, że mowa o dwóch różnych sprawach. Po pierwsze kwestia poprawnego wyświetlania się strony pod różnymi wiodącymi przeglądarkami może, ale nie musi dotyczyć osób niepełnosprawnych. Bo o ile osoba upośledzona ruchowo będzie korzystać np. IE7 lub FF, to osoba niewidząca będzie korzystać z przeglądarki głosowej. Czyli strona jedynie dostosowana do wiodących przeglądarek BĘDZIE ustępować stronie przechodzącej poprawnie walidację - czyt. zgodniej ze standardami W3C.
Osiągnięcie zamierzonego celu (kosztem standardów) to też nie do końca sukces projektanta - chociaż można i trzeba te kwestie od siebie oddzielić. Strona może przynosić miliony, bo jej celem jest sprzedawanie i działać pod tym kątem dobrze, ale może w ogóle nie odpowiadać potrzebom osób niepełnosprawnych. A konsekwencje to: kiepski PR, i świadome ograniczanie zysków - no bo przecież mogłaby przynosić milionyx2. Ludzie niepełnosprawni też mają pieniądze.
Chcę powiedzieć tylko tyle, że z której strony by tej kwestii nie oglądać strona kompatybilna z wiodącymi przeglądarkami, bezbłędnie realizująca cel właściciela może ustępować i z wielu powodów ustępuje tej przechodzącej walidację. Tyle, że co ma piernik do wiatraka :)
Robert Drózd
2. Robert Drózd 12.10.2009 / 13:29
Standardy nie muszą być celem samym w sobie - powinny być raczej środkiem do celu. Poprawny składniowo kod pomaga zarówno o osiągnięciu celów dostępności, jak i kompatybilności. Tak więc standardy powinny być regułą - od której odstępujemy dopiero wtedy, gdy np. dostosowanie jest nieopłacalne, albo niemożliwe.

Przy czym zastrzeżenie: używanie WYSIWYG nie jest żadnym usprawiedliwieniem dla złego kodu, bo:
1) kod można skutecznie czyścić, choćby dla TinyMCE są pluginy obsługujące wklejanie z Worda
2) w zasadzie czyszczenie (oraz ograniczanie aplikacji WYSIWIG tylko do pewnych funkcjonalności) jest konieczne ze względów bezpieczeństwa i wydajności. Tekst wklejony z Worda potrafi w postaci kodu parukrotnie większe rozmiary.
Bartek Cymer
3. Bartek Cymer 12.10.2009 / 22:53
I taka była intencja tekstu - standardy są celem nie tylko samym dla siebie. Problem pojawia się wtedy kiedy ślepo ich przestrzegamy, nawet kosztem uszczerbków w funkcjonalności serwisu. Niejednokrotnie wykorzystuje się hacki np. omijające zabroniony target=_blank w XHTML 1.0 Strict. Według mnie strona korzystająca z takich obejść, mimo że waliduje się poprawnie, nie jest stroną spełniającą standard opisany w specyfikacji w3c. W takiej sytuacji można zejść o poziom niżej z restrykcyjnością XHTMLa.
To, że standardy nie mają nic wspólnego z kompatybilnością nie jest prawdą. Częstokroć IE (głównie 6 ale nie tylko) wymusza na nas stosowanie hacków, które nie przejdą walidacji lub jeśli nawet to nie są one opisane w specyfikacji a więc siłą rzeczy nie są z nią zgodne.

Co do WYSWIG 1) tak - jak najbardziej i 2) właśnie o owo ograniczanie funkcjonalności się rozchodzi, udostępniając taki kombajn, w którym można zrobić dosłownie wszystko, czyszczenie nie zawsze jest w 100% skuteczne.
Tomasz Kępski
4. Tomasz Kępski 14.10.2009 / 11:16
Język HTML, czy XHTML (często niesłusznie w obiegowej opinii traktowany jako "ten lepszy", no bo ma x na początku ;-) ) jest opisany zbiorem reguł. Tak jak np. język polski. Jeśli reguły nie są spełnione to w zależności od kalibru mamy albo błędy albo całkowitą dyskwalifikację tekstu/kodu jako reprezentanta języka.

Jeśli w wypracowaniu pojawiają się błędy ortograficzne, stylistyczne, gramatyczne to do pewnego poziomu jest to czytelne. Jednak po przekroczeniu pewnej granicy tekst przestaje być zrozumiały. Spróbuj komisji sprawdzającej prace maturalną powiedzieć, że nagminne błędy ortograficzne to kompromis.

Bardzo tolerancyjne przeglądarki przyzwyczaiły webmasterów do niedbałości o jakość kodu i nie zgodzę się, że "Specjalista od lat kodujący serwisy siłą rzeczy jest zaznajomiony ze standardami". Miałem okazję poznać prace koderów z wieloletnim doświadczeniem, których kod należałoby ze wstydem ukryć. Właśnie podejście "po co mi standard skoro się dobrze wyświetla w wiodących przeglądarkach". Tyle, że nowa wersja przeglądarki wyjdzie i kod może trzeba będzie przepisać, albo co gorsza dorzucić kilka haków. A tej mniej popularnej w ogóle się nie da odczytać.

Gros z popełnianych błędów usprawiedliwianych "kompromisem" da się uniknąć poprzez zrozumienie dlaczego tak, a nie inaczej specyfikacja mówi i wyrobienie dobrego nawyku = brak nakładu czasu i pracy w przyszłości.

100% poprawność kodu nie zawsze jest realizowana, ale podstawowa różnica jest między postawami i tak się wyświetli mniej więcej dobrze w wiodących przeglądarkach, a świadomie stosuję elementy spoza standardu, bo np. wnoszą coś dla użytkowników, albo niestety muszę dodać to i owo ze względu na IE Choć w tym ostatnim często lekiem są komentarze warunkowe- zgodne ze składnią opisaną w specyfikacji a dają pole do popisu i pozwalają precyzyjnie zdefiniować docelową przeglądarkę.

Reasumując HTMLowemu bałaganiarstwu mówimy nasze zdecydowane NIE.

Przy okazji 100% walidacja kodu nie jest warunkiem dostępności strony. Choć niewątpliwie jakość kodu ma wpływ na dostępność.
 1 / 1 
Trwa zapisywanie komentarza
Dodaj komentarz
Zaloguj się
Jeśli nie masz jeszcze konta w Interaktywnie.com - możesz się zarejestrować albo
wymagane
 
obrazek nieczytelny
 
 
wyślij
wizytówki firm
szukasz klientów dla firmy?
NuOrder
 
Arrow
newsletter
Arrow
Loader
Up Down
ostatnie komentarze
 
Dołącz do społeczności interaktywnie.com
 
 
 
 
© 2019 interaktywnie.com. All rights reserved.