|
STANDARDY W SIECI - ROZWAŻANIA I WSKAZÓWKI. Artykuł niniejszy adresowany jest do jak najszerszego grona internautów, szczególnie jednak - menedżerów, osób odpowiedzialnych za obieg informacji i publikacje w firmach, pracowników marketingu i samodzielnych webmasterów. Wielu z nich słyszało, że wdrożenie zgodności ze standardami czyni publikację w WWW lepszą co do oszczędności nakładów, łatwości zarządzania i wydajności.
Niestety, nie ma podręcznika, który mówiłyby, jak się do tego zabrać i jak zorganizować proces przekształcenia. Naturalna jest obawa, że nie da się tego zrobić w stosunku do rozległych zasobów. Brak też jasności co do tego, jakie właściwie są standardy sieciowe i jakie są pożytki z tego, że witryna WWW spełnia wymogi dostępności (accessibility). Prosimy zajrzeć do artykulu Standardy: po co, dlaczego i jak? np. do artykułu "Buy standards compliant Web sites" oraz artykułu na temat pożytków z dostępności - "Auxiliary Benefits of Accessible Web Design". Metoda, jaką proponujemy w niniejszym artykule, ma zastosowanie do witryn o każdej wielkości; od prywatnych, firmowych, aż po obszerne zasoby dużych korporacji. Pokażemy kolejne kroki, które mogą być wykonane przez każdego zainteresowanego, prowadzące od analizy istniejących zasobów WWW do organizacji nowej witryny. Każdy z tych kroków został opisany jako osobny etap, tak aby mógł być wykonany w różnym czasie, na rożnym poziomie i przez różne osoby, niezależnie od ich indywidualnych kwalifikacji, a zależnie wyłącznie od wdrożonej procedury.
Decyzja o zakresie kontroli Pierwszym krokiem jest ustalenie listy kryteriów, jakie posłużą do oceny poziomu zgodności ze standardami podczas wstępnej oceny witryny. Proponujemy, by listę taką ustalić wspólnym wysiłkiem zainteresowanych osób i pracowników. Mogłaby wyglądać następująco: * walidacja oznakowania
* walidacja arkuszy stylów
* dostępność
* internacjonalizacja
* metadane
* HTTP, właściwa konfiguracja serwera
* poprawność pisowni
* zgodność z firmowymi wymogami dla dokumentów (nagłówki, stopki, logo, podpisy, daty itd.) Proponujemy w każdym razie uwzględnienie czterech pierwszych kryteriów. Ich wyjaśnienie podane jest w dalszej treści artykułu. Niektóre z tych zagadnień mogą wykraczać poza doświadczenie i kompetencje zespołu odpowiedzialnego za witrynę. Należy wtedy poszukać osób kompetentnych w tych dziedzinach. Często zdarza się, że osoby takie są w zasięgu ręki (np. informatyk pracujący w zupełnie innym dziale) albo łatwo będzie je znaleźć, jeśli konkretne zagadnienie zostanie trafnie nazwane.
Analiza witryny Mając ustalone kryteria, można dokonać przeglądu witryny i ustalić jakie są problemy. Na początek dobrze byłoby ułożyć pełną listę adresów URI dokumentów składających się na witrynę. Nie jest to zadanie skomplikowane, można go wykonać za pomocą prostego robota, który podążając odsyłaczami między dokumentami sporządzi raport wszystkich URI - najlepiej w postaci czystego tekstu, po jednym adresie w każdym wierszu. Może się zdarzyć, że technologia na jakiej oparta jest witryna uniemożliwia robotom dostęp do dokumentów. Ale i wtedy warto sprawdzić czy i w jakim zakresie dokumenty witryny są niedostępne. Bowiem oznaczać to może także niedostępność witryny dla wyszukiwarek sieciowych, czyli blokowanie tego źródła ruchu na witrynie. Lista kryteriów oceny witryny może być pomocna do uruchomienia programu Log Validator, specjalnie przygotowanego dla pomocy przy analizie stanu witryn WWW. Log Validator działa na podstawie listy adresów URL i dokonuje analizy w ramach modułów wybranych podczas jego uruchmienia. (Będzie to jednym z zadań zespołu technicznego pracującego nad ulepszeniem witryny. Należy przedyskutować w tym zespole sposób dostosowania LogValidatora do konfiguracji witryny). Efektem takiej analizy jest mapa "stanu zdrowia" witryny i można wtedy przyjąć jakąś strategię jej naprawy i usunięcia błędów. W szczególności liczba dokumentów witryny nie spełniających przyjętych kryteriów może być bardzo duża. Na przykład wszystkie dokumenty okażą się systematycznie błędne z punktu widzenia ich walidacji. Nie należy załamywać rąk, bo może to być w gruncie rzeczy bardzo optymistyczna informacja. Otóż jeśli witryna korzysta z jakiegoś mechanizmu automatycznego generowania dokumentów na podstawie szablonów, to być może wystarczy tylko poprawić błędy w tych szablonach. Po poprawieniu szablonów należy powtórnie uruchomić testy. Mogą one wykazać mniej błędów lub brak błędów w ogóle. Jeśli za działanie automatu odpowiada konkretny programista lub firma, należy zwrócić się do nich by odpowiednio poprawili jego działanie. W przyszłości, gdy przyjdzie moment projektowania całkiem nowej witryny WWW, należy kierować się zaleceniami zawartymi w dokumencie "Buy standards compliant Web sites". Jeśli analiza nadal wykazuje błędne dokumenty, należy przejść do następnych etapów opisanych poniżej. Dodatkowa korzyść z pierwszego etapu jest taka, że mamy teraz konkretny obraz witryny w postaci kompletnej listy dokumentów. Przesunięcie części dokumentów w inne miejsce witryny czy też usunięcie jakiś zasobów może być teraz dokonane płynnie, to znaczy z odpowiednim przekierowaniem odsyłaczy do naszych zasobów z innych witryn czy wyszukiwarek. W ten sposób unikamy utraty ruchu na naszej witrynie i podnosimy jej jakość zgodnie z zasadą "dobre adresy są zawsze czynne".
Organizacja pracy Mamy teraz wykaz wszystkich dokumentów błędnych oraz obraz innych problemów i wad naszej witryny. Nie jest istotne, czy ta lista jest długa czy krótka - nie ma to wpływu na sposób postępowania. Pierwsza zasada dalszego postępowania brzmi: Nie poprawiaj błędów w dokumentach, dopóki nie poprawisz organizacji pracy ich tworzenia. Zabranie się od razu do poprawienia wszystkich błędów w dokumentach za jednym zamachem może być złym pomysłem z dwóch powodów: * jeśli błędów jest bardzo dużo, praca nad ich poprawieniem może być bardzo żmudna i zaabsorbować zespół ludzi na bardzo długo - zatem może być bardzo kosztowna,
* jeśli nie zostanie wdrożona procedura tworzenia bezbłędnych dokumentów, ilość błędów będzie się akumulować, a kolejne akcje ich poprawiania będą o tyle bardziej kosztowne, że wielokrotnie będą poprawiane te same błędy. Istotna jest kompleksowość naprawy błędów. Nie należy poprawiać dokumentów pod jednym kątem (np. walidacji oznakowania) zostawiając na razie na boku inne kryteria (np. dostępności czy walidacji stylów). To, co zostało naprawione z jednego punktu widzenia, może zostać zepsute, gdy przyjdzie do wprowadzania zmian wedle innych kryteriów. Zatem: nie naprawiamy wszystkiego za jednam zamachem ani nie dzielimy naprawy na różne etapy. Naprawiamy najpierw proces tworzenia dokumentów. Kluczem do sukcesu omawianej metody jest realistyczna ocena nakładów w stosunku do możliwych efektów. Zwłaszcza, gdy trzeba dokonywać wyborów. Dobrze jest spróbować zmierzyć na reprezentatywnej próbce dokumentów, ile czasu i jakich kwalifikacji wymaga ich naprawa. Da to pojęcie o tym, jakie środki trzeba poświęcić na realizację jakich zadań. Gdy już przyjdzie do planowania pracy, o wiele lepiej jest posługiwać się dzienną normą poprawionych dokumentów niż normą tygodniową czy miesięczną. Osobom odpowiedzialnym za to zadanie łatwiej będzie wywiązywać się z normy 5 dokumentów dziennie niż 25 dokumentów poprawianych raz w tygodniu. Proces naprawy dokumentów powinien być regularnie nadzorowany. Systematyczne spotkania i dyskusje pozwolą ustalić, czy często powtarzające się problemy wynikają z działania programów (systemu zarządzania dokumentami - CMS) czy samego sposobu pracy. Poprawy może wymagać zarówno organizacja pracy, jak i jakość używanych do niej narzędzi. Po pewnym czasie, zebrawszy doświadczenia we wdrażaniu tej metody naprawy, można będzie wyznaczyć sobie konkretne cele cząstkowe. Na przykład taki, że 50% ruchu na serwerze dotyczy dokumentów, które całkowicie spełniają założone kryteria. Następnie można podnieść poprzeczkę na 60% itd. Ważnym jest, by cokolwiek się bada, mierzy lub wyznacza, wyrażało się rozsądnie zakreśloną wielkością i składało się na osiągalny, ciągły proces doskonalenia. Warunkiem powodzenia procesu naprawy witryny WWW jest zaangażowanie doń każdego, kto bierze udział w procesie publikacji dokumentów. Dla ustalenia źródeł błędów należy poznać narzędzia, jakie są używane oraz sposób ich użycia. Można będzie wtedy określić czy problem dotyczy konkretnego narzędzia czy osoby, która go używa. Jeśli źródłem błędów jest jakieś narzędzie autorskie, należy zebrać opinie na temat jego działania i negocjować z twórcą narzędzia, by je poprawił. Dotyczy to zwłaszcza dużych firm, gdzie z tych samych narzędzi korzysta wielu użytkowników. Tędy prowadzi najbardziej efektywna droga do podniesienia jakości. O ulepszeniach należy głośno mówić - publicznie lub przynajmniej w ramach zespołu. Dla wykazania się osiągnięciami i dla zachęcenia innych.
Jak poprawić jakość witryny WWW?Program LogValidator, o którym wspomnialiśmy już powyżej, może pomóc z poprawie jakości witryny WWW przez wskazanie tych dokumentów. które są błędne. Domyślne działanie programu polega na progresywnej walidacji dokumentów. Zasada działania jest prosta: na podstawie logów serwera układana jest codziennie lista najczęściej pobieranych dokumentów. Pierwsze n dokumentów z takiej listy (n to liczba do ustalenia) wysyłanych jest do walidatora na serwerze W3C (W3C Markup Validator). Serwer ten zwraca wynik walidacji. Dlaczego tak? Pozwala to zacząć od poprawienia najczęściej pobieranych dokumentów i umożliwia ocenę jakości witryny głównie z tego punktu widzenia - nie zaś absolutnej liczby dokumentów. LogValidator jest programem o modularnej budowie, napisanym w języku Perl, zatem łatwo można dopisać do niego własne moduły uwzględniające własne potrzeby. Na przykład moduł sprawdzający poprawność pisowni albo moduł sprawdzający, czy każdy dokument zaopatrzony jest w odpowiednie logo i standardową stopkę. Albo też moduł sprawdzający aktualność odsyłaczy do innych dokumentów. Program LogValidator łatwo jest zainstalować na serwerze i jest on dostępny w archiwum CPAN. Po zainstalowaniu LogValidatora, można z niego korzystać na różne sposoby. Na przykład zespół pracujący nad naprawą witryny może co rano otrzymywać pocztą listę URL dokumentów, na które powinien zwrócić uwagę. Ich treść wymaga poprawienia albo źródło błędów leży gdzieś indziej i należy je odpowiednio raportować.
Przegląd Powyższa metoda pozwala krok po kroku poprawiać jakość witryny, lecz wymaga także ciągłego jej testowania, jeśli problemy wciąż się pojawiają. Co pewien czas, (np. co 3 miesiące) należy powtórzyć pełną analizę, by przekonać się, czy całość witryny uległa poprawie, a także lepiej określić problemy związane z szablonami służącymi do generowania dokumentów. Jest to też okazja do oceny realizacji celów, jakie postawione zostały na początku procesu. Jeśli jakość witryny nie poprawiła się, należy coś zmienić w samym procesie jej naprawiania. W końcu chodzi także o podsumowanie pracy zespołu, który realizował proces naprawczy, satysfakcję z wyników i utrwalenie zdobytego doświadczenia, które jest cenne dla organizacji pracy. Dlatego podsumowanie wyników naprawy powinno być należycie zredagowane i opublikowane. Stanowić będzie rodzaj podręcznika do utrzymywania witryny na wysokim poziomie jakości. Często firma posiada rodzaj oficjalnego podręcznika na temat kompozycji logo czy też kolorów firmowych w ich różnorodnych zastosowaniach. Taki podręcznik można uzupełnić o podstawowe techniki gwarantujące jakość dokumentów publikowanych w WWW.
Zachowanie osiągniętego poziomu jakości Techniki opisane w tym artykule mają charakter ogólny i wymagają konkretyzacji stosownie do lokalnych potrzeb. Jeśli proces publikacji podlega jakimś szczególnym wymogom albo wymogi takie zmieniają się, wtedy również proces kontroli jakości musi być zmieniany. Proponowane tu rozwiązanie co do oceny i poprawy jakości publikacji pomyślane jest jako zbiór takich komponentów, które nie wpływają na siebie nazwajem, zatem mogą być dowolnie usuwane bądź dodawane w razie potrzeby. Może się zdarzyć, że na jakiś problem nie można nic poradzić w sposób bezpośrednio skuteczny, bo jego rozwiązanie leży poza zasięgiem aktualnych możliwości. Na przykład używane jest narzędzie do publikacji, które generuje błędy w dokumentach. Pomimo różnych prób i zastosowania odpowiednich metod pracy, błędów tych nie udało się wyeliminować. Wtedy trzeba koniecznie spisać swoje doświadczenia i poinformować o nich producenta programu, pisząc w imieniu firmy. Można oczekiwać, że producent będzie liczył się z opinią użytkownika reprezentującego nabywców jego produktu. Dla utrzymania poziomu jakości witryny WWW pożądane jest nagradzanie dobrych własnych autorów i pomaganie tym, którzy mają kłopoty. Dla ogólnego sukcesu potrzebne jest przekonanie o pożytkach z obranej metody postępowania. Należy zachęcać osoby bezpośrednio zaangażowane w proces publikacji do zgłaszania kłopotów, jakie mają ze spełnieniem postawionych wymogów bądź z narzędziami, jakich używają. Jest to droga do usprawnienia organizacji całego procesu.
Konkluzje Opisana metoda jest prosta i była stosowana przez wiele lat wewnątrz W3C w celu zachowania poprawności dokumentów publikowanych na serwerze W3C. Może ona okazać się bardzo skuteczna także w ramach każdej innej firmy czy zespołu.
Podziękowania Dziękuję osobom, które przejrzały ten artykuł przed publikacją: Olivier Théreaux, Stephanie Troeth, Denis Boudreau oraz uczestnicy public-evangelist mailing-list.
Created Date: 2003-03-28 by Karl Dubost >
Ten adres e-mail jest ukrywany przed spamerami, włącz obsługę JavaScript w przeglądarce, by go zobaczyć
>
Last modified $Date: 2003/05/30 08:36:57 $ by $Author: ot $ Copyright © 2000-2003 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply. Your interactions with this site are in accordance with our public and Member privacy statements.
Standardy: po co, dlaczego i jak?
Status Niniejszy artykuł powstał w ramach działalności Grupy Roboczej ds. Jakości (Quality Assurance Interest Group). Wszelkie komentarze powinny być kierowane do publicznego dostępnego archiwum listy dyskusyjnej
Ten adres e-mail jest ukrywany przed spamerami, włącz obsługę JavaScript w przeglądarce, by go zobaczyć
lub prywatnie do Karla Dubost
Ten adres e-mail jest ukrywany przed spamerami, włącz obsługę JavaScript w przeglądarce, by go zobaczyć
. Autor dziękuje osobom, które poświęciły swój czas na przejrzenie artykułu i uwagi.
Wstęp Artykuł opisuje proste i dające się łatwo zastosować techniki podniesienia jakości witryny i zapewnienia poprawności strukturalnej dokumentów. Większość dokumentów w sieci WWW jest strukturalnie niepoprawna. Można założyć, że dotyczy to 99% dokumentów, choć brak jest ścisłych statystyk. Dlaczego tak się dzieje?
HTML i standardy Na temat niepoprawności dokumentów WWW istnieją typowe opinie i usprawiedliwienia, w większości wynikające z braku wiedzy na temat tego, czym jest walidacja. 1. Typowa opinia dyrektora naczelnego: "gdyby moje strony WWW wykonane były zgodnie ze standardami, byłyby nieciekawe i nie przyciągałyby klientów" Standardy W3C pozwalają osiągać wszelkie efekty na stronach WWW. Zgodność ze standardami nie ma nic wspólnego z ograniczaniem się do czystego tekstu. 
Standardy W3C obejmują obecnie zintegrowany zestaw technologii pozwalających na użycie pełnego wachlarza multimediów: XHTML (oznakowanie strukturalne), CSS (arkusze stylów), SVG (dwuwymiarowa, wektorowa animacja graficzna) oraz SMIL (synchroniczne multimedia). Obsługa tych technologii wynika z porozumienia wielu różnych firm obecnych na rynku WWW.
2. Typowa opinia dyrektora technicznego: "nie mam pieniędzy, by zadbać o standardy w ramach witryny WWW. To kosztuje za dużo". Trzymanie się standardów upraszcza oznakowanie dokumentów i eliminuje tworzenie osobnych wersji dla różnych przeglądarek. Wydłuża się okres żywotności dokumentów, także dlatego, że są niezależne od różnych efemerycznych technologii. W efekcie trzymanie się standardów oznacza oszczędności.
3. Typowa opinia dyrektora artystycznego: "trzymanie się standardów ograniczałoby moją kreatywność". Techniczne ograniczenia istnieją w każdym medium i każdej dziedzinie sztuki: rysunku, rzeźby czy stron WWW. Malowanie akwarelami czy farbami olejnymi stawia przed artystą własne wymogi warsztatowe i trudno powiedzieć, że ograniczają one kreatywność. Raczej stanowią właśnie podstawę tworzenia artystycznej ekspresji. Twórczość zgodna ze standardami sieciowymi otwiera nową przestrzeń technik właściwych nowemu medium, nowej technologii i nowemu sposobowi odbioru. W tym nowym medium jest jeszcze bardzo dużo do odkrycia.
4. Typowa opinia grafika: "nie obchodzi mnie dostępność przekazu dla osób niepełnosprawnych, to nie jest nasza publiczność". Projektowanie z uwzględnianiem odbioru przez osoby ułomne jest korzystne dla jakości witryny w ogóle. Osoby niepełnosprawne stanowią od 8% do 10% populacji. Utrzymywanie witryny konstruowanej zgodnie z wytycznymi dostępności dla osób niepełnosprawnych (accessibility) - a tym samym zgodnie ze standardami, ułatwia zarządzanie dokumentami. Oczekiwać można wzrostu zainteresowania witryną, a także wiele różnorodnych przeglądarek należycie wyświetli zawartość witryny. W niektórych krajach uwzględnianie potrzeb osób niepełniosprawnych jest wymagane przez prawo. Tak jest w Australii i USA. Również u Europie planowane są podobne regulacje.
5. Typowa opinia programisty: "dlaczego miałbym przestrzegać standardów? W Sieci panuje wolność". Sieć jest wspólnym miejscem dla wielu ludzi, o których potrzebach trudno jest wiedzieć coś z góry. Standardy zostały pomyślane po to, by w Sieci było miejsce na wszystkich jej potencjalnych użytkowników. Przestrzeganie standardów jest zatem powinnością i interesem wszystkich użytkowników Sieci. Na odwrót: przywiązanie do rozwiązań lansowanych przez jedną firmę lub wyłączne oparcie się na technologii, do której ktoś ma zastrzeżone prawa, ogranicza to wspólne miejsce i wolność w Sieci.
6. Typowa opinia autora dokumentów: "ja po prostu postępowałem zgodnie z instrukcją w podręczniku". Niestety, wiele podręczników pomija kwestię jakości dokumentów. Nie uchyla to zasady, że każdy, kto tworzy dokumenty powinien je walidować. Niezależnie od tego jakich narzędzi używa się do tworzenia publikacji w Sieci, należy być krytycznym w stosunku do podręczników i instrukcji towarzyszących danemu narzędziu i zawsze konfrontować swą pracę ze specyfikacją odpowiedniego standardu sieciowego. Jest wiele miejsc w Sieci, gdzie zebrane są dobre materiały pomocnicze do tworzenia wszelkich publikacji zgodnie ze standardami W3C. Na serwerze W3C znaleźć można powiększającą się ciągle listę poradników promujących dobrą praktykę. Niekóre osoby z W3C tworzą programy bezpłatne i przenaczone do powszechnego użytku. Służą one technologiom i standardom rozwijanym przez W3C i znajdują szerokie zastosowanie.
7. Inna typowa opinia autora: "nie moja wina, że mój edytor HTML tworzy strukturalnie niepoprawne dokumenty". Faktycznie, wiele narzędzi przyczynia się do tego, że dokumenty są niepoprawne. Nawet takie, które mają wbudowany tzw. "walidator". Jedyne, co można w tej sytuacji poradzić, to polecić używanie programu walidacji dokumentów zainstalowanego na serwerze W3C (http://validator.w3.org/). Jednocześnie należy powiadomić producenta narzędzia (przez e-mail, listownie lub telefonicznie), że jego produkt działa źle. Powinien o tym wiedzieć i coś na to poradzić.
8. Typowa opinia redaktora: "to nie moja wina, to nasz program do generowania dokumentów HTML został tak zaprojektowany" (często chodzi tu o system z interfejsem użytkownika w postaci przeglądarki WWW.) To prawda, często nie jest to wina użytkowników. Jeśli jest to system oparty na formularzach, w które wpisuje się tekst nieoznakowany, należy zwrócić się do autora tego interfejsu lub osoby odpowiedzialnej za jego działanie. Jeśli nie wiadomo, jak i gdzie powstają błędy, należy wynikowy dokument zwalidować na serwerze W3C i przesłać raport z walidacji osobom odpowiedzialnym za działanie systemu. HTML jest standardem (tak jak i XHTML) Język HTML podlegał ewolucji i występuje obecnie w szeregu wersji. Wszystkie one są standardami i można spośród nich wybrać tę, która jest potrzebna. W większości przypadków najbardzie odpowiednia będzie wersja najnowsza, chyba że tworzymy publikację dla specyficznych odbiorców lub dla użytkowników starszych, niedoskonałych przeglądarek. Użycie określonej wersji HTML przesądza o tym, jakich elementów i atrybutów można użyć do znakowania dokumentu. Na przykład język HTML 4.01 ma właściwą sobie listę elementów oraz listę ich atrybutów, których można użyć. HTML 4.01 pozwala oznaczyć akapit i identyfikator dla odsyłania doń w następujący sposób: <p id="ref">To jest akapit</p> Zwróćmy uwagę na sposób zagnieżdżenia w sobie elementów. Niektóre elementy nie mogą być zagnieżdżone w innych, a niektóre atrybuty należą wyłącznie do pewnych elementów. Oznakowanie jakie wolno jest wnieść do dokumentu - czy to ręcznie, czy też projektując jakiś program, który tworzy dokumenty HTML - zależy od wersji języka HTML. Poniższa tabela zawiera listę wskazań na wersję HTML, z których jedno powinno znaleźć się na początku każdego dokumentu HTML. Wersja DTD treść deklaracji "DOCTYPE" w dokumentach - HTML 2.0 DTD <!DOCTYPE html PUBLIC "-//IETF//DTD HTML 2.0//EN"> - HTML 3.2 DTD <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"> - HTML 4.01 - Strict, Transitional, Frameset <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN"
"http://www.w3.org/TR/html4/frameset.dtd">
- XHTML 1.0 - Strict, Transitional, Frameset <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">
- XHTML 1.1 DTD <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
Nie można zwalidować dokumentów HTML, które nie zaczynają się od którejś z wymienionych deklaracji "DOCTYPE" wskazującej na konkretną DTD. Dlatego nie można zapominać o umieszczeniu tej deklaracji. Narzędzia autorskie HTML muszą proponować użytkownikowi wybór którejś z deklaracji i generować oznakowanie zgodne z odpowiednią DTD. Podobnie zawierać ją muszą szablony HTML służące do programowego tworzenia dokumentów HTML. Poniżej podany jest przykład szablonu dokumentu XHTML 1.0: <?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> <head>
<title>Szablon dokumentu XHTML 1.0 w wersji Strict</title>
<meta http-equiv="content-type" content="text/html; charset=utf-8" />
<meta http-equiv="Content-Style-Type" content="text/css" />
</head> <body> ... treść dokumentu oznakowana zgodnie z XHTML 1.0 - Strict ... </body>
</html> Walidacja dokumentów Walidacja dokumentów HTML polega na konfrontacji oznakowania danego dokumentu z regułami zapisanymi w DTD na którą wskazuje deklaracja "DOCTYPE". Każdy dokument opublikowany lub przeznaczony do publikacji można sprawdzić walidatorem HTML zainstalowanym na serwerze W3C. Wystarczy podać jego URL albo wysłać na serwer W3C dokument zapisany na lokalnym dysku. Walidator zwróci listę błędów albo komunikat o bezbłędnym dokumencie. Jeśli dokument HTML tworzony jest za pomocą formularza (to znaczy oznakowanie nie jest wpisywane ręcznie), raport z walidacji należy przesłać osobie odpowiedzialnej za działanie programu generującego dokumenty HTML i żądać poprawienia działania programu. Jeśli oznakowanie wnoszone jest bezpośrednio i od podstaw, a walidator wskazuje błędy w dokumencie, należy po prostu poprawić wskazane błędy, kierując się numerami wierszy podanymi w raporcie z walidacji. Walidator podaje numery wierszy w których znalazł błędy, czytając dokument jeden raz od pierwszego wiersza do ostatniego. A to oznacza, że błąd występujący na początku dokumentu może skutkować błędną interpretacją dalszej części dokumentu, w rezultacie walidator może raportować wiele kolejnych błędów pochodnych. Dlatego dobrze jest zawsze zacząć poprawianie dokumentów od pierwszych raportowanych błędów i poddać dokument powtórnej walidacji. Po czym powtarzać cykl poprawiania i walidacji aż do uzyskania bezbłędnego dokumentu. Jeśli oznakowanie nie jest wpisywane bezpośrednio, lecz tworzone zaocznie przez jakiś program, a dokumenty są niepoprawne strukturalnie, należy zgłosić to producentowi programu. Większość takich narzędzi zawiera informację o tym jak skontaktować się z pomocą techniczną. Poniżej zamieszczamy odsyłacze do odpowiednich stron WWW kilku producentów narzędzi autorskich: * Amaya - Bug report
* Dreamweaver - Bug report
* FrontPage - Bug Report
* GoLive - Bug report
* Homesite - Bug report
* Netscape Composer - Bug report Programiści tworzący systemy generowania dokumentów HTML na podstawie szablonów, tworzący narzędzia autorskie i systemy "content management" (CMS) mogą stosować HTML Validator dla sprawdzania działania swoich instalacji. Kody źródłowe tego walidatora są dostępne bezpłatnie, dlatego może on być łatwo wbudowany w dowolny system edycyjny. Walidator W3C jest często doskonalony i każdy może uczestniczyć w jego rozwijaniu. Uwaga: Może się zdarzyć, że dokumenty poprawne strukturalnie, czyli odpowiadające regułom zapisanym w konkretnym DTD, pozostają jednak niezgodne ze specyfikacją odpowiedniej wersji HTML. Dzieje się tak dlatego, że nie wszystkie wymogi HTML dają się łatwo sformalizować. W najbliższym czasie opublikowana zostanie lista możliwych błędów, których HTML Validator nie jest w stanie wykryć. Niektóre walidatory dostępne on-line.
* W3C HTML validator
* WDG HTML Validator
* Doctor HTML Weryfikacja odsyłaczy Osobnym problemem, który dotyka wiele witryn WWW, jest aktualność zawartych na nich odsyłaczy. Zamieszczanie w dokumentach odsyłaczy do innych witryn opiera się na założenu, że wskazywane obiekty pozostają bezterminowo dostępne pod danym adresem. To założenie musi być weryfikowane, by móc gwarantować, że odsyłacze z witryny są bezbłędne i aktualne. W tym celu W3C udostępniło narzędzie o nazwie W3C Link Checker. Link Checker generuje raport z badania odsyłaczy prowadzących od wskazanego dokumentu. By sprawdzić aktualność odsyłaczy, wysyła pod adresy zawarte w odsyłaczach zapytanie HEAD HTTP. Jeśli serwer jest źle skonfigurowany, może być raportowany błąd, pomimo że odsyłacz jest dobry. Poniżej przedstawiony jest zapis z raportu generowanego przez Link Checker. Podany jest czas, w jakim zapytany serwer odpowiedział: Checking link http://webstandards.org/
HEAD http://webstandards.org/ fetched in 0.1s Poniżej listy odsyłaczy w raporcie znajduje się zestawienie wszystkich odsyłaczy błędnych oraz przekierowanych. Na tej podstawie należy dokonać korekty w sprawdzanym dokumencie. Więcej informacji na temat znaczenia odsyłaczy można znaleźć w artykule Cool URIs don't change, napisanym przez Tima Berners-Lee. Kod źródłowy programu W3C Link Checker jest dostępny bezpłatnie i każdy webmaster może zainstalować ten program na swoim serwerze, by ułatwić wszystkim chętnym sprawdzanie poprawności odsyłaczy w ich dokumentach.
Walidacja CSS Kaskadowe Arkusze Stylów (CSS - Cascading Style Sheets) to datująca się od 1966 roku technologia pozwalająca w przejrzysty sposób oddzielić zapis strukturalnego dokumentu od definicji dotyczących jego prezentacji. Od tego czasu wiele przyglądarek zacząło obsługiwać CSS 1, a także wersją CSS 2 tego standardu. Obecnie można używać zarówno CSS 1, jak i CSS 2 dla określania sposobu prezentacji dokumentów. Posługiwanie się arkuszami stylów daje wiele korzyści, takich jak obniżenie kosztów utrzymania publikacji w WWW oraz lepszą jej czytelność przez różne przeglądarki. Starsze metody zapewnienia pożądanego wyglądu publikacji, jak tworzenie różnych jej wersji dla różnych przeglądarek, posługiwanie się tabelami czy językiem JavaScript, były bardziej kłopotliwe i szacunkowo o ok. 30% droższe. Nie należy używać elementu FONT z atrybutem FACE dla określania pożądanej czcionki. Jest to szkodliwe z punktu widzenia internacjonalizacji przekazu w Sieci. Aby dowiedzieć się, jak się uporać z problemem czcionek w WWW za pomocą CSS, najlepiej jest przeczytać artykuł Todda Fahrnera Beyond the FONT tag: Practical HTML text styling. Arkusze stylów należy walidować analogicznie jak właściwy dokument HTML. Na serwerze W3C dostępny jest walidator W3C CSS Validation Service. Ten walidator może być również zainstalowany na dowolnym serwerze, gdyż jego kody źródłowe są dostępne bezpłatnie.
Weryfikacja dostępności Opublikowanie witryny WWW to nie wszystko. Najczęściej przez dłuższy czas nic nie wiadomo o odbiorcach publikacji. Osoby odwiedzające witrynę posługują się różnym sprzętem, różnymi przeglądarkami i miewają specyficzne ograniczenia odbioru. Uwzględnienie takich ograniczeń, czyli zadbanie o szeroką dostępność (accessibility) witryny jest bardzo opłacalne z wielu względów. Niestety, z istoty rzeczy nie może być jednej automatycznej metody sprawdzenia, czy witryna spełnia takie warunki, czy nie. Istnieją w Sieci narzędzia jak Bobby, które mogą być pomocne, ale o stopniu dostępności witryny rozstrzyga faktyczny jej odbiór przez ludzi. Web Accessibility Initiative to organizacja prowadząca listę witryn z materiałami pomocnymi dla projektowania witryn pod kątem ich dostępności.
Stopniowa naprawa witryny WWW Częstym powodem odwrócenia się od standardów jest przytłoczenie ilością błędów i perspektywą ogromnej pracy do wykonania. Drugim powodem jest zagubienie w technicznych zawiłościach powodujące, że nie wiadomo, od czego i jak rozpocząć naprawę.
Żródła, podziękowania autora:
Niniejszy artykuł powstał w ramach działalności Grupy Roboczej ds. Jakości (Quality Assurance Interest Group). Wszelkie komentarze powinny być kierowane do publicznego dostępnego archiwum listy dyskusyjnej
Ten adres e-mail jest ukrywany przed spamerami, włącz obsługę JavaScript w przeglądarce, by go zobaczyć
lub prywatnie do Karla Dubost
Ten adres e-mail jest ukrywany przed spamerami, włącz obsługę JavaScript w przeglądarce, by go zobaczyć
.
Autor dziękuje osobom, które poświęciły swój czas na przejrzenie artykułu i uwagi.
Wstęp Dla serwera W3C Gerald Oskoboiny opracował narzędzie (skrypt Perl), które co tydzień ustala dziesięć najczęściej pobieranych dokumentów spośród tych, które są niepoprawne strukturalnie. Webmaster otrzymuje co tydzień e-mail z taką listą i może od razu przystąpić do poprawiania konkretnych dokumentów. Skrypt ten dostępny jest publicznie i może być zainstalowany na każdym serwerze oraz dostosowany do lokalnych potrzeb. Oliver Théreaux rozwinął to nerzędzie do postaci LogValidator. Działanie tego narzędzia opiera się na analizie logów serwera i oprócz walidacji HTML może być uzupełnione o inne moduły. Na przykład o sprawdzanie pisowni, o sprawdzanie odsyłaczy czy też sprawdzanie obecności odpowiednich meta-danych.
Podziękowania - Autor dziękuje osobom, które przejrzały ten artykuł: Ian Jacobs, Susan Lesch, Olivier Théreaux, Stephanie Troeth, Jeffrey Zeldman oraz uczestnikom listy dyskusyjnej public-evangelist. Artykuł nie mógłby powstać bez udziału Kim Nylander, która pomogła w jego napisaniu.
Created Date: 2003-03-28 by Karl Dubost >
Ten adres e-mail jest ukrywany przed spamerami, włącz obsługę JavaScript w przeglądarce, by go zobaczyć
>
Last modified $Date: 2003/05/30 08:36:57 $ by $Author: ot $ Copyright © 2000-2003 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply. Your interactions with this site are in accordance with our public and Member privacy statements. --- Warto Zajrzeć - Zapraszamy na inne nasze strony!
|
