Niedzielne webmajstrowanie,
czyli jak nie tworzyć stron WWW

Aż trudno bowiem uwierzyć, jak często wędrując po polskim Internecie spotkać można niepoprawnie wykonane strony WWW. Pół biedy byłoby jeszcze, gdyby sytuacje takie dotyczyły jedynie prywatnych stron osobistych, będących w większości tylko - co tu ukrywać - miłą zabawą. Gdy jednak w podobny sposób wygląda wiele sieciowych wizytówek firm, nawet tych dużych i renomowanych, bądź strony mające ambicje bycia publicznym serwisem informacyjnym, jest to już problem, którego nie można bagatelizować.

Niestety, wiele stron WWW w Polsce - zarówno prywatnych, jak i firmowych - jest wciąż dziełem "niedzielnych webmajstrów", którzy nauczyli się jako-tako obsługiwać jeden edytor do tworzenia stron WWW, i zrobiwszy za jego pomocą kilka stron nabrali przekonania, że umieją już wszystko. Rzeczywistość okazuje się niestety daleka od tych przekonań, co nie przeszkadza bynajmniej takiemu "webmajstrowi" w oferowaniu swoich usług np. firmom, jako że szefowie owych firm sami zwykle niezbyt znają się na Internecie (w końcu nie są od tego...), a nie mają "pod ręką" nikogo, kto mógłby kompetencje "webmajstra" ocenić. I tak powstają strony-potworki, które zamiast zachęcać - zniechęcają użytkowników do ich czytania.

Na co zatem powinien autor strony WWW zwracać uwagę i czego się wystrzegać, aby nie okazać się "niedzielnym webmajstrem"?

Dwa podstawowe błędy

Po drugie (co wiąże się z pierwszym): trzeba mieć świadomość tego, że nasze strony mogą oglądać użytkownicy posługujący się różnymi systemami operacyjnymi, różnymi przeglądarkami WWW, a także - last but not least - sprzętem o bardzo różnych możliwościach, np. graficznych. Wiele stron WWW, które miałem okazję oglądać, sprawia wrażenie, jakby ich autor był przekonany (być może istotnie był...), że wszyscy użytkownicy Internetu pracują wyłącznie w środowisku Windows, i to na dodatek Windows 95 (no, może są jeszcze jakieś niedobitki używające Windows 3.1, ale i tak na pewno zaraz sobie zmienią na nowszą wersję) oraz używają jedynie słusznej przeglądarki WWW, czyli Microsoft Internet Explorera, i to w jego najnowszej wersji - a jeżeli jeszcze jej nie mają, to powinni zaraz sobie zainstalować. Jakby tego było mało, to na wielu stronach znaleźć można zalecenia oglądania ich w określonej rozdzielczości i przy określonej liczbie kolorów. Hmmm... przepraszam, a co to takiego tryb 800x600 HiColor na Amidze? Albo na Sun SPARCstation? I czy istnieje wersja MSIE na te komputery?

Niestety, trzeba to sobie - i wszystkim "niedzielnym webmajstrom" - powiedzieć, że używanie techniki WYSIWYG do tworzenia stron WWW jest grubym nieporozumieniem. Profesjonalne tworzenie stron WWW za pomocą oprogramowania typu WYSIWYG jest po prostu niemożliwe, dlatego, że sama koncepcja WYSIWYG jest zasadniczo sprzeczna z ideą języka HTML! Podstawowym założeniem WYSIWYG jest, że ostateczna postać tworzonego dokumentu będzie wyglądała zawsze tak samo, jak widzimy ją na ekranie podczas jej tworzenia. HTML to jednak nie edytor w rodzaju Worda! Język HTML nie jest pomyślany jako narzędzie opisywania tego, jak dokument ma wyglądać, ale co (w sensie logicznym) zawiera. Nie określamy np., że dany fragment tekstu ma być zapisany czcionką pogrubioną o wielkości 24 punktów, tylko że fragment ten jest nagłówkiem pierwszego poziomu. Sposób wyróżnienia takiego nagłówka zależy wyłącznie od przeglądarki - w jednej przeglądarce może to być wspomniana czcionka pogrubiona o wielkości 24 punktów, w innej zupełnie inna. W wielu przeglądarkach (np. w Mosaicu) użytkownik może sobie nawet sam skonfigurować, jakie elementy strony w jaki sposób mają być wyświetlane. Tu załamuje się cała koncepcja WYSIWYG: jedna i ta sama strona WWW może w różnych przeglądarkach wyglądać całkowicie różnie. I tworząc stronę musimy to uwzględniać: należy ją projektować "logicznie", zgodnie z ideą HTML-a, a nie "wizualnie". O prawidłowy wygląd strony, która jest dobrze zaprojektowana pod względem logicznym, zatroszczy się już... sama przeglądarka, dopasowując go w najlepszy sposób do możliwości środowiska, w którym stronę oglądamy - w końcu po to właśnie ona jest! I to naprawdę działa, co miałem okazję nieraz sprawdzić "na własnej skórze". Dobre logiczne zaplanowanie dokumentu HTML pozwala niejednokrotnie pisać go niemal "na ślepo", bez sprawdzania na bieżąco jego wyglądu w przeglądarce, a ostateczny efekt wymaga tylko niewielkich poprawek. Oczywiście do projektowania pewnych szczególnych elementów strony, jak np. tabelki, czy graficzne mapy odsyłaczy, wsparcie się wyspecjalizowanymi narzędziami "wizualnymi" może być bardzo pomocne, ale zasadniczy szkielet strony musimy sami napisać w HTML-u - nie należy liczyć na to, że jakiś program zrobi to za nas.

Podobnym nieporozumieniem jest tworzenie stron "przywiązanych" do jednej platformy sprzętowej czy programowej - dających się poprawnie odczytać tylko w określonej przeglądarce, przy określonej rozdzielczości itp. Ograniczamy w ten sposób istotnie grupę użytkowników, dla których strony te będą dostępne. Tim Berners-Lee, twórca HTML-a, określił to jako cofanie się do czasów sprzed WWW, kiedy praktycznie nie było szansy, aby dokument stworzony na jednym typie komputera dał się odczytać na innym. Oczywiście zawsze można powiedzieć - jak argumentują niektórzy - że nie ma żadnego obowiązku tworzenia strony w taki sposób, aby była czytelna dla wszystkich. Rzecz jasna, że nie ma. Tylko warto zadać sobie pytanie: w jakim celu tworzy się daną stronę i umieszcza ją w sieci? To, co może być argumentem w przypadku prywatnej strony, której celem jest głównie rozrywka jej autora i jego znajomych, nie sprawdza się np. dla reklamowej witryny firmy. Firmie, która umieszcza w sieci swoją witrynę, zależy wszak na tym, aby obejrzało ją jak najwięcej osób - potencjalnych klientów. Jeżeli - jak słyszy się ostatnio - firmy np. rejestrują sobie podwójne domeny, aby zyskać o kilka procent większą "oglądalność" wśród użytkowników, którzy pomyłkowo wpiszą adres www.firma.pl zamiast www.firma.com.pl (lub odwrotnie), to czy mogą pozwolić sobie na utratę kilkunastu procent potencjalnych klientów, którzy po zajrzeniu na jej witrynę i stwierdzeniu, że dla ich przeglądarki jest nieczytelna, zrezygnują z prób dalszego jej penetrowania? Wydaje się, że odpowiedź na to pytanie jest oczywista, a jednak... a jednak wiele firm może się "pochwalić" właśnie takimi witrynami.

Pisz dla każdej przeglądarki

Aby nie działać "na oślep", nieodzowne jest posiadanie dobrego opisu języka HTML, z uwzględnieniem różnic między poszczególnymi przeglądarkami. Oficjalną specyfikację standardu HTML 3.2 znaleźć można w sieci pod adresem http://www.w3.org/pub/WWW/TR/REC-html32.html, to jednak nie załatwia sprawy, gdyż brak w niej informacji o rozszerzeniach Netscape'a i Microsoftu, a ponadto czytanie formalnej specyfikacji języka, zapisanej w specyficznej notacji, nie należy do zajęć najwdzięczniejszych. Dlatego warto sięgnąć po inne publikacje z tego zakresu, na czele z najsłynniejszą chyba HTML Reference Library. Ma ona postać pliku w formacie Windows Help i można ją pobrać m.in. z serwisu TUCOWS (http://tucows.it.pw.edu.pl/htmlacc.html). Bardzo cenną pomocą jest też wydana przez wydawnictwo MIKOM książka Włodzimierza Macewicza "HTML - język opisu dokumentu hipertekstowego" - znakomity, zwięzły "bryk" wszystkich poleceń HTML-a z zaznaczeniem, która przeglądarka co akceptuje. Mimo tego, że zawarte w niej informacje są już nieco nieaktualne, uważam że książkę tę nieodzownie powinien mieć pod ręką każdy poważnie traktujący swoją pracę webmaster.

Oczywiście tak jak w każdym działaniu, również w "standaryzowaniu" naszych stron WWW niezbędne jest zachowanie zdrowego rozsądku. Jeżeli głównym celem strony ma być np. zademonstrowanie niezwykłego efektu wizualnego, możliwego do uzyskania tylko za pomocą określonej przeglądarki, trudno wymagać od tej strony, aby była zgodna ze standardem. Nie powinna jednakże być w taki sposób skonstruowana np. główna strona witryny firmy.

Podobnie, skoro Netscape i MS Internet Explorer stanowią łącznie ponad 90% wszystkich przeglądarek WWW używanych na świecie, nieco nierealistyczny jest postulat zrezygnowania z rozszerzeń akceptowanych przez obie te przeglądarki (ale już używanie na stronie rozszerzeń akceptowanych przez tylko jedną z nich jest rzeczą dyskusyjną). Przykładowo, stosowane już w ogromnej ilości stron WWW tzw. ramki nie należą do standardu HTML 3.2, choć akceptuje je zarówno Netscape, jak i MSIE (a także kilka innych przeglądarek). Pomimo ich niestandardowości, trudno jednak sobie wyobrazić powszechne zaprzestanie stosowania ramek; bardziej prawdopodobne jest raczej, że znajdą się one w następnej wersji standardu HTML (osobną sprawą jest rzeczywista potrzeba używania owych ramek - wśród wielu widzianych przeze mnie stron z ramkami znalazłoby się może zaledwie kilka takich, na których użycie ramek istotnie wzbogaciło wartość informacyjną strony w porównaniu z przypadkiem, gdyby tych ramek nie było; w znakomitej większości ramki są jedynie wizualnym "bajerem"). Jednak nawet gdyby ramki były częścią standardu, i tak musielibyśmy się liczyć z faktem, że nie każda przeglądarka będzie w stanie je wyświetlić, ze względów czysto technicznych - np. trudno wyobrazić sobie ramki w przeglądarce pracującej w trybie znakowym. Zatem jeżeli decydujemy się na utworzenie strony z ramkami, strona taka powinna zawierać również wersję "bezramkową" (część <NOFRAMES>), aby posiadacze przeglądarek nie obsługujących ramek również "coś z niej mieli" - w przeciwnym razie zobaczą bowiem jedynie całkowicie pustą stronę.

Powyższy przykład dobrze ilustruje pewną ogólną regułę, której powinniśmy przestrzegać przy tworzeniu stron WWW. Pierwotna wersja HTML-a (mająca rzecz jasna z dzisiejszego punktu widzenia bardzo niewielkie możliwości) została zaprojektowana tak, aby w każdym środowisku sprzętowo-programowym, w jakim strona będzie oglądana, zachować maksimum zawartych na niej informacji, jakie w danych warunkach da się zaprezentować. Rzecz jasna, nie da się np. przy pracy w trybie tekstowym pokazać rysunków, ale różne poziomy nagłówków w tekście można znakomicie odróżniać, zamiast wielkością czcionki - kolorami, jaskrawością, itp. atrybutami. Powinniśmy się starać zachować tę prawidłowość. W tworzeniu stron WWW bardziej popłaca odrobina konserwatyzmu, niż zbytnia pogoń za nowinkami. Wzbogacając naszą stronę o jakikolwiek zaawansowany element - applet Javy, ramki, animację, mapę graficzną czy choćby zwykły rysunek powinniśmy zadawać sobie jedno pytanie - a jak to wypadnie w przeglądarce, która tego elementu nie obsługuje? Na ile to możliwe, pozbawienie strony tego elementu nie powinno zubażać jej wartości informacyjnej. Wspomniałem już o tym, że strona "ramkowa" powinna mieć swoją wersję "bezramkową". Jeżeli używamy na stronie animowanego GIF-a - zróbmy go w taki sposób, aby jego pierwsza klatka stanowiła samoistną całość, która będzie "coś mówiła" użytkownikowi oglądającemu stronę w przeglądarce nie "rozumiejącej" animacji. Rozważnie trzeba używać appletów Javy, aby przypadkiem w przeglądarce, która ich nie obsługuje, czegoś z zawartości strony nie "zgubić". Podam tu dwa przykłady. Widziałem serwer WWW, na którego stronie głównej całe menu pozwalające przejść do następnych stron zrealizowane było w postaci bardzo efektownego appletu Javy. Wyglądało to wspaniale, tylko... użytkownicy przeglądarek bez Javy (większość przeglądarek pod "stare" Windows!), albo mający w przeglądarce opcję ładowania appletów wyłączoną (wiele osób robi tak ze względów bezpieczeństwa) nie widzieli na tym serwerze niczego więcej poza stroną główną! Należało w tym przypadku posłużyć się tekstem alternatywnym, zawierającym odsyłacze do pozostałych stron - konstrukcja <APPLET> w HTML-u zawiera wszak specjalne miejsce na wprowadzenie takiego tekstu, który jest pokazywany przez przeglądarkę nie "rozumiejącą" Javy.

Gorzej jest, gdy Java nie stanowi tylko graficznego "bajeru" uatrakcyjniającego stronę, ale spełnia istotną rolę dla jej zawartości informacyjnej - ot, chociażby opisywane jakiś czas temu w dziale "Galeria" strony pozwalające zapoznawać się z przekrojami anatomicznymi ciała ludzkiego. Tu zdaje się, że bez Javy ani rusz... Wbrew pozorom, jednak jest wyjście: zbliżone efekty często uzyskać można za pomocą tradycyjnego programu CGI działającego na serwerze. Przykładem może być choćby słynna interakcyjna mapa świata firmy Xerox (http://mapweb.parc.xerox.com/map), a w Polsce - automatycznie generowane wykresy cen akcji na stronie giełdowej (http://yogi.ippt.gov.pl/gielda/gielda.html). Oczywiście skrypty CGI nie zastąpią całkowicie efektów możliwych do uzyskania za pomocą Javy (gdyby tak było, to Java by nie powstała...), niemniej jednak co stoi na przeszkodzie, aby użyć na stronie i jednej, i drugiej formy prezentacji? Wtedy użytkownicy przeglądarek bez Javy też mają jakąś szansę...

Analogiczne uwagi odnoszą się do skryptów Javascript, te jednak niosą ze sobą pewien dodatkowy problem: otóż jeżeli wpiszemy w treść strony skrypt nie "ukrywając" go w specjalny sposób przed starszymi przeglądarkami, które skryptów nie obsługują (sposób takiego "ukrycia" zademonstrowany jest np. w opisie Javascriptu na serwerze WWW Netscape'a, można go znaleźć także w książkach na temat tego języka), strona oglądana w takiej przeglądarce będzie "zaśmiecona" wyświetloną w sposób jawny treścią skryptu, co należy uznać za efekt wysoce niepożądany. Takich sytuacji należy bezwzględnie unikać - jeżeli na początku strony, przed właściwą zawartością, widnieć będzie kilka czy kilkanaście wierszy wypisanego w bezładny sposób niezrozumiałego tekstu (tak właśnie prezentuje się "nie schowany" skrypt w przeglądarce nie obsługującej Javascriptu), natychmiast zniechęca to do jej dalszego oglądania.

W ogóle bardzo wskazane jest (a jeżeli stosujemy jakieś niestandardowe konstrukcje, to wręcz niezbędne) sprawdzanie wyglądu tworzonej strony w kilku różnych przeglądarkach WWW, a nie tylko w jednej. Powinniśmy tu brać pod uwagę co najmniej trzy przeglądarki: Netscape, Microsoft Internet Explorer oraz Lynx (ta trzecia to zapewne niezbyt znana użytkownikom Windows przeglądarka pracująca w trybie tekstowym! - będzie jeszcze o niej mowa). Warto też wziąć pod uwagę, że nie wszyscy muszą dysponować najnowszymi wersjami zarówno Netscape, jak i MSIE, warto więc też przetestować stronę na starszych wersjach tych przeglądarek. Wiele cennych wskazówek na temat tego, jak pisać strony w sposób niezależny od przeglądarki, zebranych zostało na stronie pod wymownym tytułem "Best Viewed With Any Browser": http://server.berkeley.edu/~cdaveb/anybrowser.html. Można tam znaleźć m.in. szczegółowe omówienia różnic między poszczególnymi przeglądarkami, a także bardzo dobry program pozwalający sprawdzić zgodność dowolnej strony WWW z różnymi przeglądarkami i ze standardem HTML.

Uwaga na tryb tekstowy! *

A przecież niewiele wysiłku wymaga zaprojektowanie strony, która nie tracąc nic ze swoich graficznych walorów będzie czytelna także dla przeglądarki tekstowej. Zamiast owego nic nie mówiącego "[IMAGE]", trzeba - jak to "od urodzenia" przewiduje standard HTML - zaopatrywać obrazki w tekst alternatywny, wyświetlany przez przeglądarki niegraficzne. Jakże wiele spośród tych obrazków zawiera wszak w istocie tekst - tyle, że zapisany w jakiś efektowny, ozdobny sposób. Dlaczego zatem taki tekst nie znajduje się w parametrze ALT= odpowiedniego polecenia <IMG>? Dla innych grafik, takich jak np. zdjęcie autora strony, odpowiednie może być krótkie omówienie, co jest na rysunku, np.: "(tutaj logo naszej firmy)". Jeszcze inne z kolei obrazki mają jedynie znaczenie dekoracyjnych "ozdobników" upiększających stronę: kolorowe kuleczki przy poszczególnych pozycjach wykazów, rysunki kopert przy adresach e-mailowych, uśmieszki, biegające pieski, obracające się znaki zapytania, symbol "roboty drogowe" na niedokończonych stronach - to wszystko możemy całkowicie wyeliminować z wersji tekstowej, podając w parametrze ALT="" tekst pusty!

Są wreszcie rysunki z punktu widzenia informacyjnej zawartości strony niezbędne. Wykresy, schematy, plany, nierzadko zdjęcia (gdy np. strona prezentuje galerię malarstwa, albo katalog wyrobów jakiejś firmy...) - tego wszystkiego tekstem zastąpić się nie da. Możemy jednak, poza bezpośrednim wstawieniem tych rysunków na stronę poleceniem <IMG>, umieścić gdzieś w jej treści "normalny" odsyłacz prowadzący do pliku z danym rysunkiem - odsyłaczem takim może być nawet wprost sam rysunek! Wbrew pierwszemu wrażeniu, wcale nie jest to bez sensu - użytkownik przeglądarki tekstowej, "klikając" na alternatywny tekst wyświetlany w miejscu takiego rysunku (zawierający np. informację "wykres - kliknij tutaj") może przynajmniej "ściągnąć" sobie dany rysunek na swój dysk, i spróbować obejrzeć później za pomocą osobnego programu. Analogiczne postępowanie wskazane, a nawet wręcz niezbędne jest w przypadku, gdy rysunek stanowi graficzną mapę odsyłaczy: wówczas cały rysunek musimy objąć "głównym" odsyłaczem, prowadzącym do strony z tekstowym wykazem "linków" zawartych na mapie - w ten sposób będą mogli z niej skorzystać również użytkownicy, których przeglądarki nie obsługują parametru USEMAP= (powyższe dotyczy zgodnej z HTML-em 3.2 nowszej odmiany map, bezpośrednio interpretowanych przez przeglądarkę - tzw. client-side imagemaps; w przypadku map "starszej generacji", realizowanych przez odpowiednie oprogramowanie po stronie serwera WWW, postępowanie jest nieco trudniejsze i może wymagać modyfikacji działającego na serwerze programu imagemap). Oczywiście alternatywnym rozwiązaniem może być niezależne umieszczenie takiego odsyłacza, lub nawet całej tekstowej postaci mapy, w innym miejscu strony - jest to np. często praktykowane na serwerach amerykańskich. Omówione dwie konstrukcje nie są być może dla początkujących autorów stron WWW oczywiste, dlatego warto przedstawić tu ich przykłady. Pierwsza z omawianych konstrukcji - rysunek będący odsyłaczem do samego siebie - wygląda mniej więcej w taki sposób:

   <a href="rysunek.gif">
   <img src="rysunek.gif" alt="Rysunek - kliknij tutaj">
   </a>

   <a href="mapa-text.html">
   <img src="mapa.gif" alt="Kliknij tutaj dla wersji tekstowej"
        usemap="#nazwa_mapy">
   </a>

Nie wszyscy używają Windows

Jeżeli już o liczbie kolorów mowa, to stosowanie na stronach WWW grafiki więcej niż 256-kolorowej jest pozbawione sensu: niepotrzebnie wydłuża - i to znacznie! - czas ładowania rysunku, nie dając w zamian aż tak wyraźnego polepszenia wrażeń wizualnych. 256 kolorów to w tej chwili "norma", której przekraczać w żadnym wypadku nie należy. Co więcej, rysunki powinny być tak przygotowane, aby były w miarę dobrze widoczne również w trybie 16-kolorowym. Oczywiście nie jest to możliwe np. w przypadku zdjęć, ale wszelkie elementy służące tylko jako graficzne "ozdobniki" strony powinny "przyzwoicie" wyglądać w 16 kolorach. W szczególności dotyczy to rysunków, czy też jednolitych kolorów, używanych jako tła stron! - niejednokrotnie zdarzało mi się widzieć strony o tak fatalnie dobranej kombinacji koloru tła i tekstu, że w trybie 16-kolorowym nie było nic widać. Należy też przy doborze kolorów pamiętać o posiadaczach monitorów monochromatycznych - strony, które są czytelne tylko w kolorze, również nie należą w polskim Internecie do rzadkości. W ogóle nie należy przesadzać z ilością grafiki na stronie: strona na naszym lokalnym dysku może prezentować się wspaniale, ale pamiętajmy, że ci, którzy będą ją oglądać, muszą ją załadować z sieci! Widywałem strony wyposażone w tyle grafiki, appletów, plików dźwiękowych, że były w stanie ładować się nawet i pięć minut (przy w miarę nieobciążonych łączach). Ręczę, że przeciętny użytkownik zrezygnuje z ładowania takiej strony najdalej po minucie.

Jednym z najbardziej fatalnych pomysłów Microsoftu, zastosowanych w przeglądarce Internet Explorer (powielonym następnie również przez Netscape'a), było wprowadzenie "rozszerzenia" do HTML-a w postaci parametru <FONT FACE=...>, pozwalającego na ustalenie kroju czcionki, jakim ma być wypisany dany fragment strony. Dlaczego jest to pomysł fatalny? Bowiem nazwy krojów czcionek są nie tylko różne w różnych systemach operacyjnych, ale mogą być przecież także różne w różnych indywidualnych instalacjach tego samego systemu! Nie każdy posiadacz np. Windows ma te same czcionki! Jeżeli teraz nieświadomy niczego "webmajster", projektujący swoją stronę za pomocą przyjaznego "wizualnego" narzędzia, wpadnie na pomysł uatrakcyjnienia swojej strony poprzez np. zapisanie pewnego jej fragmentu jakąś oryginalną czcionką, którą (a jakże) wybrał sobie z elegancko zaprezentowanego mu przez program menu wszystkich czcionek zainstalowanych w systemie - jego systemie - to efekt, który zobaczą odbiorcy strony, zależeć będzie od tego, czy przypadkowo również mają zainstalowaną tę czcionkę w swoich komputerach. A jeżeli - również przypadkowo - mają zainstalowaną czcionkę o takiej samej nazwie, ale w rzeczywistości zupełnie innym kroju?

No dobrze, ale autor strony może być świadomy problemu i stosować w <FONT FACE=...> tylko najpopularniejsze czcionki. Ot, taką np. czcionkę Arial. Przecież mają ją wszyscy... Nieprawda! W Unixie nie ma czcionki Arial - analogiczna czcionka rzeczywiście istnieje, ale nazywa się Helvetica. Na Macintoshu - jeszcze inaczej. Ale nawet gdy ograniczymy się do samych Windows, <FONT FACE=...> potrafi nielicho "namieszać". Oto mamy np. stronę, na której użyta została konstrukcja <FONT FACE="Arial">. I oto, co się dzieje? Oglądana pod Windows 95 strona wygląda dobrze - za to w Windows 3.1 za nic nie da się uzyskać na niej polskich liter. Zamiast nich widać "robaczki". Po prostu sposób kodowania czcionek w obydwu wersjach Windows jest różny, i o ile w Windows 95 polskie litery "mieszczą się" w normalnej czcionce Arial, o tyle w Windows 3.1 czcionka o nazwie Arial jest czcionką bez polskich liter, a polskie litery zawiera inna czcionka, o nazwie Arial CE. Ot i kłopot... Jeżeli już zatem koniecznie upieramy się przy stosowaniu <FONT FACE=...>, to trzeba wiedzieć, jak nazywa się interesująca nas czcionka we wszystkich najpopularniejszych systemach operacyjnych (rzecz jasna, że możemy stosować tylko czcionki znajdujące się w standardowej instalacji każdego z tych systemów), i wszystkie te nazwy wymienić w poleceniu, pamiętając jeszcze o zachowaniu odpowiedniej kolejności (tzn. np. najpierw Arial CE, a potem Arial - aby uniknąć problemu z polskimi literami w Windows 3.1). Najlepiej jednak zapomnieć o tym, że coś takiego jak <FONT FACE=...> w ogóle istnieje i trzymać się odeń z daleka.

<FONT FACE=...> i jemu podobne rozszerzenia, "wizualne" narzędzia do tworzenia stron, pisanie "pod" określoną przeglądarkę - to wszystko rozwiązania rodem z korporacyjnych Intranetów, gdzie faktycznie wszyscy potencjalni czytelnicy strony dysponują tym samym, ujednoliconym w obrębie firmy oprogramowaniem, i strona w istocie wygląda u każdego tak samo. Trzeba sobie jasno zdać sprawę z faktu, że to przede wszystkim z myślą właśnie o rynku intranetowym produkują swoje przeglądarki, serwery WWW, "kreatory" stron i temu podobne programy wielcy producenci tacy jak Microsoft czy Netscape. Przedstawiciele tych firm dają to zresztą jasno do zrozumienia podczas wszelkich prezentacji swoich wyrobów przy okazji różnych targów i konferencji: są one przedstawiane w pierwszym rzędzie jako narzędzia intranetowe; Internet, jeżeli jest w ogóle wspomniany, znajduje się na dalszym planie. Jednak miejsce tego, co intranetowe, jest w obrębie Intranetu, a nie w sieci globalnej. Tych dwu obszarów zastosowań nie należy mylić.

Odnosi się to w szczególności do innego, bardzo modnego ostatnio w pewnych kręgach pomysłu Microsoftu - ActiveX. To także pomysł typowo intranetowy, którego nie należy przenosić do "dużego" Internetu. Microsoft zachwala ActiveX jako konkurencję dla Javy; w przeciwieństwie jednak do tej ostatniej, która jest (pierwszym w historii zresztą) językiem programowania niezależnym od komputera, na którym program jest uruchamiany - w związku z czym jej applety mogą być wykonywane w każdym środowisku, dla którego istnieje "rozumiejąca" Javę przeglądarka - kontrolki ActiveX są zwykłymi fragmentami programu wykonywalnego pod Windows. Rzecz jasna zatem, że strona WWW z kontrolkami ActiveX może być prawidłowo odczytana tylko przez użytkowników jednego typu komputera, i jednego systemu operacyjnego. Znowu mamy "powrót do czasów sprzed WWW"... Że nie wspomnę już o bezpieczeństwie tego rozwiązania - o ile Java projektowana była od razu z uwzględnieniem zagadnień bezpieczeństwa, i pewne potencjalnie groźne operacje po prostu w tym języku w ogóle nie istnieją (choć i tak ma on swoje "dziury"), o tyle kontrolka ActiveX nie ma żadnych ograniczeń i może zrobić literalnie wszystko - istnieje np. kontrolka formatująca dysk użytkownikowi, który miał nieszczęście załadować zawierającą ją stronę. Dlatego wielu użytkowników WWW wyłącza w swoich przeglądarkach opcję ładowania kontrolek ActiveX (a na wszelki wypadek, także i appletów Javy) - tym bardziej więc nie ma sensu projektowanie zawierających je stron, bo nawet ci użytkownicy, którzy mają takie możliwości, w takiej sytuacji również ich nie zobaczą.

Na zakończenie nie sposób pominąć jeszcze jednego tematu. Był on już wprawdzie poruszany na łamach naszego miesięcznika, ale gdy mówimy o źle zaprojektowanych stronach WWW, nie sposób nie podkreślić jeszcze raz, że polskie litery na stronach WWW zapisujemy wg standardu ISO 8859-2. Standard ten potrafią odczytać nowe wersje przeglądarek (Netscape i MSIE od 3.0 wzwyż) pracujące we wszystkich środowiskach, podczas gdy strony zapisywane w kodzie Windows (określanym przez część użytkowników pogardliwie jako "cep" - od jego oznaczenia CP 1250) - tylko przeglądarki pod Windows. Stosowanie na stronach "cepa" wywołuje czasem niezamierzone efekty komiczne: swego czasu np. wszyscy użytkownicy przeglądarek unixowych zanosili się śmiechem na widok strony Microsoftu przygotowanej dla kampanii promocyjnej Start 32. Jej hasło reklamowe, pozbawione na skutek niezgodności kodów wszystkich liter "ś", widniało bowiem w przeglądarce jako "Kto by pomylał - my pomylelimy". Nie było to chyba zbyt dobrą reklamą...

Przy tym polskie litery powinny być zapisywane na stronach wprost, jako znaki o odpowiednich kodach, a nie przy użyciu "HTML entities", czyli specjalnych zapisów zaczynających się od znaku &. Np. literka "ć" powinna być po prostu literką "ć", a nie "&#230;" - użycie tego drugiego zapisu potrafi uniemożliwić działanie mechanizmu przekodowywania znaków z kodu ISO w przeglądarce (a na pewno uniemożliwi działanie skryptów przekodowujących "w locie" na serwerze WWW, czy wszelkich programów do przekodowywania plików off-line). Zdarza się też, że polskie litery bywają zapisywane przy pomocy nazw znaków. Jest to postępowanie dość karkołomne, ponieważ w HTML-u zdefiniowane są wyłącznie nazwy znaków z tabeli ISO 8859-1, tak więc polskie litery zapisywać trzeba jako nazwy znaków o takich samych kodach z tej tabeli - w takiej "konwencji" np. "ć" byłoby zapisane jako "&aelig;", czyli nazwa oznaczająca skandynawski dwuznak "ae", mający w ISO 8859-1 taki sam kod, jak "ć" w ISO 8859-2. Zapis taki jest nie tylko niezgodny ze standardem HTML, ale też po prostu bezsensowny - sugeruje bowiem obecność na stronie zupełnie innego znaku niż w rzeczywistości. Co prawda, do tej pory, ze względu na przyjęty sposób kodowania czcionek, we wszystkich przeglądarkach to działało, ale nie ma żadnej gwarancji, że to się nie zmieni w przyszłości - wielcy producenci przeglądarek zapowiadają już przejście na zapis znaków w standardzie Unicode, gdzie takie zapisy będą interpretowane prawidłowo - tzn. wyświetlane będą znaki z pierwszego zestawu ISO. Dodać też trzeba, że nie wszystkie przeglądarki poprawnie interpretują pełny zestaw zdefiniowanych w HTML-u nazw (jak zachowuje się nasza przeglądarka, można sprawdzić zaglądając na stronę o adresie http://www.browsercaps.com/config/Cv/Generated/test-accentedentities.html) - zaś nazwy nie obsługiwane przez daną przeglądarkę "wyrzucane" są na ekran w sposób jawny w miejscu żądanej litery, co czyni stronę całkowicie nieczytelną. Jak widać, właściwie wszystko przemawia przeciwko używaniu tej formy zapisu polskich liter.

Niestety, kodowanie polskich liter wg ISO 8859-2 ma również swoją negatywną stronę: będzie ono sprawiać kłopoty starszym wersjom przeglądarek pracującym w systemach innych niż Unix, gdyż nie są one wyposażone w możliwość automatycznego przekodowywania znaków z kodu ISO na używany lokalnie w danym systemie. Nie jest to jednak de facto argument przeciwko kodowaniu ISO, gdyż analogiczne problemy, tylko w innych systemach operacyjnych, sprawiać będzie użycie każdego innego kodowania. Jedynym wyjściem - dopóki są jeszcze w użyciu stare przeglądarki - jest skorzystanie z pomocy skryptu przekodowującego zainstalowanego na serwerze WWW, który pozwala przedstawić strony w kilku różnych wersjach kodowania, przekształcając je "w locie" do postaci żądanej przez użytkownika. Jeżeli na naszym serwerze WWW nie możemy zainstalować takiego skryptu (bo np. nie jest to nasz własny serwer, lecz providera, który się na to nie godzi), możliwe jest czasami skorzystanie z pośrednictwa skryptu pracującego "na trzeciego", na obcym serwerze. Najlepszym źródłem informacji na temat skryptów przekodowujących, jak i w ogóle problemu polskich liter w WWW, jest oczywiście jak zwykle Polska Strona Ogonkowa (http://www.agh.edu.pl/ogonki/).

Powyższy tekst oparłem na rzeczywistych problemach i błędach, na jakie natrafiałem przeglądając polskie strony WWW. Smutne jest to, że wiele ze stron, na których je napotykałem, było witrynami providerów Internetu! Czyżby tak mało wiedzieli oni na temat sieci, którą mają ambicję zawodowo się zajmować? Mam nadzieję, że przedstawione w tym tekście uwagi pomogą Czytelnikom w konstruowaniu lepszych i "przyjaźniejszych" dla wszystkich stron WWW, a w każdym razie uczulą na problemy, jakie mogą być z tym związane. Byłoby to niewątpliwie z korzyścią dla całej polskiej sieci.

Powrót do wykazu artykułów o Internecie

Statystyka