Working together for standards The Web Standards Project


WaSP: Walka o standardy

World Wide Web Consortium (W3C),
wspólnie z innymi grupami, tworzy technologie budowy i interpretacji zawartości na stronach WWW. Technologie te, zwane standardami sieciowymi są starannie projektowane, aby dostarczać jak najwięcej korzyści jak największej liczbie użytkowników sieci, zapewniając przy tym długą żywotność wszystkich dokumentów w internecie. Szczegóły znajdują się na pasku z boku.

Projektowanie i budowanie zgodnie ze standardami upraszcza i obniża koszty produkcji, a przy tym zwiększa dostępność strony dla większej liczby ludzi na większej liczbie urządzeń sieciowych. Strony tworzone według tych zasad będą działać poprawnie zarówno w kolejnych wersjach przeglądarek jak i na urządzeniach z dostępem do internetu wchodzących dopiero na rynek.

Skoro brzmi to tak prosto i sensownie, to w czym jest problem? I po co istnieje Web Standards Project?

Problem

Mimo, że czołowi twórcy przeglądarek byli zaangażowani w tworzenie standardów sieciowych odkąd tylko powstało W3C, podporządkowanie tymże standardom przychodziło im z trudem. Wypuszczając kolejne przeglądarki, które nie wspierały jednolicie standardów, producenci niepotrzebnie sfragmentowali sieć, krzywdząc w ten sposób projektantów, developerów, użytkowników i firmy.

Brak jednolitego wsparcia dla standardów W3C doprowadzało użytkowników do frustracji: używając "złej" przeglądarki, wielu nie mogło ujrzeć zawartości na stronie czy wykonać żądaną transakcję. Wśród nich najbardziej poszkodowane były osoby niepełnosprawne.

Dylematy i koszta

W tym samym czasie brak jednolitego wsparcia dla najważniejszych standardów W3C postawił projektantów, developerów i właścicieli stron przed dylematem: czy mogli sobie pozwolić na implementacje wielu wersji tej samej strony, aby przystosować ja do niekopmatybilnych przeglądarek? Jeśli nie to które przeglądarki powinni oni zlekceważyć i ile milionów klientów przez to odprawić z kwitkiem? Jakkolwiek nie wybrać, koszt był za duży. Wciąż jest.

Rozczłonkowany rynek przeglądarek przyczynił się do wzrostu kosztu tworzenia stron o conajmniej 25%. Ze względu na brak funduszy, wielu developerów produkowało strony, które ograniczały potencjalnych klientów. Wielu developerów, którzy wiedzieli o standardach, nie widziało sensu pisania stron dla przeglądarek, które ich nie wspierają. Inni wiedzieli o standardach bardzo mało lub w ogóle – i wielu wciąż nie wie, włiczając duże agencje, które stosują ASP, Java, Flash MX czy Net, bez większej wiedzy o strukturalnych i semantycznych znacznikach, arkuszach stylów i znaczeniu oddzielenia struktury od prezentacji.

Niektórzy projektanci, po napotkaniu trudności wynikających z niekompatybilności przeglądarek, celowo pomijali wszystkie technologie sieciowe z wyjątkiem tych najstarszych i najbardziej uniwersalnych. Takie strony często poprawnie działały we wszystkich przeglądarkach, ale kosztem funkcjonalności i satysfakcji klienta.

Inni oparli się na edytorach i narzędziach wizualnych, tworząc wiele wariantów tej samej witryny z myślą o dziwactwach różnych wersji popularnych przeglądarek. Było to niczym innym jak marnowaniem pieniądzy i transferu. Ponadto często wiązało się to z budowaniem stron, które przestawały działać w następnym pokoleniu przeglądarek (i które tak naprawdę nigdy nie działały w alternatywnych przeglądarkach i urządzeniach, od przeglądarek tekstowych typu Lynx do mniej popularnych graficznych jak Opera). Sieć jest zaśmiecona trupami stron, które kiedyś robiły wrażenie i które teraz nie potrafią współpracować ze współczesnymi przeglądarkami i urządzeniami. Co gorsze, takie strony tworzone są każdego dnia.

Niektórzy projektanci byli tak sfrustrowani, że odwórcili się od standardów i zaczęli opracowywać odrębne firmowe rozwiązania. Chociaż bogate w potencjał kreatywności, takie technologie cierpią na brak ogólnej dostępności, i zawodzą w zaspokojaniu podstawowych potrzeb jak drukowanie, kopiowanie, wklejanie, dodawanie strony do ulubionych i inne zadania, które użytkownicy muszą wykonywać zarówno na stronach informacyjnych jak i transakcyjnych.

Narodziny potrzeby

W odpowiedzi na te problemy, w 1998 roku został powołany The Web Standards Project (WaSP) celem promowania standardów sieciowych i zachęcania twórców przeglądarek do tego samego, przez to zapewniania pełnego dostępu dla wszystkich.

Chociaż nasze przesłanie początkowo spotkało się z oporem (szczególnie ze strony departamentów marketingu i Public Relations firm produkujących przeglądarki), ostatecznie zwyciężyliśmy – po części ze wględu na to, że wielu inżynierów przyznało nam rację i ujrzało w nas sojusznika w wewnętrznych walkach z managmentem.

Począwszy od roku 2000, po kolei w wiodących przeglądarkach zaczęła się znacznie poprawiać interpetacja standardów. Obecnie duża część z nich, nie tylko najpopularniejszych, ma bardzo dobre wsparcie dla HTML 4, XHTML 1, CSS, ECMAScript (standardowa wersja JavaScript) i DOM – lub jest na dobrej drodze do tego.

Dzięki tym przeglądarkom, projektanci i developerzy w końcu mogą budować strony przy użyciu XHTML i CSS, i w większości przypadków mogą oddzielać prezentację od struktury, aby zmaksymalizować przenośność i dostępność. Z pewną dozą ostrożności, mogą także używać standardu W3C – DOM, aby dodać swoim stronom szczególnego zachowania.

Więc w czym tkwi problem? I dlaczego Web Standards Project wciąż istnieje?

Wyzwania przed nami

Mimo, że dzisiejsze przeglądarki wspierają standardy, tysiące profesjonalnych projektantów i developerów wciąż używa przestarzałych metod, które mieszają prezentację ze strukturą, w niektórych przypadkach całkowicie unikając semantycznych struktur i błędnie stosując (X)HTML jako narzędzia prezentacyjnego. Dobrze płatni profesjonaliści masowo produkują niezgodne i niedostępne strony pełne strukturalnie bezsensownych znaczników, olbrzymich map obrazów, nadmiernie zagnieżdżonych tabel i przestarzałych skryptów wykrywających wersję przeglądarki, które wywołują niemałe problemy z dostępnością, a paradoksalnie ich przeznaczeniem było ich unikanie.

Wiele książek poświęconych tworzeniu stron internetowych wciąż uczy przestarzałych metod, a wielu praktyków szczyci się budowaniem stron działających dokładnie tak samo w kilku przeglądarkach, kosztem dostępności, żywotności i zgodności wprzód. Inni piszą kod, który działa tylko w garstce popularnych przeglądarek.

Tak więc, jednym z podstawowych celów WaSP jest dostarczanie zasobów wspomagająych uczenie metod zgodnych ze standardami, co jest w interesie twórców stron i ich użytkowników.

Wielu profesjonalistów realizuje swoją pracę za pomocą edytorów wizualnych stworzonych w czasie tzw."wojen przeglądarek". Jak wspomniano wcześniej, takie narzędzia z reguły tworzą błędne i niepoprawne składniowo strony zoptymalizowane dla dziwactw przeglądarek 4.0 zamiast dla standardów sieciowych. W roku 2002, dwa czołowe edytory wizualne znacznie poprawiły wsparcie dla standardów i dostępności (jeden z nich z pomocą The Web Standards Project). Jednakże, aby skorzystać z tych ulepszeń, profesjonaliści muszą nauczyć się podstaw i zdać sprawę z korzyści płynących z projektowania i budowania zgodnie ze standardami sieciowymi. To znowu wskazuje na potrzebę lepszej edukacji developerów.

Klienci i zarządzający stroną także potrzebują informacji, jesli tylko chcą by ich strony były dostępne w dzisiejszych przeglądarkach i urządzeniach i aby takie pozostały wraz z rozwojem tychże przeglądarek i urządzeń. Mamy nadzieję, żę poinformowani o korzyściach stosowania standardów, właściciele stron przestną patrzeć na swoje witryny jako rodzaj drukowanej reklamy, która musi wyglądać wszędzie tak samo. Mamy nadzieję, że zamiast tego skupią się na dostarczaniu odpowiedniej treści i funkcjonalności w ramach wyglądu, który może się różnić w zależności od potrzeb i możliwości danych przeglądarek i urządzeń.

Oryginalne oświadczenie misji

Oryginalne oświadczenie misji WaSP z 1998 roku jest dostępne w archive.webstandards.org.

© 1998-2006 Web Standards Project, www.webstandards.org

Tłumaczenie wykonane przez: Tłumaczenia team.


All of the entries posted in WaSP Buzz express the opinions of their individual authors. They do not necessarily reflect the plans or positions of the Web Standards Project as a group.

This site is valid XHTML 1.0 Strict, CSS | Get Buzz via RSS or Atom | Colophon | Legal