O tym, że przejście ze specyfikacji Transitional na Strict trwa zbyt długo pisało już wielu autorów, w tym Roger Johansson. I odkąd zajmuję się stronami – również byłem zwolennikiem tego, by podchodzić do kodu jak najbardziej rygorystycznie. Z tym, że z czasem zauważyłem, że na pewne zmiany jest za wcześnie i zamiast narzucać pewne reguły, trzeba by się zastanowić, czy jesteśmy w ogóle w stanie je spełnić.
Dawno nie poruszałem kwestii technicznych na swoim blogu, więc przypomnę jedynie, że jestem umiarkowanym przeciwnikiem XHTML w warunkach komercyjnych, skłaniającym się w stronę “HTML5″.
Zatem, czy jesteśmy w stanie spełnić wymogi specyfikacji Strict, nawet na poziomie zwykłego HTML, bez marketingowego “X”?
My, jako twórcy – owszem - w pewnym zakresie - jesteśmy. Czy przeciętny, nietechniczny, użytkownik końcowy jest w stanie spełnić wymogi stawiane mu przez technologię? Nie, nie jest.
Patryk Zawadzki poruszył kwestię semantyki w dokumentach biurowych – kwestię, która wychodzi poza wybór Worda czy Excela do napisania dokumentu, bo dotyczy także kreowania treści w stronach internetowych.
Warto bowiem zwrócić uwagę na fakt, że w dyskusjach przed projektem niemal każdy stwierdza, że treść jest najważniejsza. Lecz kiedy przychodzi czas jej wprowadzania okazuje się, że jest to element traktowany kompletnie po macoszemu – zajmuje się tym osoba, która nie ma o tym pojęcia.
I naprawdę, nie jest to kwestia edytorów – nieważne czy taka osoba dostanie FCKEditor, TinyMCE, składnię wiki czy markdown. To tylko narzędzia – tak, jak nie da się zabronić człowiekowi użycia siekiery w charakterze broni, tak nie da się go zmusić do tego, by nagłówek był nagłówkiem, akapit akapitem a tabela tabelą. Jako deweloperzy mamy prawo i obowiązek edukować klientów i użytkowników końcowych w tworzeniu semantycznych dokumentów.
A na razie, dopóki liczba ludzi kompetentnych nie zmarginalizuje tych niekompetentnych (wyeliminować niekompetencji całkowicie się nie da), nie warto pchać się w technologie zbyt rygorystyczne. Jeśli nie mamy kontroli nad tym, jak ostatecznie będzie wyglądała strona i kto będzie nią zarządzał, lepiej brać pod uwagę najbardziej pesymistyczne scenariusze i z góry uprzedzać przeglądarkę, że ładuje kod, który potencjalnie stał się zupą tagów. To, czy będzie to XHTML czy HTML zależy tylko i wyłącznie od wiedzy i umiejętności nazwania rzeczy po imieniu.
Z komercyjnego życia – niedawno prowadziłem projekt klientowi, który na etapie specyfikacji określił, ku mojemu miłemu zaskoczeniu, że chciałby by strona spełniała wymogi XHTML Strict, WAI-AA i była w pełni nawigowalna z poziomu przeglądarek tekstowych.
Żadnego flasha, żadnych splashów, żadnych javascriptowych rozwijalnych menu.
Nie jest to co prawda pierwszy taki klient – coraz częściej się tacy świadomi klienci zgłaszają, lecz jest to wciąż margines zleceń. Problem pojawił się na etapie przedstawiania wyceny, gdy okazało się, że wprowadzenie treści to prawie 1/3 całego projektu (chodziło o wprowadzenie kilkuset dokumentów i produktów).
Powiązane wpisy:
by Luken
15 Oct 2006 at 18:41
Teraz klienci stawiają na “wypasioną” treść, coraz częściej się spotykam z kolesiami, którzy piszą treść w Wordzie, tam kolorują, powiększają itd. a później przychodzi mi mail proszę poprawić treść strony xxx i zastąpić nią treścią w załączonym dokumencie. Na ogół z takich metod wychodzi kupa. Cóż klient nasz pan.
by Michał Siek
15 Oct 2006 at 19:24
Kiedyś pisałem do paneli masę dodatkowych funkcji, które “porządkowały” kod. Teraz stwierdzam, że nie ma to większego sensu. I tak zawsze znajdzie się ktoś kto wymyśli przypadek, którego ja nie uwzględniłem.
Dane wklepuje zwykle jakaś tam Pani Tereska, która w nosie ma wszelkie standardy. Trzymanie się wzorców przypomina nieraz walkę z wiatrakami. Ludzie są leniwi. Ciężko to przeskoczyć.